month11y issue 38

Welcome to your monthly frequent11y newsletter, brought to you by @ChrisBAshton. I hope you enjoy these a11y articles I’ve collated and summarised for you. (Psst – if you find these emails too long, consider switching to shorter, more frequent updates). Now on with the show!

A Practical Approach to Automated Accessibility

Mark Steadman writes a mini series on automated accessibility. In this introductory article, Mark introduces his three-step plan for introducing automated accessibility checks into your pipeline:

Phase 1: Linting
- Linting is a quick and easy step for catching issues by statically analysing source code.
- In his subsequent article, Mark recommends axe Accessibility Linter that enforces around 30 accessibility rules. He also recommends webhint and HTML Validate.
- Mark claims that linting is expected to catch around 20-25% of accessibility issues: basic ones such as images missing the alt attribute.
Phase 2: Automated Accessibility Libraries
- You can add a library such as axe-core or pa11y into your pipeline, configuring it with a list of routes to visit. The library will perform some general accessibility checks on your application at runtime, as opposed to just looking at the source code. This can catch contextual issues such as a piece of text having poor colour contrast against its background.
- In Mark’s accompanying article, Automated Accessibility Part 2: Mobile Web Testing, Mark elaborates on how to configure these libraries to run against responsive views of your application. For example, you can run pa11y against the ‘mobile’ view of your application by pairing it with a browser emulator tool such as Cypress.
Phase 3: Accessibility Regression
- Mark’s final phase of automation is to create “regression tests”. These are specific, accessibility-focused unit tests, written in code. For example, you can write a test that checks that aria-expanded is being properly set every time a user clicks on an expand/collapse section.
- Mark builds on this in his article, Automated Accessibility Part 3: Regression Tests, which builds on the Cypress automation of the previous article and shows example code for interacting with the page and asserting conditions.

There are a lot of different testing approaches and tools out there, so having a three phase plan for testing is a useful way to make the process less daunting.

The Surprising Truth About Pixels and Accessibility

Josh Comeau dispels the myths around using px, rem and em in your designs. He introduces these with no assumed knowledge, gradually explaining when to use each one, using inline interactive examples to aid learning. It’s really worth checking out.

My takeaways:

A reminder that px doesn’t actually map to hardware pixels, but it’s the most concrete measurement we have.
There are two main ways a user can make the text on their screen bigger: “zooming” (⌘ + + on MacOS, ctrl + + on Windows/Linux), or “font scaling” (changing the browser’s default font size).
When deciding whether to use pixels or rems, ask “Should this value scale up as the user increases their browser’s default font size?” If yes, use rem, if no, use px. So you’d use rem for text, but you might use px for borders or padding.
Josh recommends using rem over em due to em‘s compounding issues (making it hard to predict what size an element actually ends up being). An exception is for the margins of headings and paragraphs, for which Josh uses em.

It gets more complicated: should you use px or rem in your media queries? The answer is rem. If a user has increased their default font size, the available space is reduced, so they’re more likely to need your ‘mobile’ view. Using a rem-based media query such as @media (min-width: 50rem) means a user who increases their default text size will need a bigger screen to get the non-mobile styles. (If a user sets their default text size to 32px, this is “double the standard text size” and means that “50rem will now be equal to 1600px instead of 800px”).

Josh goes into more examples. Be careful when using rem to define button sizes, as declaring something like width: 15rem could mean the button becomes too large for its container. You can combine this with max-width: 100% to prevent the overspill. Similarly, use min-height as opposed to height.

Josh ends the article by discussing the numerous ways you can manage your rem size to px conversions, e.g. through defining a 62.5% base font size, using calc, or leveraging CSS variables.

Face-off: Should kit colours be catered to colour-blind fans?

Anyone who’s ever played FIFA on a game console will at some point have ended up playing a game where both sides have really similar looking kits. It becomes difficult to know who you can pass to, and makes the game less enjoyable.

This is an issue faced by the large portion of sports viewers who are colour blind, and consequently, the 2027 Rugby World Cup will be the first that bans red-green kit clashes.

This article from RugbyWorld.com shares an opinion-piece from two enthusiasts. The first is in favour of the move, for obvious reasons. The latter is against it, favouring the idea of a ‘home kit’ and an ‘alternative white kit’, which would solve the problem in a different way. He argues that “turning out in the colour of your nation matters”.

I think the announcement is a positive move for accessibility, but it’s interesting to think about the different ways the issue can be tackled.

Accessible front-end components: claims vs reality

Hidde de Vries shares his tips for finding accessible components, warning that many components that claim to be “accessible” actually aren’t. Hidde’s checklist:

How did they test? A component’s website should ideally explain how a component was tested, e.g. perhaps only automated tests have been run and you should do some further testing before choosing it. Try to find specifics around exactly what version of WCAG they claim to be valid against, for example.
Who did they test with? Accessibility isn’t just about technology, it’s about making sure a pattern works for people with disabilities. Did the developers specifically include people with disabilities, in their testing?
Are they open about the pros and cons of their approach? It’s a good sign if the developer is open about this, as many components aren’t one-size-fits-all.
Who created them? Hidde puts extra trust in components developed by organisations that work in accessibility or work for the public good.
Look at GitHub issues – their presence could be a warning sign.
Find out about commitment – are they proactive or reactive in their component’s development?

Brief Note on Buttons, Enter, and Space

An interesting article by Adrian Roselli, sharing something I didn’t know:

A native <button> fires on key down when that key is Enter. If you hold down the Enter key, it continues to fire for as long you hold Enter (or something crashes).

A native <button> fires on key up when that key is Space. If you do not release the Space, and also press Tab to move away from the control, the control will not fire.

These can blow up once a screen reader is in play. If you run Narrator/Edge, pressing Space is the same as pressing Enter, but holding either down does not repeatedly fire the event. NVDA/Firefox and JAWS/Chrome treat Space as Enter — fires on key down and holding it down continues to fire. The Windows screen readers all intercept the event, so you cannot listen for which key was pressed in your page. VoiceOver/Safari/macOS behaves as if VO was not running, and (in my script) the keyboard events are captured.

…and that’s pretty much the whole article! There’s also an interactive example so you can try it out for yourself. The TLDR is to be careful when trying to re-implement native browser behaviour in your custom components, and consider the nuance of the different keys, to support your powerusers.

Flexbox and the Screen Reader Experience

A Webaim article that reminds us that whilst CSS flexbox can be used to change the visual order of content, it often has no bearing on how the content is consumed by a screen reader. This can lead to major accessibility issues if the intended reading order differs from the order in which it appears in the DOM.

The takeaway is to always structure information in the correct order in the DOM, then ensure that visual presentations (at all widths) convey that order. The author doesn’t want us to leave with the feeling that flexbox is “dangerous”, but that it is powerful and that screen reader testing is essential.

The Monarch could be the next big thing in Braille

A collaboration project between HumanWare and the American Printing House for the Blind (APH) has resulted in the Monarch: a “multipurpose” Braille device.

Refreshable Braille displays have existed for years, but have been expensive, slow to refresh, and fragile. A new “braille pin mechanism” created by startup Dot has been incorporated into the design: these pins are individually replaceable and are much faster to raise.

APH partnered with over 30 international organisations to create a new electronic braille standard, called eBRF. “This will provide additional functionality to Monarch users including the ability to jump page to page (with page numbers matching the print book pages numbers), and the ability for tactile graphics directly into the book file, allowing the text and graphics to display seamlessly on the page.”

The author notes that the graphical capability is “a serious leap forward”. It will now be possible for braille readers to pull up a visual of a graph, animal, letter or number shape, allowing the consumption of simple graphics. From APH.org:

The Monarch is approximately 4.5 pounds and the size of a 15-inch gaming laptop. The device features an 8-dot braille keyboard, zoom in/out buttons, direction pads, up/down arrow buttons, and a 10 line by 32 cell refreshable braille display, which is capable of rendering multiple lines of braille and tactile graphics with equidistant pins. This technology will bridge the educational gap for students along with the development of a new dynamic file type that will bring braille and graphics together in a navigable file.

The Monarch is not currently available to purchase. You can sign up to product updates on the website above.

What it’s really like to be openly disabled in an interview process:

This Medium article is written by Mal: a “multi-disciplinary designer + artist, storyteller, neurodivergent (autist + adhd); she/they”. She shares three interview experiences, two positive and one negative.

The first was for an interview last September, in which Mal received the interview questions in advance. Though she didn’t get the job, “the interview went well, I said exactly the stories I wanted to say to each question, and was only a normal level of anxious the whole time”.

The second was the interview for her current job, where she didn’t ask for the questions in advance. She realised halfway through the Zoom call that she was unable to process anything, and told the interviewers what was happening. She asked to follow up and answer the rest of the questions in an email that day. She got the job offer, and given the interview proces was so inclusive, she felt that working there would be a similar experience, so accepted.

The negative experience Mal had concerns an interview somewhere else, where Mal asked for either the questions a day or two in advance, or the opportunity to submit written responses (with a virtual follow-up meeting to meet face to face). The HR person phoned Mal out of the blue and asked her if she had anything official to send that could ‘prove’ her autism.

Mal offered to send a diagnosis assessment from her psychologist, but that it would not explain how she is at work or why she needs these specific accommodations. The HR person followed up and asked Mal to get her doctor to fill out an accommodation form.

Mal ultimately didn’t go through with it. Where Mal lives, doctors would charge around $100 for such a request. Mal would have to find a way to print the form without owning a printer, and would have to spend half an hour on hold to make an appointment, and would have to schedule an appointment that fits within her existing work schedule, and would have to explain to the GP what is needed and hope the GP fills in the form correctly. All for a form she would only use once, given its specific nature tied just to this job application. And all just to participate in the interview process.

Don’t be like this HR person.

My Thoughts on Accessibility of NFTs and Web3

Apologies if this is so last year (this post has been in my bookmarks since February 2022, and admittedly we haven’t heard much about Web3 since the rise of ChatGPT). But this article by Crystal Preston-Watson evaluates an emerging and hyped technology for its accessibility, so there’s certainly a crossover.

Crystal explains that a non-fungible token (NFT) is a unique digital asset that can be bought using blockchain technology. Crystal has a visual impairment, but is not a screen reader poweruser. So, she attempted to go through the process of creating a Coinbase wallet, buying Ethereum (ETH) and then purchasing an NFT on OpenSea, testing the end-to-end transaction from an accessibility perspective.

The first takeaway is perhaps surprising: whilst there were significant accessibility issues, Crystal didn’t encounter anything more or less accessible than the process of buying items on many other eCommerce sites right now.

There were some unique challenges, such as having to verify their identity for the Coinbase account, which requires the app taking pictures of the front and back of one’s driving license, and also taking a selfie. Crystal notes that some users would require in-person assistance, opening them up to security vulnerabilities of sensitive information.

Before using OpenSea, Crystal has to transfer ETH to a wallet. Coinbase directed them to set up a passcode/biometrics, then generated a recovery phrase (for backup wallet recovery). Coinbase prompted Crystal to either back up the phrase in the cloud, or write it down, or copy the words to the phone’s clipboard (for then storing somewhere locally). Crystal elected for the latter, but was then told the phrase would only be copied to the clipboard for one minute. This time limit was insufficient given Crystal was using a screen reader, so they were forced to use cloud storage instead.

The biggest blocker to the transaction turned out to be the utter lack of alt text on OpenSea, and then the financial burden of the ‘gas fees’. Crystal ended up not buying an NFT.

It’s easy to get caught up in the hype of a new technology – but we should do all we can to ensure disabled users aren’t left behind.

Continuing the look at new technologies…

ShatGPT

Steve Faulkner gives a frank accessibility review of the ChatGPT UI:

The chat history is not navigable using the keyboard, as the links are not focusable. It makes use of <a> markup without a href or tabindex, so is not keyboard-accessible.
The UI contains lots of unlabelled buttons, relying on icons alone to convey intent. JAWS announces them as “unlabelled button 1, unlabelled button 2, unlabelled button 3” – good luck using the interface!
Similarly, the buttons fail WCAG 1.4.11 Non-text contrast, as their contrast ratio is just 2.1:1.
The information panel describing “Reasoning/Speed” and “Conciseness” is largely hidden from screen reader users.

Steve goes on to try to ask ChatGPT how it should make the markup more accessible, and is not impressed with the result.

But I think the bigger takeaway is that this multi-billion dollar company clearly has little regard for the accessibility of its product, which seems to be a trend with hyped and emerging technologies. So frustrating.

W3C Design System

A redesigned W3C website has launched with a Design System. The design system draws inspiration from the GOV.UK design system and uses some GOV.UK-owned components such as accessible autocomplete.

DAC performed accessibility audits of the new W3C website, and their reports can be downloaded from the redesign project website.

Thanks to Derren at GDS for sharing this with me!

Whew, that was a long newsletter! Did you know that you can subscribe to smaller, more frequent updates? The dai11y, week11y and fortnight11y newsletters get exactly the same content. The choice is entirely up to you! Curated with ♥ by developer @ChrisBAshton.