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.
4. If the visual design includes graphical elements which provide meanning, such as an icon, check these elements have a textual alternative, if meaning isn't conveyed via associated displayed text within the same semantic element. For example, a button that contains soley a cog icon, would require a textual alternative for the icon to provide meaning, a button that contains a cog icon and the text 'Account settings', does not require a textual alternative for the icon, as meaning is conveyed from the associated text within the same button element.

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

Good colour contrast enables more people to consume our content. Colours should meet a contrast ratio of 4.5:1 or higher, this includes stand-alone graphical objects (with no associated text) that have meaning.

Use a tool such as contrast checker to perform this check.

For more information see the colour contrast guideline.

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.

8) Content resizing - Font size

Users must be able to resize content with browser settings, in this case via font size settings. When text is resized, content and layout should adapt, to provide a good user experience with the increased font size.

View the component or feature, increase the browser font size to the largest default setting and check the following:

• All text increases in size proportionally
• All other content (images, icons etc.) increases in size proportionally (and provides a good user experience with the increased size of text content)
• All content reflows as expected (and provides a good user experience with the increased text size)
• All content can be read

If working on foreign language content, and using Firefox browser, if font sizes are not respected, check advanced font settings, based on language, are specified.

For more information see the Content resizing guideline.

9) Content resizing - Zoom (Scaling)

Users must be able to resize content with browser settings, in this case via zoom. When web pages are zoomed, content and layout should adapt, to provide a good user experience at the increased scale.

View the component or feature, use browser settings to zoom to 400% and beyond and check the following:

• All text increases in scale proportionally
• All other content (images, icons etc.) increases in scale proportionally (and provides a good user experience at the increased scale)
• All content reflows as expected (and provides a good user experience at the increased scale)
• All content can be read

For more information see the Content resizing guideline.

10) Heading structure

Good heading structure enables more people to consume our content. This is particularly important to users of assistive technology, such as a screen reader, for which headings and good heading structure is essential to navigating and understanding web pages and content.

View the component or feature in the browser, view the heading structure and check the following:

• Logical - Is the heading structure logical, does it make sense? Headings should represent sections and subsections of content.
• Levels - Check each heading level 2 (H2) is a subheading of a heading level 1 (H1), and that each heading level 3 (H3) a subheading of a heading level (H2), and so forth.
• Missing - Are any heading levels missing or skipped? If viewing a component or feature in isolation, you may not have all heading levels. Headings should however, always be sequential and hierarchical, if they aren't this can cause confusion for a screen reader user; and make it harder to navigate and find content.
• Heading level 1 - Check there is no more than one heading level 1 (H1). Pages should have only one primary subject, while the HTML standard permits more than one heading level 1, this is not supported with assistive technology such as a screen reader.
• Main landmark - Check that the H1 is the first content within the main landmark, this will ensure that screen reader users who navigate via headings don’t miss content.
• Related content - Ensure headings are followed by content. A heading should always label a portion of content, they should be followed by either non-heading content such as a paragraph or time element, or the next sequential hierarchical sub-heading. For example, a H3 should not be followed directly by another H3, as it would not be labelling a portion of content.
• Presentation - Check that heading elements are not being used soley to achieve presentation. Heading elements should not be used to make text bold or larger, when there is no semantic meaning of heading for the content.
• Foreign language - If working with foreign language content, translate heading text and check each heading is an appropriate label for the portion of content which follows it.
• Isolation - If viewing a component or feature in isolation, check if the heading structure is correct for the component or features intended use within a page. Check again that the page will only include one heading level 1.

For more information on heading structure see:

• Headings guideline from BBC Mobile Accessibility Guidelines
• Heading guide from BBC Guide to Accessible HTML Documents

How to view the heading structure

Use a third party tool such as Web Developer browser extension to view the heading structure.

• View the component or feature in Chrome or Firefox browser
• Open Web Developer browser extension
• From the extension menu choose: 'Information'
• Then choose: 'View document outline'

Note, this guide takes one approach, there are other ways you could do this.

11) Automated standards check

Check for common accessiblity issues with an automation tool.

To perform this check, run a tool such as axe browser extension in Chrome or Firefox. Check best practices and web accessiblity standards (WCAG 2.2 Level AA) - See 'Rules and Issues' in the tool settings.

Always ensure this check is completed alongside other checks, finding no issues is not a direct colleration to providing a good user experienece with assistive technology. Always sense check any reported issues manually.

12) Keyboard only

View the component or feature in the browser, and check the following:

• Actionable elements - Using a keyboard only and without the use of another input method such as trackpad or mouse, check all actionable elements, such as links, buttons and form elements, are focusable, by navigating to them, by pressing the Tab key.
• Non interative elements - Check non interative elements such as headings or paragraph text, are not focusable.
• Control - Check all actionable elements can be controlled using a keyboard only. For example, check links can be actioned with the enter key, and buttons can be actioned with both the enter key and spacebar.
• Focus visible - When an element has focus, it should be visible. If you can't see where focus has moved to, this is a issue.
• Logical - The focus order, also sometimes referred to as the tab order due to the use of the tab key to move focus, should be logical. When you press the Tab key, you should be able to anticipate the order in which you will move through actionable elements in a component or feature.
• Order - Generally the tab order should move from left to right, as you work your way down, there will be some exceptions to this when layout or user interface best practices dictate, though these should be few and far inbetweeen.
• Focus indicator - The focused element, and the styling that indicates focus, should be fully visible (AAA). Generally browser default styling that indicates focus (such as a blue outline) does not pass guidelines. The BBC uses a two-color (double ring) focus indicator solution, or a variation on this theme that is context specific.
• Touch - If specified, focus indicators can be shown only when a keyboard is used. In this case, check using a touch device, that focus indicators are not visible.
• Attaching focus to non actionable elements - On occasion this will be required, if so, check using a screen reader, that newly focused content is announced and you can navigate onwards.
• Interactions provide a good user experience - It’s important to carefully consider if focus needs to be moved on the users behalf after an in-page interaction. Check interactions provide a good user experience. For example, if a ‘Show more updates’ button is activated and new content is inserted above the button, by default focus would remain on the button after activation, this would be a frustrating experience for keyboard only users, who would then have to identify the new content and navigate to it. In this example, upon activation of the button, focus should be moved on the users behalf, to the new content, and a visible focus indicator applied.

13) No CSS

Semantic HTML is the foundation of accessible user experience on the web. When HTML is viewed in the browser without styling, this is referred to as the ‘no CSS’ experience, and this can be presented to users at times; in which case core content should be accessible and readable.

Follow the testing steps for no CSS.

14) No JavaScript

The no JS (JavaScript) experience isn't an accessibility concern, though it often gets thrown into this bucket, to ensure this hasn't been forgotten about check it now.

When HTML and CSS are viewed in the browser, and JavaScript is missing, this is referred to as the ‘no JS’ experience, and this can be presented to users at times; in which case core content should be functional. For example, when JavaScript is missing for content such as a video player, which uses JavaScript to play the video, users should instead be presented with information about why the video isn’t available and / or alternative content such as a transcript.

Turn JavaScript off, then view the component and check the following:

• Missing - Is content or functionality missing? If so, is the core purpose of the component or feature still fullfilled?
• Not equivalent - If the content or functionality isn't equivalent to that viewed with JS, does the component or feature still make sense?
• Functional - Is information provided about why content isn’t available and / or alternative content available?

JavaScript

JavaScript can be used to enhance the semantic HTML and CSS foundation of accessible web pages, enabling greater interactivity and adding dynamic behaviour to experiences on the web. Web pages should be built to work in a progressive manner, ensuring a functional experience without JavaScript.

For more information see the progressive functionality guideline.

How to turn Javascript off

Some browsers have built in settings which enable you to easily turn off / disable JavaScript. With browsers that don’t offer these settings, you can use a third party tool.

Chrome

• Built in setting: In the 'Chrome' menu go to 'Settings', then under 'Privacy and security', choose 'Site settings', under 'Content' choose 'JavaScript', then select 'Don't allow sites to use JavaScript'.
• Third party tool: Open Web Developer browser extension and choose: 'Disable', then 'Disable JavaScript'.

Firefox

• Built in setting: Go to 'Tools', 'Browser tools', then 'Web developer tools'. In the 'Web developer tools' go to 'Settings' (found under the 3 dot menu), then under 'Advanced settings' check 'Disable JavaScript'.

Safari

• Built in setting: In the 'Safari' menu go to 'Settings', then under 'Security' uncheck 'Enable JavaScript' for 'Web content'.

Note, this guide takes one approach, there are other ways you could do this.

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