Accessibility Testing for Engineers

a11y-testing.md

Accessibility Testing for Engineers

Ahoy, engineering team!

I'd like to share some best practices around accessibility testing: what to look for, how to test it, how to balance the work with other priorities.

The important things to remember are that:

1. Accessibility is about access for disabled people. Marginalizing their experience forever is continuous discrimination, full stop.
2. The best time to start is now. The earlier you address it the better, but you can always iterate as you move forward.

Accessibility success is more about culture than compliance!

WCAG - the Web Content Accessibility Guidelines

Speaking of compliance: WCAG 2.2 is the current standard for accessibilty acceptance criteria. Many laws around the globe point to WCAG as a way to implement things (like Section 508 for the US Gov’t).

Some of it can be automated (estimates range from 30-50% or higher of WCAG SC's by volume on a page), while the rest needs to be manually validated by humans.

There are 3 levels for Success Criteria:

• Level A - an absolute must
• Level AA - also a must
• Level AAA - most often a “nice to have” and not requirements

While WCAG is helpful, it is also a starting point. Create an Accessible User Experience that's pleasant to use your goal by testing often and considering disabled peoples’ experiences in the process.

There haven’t historically been many examples of success. I created A11yWins to sweeten the atmosphere but it was impossible to keep going. Aim for progress over perfection!

ARIA

ARIA stands for Accessible Rich Internet Applications (currently verison 1.2). It’s a standard set of attributes for plumbing accessibility information into HTML.

The attributes consist of roles, states, and properties like role="button", aria-hidden="true", and aria-describedby="someId".

⚠️ Use with caution, as it’s easy to get wrong and forget to test with Assistive Tech, where the impacts are! ⚠️

I usually have the ARIA spec open in a tab when I use it to make sure I got it right. You can also check A11ysupport.io for any data on support. The ARIA Authoring Practices Guide is also a helpful resource for understanding conventions, although the patterns aren’t typically ready for production.

My testing workflow

Here are the steps I typically follow:

1. Test with the keyboard, starting with the Tab key. Can you reach, operate, and see every focused interactive control?
2. Use browser DevTools and extensions. Chrome Axe extension and Accessibility DevTools inspector are my faves.
3. Zoom in to at least 200% (and larger). Does content reflow into a single column? Does anything break when zoomed in?
4. Fire up a screen reader and follow a cheat sheet. VoiceOver on Mac with Safari and NVDA with Firefox or Chrome on Windows.
5. Test visual characteristics like motion and color contrast. Recommend a design checklist for your designer colleagues.
6. Make note of any missing transcripts, captions, and other alternative media content.

Automation could be a future session, as there are other tools (like Testing Library) and techniques that can bake in accessibility!

One last tip that could factor in to testing: the WebAIM Screen Reader Surveys have info on commonly used screen reader and browser combos. You can pair this with your own site analytics to understand what to prioritize.

The main stuff

Here are my other recommendations based on observations of our engineering team practices, what I’ve seen in the codebase, and your questions:

1. Headings.

   • Headings are a critical function for people using Assistive Technology (AT). They are also helpful for SEO and reader modes.
   • Use h1-h6 headings in order to create an overall page structure in HTML. Think of an outline with Roman numerals, etc. in Microsoft Word.
   • Style headings with CSS classes so you can choose the right heading level for the content, not the way it looks!
   • I like the Web Developer Toolbar, Accessibility Insights and VoiceOver Rotor for visualizing headings.

2. Landmarks & semantic structure.

   • Similar to headings, landmark elements and ARIA roles create a structure for navigating a webpage with AT: things like <main>, [role="search"], <section aria-label="Some section">, etc.
   • Other HTML structures are useful for accessibility as well, like unordered/ordered lists, fieldsets, and definition lists.
   • Accessibility Insights is great for landmark debugging as well.
   • Landmarks are technically a best practice in WCAG but using semantic HTML to indicate relationships in HTML markup is a requirement.

3. Links and buttons.

   • We have elements built-in to the web platform for navigating (the <a href=""> tag!) and toggling things (the <button> tag!).
   • These are great examples of how using default HTML can minimize your effort to recreate features.
   • Links with href attributes and buttons are focusable by default. You can typically do less work by using these elements instead of slapping click events on non-interactive elements like DIVs or SPANs.
   • Try to use links for navigating and buttons for other interactive functions in apps.
   • Here’s a whole article I wrote on Links and Buttons.

4. Interactive components.

   • Some of my favorite parts, especially the mechanics of interactive JavaScript with focus management and ARIA live regions.
   • Focus needs to be moved into new content like modals, menus, and with client-side routing.
   • Ensure focus is visible and not lost behind layers or in inactive components (like hidden menus).
   • Live regions can announce changes in content without moving focus, helpful for Auto-save functions, alerts and as a component of client-side routing.
   • TabIndex is one tool for making something focusable or not. It also requires interactive ARIA roles and other attributes to be present for screen reader access.
   • These aspects are highly testable, especially keyboard accessibility.