AccessibilityPerceivable

Users must be able to perceive the content.

Text alternative for non-text content, captions and other alternatives for multimedia should be provided, and content should be adaptable by the user to fit their requirements.

Index

Text Alternatives

1.1.1 - Non text content

All non-text content like images, charts, icons and infographics, must have an appropriate text equivalent. This ensures that information conveyed by non-text content is available to people who cannot see it, like screen reader users.

Understanding Success Criterion 1.1.1: Non-text Content

Implementation guidance

All images must have an alternative text description that describes its meaning, not what the image is:

images that communicate information (for example icons and logos) have short text descriptions
editorial images that support the text around them have short descriptions
images that communicate complex information (for example infographics, charts and diagrams) have longer text descriptions within the same page
decorative images have the null (or empty) alternative description alt="" (no space between the quotations)

How to test with a manual code check

identify images on the page, right click on them and select ‘Inspect’
check the image tag to see if the alt attribute exists
for decorative images, the alt attribute should be alt="" or just alt
for editoral images and images which communicate information check that the descriptions are appropriate
for images of complex information, check that the description refers to the availability of a longer description and that this is present on the page

How to test with JAWS

Use the ‘G’ key to navigate to the images on the page and check that a meaningful textual description is read out for informative images, and that decorative images are not announced.

Helpful links

Time based media

1.2.x - Alternatives for audio and video

Audio and video content has appropriate alternatives to ensure that everyone has a comparable experience when interacting with this content. This may include transcripts, captions and audio description depending on the type of audio or video content.

Implementation guidance

The alternative required depends on the context of the audio or video, but broadly:

always provide a transcript
always provide captions for videos
if the narration of a video does not include all the detail required, then provide audio description

Provide accessible transcripts and alternative versions of content next to the original multimedia content.

Closed Captions (where the captions are separate from the video content) should be used where the video player supports this. Captions should be checked for accuracy, especially where auto generated.

For live video content like livestreams of events, captions should be provided which are synchronised with the audio.

How to test with a visual check

If the page contains multimedia content, check that the required alternative is available.

The transcript should be available near to the multimedia content but can be a link to another page.

If a second version of the content is available with audio description then this must be easily accessible from the non-audio described version.

Helpful links

Home Office Design System - Audio and Video

Adaptable

1.3.1a - Info and relationships - Tables

When information is visually presented as a table, this structure must be conveyed appropriately to assistive technologies. This ensure that tables are available to screen reader, screen magnification and speech recognition tool users.

Where possible, you should use semantic HTML to implement content structures.

Understanding Success Criterion 1.3.1: Info and Relationships

Implementation guidance

Tabular data is presented using proper HTML markup (<table>, <tr>, <th>, and <td> elements).

Tables include a <caption> element which summarises the overall purpose of the table.

Avoid creating complex tables (with multiple rows or columns of headings).

If semantic tables are not possible, as a last resort, use ARIA roles to replicate the structure of a table. This is highly complex and involves a lot of additional coding, so avoid it if you can. See ARIA: table role for implementation advice.

How to test with a manual code check

right click on any tables and select the ‘Inspect’ option
manually review the table structure to identify the presence of the correct mark up
note - <thead> and <tbody> are not semantic HTML and are used for formatting purposes. The only valid semantic tags are shown
if there are no semantic tags, check for ARIA roles related to tables. All appropriate roles, descriptions and indexes need to be available to pass this requirement

How to test with JAWS/NVDA

Use the ‘T’ key to reach the tables on the page, use Ctrl+Alt+arrow keys to navigate the tables and check that the correct row or column headers are announced by the screen readers for each data cell.

Helpful links

1.3.1b - Info and relationships - Lists

When presenting lists of information, you must communicate this list in a way that assistive technology users can understand.

Where possible, you should use semantic HTML list options which are appropriate to the information being presented.

Understanding Success Criterion 1.3.1: Info and Relationships

Implementation guidance

Use appropriate and proper HTML markup for lists of items:

ordered lists for structured data like the steps in a process (<ol> and <li>elements)
unordered lists for unstructured data like the ID documents required for a process (<ul> and <li>)
description list/definition list to group a series of key terms and their descriptions/definitions together (<dl>, <dt> and <dd>)

If semantic options are not available, use the ARIA list and listitem roles to replicate semantic structure. This is a last resort. Note: ARIA lists do not have list types - they are all just lists.

How to test with a manual code check

right click on any list of information and select the ‘Inspect’ option
manually review the list to ensure the appropriate list type has been used for the data and that no additional tags exist inside the list tag
if no semantic tags exist, check for the presence of ARIA roles relating to lists. Note that ARIA lists don’t have different types and are all just ‘lists’

How to test with JAWS/NVDA

Use the ‘L’ key to reach the lists on the page and check that all content that visually and logically represents a list is announced as ‘list’; that content that does not represent a list is not announced as a list.

Helpful links

Web Accessibility Tutorials - Content Structure - Lists

1.3.1c - Info and relationships - Headings

Where visual headings are used to communicate the structure of a page, they must also be communicated in a way that supports assistive technology users to access this structure.

You should use semantic HTML headings to structure your page. Heads should cascade from H1-H6. Each page must have at least a Level 1 Heading (H1).

Understanding Success Criterion 1.3.1: Info and Relationships

Implementation guidance

Use proper HTML markup for headings (<h1> through <h6> elements).

Each page should have a H1 which describes the overall purpose of the page.

This should be similar to the title of the page (see 2.4.2 - Page title).

Do not skip heading levels or use multiple H1s on a page if you can avoid it.

If you cannot use semantic headings, use the ARIA heading role and aria-level attribute to provide heading structure to the page. This is a last resort.

How to test with a manual code check

right click on any heading and select the ‘Inspect’ option
manually review the correct heading structure has been applied to visual headings
if no semantic tags exist, check for the presence of ARIA heading role and the aria-level attribute

How to test with JAWS

Use the ‘H’ key to reach the headings on the page and check that all text that visually and logically represents a heading is announced as ‘heading’; that the correct level is announced for each heading; that text that does not represent a heading is not announced as a heading.

Use the JAWS key + F6 to open the Heading List dialog. Review this to check that the heading structure matches the visual document outline

How to test with NVDA

Use the NVDA key + F7 to show the elements list that should show you all the headings available on the page. Review this to check that the heading structure matches the visual document outline

Helpful links

1.3.1d - Info and relationships - Form fields

All form fields have an associated visible label. Where this isn’t possible a non-visible label must be present.

Sets of radio buttons or checkboxes must be grouped together so that assistive technology users can understand the relationship between these controls.

Where specific format or input requirements need to be met, hint text linked to the form fields is provided.

Understanding Success Criterion 1.3.1: Info and Relationships

Implementation guidance

If you can, use the <label> tag and ‘for’ attribute to give form field elements visible labels.

Group sets of radio buttons or checkboxes using the <fieldset> tag and have an appropriate <legend> tag to label the group.

If you cannot use <fieldset> and <legend>, use the radiogroup and radio ARIA roles and associated attributes for radio buttons. Use the group and checkbox ARIA roles and associated attributes for checkboxes. This is a last resort.

Use aria-describedby to reference hint text from the form control if specific format or input requirements need to be met by users.

Ensure information on entry format isn’t given by placeholders alone and that this is available to screen reader users.

If you cannot use visible labels, follow the requirements of 4.1.2 - Name, role, value.

How to test with a quick check

The following quick check will show you if this requirement has been implemented. It will not necessarily show you if it’s failed. If this check doesn’t work then complete the other manual code checks.

click on the visible label for the form control you’re testing
if focus moves to the control or activates it then the control and the label are correctly associated
if focus doesn’t move or the control is not activated, complete further testing

How to test form elements with a manual code check

right click on a form element and select the ‘Inspect’ option
manually review the form element and check that a label has been associated with it
if there is a visible label start by checking the label. It should be wrapped in a <label> tag and should have a for attribute which references the id of the form element it labels
if there is no visible label or it doesn’t have a for attribute, look for aria-label or aria-labelledby on the form element
check that any additional hint information is linked using aria-describedby
check that any additional hint information is not only provided using placeholder text

How to test radio buttons or checkboxes with a manual code check

right click on a radio button or checkbox group and select the ‘Inspect’ option
manually review to identify if the group of elements are enclosed within a <fieldset> tag and the question/statement is within a <label> tag.
if this is missing, check for appropriate ARIA alternatives
check that any additional hint information is linked using aria-describedby

How to test with JAWS

Use the ‘F’ key to reach all the form elements on the page and check that they have an associated label and that any hint text is read out.

Use the JAWS key + F5 to list form fields. Review this to check that everything is labelled.

Ensure that any additional hint text is announced by the screen reader you’re using.

How to test with NVDA

Use the ‘F’ key to reach all the form elements on the page and check that they have an associated label and that any hint text is read out.

Use the NVDA key + F7 to show you a list of the form elements on the page. Review this to check that everything is labelled.

Ensure that any additional hint text is announced by the screen reader you’re using.

Helpful links

Web Accessibility Tutorials - Forms Concepts

1.3.1e - Info and relationship - Landmarks

Content sections within a page should have an appropriate HTML5 section element or ARIA landmark role defined.

Understanding Success Criterion 1.3.1: Info and Relationships

Implementation guidance

As a minimum, you must include a main landmark (either the HTML 5 <main> or ARIA role="main") on each page.

Add extra landmarks, for example navigation and footer content, if the page has these areas.

All the section’s content or functionality must be contained within a landmark.

Where multiple landmarks of the same type are used e.g. navigation, use aria-label to add a descriptive label to the navigation area e.g. ‘Related Links’ for a secondary navigation area.

How to test with a manual code check

right click on the page and select the ‘Inspect’ option
review the code to ensure that the main section of the page either uses the <main> tag or has role="main"
check that navigation areas have either <nav> or role="navigation"
check that where multiple areas of navigation exist, they all have a landmark and an appropriate label

Testing with JAWS

Use the ‘R’ key to get the screen readers to announce all landmarks on the page and check that the right landmark is announced for each page section (e.g. ‘main’ for the main content area).

Testing with NVDA

use the ‘D’ key to hear all the landmarks on the page and check that the right landmark is announced for each section
use the NVDA key + F7 to show you the list of landmark elements on the page. Review this to check that all the required landmarks exist and that they are labelled appropriately

1.3.2 - Meaningful sequence

When the order of content is important, the content order must be preserved no matter how it is presented to the user.

This ensures that the order of content is meaningful whether someone is looking at it, listening to it with a screen reader, or has stripped out visual styling using a browser plugin.

Understanding Success Criterion 1.3.2: Meaningful Sequence

Implementation guidance

The structure of your code should reflect the visual structure of the page.

This keeps the order of content meaningful for screen reader users, or users who have turned off visual styling.

The underlying structure must still make sense if it is different to the visual structure.

How to test with a visual check

to check the reading order of the page, the visual styling needs to be switched off
you can do this by using a simple bookmarklet like Disable CSS Bookmarklet or, depending on the browser, using the ‘Reading view’ option in the browser
you can also manually review the DOM to see how content appears
regardless of the method, once enabled, you should read through the linerised content to check that the reading order follows the reading order with styles enabled

Testing with JAWS/NVDA

Use the arrow keys (or Insert + down arrow) to go through the whole page and check that its content is read out in a logical order.

1.3.3 - Sensory characteristics

Instructions must not depend on sensory characteristics like shape, size, colour, or location. This ensures that instructions can be understood by users who are unable to see or recognise information communicated using sensory characteristics.

Understanding Success Criterion 1.3.3: Sensory Characteristics

Implementation guidance

Do not rely on visual descriptions like ‘green’ or ‘below’ to communicate user instructions. For example, in ‘Press the green ‘Next’ button to continue’, the colour is supplemented by non-sensory information.

How to test with a visual check

If the page contains any instructions around where to find, or how to interact with, content on the website, check that these instructions do not rely on the ability of users to perceive shape, size, visual location or sound.

1.3.4 - Orientation

A page view must not be locked to either horizontal or vertical views only, unless this is essential.

There are limited cases where ‘essential’ orientation locking applies. Check with the A&I team for cases.

Understanding Success Criterion 1.3.4: Orientation

Implementation gudance

Let the user view pages in their preferred orientation.

Use CSS to allow both landscape and portrait.

Do not try to force a specific orientation or aspect ratio.

Do not show a ‘please rotate your device’ screen at particular orientations.

As best practice, make sure content works appropriately in both landscape and portrait orientation.

How to test with a visual check on mobile

View the page on a mobile device and change the orientation.

How to test with a visual check on desktop

right click on the page and select ‘Inspect’
activate the device toolbar
select the ‘rotate’ option in the toolbar and observe whether the content moves into the new orientation successfully
resize the browser window to have a portrait or landscape aspect ratio. Observe if a ‘Please rotate your device’ message is shown.

1.3.5 - Identify input purpose

In an input field, the purpose of each input field that collects information about the user can be understood by assistive technologies and browsers by using autocomplete.

Understanding Success Criterion 1.3.5: Identify Input Purpose

Implementation guidance

If a form field relates to the user’s personal information (from the set of input purposes listed at Input Purposes for User Interface Components), include an explicit autocomplete attribute with the relevant value.

This ensures that the purpose of the input can be programmatically determined/understood by user agents and third party tools (such as password managers).

How to test with a manual code check

Right click on each form field requiring information that can be suggested by the browser, select ‘Inspect’ and check that the autocomplete attribute is included in its source code and that the correct value has been given to this attribute.

Distinguishable

1.4.1 - Use of colour

Information conveyed with colour must also be identifiable from context, labelling, or alternative forms

Understanding Success Criterion 1.4.1: Use of Color

Implementation guidance

When rendered in monochrome, information does not disappear.

Do not only use colour to indicate important content. Use a visible border and label, underline or other visual effect as well.

Do not only use colour as a key for information graphics and charts. Use distinctive non-colour differences, like patterns or directly applied labels, as well.

Underline links instead of relying on colour contrast.

How to test with a manual code check

If colour is used to convey information or distinguish between items, check that the same information is provided via an alternative means.

Use of colour also applies to links that aren’t underlined.

Check that all links within the content (not navigation).

1.4.2 - Audio control

Audio/video must not play automatically unless the user is pre-warned and can control the audio

Understanding Success Criterion 1.4.2: Audio Control

Implementation guidance

Audio or video content that plays automatically, for example an alert sound, lasts for three seconds or less.

Audio or video that plays automatically and lasts for more than three seconds can be paused and/or stopped using on screen controls.

How to test with a manual code check

listen to the page without any assistive technology running
ensure that any sounds that play automatically only last for 3 seconds or less
if a sound lasts for more than 3 seconds, check that audio controls are available

1.4.3 - Contrast

There should be enough difference (contrast) between a background and the foreground content so that user can easily differentiate the two.

Understanding Success Criterion 1.4.3: Contrast (Minimum)

Implementation guidance

Text, including text in images, must have a contrast ratio of at least 4.5:1 against its background colour.

Where text crosses different background colours or an image, all of the text must meet the contrast requirement.

This requirement does not include incidental text in photographs, images or illustrations.

The Home Office Accessibility standard has removed the ability to have larger text at lower contrast ratios (3:1 for large or bold text). The standard requirement for all text contrast is 4.5:1.

How to test with Colour Contrast Analyser

Use the Colour Contrast Analyser to check that the contrast ratio between text and background colours is at least 4.5:1 for standard text.

How to test with developer tools

open developer tools in Chrome
use the inspector tool to highlight content
a tooltip will appear with contrast information. Check that it shows as pass

How to test with manual code check

use an online contrast checker e.g. WebAIM Contrast Checker
identify the HEX values from the CSS for text and background colours
use the design specification for the site to identify the HEX values and use the site to check these meet or exceed the 4.5:1 requirement

1.4.4 - Resize text

Users should be able to resize text up to 200% without any problems with the presentation and structure of the page (for example truncated text, overlaps or missing items).

Understanding Success Criterion 1.4.4: Resize text

Implementation guidance

Avoid setting specific width and height sizes for containers if you can, so they will adapt to the size of the content they contain.

Avoid using CSS absolute positioning, as these layouts can easily end up overlapping other content or containers.

Do not disable pinch-zoom functionality on mobile/tablet devices with <meta> tags such as user-scalable=no or maximum-scale=1.

Use relative text sizing, like percent sizes, em units or named font sizes.

How to test with browser zoom

Use the Zoom functionality of the browser to enlarge the page to 200% and check that you can access all content without having to scroll horizontally. Check that changed content structures - ie burger navs can still be reached.

Common browser sizes should be used when testing. Ideally you should test at 1024x768, 1280x1024 and 1920x1080 to cover the most common layouts for desktop.

How to test with browser settings

Use the settings within a browser to resize text without zooming

How to test on mobile/tablet

Check that you can pinch/zoom on a mobile/tablet device.

How to test with a manual code check

Inspect the page code to see if <meta name="viewport"> includes code which blocks user pinch/zoom control such as user-scalable=no or maximum-scale=1

1.4.5 - Images of text

Meaningful text must not be presented as part of an image because it cannot be resized, it deteriorates in quality when magnified and is not customisable by the end user.

Meaningful text is anything which is used to aid understanding for users.

Understanding Success Criterion 1.4.5: Images of Text

Implementation guidance

Do not use images for meaningful text that gives users information. Text in some types of images, like SVGs, can resize without deterioration, but cannot be customised. As a result no images of text are allowable.

The Home Office standard for images of text is stricter than the WCAG requirements.

How to test with browser settings

Turn images off and check that no text disappears

How to test with a manual code check

Select all the text on the page - any images of text will not be selectable

1.4.10 - Reflow

Users should be able to magnify the page up to 400% and content should reflow - move into one column - and not add horizontal scroll bars.

Content should not be cut off or omitted entirely when magnified.

Understanding Success Criterion 1.4.10: Reflow

Implementation guidance

Make sure your pages are responsive, so the content will ‘reflow’ to a single column gracefully.

There are a small number of exemptions for this requirement:

Maps and diagrams where scrolling is necessary to understand content, or where stacking information would change the meaning
Complex tables with many columns (although individual cells must not scroll)

How to test with browser zoom

Use the Zoom functionality of the browser to enlarge the page to 400% and check that you can access all content without having to scroll horizontally.

Note the exemptions to this requirement in implementation advice.

1.4.11 - Non text contrast

Interactive controls, keyboard focus, icons and content required for understanding e.g. charts and infographics must have enough contrast (at least 3:1) with adjacent colours.

Understanding Success Criterion 1.4.11: Non-text Contrast

Implementation guidance

Buttons or other inputs and controls must have a contrast ratio of 3:1 or higher in all their states.

Parts of graphical objects, like icons, that convey information must have a minimum contrast ratio of 3:1 with adjacent colours.

The keyboard focus must meet colour contrast requirements and be easy to identify.

How to test with Colour Contrast Analyser

Use the Colour Contrast Analyser to check that

the contrast ratio between each informative object within icons and its surrounding colours is at least 3:1
the contrast ratio between the border and focus indicator of form fields and buttons/links and the background colour is at least 3:1

How to test with a manual code check

Use an online contrast checker e.g. WebAIM Contrast Checker
Identify the HEX values from the CSS for outline styles and states and input these into the colour contrast checker
Use the design specification for the site to identify the HEX values and use the site to check these meet or exceed the 3:1 requirement

1.4.12 - Text spacing

For regular HTML page content, no loss of content or functionality happens when a user changes line height, letter or word spacing.

Understanding Success Criterion 1.4.12: Text Spacing

Implementation guidance

Make sure your CSS lets users adjust:

Line height (line spacing) to at least 1.5 times the font size
Spacing following paragraphs to at least 2 times the font size
Letter spacing (tracking) to at least 0.12 times the font size
Word spacing to at least 0.16 times the font size

Users should be able to adjust text spacing without breaking layouts, overlapping elements or problems seeing content.

How to test with a visual check

You can use the Text Spacing Bookmarklet to modify the content spacing and check that all content adapts and is still visible.

1.4.13 - Content on hover or focus

Extra content e.g. tooltips:

can be viewed easily
don’t cover up key content
can be dismissed without moving focus or hover
can be hovered over (i.e. it doesn’t disappear if you move the mouse)
is persistent and doesn’t disappear until the user moves focus / hover away

Understanding Success Criterion 1.4.13: Content on Hover or Focus

Implementation guidance

Position the additional content so that it does not obscure any other content, including the trigger. This does not include white space and purely decorative content, such as a background graphic which provides no information.

Provide an easy way to dismiss the additional content, such as by pressing Escape or selecting a close button.

The additional content should stay on screen until dismissed by the user.

The additional content should stay on screen if the user hovers over it.

How to test using a visual check

When new content appears on mouse hover or on keyboard focus complete the following checks:

check that you can dismiss the new content by pressing the Esc key or a close button
check that you can move the mouse pointer to the new content
check that the new content does not disappear until you move the mouse pointer or keyboard focus to the next item on the page

Get in touch

If you’ve got a question or suggestion share it on the Home Office DDaT Slack channel #ask-accessibility or email access@digital.homeoffice.gov.uk.