Summary of this set of standards
All interactive components and page navigations must be operable via different input modalities.
Users should be able to easily navigate around the site and have enough time to interact with the content without discomfort or physical reactions.
Keyboard Accessible
Enough time
Seizures and physical reactions
Navigable
- 2.4.1 - Bypass blocks
- 2.4.2 - Page title
- 2.4.3 - Focus order
- 2.4.4 - Link purpose in context
- 2.4.5 - Mulitple ways
- 2.4.6 - Headings and labels
- 2.4.7 - Focus visible
- 2.4.11 - Focus Not Obscured (Minimum) New
Input Modalities
- 2.5.1 - Pointer gestures
- 2.5.2 - Pointer cancellation
- 2.5.3 - Label in name
- 2.5.4 - Motion actuation
- 2.5.7 - Dragging Movements New
- 2.5.8 - Target Size (Minimum) New
Keyboard Accessible
2.1.1 - Keyboard accessible
Level AIt must be possible for someone using a keyboard to complete all tasks in a service.
This approach will also ensure that users on touch devices that are running assistive technology will also have access to all parts of a service.
Understanding Success Criterion 2.1.1: Keyboard
Implementation guidance
Users must be able to access all interaction and functionality with the keyboard.
- Do not set the focus order of a page. Use tabindex="0" to add to the inherited tabbing order of the page.
- Only interactive elements should recieve keyboard focus. Do not add keyboard focus to headings or other non-interactive content.
- Review 2.4.3 Focus Order and follow the recommendations.
How to test with a keyboard
Using the keyboard to navigate the page using the Tab and arrow keys, check that you can reach all actionable items (e.g. links, buttons, form fields, tabs, sliders, menus) and that you can activate all items by pressing the Enter key or Spacebar.
You should also be able to move backward to the top of the page using shift + tab
2.1.2 - No keyboard trap
Level ANo item traps the keyboard focus; upon reaching any item on the page, it is possible to move to the item that precedes or follows it using the keyboard.
Understanding Success Criterion 2.1.2: No Keyboard Trap
Implementation guidance
Users must be able to move keyboard focus to an element and away again.
Components which need to contain focus until dismissed, for example dialogue boxes and ‘hamburger’ menus, must provide a close button or other way to exit.
Check that plugins and iframes are compatible with keyboard focus.
How to test with a keyboard
- Using the Keyboard, navigate the page and ensure that focus is not trapped by any component.
- Where components exist that are required to contain the focus until users dismiss the component, check that there is a suitable dismiss option e.g. a close button or the escape key.
2.1.4 - Character key shortcuts
Level AIf single character key shortcuts have been set up within a page, the user can switch them off or remap them.
Character keys should only work where keyboard focus is on the component the key relates to.
Understanding Success Criterion 2.1.4: Character Key Shortcuts
Implementation guidance
Make sure users have a way to turn off single-key shortcuts. This could be in a preference section of your site.
Alternatively, allow users to change character-key shortcuts to more complex or chorded shortcuts, for example changing from ‘A’ to CTRL+A.
How to test with a manual check & keyboard
If single character key shortcuts exist, you should test:
- that the shortcut keys perform the function expected
- do not clash with any browser or Operating System level shortcut keys
You should also test that either of the following is true:
- Ensure that remapping options work including remapping to more complex or chorded shortcuts
OR
- Ensure that the shortcut keys can be switched off.
Enough time
2.2.1 - Timing adjustable
Level AWhen a time limit, like a session timeout, is set ensure a user is informed, especially if this may result in a loss of data.
It must be possible for the user to define the length of the timeout (e.g. in settings), turn it off, delay it, or extend the length of time.
Understanding Success Criterion 2.2.1: Timing Adjustable
Implementation guidance
Where timeouts are implemented:
- tell users about the timeout, and what the timeout limit is, at the start of the process
- alert users when they are about to reach the timeout limit, giving them enough time(at least 60 seconds) to opt to extend it
- you could provide functionality to allow time limits to be extended
- timouts should only be allowed to be extended up to 10 times
- you could also provide functionality that allows users to set a timeout limit before they encounter a timeout, for example in settings
Where timeouts are implemented using Javascript, you should have a non-javascript based approach to allow the user to manage the timeout.
In addition to the implementation guidance, you should:
- provide an indication on the page as to when the page will time out and how to extend the timeout
This could be by using the Inset text component for example:
When a user experiences a timeout, provide a way to get back to where they were.
How to test with a visual check
If timeouts exist, conduct the following checks:
- when a timeout occurs while you are interacting with the pages, check that a warning message is displayed before the timeout occurs and that an option to extend the session is offered
- when a timeout occurs as a result of user inactivity, check that you are informed of the length of inactivity that would generate a timeout at the beginning of the process
- check if there is an option available for the user to adjust the timeout before they encounter it e.g. in settings
In addition, you should check that:
- If the timeout occurs, that users are provided with a way to get back to where they were
How to test with JAWS and NVDA
Where a timeout exists, check:
- that the timeout warning message is communicated to the screenreader
- that on timeout, a screenreader user is alerted that the timeout has occurred
2.2.2 - Pause, stop, hide
Level AAvoid moving or animated content on pages.
When content moves (is animated, blinks or scrolls) automatically for more than five seconds, or when content automatically updates on the page, it must be possible for users to pause, stop or hide it.
Understanding Success Criterion 2.2.2: Pause, Stop, Hide
Implementation guidance
Do not display moving content automatically if you can avoid it.
If the content has to animate automatically, make sure that the animation lasts 5 seconds at most. Otherwise, provide an option for users to pause, stop or hide this content.
Ideally, content should not update automatically (this applies to frequent changes that would be distracting to users). If the content has to update, provide an option for users to pause, stop or hide this content.
How to test with a visual check
If the page contains animated content, check that the animation stops after 5 seconds.
If the animation lasts longer than 5 seconds, check that a pause, stop or hide button is available.
Check that content does not update automatically. If it does, check if an option for users to pause, stop or hide this content exists.
Seizures and physical reactions
2.3.1 - Three flashes or below
Level AA page must not contain content that flashes more than three times a second.
Understanding Success Criterion 2.3.1: Three Flashes or Below Threshold
Implementation guidance
Content must not flash more than three times a second.
How to test with a visual check
Ensure any flashing or blinking content isdoes not flash more than three times a second.
Helpful links
Trace Research & Development Center - Photosensitive Epilepsy Analysis Tool (PEAT)
Navigable
2.4.1 - Bypass blocks
Level AWhen there is repeated content (like a header) at the top of the page, there must be a way for keyboard users to move focus directly to the start of the main content area of the page.
Consider including shortcuts to allow the user to jump between other parts of the content on long pages
Understanding Success Criterion 2.4.1: Bypass Blocks
Implementation guidance
Provide a ‘Skip to main content’ link close to the start of the page.
This link moves the visual and keyboard focus to the main content area, skipping the navigation.
How to test with a keyboard
Use the Tab key to navigate the page and check that a skip link (e.g. ‘skip to main content’) appears near the beginning of the tab order.
Verify that activiating the link moves the visual and keyboard focus to the start of the main content.
2.4.2 - Page title
Level AEach page must have a unique title that indicates its topic or purpose.
Understanding Success Criterion 2.4.2: Page Titled
Implementation guidance
Each page title must be unique within the service and shows the stage of the journey the user has reached.
The title must indicates the page topic or purpose.
Suggested format : Step title - Service name - Platform (if applicable).
For example (external): Do you live in the UK? - Apply for a passport - GOV.UK
For example (internal): Personal details - Metis HR
Avoid symbols, which may not be read correctly by a screen reader
How to test with a visual check
Read the title on the browser tab and check that it accurately describes the page content.
Check that the page title changes through a user journey to reflect the stage of the process. If the content on a page changes without a page refresh, check that the page title updates.
How to test with JAWS and NVDA
Check the title tag is read out and is clear. Use insert + T to read current window title
2.4.3 - Focus order
Level AIt must be possible to navigate through content in a way that makes sense.
Understanding Success Criterion 2.4.3: Focus Order
Implementation guidance
The visible focus order matches the logical order of navigation and interaction on the page.
The easiest way to do this is to ensure the Document Object Model (DOM) follows the visual layout of the page, so your code has the same layout as your onscreen content.
Only content which is interactive should appear in the focus order. Non-interactive content, for instance headings and paragraphs, should not get focus.
Standard HTML components inherit the keyboard focus using the ordering of components in the code.
Add keyboard support when you use non-standard HTML components, as these are not inherited.
In general, the focus order should move across and down the screen in a ‘Z’ shape.
If users move the focus dynamically, for example by opening a modal dialog, you must ensure that you programmatically manage the focus to the modal. Similarly, when a modal is closed, you should manage the focus back to the most logical location in the original document - usually the control which opens the modal. With modals, you should ensure that it remains within the modal and doesn’t stray into the document below.
Dynamic controls should not reset or lose the focus.
How to test with a keyboard
Use the Tab key to navigate the page and check that the actionable items (e.g. links, buttons, form fields) receive the focus in a logical order (i.e. the focus does not jump around the page).
Check that any non-standard components have correct focus ordering.
Check that focus is managed when interacting with modal dialogs.
Check that the focus is not reset or moved to the top of the page by dynamic controls.
2.4.4 - Link purpose in contex
Level ALink text should make it clear what the link is i.e. where the links goes. Links should make sense out of context e.g. when using a links list.
Understanding Success Criterion 2.4.4: Link Purpose (In Context)
Implementation guidance
Link text must clearly show what will happen when the link is clicked.
Descriptive link text for documents should include the document type.
The link text should indicate if links open new browser windows or tabs.
Links that point to the same destination must all have the same link text.
Link names must be accessible.
How to test with a visual check
Read all links on the page and check that they clearly and accurately describe their destination content (i.e. what page are they going to load?).
Activate the links and, if they open a new browser tab/window or content other than a web page (e.g. a PDF document), check that this is clear from their text.
How to test with JAWS and NVDA
Use the JAWS/NVDA Key + F7 to show the elements list that should show you all the links available on the page. Review this to check that the links make sense out of context.
2.4.5 - Multiple ways
Level AAUnless the service is a series of steps, there must be different ways for people to locate and navigate content.
Understanding Success Criterion 2.4.5: Multiple Ways
Implementation guidance
In additional to general navigation, your site should include at least one of the following:
- a site search available on every page
- a link to a site map, normally in the footer
- a link to an A-Z index of pages
Exceptions to this are services which are made up of a series of steps or which have the primary purpose of looking up information.
Site search should be able to deal with spelling errors and differing terminology.
How to test with a visual check
If the page is part of a website containing different sections of content (as opposed to be a step in a process, for example), check that it contains a Site Search functionality or a link to a site map or to an A-Z index of pages.
2.4.6 - Headings and labels
Level AAHeadings must indicate the topic or purpose of the content in that section of the page, and labels must indicate the purpose of the field they relate to.
Understanding Success Criterion 2.4.6: Headings and Labels
Implementation guidance
Headings within your content must describe the purpose or topic of the content that follows.
Organise content into short sections.
Headings of the same level should have content between them, for example two H2s must be separated by content.
Labels for fields should indicate the purpose or requirement of the field they relate to.
How to test with a visual check
- read the page and check that its content is organised in short sections and that each section is preceded by a unique, descriptive heading.
- check that heading of the same level have content between them
- check that labels for fields indicate their purpose
How to test with JAWS
Use the JAWS Key + F6 to list Headings.. Review this to check that headings are descriptive.
Use the JAWS Key + F5 to list form fields. Review this to check that everything is labelled.
How to test with NVDA
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.
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 headings are descriptive.
Helpful links
GOV.UK Design System - Headings
2.4.7 - Focus visible
Level AAIt must be easy to tell which element has keyboard focus.
Understanding Success Criterion 2.4.7: Focus Visible
Implementation guidance
Interactive elements, like links, buttons and form fields, must have a visible focus indicator.
You must set the visible focus rather than relying on browser default settings.
Elements which are visually hidden should not receive visual focus, as this will cause the focus to vanish from the page.
The focus indiciation must meet 1.4.11 Non text Contrast requirements.
How to test with a keyboard
Use the Tab and arrow keys to reach all actionable components on the page and check that you can see where the focus is at all times.
Check that browser default visible focus has been overriden and aligns to the style of the rest of the site.
2.4.11 - Focus Not Obscured (Minimum)
Level AAThis Success Criterion is about ensuring a component that currently has focus is not entirely obscured by another element. It applies to the initial state of focus, for example, when the element gets focus, it must be in view.
Failure example: a button or link having focus and being obscured by a modal or pop-up window, or a sticky header or footer will be a failure.
However, if a component has visible focus and then the user moves a modal window over the focused component, this is not a failure as the original focus state was visible to the user. See 2.4.12 - Focus Not Obscured (Enhanced) for partial obscurity conformance.
Partial obscurity does not result in a failure of this Criterion. For example, if a sticky header stays at the top of the page and a focused element is partially obscured (for example, half a button) then this is not a failure.
Understanding Success Criterion 2.4.11: Focus Not Obscured (Minimum)
Input Modalities
2.5.1 - Pointer gestures
Level AAny functionality which requires a multipoint or path based gestures has an alternative single pointer, non path-based gesture.
Understanding Success Criterion 2.5.1: Pointer Gestures
Implementation guidance
If you are using gesture controls like drag-and-drop or pinch zoom, provide a single pointer equivalent that doesn’t require path/directional gestures.
Users must be aware that the alternative exists and be able to complete with keyboard or single click operation.
If you are using multipoint gestures (like pinch/zoom) or path based gestures (like slider controls, drag and drop) exist, you need to provide an alternative that can be achieved with a single pointer, non path based gesture.
For example, with slider controls you could provide buttons to increase or decrease the value. For pinch/zoom controls, you could provide increase/decrease zoom options.
How to test with a visual check
- identify controls or content which requires gestures e.g. drag-and-drop, pinch zoom or sliders
- Check if alternatives exist e.g. drag-and-drop can be done by assigning an ordering, pinch zoom can be done using zoom in/out buttons and sliders can be moved using +/- buttons or value inputs
How to test with a mobile device
Ensure that gestures available on a mobile device have an accessible alternative which is communciated to screen reader users.
2.5.2 - Pointer cancellation
Level AAny script triggering must be done on the ‘up’ event – not the ‘down’ event.
Understanding Success Criterion 2.5.2: Pointer Cancellation
Implementation guidance
Activation of any function should occur on the up-event. This is where the control is released by the user, for example by using a finger or a mouse. Using the click event by default will only trigger the event on release.
After a down-key event, users must be able to cancel the action that will be executed on the up-key event. This means that if a user selects a control but moves the mouse away from the control before the up-key event, the functionality should not be triggered.
How to test with a visual check
Using the mouse move over an item and left click and hold. Ensure that no action was triggered.
Move the cursor away from the item and release the left mouse button. Ensure that no action was triggered.
2.5.3 - Label in name
Level AFor user interface components with labels that include text or images of text, the Accessible name contains the text that is presented visually.
Understanding Success Criterion 2.5.3: Label in Name
Implementation guidance
The accessible name can be the ‘label’ used on a form input. This can be provided by the label element in HTML or by an aria-label or similar.
The accessible name and visible label of a control must match.
The accessible name can include additional text but the visible name must remain present and unbroken. This means you can prepend or append additional text, but not insert extra words between the visible words.
How to test with a visual check
Where a visual label is used on a control check that the HTML uses the same label. This ensures speech recognition users can say the name of an item?
How to test with JAWS/NVDA
Move to control or form field. The readout for the screen reader should match the visual label if there is one
For example a button visually showing submit should read this, not continue.
2.5.4 - Motion actuation
Level AAny functionality that is initiated by tilting or shaking (etc) a device, must be able to be intiated by a button, or other control.
Users must be able to switch off motion acutation.
Understanding Success Criterion 2.5.4: Motion Actuation Level A
Implementation guidance
On mobile applications, where functionality is performed when the user tilts or shakes the device, provide an alternative way of performing the functionality that does not rely on motion.
Provide a way to switch off motion actuation in settings.
How to test with a visual check
Identify any functionality which requires motion. Check if an alternative option is available.
Check that controls exist to allow users to switch off motion actuation.
2.5.4 - Motion actuation
Level AAny functionality that is initiated by tilting or shaking (etc) a device, must be able to be intiated by a button, or other control.
Users must be able to switch off motion acutation.
Understanding Success Criterion 2.5.4: Motion Actuation Level A
Implementation guidance
On mobile applications, where functionality is performed when the user tilts or shakes the device, provide an alternative way of performing the functionality that does not rely on motion.
Provide a way to switch off motion actuation in settings.
How to test with a visual check
Identify any functionality which requires motion. Check if an alternative option is available.
Check that controls exist to allow users to switch off motion actuation.
2.5.7 - Dragging Movements
Level AAThis Success Criterion is about ensuring users can interact with components that can be dragged, for example a slider or moving something from one part of a page to another, using only a pointer device.
Keyboard accessibility is not applicable for this Criterion.
Some users may not use a mouse, but instead another means to interact with a pointer device, such as head or eye tracker or voice control.
To meet this Criterion, a user should be able to select an element and instead of drag and drop they should be able to point and click. A user could for example, use a mouse to click select, drag, and then drop a component, or click to select, release, and then click on the destination to drop the component.
Understanding Success Criterion 2.5.7 - Dragging Movements
2.5.8 - Target Size (Minimum)
Level AASuccess Criterion 2.5.5 concerns itself with a minimum target size of interactive components of 44 by 44 pixels to aid users who have hand tremors or dexterity issues.
Success Criterion 2.5.8 allows a smaller size of 24 by 24 pixels, this could be an element being 20 pixels wide with 4 pixel spacing between, or 10 pixels with 14 pixel spacing.
There is ambiguity in this guideline, as it states that as long as there is a minimum spacing of 24 pixels between elements, essentially, the target element could be 0 pixels. This doesn't really make sense, so assume an element should be a minimum of 24 by 24 pixels or up to 24 pixels between them.
Additionally, this Criterion only applies to components that are not native components such as checkboxes, inputs or sentences. Where custom components have been designed, these are in scope. There are several exemptions to this Criterion which are detailed on the Understanding Success Criterion 2.5.8 - Target Size (Minimum) page.