fortnight11y issue 75

Your fortnightly frequent11y newsletter, brought to you by @ChrisBAshton:

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.

Did you know that you can subscribe to dai11y, week11y, fortnight11y or month11y updates! Every newsletter gets the same content; it is your choice to have short, regular emails or longer, less frequent ones. Curated with ♥ by developer @ChrisBAshton.