Accessibility guidance for: - Testing

What testers and quality assurers need to do to make digital services accessible.

Understand types of testing

There are 3 types of accessibility testing:

testing with people - see the guidance on user research
automated testing
manual testing with guidelines

Automated testing

Make automated testing part of your build process or use it for a scan across your website or parts of it. Remember that automated tests only check some of what you need to test.

Manual testing

Manual checks are the most efficient way to test for accessibility issues on individual pages or components.

Use this guidance and Microsoft's Accessibility Insights Chrome extension.

It is important to learn about accessibility before you start. Otherwise you can waste time wondering about things which aren't a problem or disagreeing with your colleagues.

Check orientation is not locked

Use a mobile device and switch from portrait to landscape and back again. You should be able to see all the content and functionality.

Identify any navigational mechanisms (navigation bars, search fields, and skip links) that appear on multiple pages.

Check that the links or buttons are presented in the same order each time they appear, even if other items are removed or added between them.

If the navigation is defined by templates, you only need to check 1 or 2 pages.

Set language

You need a small bit of markup on every page for screenreaders (and search engines) to know what language the content (or a part of the content) is in.

How to code for language

In the HTML element, set the language for the whole page to English:

<html lang="en">

or whatever language the page is in.

If there are changes of language within the page, mark these up as well:

<p>Make sure you find out about other Government events in France (<span lang="fr">conventionné</span>).</p>

You can apply the lang attribute to any container.

Set page titles

A good page title helps users find what they want and recognise they're in the right place. It's the link that shows in search results and the first thing a screenreader will read out when the user lands on a page.

Each page title must be unique and descriptive. Keep it concise and consider putting important keywords near the beginning.

Best practice for page titles

Best practice is generally: Page name – Site name

For example: About HS2 – HS2

The first element (here "About HS2") is the main heading of the page.

If you can, use templates to keep things consistent and use your content management system to generate what comes after dash.

Define page structure

You can help people who use assistive technologies understand the structure of the page and navigate it by including "landmarks" (hidden labels for sections of the page). Landmarks also help users looking at multiple pages skip repetitive sections.

Use ARIA landmarks to identify the regions of a page.

Landmarks you need

Make sure that you've defined these landmarks if your page includes them:

banner: at the top of the page, usually contains the logo
navigation: elements that link to other pages, usually in the banner
search: the search field, usually in the banner
main: contains the main content of the page. It should be unique on each page.
contentinfo: the footer. This is shared across pages.

You'll need to define headings, lists and data tables in content areas too.

Follow the header and footer components in the service manual.

Define skip links

Use a skip link to help keyboard-only users skip to the main content on a page.

Also add a skip link at the start of a long list of links or form fields (for example, over 20 checkboxes in a filter). This lets people who use keyboard-style access with a switch or head-wand skip to the end and avoid having to keep pressing the same key.

Skip links can be invisible by default, but must be very visible when focused.

Follow the skip link component in the service manual.

Use headings correctly

Everyone relies on meaningful headings to navigate the page but they are especially important for some people with access needs. Make sure your headings reflect the page structure.

Structure headings for accessibility

The H1 is the same as the page title. You should have only 1 H1 on a page.

Each main section of your page should start with an H2 and each sub-section of an H2 with an H3. It is possible to have sub-sub-sections which start with an H4.

With each heading, ask yourself if it's a sub-section of the previous heading. If not, it should be at the same level as (or higher than) the previous section.

Make sure that headings follow the correct "nesting" order and don't skip levels. The structure of the page is the key thing, not the size and style of the text.

You can use a web developer toolbar (Chrome or Firefox) to see the overall heading structure of the page.

Read more about styling headings in the typography section of the service manual.

Check keyboard accessibility

Keyboard accessibility is one of the most important parts of accessibility. It enables other input methods, including switches, speech input and screen readers.

The starting point for keyboard accessibility is to use the correct HTML for links, buttons and form controls. Use components from the service manual, if you can. They've already been tested for keyboard accessibility.

How to test with a keyboard

Check that you can use:

tab to progress through links and controls
shift-tab to reverse
enter to follow links
space to select form controls (such as checkboxes)
arrows for radio buttons or tabs

Checklist for each page

Check that:

you can tab to all links, buttons and form controls
you cannot tab to non-functional elements (such as headings and paragraphs)
you can easily see where the focus is
the focus does not move to hidden elements
the focus does not get trapped in an element
scripted events (for keyboard, mouse and touch) only fire when expected
the visual order for tabbing progress is left-to-right and top-to-bottom

Test that text sizes and zooms correctly

People use their browser to change the size of content, and people with low vision may use that to a more extreme level. The guidelines specify a level of 320 (CSS) px wide. That is equivalent to 400% for a 1280px wide browser.

Users can also override the font-family and spacing for text, which can break a fragile layout. We use this text spacing bookmarklet to test with.

How to test text sizing and zooming

Check what content and functionality you can see.
Size your browser window to 1280px wide. (You can use the web developer toolbar in Firefox or Chrome.)
Zoom into 400%. (Firefox needs a tweak to do this.)
Check that you can still see all the content and functionality, even if it involves opening show/hide elements or clicking through to another page.
Activate the text spacing bookmarklet.
Check for missing or overlapping content and that there is no horizontal scrolling.
Gradually zoom out to 100%, checking the text spacing at each stage.

HS2 services must use a responsive design which helps with zooming and take care with layouts that limit text expansion.

Examples of layouts that cause problems

Fixed height containers of text often break when text spacing is changed. Use min-height instead.
Sticky elements, or containers that prevent scrolling, are often unusable at higher levels of zoom in landscape orientation. Use vertical media-queries to make sure there is enough space.
Large data tables are allowed to scroll horizontally, but you should wrap them in an element that contains the scrolling to the table, rather than making the whole page scroll.

Use ARIA patterns

ARIA (Accessibility Rich Internet Applications) adds extra information that lets people who use assistive technologies know what's going on. If a component needs more description than HTML provides, you need to mark it up with an ARIA pattern.

We use simple examples of ARIA in some of the service manual components, such as details, breadcrumbs and error messages.

How to use ARIA patterns

The W3C note on using ARIA is a good introduction.

If you have a complex component, check whether it fits into a defined pattern from the ARIA authoring practices. Patterns that might be useful are:

If you use an ARIA pattern, include the ARIA attributes, take responsibility for the keyboard interactions as part of the scripting, and test it with assistive technology.

Start with the components in the service manual. They've already been tested. Another useful resource for accessible components is the Inclusive components collection.

Label form fields clearly

Make sure that every form field has a label that tells users what information they need to enter.

More about labels

Put the label next to the form field so that the user is clear which field it relates to.

Generally the label should be visible. (There are exceptions. For example, there's a hidden label "Search the HS2 website" on the search box in the HS2.UK header. It doesn't need a visible label because people can see the search icon and the word "Search" in the box.)

Give grouped items a "legend". You can see examples in the checkboxes and radios components in the service manual.

To test the code is correct, you can usually click on the label and the field should be focused by the browser. Otherwise, check there is a "for" attribute on the label and that it matches the "id" attribute of the field.

Write good link and form control names

Links or buttons need to make sense out of context as some people experience them that way. Each link should clearly describe where it will take you. For example: "Find out where your nearest HS2 station is".

How to write good link and form control names

Ideally link text should match the heading of the target page. If the target page has the heading "HS2 stations", that's good link text.
If the target page heading is too long, shorten it but use words from it so that users can predict where the link will take them.
Avoid ambiguous phrases such as "click here", "read more" and "find out more". It's OK to say: "Read more about our line of route."
Avoid having links or buttons open new windows or tabs. If you need to open a link in a new window, say this in the link phrase. For example, "Link name (opens in new window)".
If the link goes to a document, include the file type and size in the link phrase. For example: "Link name (PDF, 200KB)".

Using the same link text for multiple links

You can use the same text for multiple links when they're in a good structure. The table row headings together with the link text must make the meaning clear.

There's an example in the summary list component in the GDS design system. At the end of each row is a link that says: "Change". The context makes it clear what "Change" refers to.

Highlight errors in forms

Make sure that error messages clearly describe what went wrong and how to fix the problem.

Include an error message wherever there's a problem with the input and check that it's visibly obvious that the message is connected to that input.

If you have an error summary at the top of a form, check that each error in the list has a link that moves the focus to the relevant form field. This helps users who rely on keyboard navigation.

Use the error message and error summary components in the service manual. They've been tested for accessibility and contain links to useful GOV.UK guidance on writing good error messages.

Check colour contrast

It's easier for people to read and interact with content if you use colours that contrast well. The HS2 meets at least level AA for contrast and we aim for AAA where possible.

Find out more about colour contrast in the accessibility section of the colour page in the design system.

Do not rely on colour or position alone

Do not rely on colour to convey meaning, for example, an instruction. To communicate with people who cannot see well or distinguish colours, you may need to:

word things differently
use more than one visual cue, for example, text and an icon as well as colour

Do not rely on people understanding instructions that refer to the position of page elements.

Why you should not say "Press the red button on the right"

If someone is:

"colour blind", they may not be able to tell the difference between red and green
zoomed in, the button may not be on the right
using a screenreader, they may not see the colour - and position, for them, is simply up or down

Use alternative text for images in content

People who cannot see a meaningful image need an alternative to understand the content. You need to add "alt-text" to explain what's in the image. Alt-text is not usually visible but is read out by screen readers or displayed if an image does not load or if images have been switched off.

You can see what alt-text an image has by viewing it with Chrome's Web Developer toolbar.

Informative images

The content of the alt-text depends on the image and its context. If the image is part of the main content of the page (not a functional image - one that triggers an action), use the alt-text to describe the image in a way that makes sense in the context.

You don't need to explain that it's an image because screen readers usually announce that.

Keep alt-text to a sentence or 2 and ideally under 125 characters including spaces. If there's important information that you cannot fit in 125 characters (for example, you're describing a complex chart), include this information in the alt-text or consider linking to more information for screen reader users. (For example, the HS2 website team is testing long descriptions to describe images of conditions appearing on a range of skin tones.)

Imagine you were reading the page out to a friend. How would you describe the image?

This is an image from the 'Building HS2' page on the HS2 website. It's displayed above a heading "Stations". The alt-text is: "Artist's impression of Birmingham Curzon Street Station." It explains what users can see in the picture.

Artist's impression of Birmingham Curzon Street Station. — An artist's impression of the new HS2 station at Birmingham Curzon Street.

This example has a caption underneath the image as well as alt-text. Read about captions and how they work with alt-text in the images component.

If you have a complex image that you cannot describe in short alt-text (such as an infographic), include a longer description in some other way on the page.

If your image has text which conveys its meaning, follow the guidance on functional images. An example would be a link to a health app which includes a brand image and the name of the app. The app name says the same as the brand image, so the image doesn't need explaining.

Decorative images

Decorative images are there to attract users' attention or motivate them, but they don't help users understand the topic. An example might be an image of a hard hat on a construction page.

If your image is decorative, give it a null text alternative like this: (alt="").

Use alternative text for functional images

Some images are "functional". That means that they trigger an action. If people can't see the image, they need an alternative.

Use "alt‑text" for images like PNG or JPEG. W3C has information about how to deal with different kinds of functional image, including logos.

The HS2 website (hs2.uk) prefers inline SVG files for functional images. SVGs don't have an alt attribute. Instead we use aria-hidden="true" and, if there is no link text, "visually-hidden" in span tags.

For some common HS2 examples of SVG functional images, see the close and search icons in the header component in the service manual. The action link is an example with link text.

Make video and other multimedia content accessible

Consider using video as well as text. Some people find it easier to understand.

With all video and animation, make sure that:

the interface is accessible for keyboard and screen reader users (including play/pause buttons and the location slider)
if the user cannot see or hear it, they can still understand it

To meet the accessibility regulations for public sector organisations, most new videos you've published or updated after 23 September 2020 must have these 3 kinds of alternative content.

Audio description

Audio description provides content for people who are blind or cannot see the video well. It is additional commentary that describes what's happening on screen in between narration, including any text, graphics or scene changes in the video.

You must include an audio description for any key information that's visible on the screen but not part of the soundtrack, for example diagrams without a verbal description. If all the visual information in the video is included in the regular soundtrack, you do not need an audio description.

If the video says the same thing as the page content, you do not need an audio description but you must make it clear that the video is an alternative to the text content. Our experience tells us, however, that even in these cases audio description can be valuable to blind people, some of whom do not read the page content.

For audio description, you can do 1 of the following:

publish an alternative version of the video with audio description added in relevant places
add a separate audio description track (if the media player supports this)

If you have a separate audio description track, make sure it includes the audio description voice-over and the original video audio (mixed and synced together). The audio description track must be the same length in seconds as the main video’s audio.

Closed captions (sometimes called subtitles)

People who are Deaf or have hearing loss may find captions helpful. Closed captions are a text alternative to audio information in video and animations that you can turn on or off.

Use closed captions rather than subtitles. They look similar but subtitles are only a text alternative for dialogue, while closed captions are a text alternative for all the audio, including important background noises.

Closed captions must include:

the words people say
who is speaking, if it's not obvious, or where they are (for example, off-screen)
important sounds like music, laughter or a door slamming

Check that any auto-generated captions are accurate and synchronise them with the visual content.

Use a contrast ratio of 4.5:1 for the text. If possible, use a fully opaque (no transparency) coloured box behind the text. We recommend a black background with white text. Find out more about using colour and accessibility, including colour contrast.

For caption fonts, follow the typography guidance in the design system.

Transcript

Transcripts provide audio and video content for people who:

are both Deaf and blind
people who process text information better than audio and visual information

It's best practice to provide a transcript for a video but it is not required to pass WCAG2.1 AA. You must, however, provide a transcript for any audio-only content, such as a podcast.

A transcript should include all the dialogue, relevant sound effects, and audio description content.

There are rare exceptions, and you do not have to meet these requirements with videos published before 23 September 2020.

Give users time to read and act

If you have set a time limit for inactivity (for example, on a multi-step form), make it at least 20 hours.

If you use 3rd party content that has a time limit, it should warn users clearly how much time they have left and let them extend or turn off the time limit.

There are exceptions to this when the time limit is essential, for example, for an online test or real-time event.

Check autocomplete in forms

If you need information only from the person who is filling the form, make sure it has the autocomplete attribute.

The W3C autofill table tells you which attribute to use for each type of form field.

If the form can be filled in for someone else, this isn't necessary.

Check flashes and animation

Make sure that users can pause, hide or stop anything that moves, blinks or scrolls automatically and lasts more than 5 seconds.

Pages should not contain anything that flashes more than 3 times in any 1 second. Or the flash should be below the general flash and red flash thresholds.

Read more about the 3 flashes or below threshold on the W3C website.

Make users aware of status updates away from current focus

Make screen reader users aware of important changes in content during an action in a way that does not interrupt their journey.

If you need to let users know the results of an action (for example, updated search results or that they have successfully submitted a form), convey this information programmatically.

How to check status messages

Use a screen reader to carry out an action that will trigger a message or a change in context dynamically.
Check whether the message is announced and describes the action accurately.

Do not add keyboard shortcuts

Do not use single letter keyboard shortcuts. (Gmail, for example, uses the "j" and "k" keys to move between emails.)

Keyboard shortcuts which use single numbers, punctuation, lowercase letters, uppercase letters or symbol characters can interfere with voice input software.

Keyboard shortcuts in 3rd party content

If you use 3rd party content with these types of shortcuts, you must have one of these:

a mechanism that allows users to turn off character key shortcuts
a functionality to remap the shortcuts to use more than one character (for example, ALT + j)

Do not override visible labels

Make sure that ARIA or HTML labels for buttons, links or anchors match or contain the same words as visible labels. That applies whether the visible label is in text or an image of text.

Do not use "onkeydown" or "onmousedown" for links and buttons

For interactive elements, only trigger actions once the user takes their finger or pointer away from the activation target. This gives users a chance to cancel or avoid activating the trigger.

Do not include text in images

Users need as much information as possible in text format, so that they can adjust its size, spacing or formatting.

Do not include text in graphical (raster) formats like PNG, JPEG or GIF. They do not work well when users zoom in. Instead put text in HTML (styled with CSS) or use SVG.

This does not apply to logos.

Do not trigger pop-ups by hover or focus

Do not trigger additional content by mouse hover or keyboard focus. It causes problems for people using zoom or a screen magnifier.

If you use 3rd party content which does this, make sure you give users a way to dismiss the content without moving the mouse or focus. For example, use the ESC key.

Do not play audio automatically

Audio must not play automatically for more than 3 seconds. It makes it hard for people to hear their screen reader.

Do not rely on touch gestures

Do not rely on touch, even for interfaces designed for touch screens. You can use touch gestures but you need a standard fallback.

For example, if you swipe between images, you also need a button that does the same thing for people using switch access or screen readers.

Do not rely on motion sensors

If you have any functionality that is triggered by device or user motion (like shaking or tilting), you must provide another way for users to activate it. For example, let the user press a button.

Also make sure that users can disable motion actions.

Use HTML rather than PDFs

Avoid using PDFs as they are not accessible. If you must use a PDF, make sure the content is also available in HTML form.