Checklist, Accessibility swarm

We’ll take you step by step through all the checks required to complete an accessibility swarm, to test a component or feature for accessibility. As a miminum complete this checklist for web products to be considered acceptable for a live release.

Following the same steps every time, ensures that everyone is testing using the same methods and using the most common techniques. The steps also enable anyone, in any role, to take part in an accessibility swarm for the first time.

As you go, make notes of any bugs you find.

1) Accessibility acceptance criteria

Accessibility acceptance criteria defines conditions for factors:

• That play a key part in a component or feature being accessible
• That are at high risk of introducing an accessibility issue

Check all accessibility acceptance criteria is met.

For more information see the guide how to write accessibility acceptance criteria.

2) Screen reader UX

Accessible design process includes documenting the user experience (UX) for screen reader users. This also helps in achieving a good UX for other types of assistive technology users.

Review the screen reader UX by inspecting the code. Note, this check should be carried out by a designer (as they are responsible for the user experience) alongside an engineer.

1. Open the documented screen reader UX to review against.
2. In a web browser, inspect the code for the component or feature. Not sure how, ask an engineer to show you.
3. Check that the code matches what is documented in the screen reader UX. Within the HTML you might see a number of additional div or span elements, these elements are mainly used to achieve layout and visual styling with CSS. By default, no semantics will be announced from either div or span elements.

Note, reviewing the screen reader UX by inspecting the code, is one step in the review process. This should never replace reviewing the user experience with a range of screen readers and other assistive technologies.

For more information see the guide how to document the screen reader user experience.

3) Visual affordance

Affordances or visual clues are used to communicate meaning and expectations, such as those that help users understand what will happen when they perform an action. Always use a consistent approach.

Review all visual affordances, such as:

1. Does an elements visual styling communicate the correct meaning? For example, do headings look like headings?
2. Does an elements visual styling communicate the correct expectations? For example, do links look like links?
3. Does any dynamic content or in-page interactions provide hints to their behaviour? For example, a 'More' button with a downwards arrow helps users understand upon activation, associated content will expand downwards.
4. Is the visual styling of an element consistent with that in other components or features?
5. Do interactive elements have consistent hover and focus styling?

More on visual affordance

Visual styling should communicate the semantic meaning of HTML elements. For example, interactive elements should look like interactive elements. If you don't have perceived affordance this may cause issues for some users. For example, those using speech recognition assistive technology, rely on being able to visually interpret meaning and behaviour to know what they can interact with and how, via speech.

In a well designed visual user experience, a sighted user should be able to identify elements and their semantic roles along with any expected behaviours by simply looking at them. For example, when viewing an article, you can usually identify text that has a semantic role of heading because the font size of it is larger than that of surrounding text.

4) Colour contrast

All colours should meet a level of 4.5:1 or higher. Use a tool such as contrast checker to perform this check.

5) Colour blindness

Colour blindness is a vision deficiency. You see colours differently to most people. You may find it hard to tell the difference between colours or you may have no colour perception at all.

It's possible to emulate vision colour deficiency with a browser tool. Use either Chrome or Firefox to perform this check.

• With the browser tool, select each of the available colour blindness options in turn.
• Are all core elements in the feature perceivable?
• Check that no meaning or information is lost (when colours can't be distingusihed).
• For example, in each emulation, with sight only, can you distingusih link text from non-linking text? And are the associated affordances for hover and focus perceivable?

Colour blindness options:

• Protanopia (no red)
• Deuteranopia (no green)
• Tritanopia (no blue)
• Achromatopsia (no colour)

Chrome

1. In the Chrome toolbar, open 'View', under 'Developer' select 'Developer tools'.
2. Within the 'Developer tools', open the 'Customize and control DevTools' menu (three dots), under 'More tools', select 'Rendering'.
3. In the 'Rendering' tab, under 'Emulate vision deficiencies' you will see the colour blindness options.

Firefox

1. In the Firefox toolbar, open 'Tools', under 'Browser tools' select 'Web developer tools'.
2. Within the 'Web developer tools', select the 'Accessiblity' tab.
3. In the 'Accessibiity' tab, under 'Simulate' you will see the colour blindness options.

6) Customised colours in Firefox

Customised colours can make content easier to read by using a user's preferred colours. We will use a Firefox preference to perform this check.

Follow the testing steps for customised colours in Firefox.

7) High contrast mode on Windows

High contrast mode is a Windows setting, that makes content easier to see by using distinct colours.

Follow the testing steps for high contrast mode on Windows.

15) Test with assistive technology

Check that the user experience is as expected with assistive technology, and that no bugs are present.

Follow the testing steps for all supported assistive technology.

For more information see the guide testing with assistive technology. Note, an accessiblity swarm should not be the first time a component or feature is checked with assistive technology, see our development approach for accessible front-end code.

Back to top