Bruce Lawson's personal site

• TikTok’s In-App Browser Reportedly Capable of Monitoring Anything You Type – “TikTok’s custom in-app browser on iOS reportedly injects JavaScript code into external websites that allows TikTok to monitor “all keyboard inputs and taps” while a user is interacting with a given website” – IABs are a boil on the bum of the Web.
• Let websites framebust out of native apps – “When a native app embeds a website via a webview, the native app has control over that page. Yes, even if it’s on a domain that the native app doesn’t control (!). This means the native app can inject whatever JavaScript it likes into any website that’s viewed in the webview”
• The point of a dashboard isn’t to use a dashboard – “A dashboard isn’t there to be used. It is there to prove that the data are easily accessible, comparable, and trackable. Only once that is done can they be actionable. Trapped data is useless data.” opines Uncle Tezza.
• New macOS 12.5.1 and iOS 15.6.1 updates patch “actively exploited�� vulnerabilities “CVE-2022-32893, is a WebKit bug that allows for arbitrary code execution via “maliciously crafted web content” – update your iOS. Because of the #appleBrowserBan, every browser on iThings is compromised, because Apple requires them all to use its WebKit.
• Facebook gave police their private data. Now, this duo face abortion charges – “Private messages discussing how to obtain abortion pills were given to police by Facebook.��
• Browsers Are Back in the Antitrust Hot Seat – “Google and Apple control more than 80% of market through Chrome and Safari, raising questions among regulators and competitors” (WSJ)

(Last Updated on 4 February 2023)

My Work Bezzie “Stinky” Taylar Bouwmeester and I take you on a wild, roller-coaster ride through the magical world of desktop screen readers. Who uses them? How they can help if developers use semantic HTML? How you can test your work with a desktop screenreader? (Parental discretion advised).

Last week I observed a blind screen reader user attempting to complete a legal document that had been emailed to them via DocuSign. This is a service that takes a PDF document, and turns it into a web page for a user to fill in and put an electronic signature to. The user struggled to complete a form because none of the fields had data labels, so whereas I could see the form said “Name”, “Address”, “Phone number”, “I accept the terms and conditions”, the blind user just heard “input, required. checkbox, required”.

Ordinarily, I’d dismiss the product as inaccessible, but DocuSign’s accessibility statement says “DocuSign’s eSignature Signing Experience conforms to and continually tests for GovernmentSection 508 and WCAG 2.1 Level AA compliance. These products are accessible to our clients’ customers by supporting Common screen readers” and had been audited by The Paciello Group, whom I trust.

So I set about experimenting by signing up for a free trial and authoring a test document, using Google Docs and exporting as a PDF. I then imported this into DocuSign and began adding fields to it. I noticed that each input has a set of properties (required, optional etc) and one of these is ‘Data Label’. Aha! HTML fields have a <label> associated with them (or should do), so I duplicated the text and sent the form to my Work Bezzie, Stinky Taylar, to test.

No joy. The labels were not announced. (It seems that the ‘data label’ field actually becomes a column header in the management report screen.) So I set about adding text into the other fields, and through trial and error discovered how to force the front-end to have audible data labels:

• Text fields should have the visible label duplicated in the ‘tooltip’ field.
• Radio buttons and checkboxes: type the question (eg, what would be the <legend>) into the ‘group tooltip’ field.
• Each individual checkbox or radio button’s label should be entered into the “checkbox/ radio button value” field.

I think DocuSign is missing a trick here. Given the importance of input labels for screen readers, a DocuSign author should be prompted for this information, with an explanation of why it’s needed. I don’t think it would be too hard to find the text immediately preceeding the field (or immediately following it on the same line, in the case of radio/ checkboxes) and prefilling the prompt, as that’s likely to be the relevant label. Why go to all the effort to make an accessible product, then make it so easy for your customers to get it wrong?

Another niggle: on the front end, there is an invisible link that is visually revealed when tabbed to, and says “Press enter or use the screen reader to access your document”. However, the tester I observed had navigated directly to the PDF document via headings, and hadn’t tabbed to the hidden link. The ‘screenreader mode’ seemed visually identical to the default ‘hunt for help, cripples!” mode, so why not just have the accessible mode as the default?

All in all, it’s a good product, let down by poor usability and a ‘bolt-on’ approach. And, as we all know, built-in beats bolt-on. Bigly.

• Northern Bloke talking about CSS on YouTube link of the month: Be the browser’s mentor, not its micromanager – Andy Bell on how we can hint the browser, rather than micromanage it by leaning into progressive enhancement, CSS layout, fluid type & space and modern CSS capabilities to build resilient front-ends that look great for everyone, regardless of their device, connection speed or context
• Focus management still matters – Sarah Higley takes us on a magical mystery tour of sequential-focus-navigation-starting-point
• Date and Time Pickers for All “the release of the React Aria and React Spectrum date and time picker components� – a full suite of fully featured components and hooks including calendars, date and time fields, and range pickers, all with a focus on internationalization and accessibility. It also includes @internationalized/date, a brand new framework-agnostic library for locale-aware date and time manipulation �� All of our date and time picker components have been tested across desktop and mobile devices, and with many different input methods including mouse, touch, and keyboard. We have worked hard to ensure screen reader announcements are clear and consistent.
• Replace the outline algorithm with one based on heading levels – The HTML spec now reflects what actually happens in browsers, rather than what we wish happens. The outlining algorithm allowed what would be effectively a generic heading element, with a level corresponding to its nesting in sectioning elements. But no browser implemented it, so the spec reverts to reality so developers didn’t mistakenly believe it is possible.
• What is the best way to mark up an exclusive button group? by Lea Verou
• Perceived affordances and the functionality mismatch – a companion piece by Léonie Watson
• JSX in the browser by Chris Ferdinandi
• An Accessibility-First Approach To Chart Visual Design
• Bunny Fonts “is an open-source, privacy-first web font platform designed to put privacy back into the internet��with a zero-tracking and no-logging policy”, so an alternative to Google Fonts
• Font Subsetting Strategies: Content-Based vs Alphabetical – “Font subsetting allows you to split a font’s characters (letters, numbers, symbols, etc.) into separate files so your visitors only download what they need. There are two main subsetting strategies that have different advantages depending on the type of site you’re building.”
• Dragon versions and meeting accessibility guidelines “Dragon responds to the visible text label, the accessible name and the “name” attribute �� Microsoft are in the process of buying Nuance, and it’s a measure of how unpopular Nuance is that most people think that a Microsoft takeover would be a very good thing.”
• The Surprising Truth About Pixels and Accessibility – “Should I use pixels or ems/rems?!��
  by Josh W. Comeau
• Android accessibility: roles and TalkBack by Graeme Coleman (Tetralogical)
• Three Steps To Start Practicing Inclusive Product Development – “Product teams aren’t intentionally designing products that exclude users, but a lack of team diversity, specialized knowledge and access to feedback from people with disabilities results in users being left behind.”
• Court OKs billion-dollar Play Store gouging suit against Google
• The hidden history of screen readers – “For decades, blind programmers have been creating the tools their community needs”
• Introducing: Emoji Kitchen – Jennifer Daniel, the chair of the Unicode Consortium’s emoji subcommittee, asks “How can we reconcile the rapid ever changing way we communicate online with the formal methodical process of a standards body that digitizes written languages?” and introduces the Poopnado emoji

(Last Updated on 8 December 2022)