After a few weeks off, the frequent11y newsletter has returned!

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:

1. 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.
2. 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.
3. 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:

1. A reminder that px doesn’t actually map to hardware pixels, but it’s the most concrete measurement we have.
2. 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).
3. 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.
4. 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.

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.