All Topics
Accessible Naming & Screen Reader Concerns
Testing an ARIA Solution

Testing a Given ARIA Solution

It’s too easy to get ARIA wrong, as most developers have an easier time using attributes than they do testing. We don’t want to rely on QA so heavily that they’re looking out for specific ARIA attributes (even if you have QA), because the feedback cycle would be so unnecessarily long. For that reason and more, it’s important to test solutions yourself early and often.

Here are some tips on how to test a given ARIA solution (after you’ve exhausted every default HTML option available):

  1. Compare your site’s analytics to the WebAIM screen reader surveys (opens in a new tab) to know what screen reader and browser combinations people actually use. This can help you prioritize.

You can also look to:

  1. People who use screen readers regularly. We’ll talk about this more in organizational skill building.
  2. Check A11ySupport.io (opens in a new tab) for specific attribute support.
  3. The ARIA Authoring Practices might have some suggestions, although these are not production ready.
  4. Snoop around issue trackers for the major repos: NVDA (opens in a new tab), WAI-ARIA (opens in a new tab), WCAG (opens in a new tab), WebKit and Safari (opens in a new tab), and more.)

Remember that screen readers aren’t the only thing in accessibility

Developers often want to solve things with attributes and markup, many of which will impact screen reader users. Just remember that screen readers aren’t the only piece of accessibility. You also need to remember and test keyboard support, visual contrast, reflow and zoom, navigating by voice (which also leverages semantic HTML), and more.

Skip links come to mind:

”Why would skip links need to be visible if they’re only for screen reader users?”

Well, skip links are for everyone who uses a keyboard. Many people need to see them, and they need to work in screen readers, too.

There are many areas of accessibility that we have to address among other web development concerns. So when you’re prioritizing work items of various sizes, keep diverse user groups and the accessibility impact of issues in mind.

The Accessibility TreeVisual and Non-Visual Experience