Testing Accsesibility for the Web
Accessibility testing for web pages is a huge field, but a lot can be tested with very little. In general, if developing for accessible pages, aim for perfect code first. If you are using semantic HTML and matching visual order to DOM order, you have gone very far. In general, screen readers should be used for testing once you have ironed out the basics of the below items.
Your page titles should accurately reflect the page the user is on, from most specific to least specific. e.g. "Contact Us - Bob's Landscaping".
Name, Role, and Value
Assistive technology will rely on three things to facilitate interaction with the user: name, role, and value. These elements can be found using the dev tools found in Chrome and other browsers under the "accessibility" tab of the elements browser. When a screen reader lands on an element, it will usually announce these three things in order.
The accessible name is what accessible technology uses to tell their users what they are focusing on. Deriving it is complex, but the name is more-or-less derived from the element's attributes in this order:
- the relevant naming attribute for the element: e.g.
altfor an image, or
labelfor a form element
- using the preceding rules for inner elements
- the inner content if the
aria-describedby should not be used as a label. Users can turn it off as it is describing information in addition to the accessible name. Accessible names are read first, followed by
While the aria-labelledby lists the ids of the labels or elements that describe the essence of an object, the aria-describedby lists the ids of the descriptions or elements providing more information that the user might need.
The ARIA role is set automatically by each element. For instance, a
button element will have a role of
img will have a role of
h1 is a
heading, etc. These can also be set manually on an element via
role, but should be avoided unless necessary.
The role defines the semantics of the element and how a user can interact with it. For example, if a button does not have a
button role, they will not be able to focus on it with all the rest of the interactive elements, nor be able to tell that they can or should interact with it.
ARIA is supposed to map directly to HTML, but now it has advanced beyond HTML and so it might not map directly. W3 has a list of all element's implicit roles[4,8], but this can also be found more easily using the dev tools. If you want to search by role first, use the periodic table of semantics.
The value can be defined by the state or current condition of the component. The value is not always present or necessary. Some of the attributes include:
aria-hidden(note that this hides the element from screen reader users. Never use this on interactive elements or elements that should be hidden from all users)
Description (interactive elements only)
Sometimes interactive elements have or can be given a description. This is additional information that is given to the user once the name, role, and value are given. This is added via
aria-describedby, which has the
id of an element that contains the description.
Testing With A Screen Reader
In this, I will be referencing VoiceOver as I am using MacOS for development.
All elements should be navigated to by using the
VO + arrow keys. This is known as "browse mode", and screen readers generally will manipulate the keyboard to operate in a way that most benefits users, which will remove some of the default keyboard behavior. This is important to do before the interactive elements, because mobile users who use a screen reader can't tab, so it is necessary to get to them using the arrow navigation.
A user should only be able to tab to interactive elements (e.g.
button, etc.). Note that this changes the mode of the screen reader to "forms mode", which gives all keyboard functionality back to what it natively expects.A
Use the rotor to ensure you can get around easily. You should be able to navigate through forms and headings easily here. If you don't see a heading or a form element in your rotor, you need to use proper semantic HTML or give your custom components the proper
When going through the elements, listen to what the screen reader says you can do and try doing that. For example, if it says "You are on a button. Press enter to press the button", you should test that pressing enter will in fact press the button.
More Assistive Technology
- Voice interaction (Dragon software, but both Windows and MacOS have it built in)
- Switch-based user interface
- Refreshable braille display
- Accessible name calculation from WCAG
- ARIA Roles
- Roles allowing name from content
- Periodic table of semantics
- Name Role and Value from W3C
- List of interactive content in HTML
- List of all elements and their roles
Last modified: 202303032155