AccessibilityOperable

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.

Index

Keyboard Accessible

• 2.1.1 - Keyboard accessible
• 2.1.2 - No keyboard trap
• 2.1.4 - Character key shortcuts

Enough time

• 2.2.1 - Timing adjustable
• 2.2.2 - Pause, stop, hide

Seizures and physical reactions

• 2.3.1 - Three flashes or below

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

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
• 2.5.8 - Target size

Keyboard Accessible

2.1.1 - Keyboard accessible

It 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 receive 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

Use the keyboard to navigate the page and check that you can reach all actionable items (e.g. links, buttons, form fields, tabs, sliders, menus) using the Tab or arrow keys, that you can activate all items by pressing the Enter key or Spacebar, and that you can move backward to the top of the page using Shift+Tab.

Helpful links

Home Office Design System - Keyboard basics

2.1.2 - No keyboard trap

No 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

If 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:

• remapping options work including remapping to more complex or chorded shortcuts

OR

• shortcut keys can be switched off.

Helpful links

Home Office Design System - Character key shortcuts

Enough time

2.2.1 - Timing adjustable

When 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 (for example 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
• provide functionality to allow time limits to be extended when a warning is triggered or that allows users to set a timeout limit, for example in settings

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, 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 screen reader
• that on timeout, a screen reader user is alerted that the timeout has occurred

Helpful links

Home Office Design System - Timeouts

2.2.2 - Pause, stop, hide

Avoid 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

A 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 does 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

When 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 activating the link moves the visual and keyboard focus to the start of the main content.

Helpful links

Home Office Design System - Skip to content links

2.4.2 - Page title

Each 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

It 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.

Helpful links

Home Office Design System - Tab navigation

2.4.4 - Link purpose in context

Link 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, for example 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 (for example a PDF document), check that this is clear from their link text.

How to test with JAWS and NVDA

Use the JAWS/NVDA key + F7 to show the elements list which should show you all the links available on the page. Review this to check that the links make sense out of context.

Home Office Design System - Links

2.4.5 - Multiple ways

Unless 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 addition 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

Headings 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 headings 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

Home Office Design System - Headings

2.4.7 - Focus visible

It 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 indication 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 overridden and aligns to the style of the rest of the site.

Helpful links

Home Office Design System - Keyboard focus

2.4.11 - Focus not obscured

When an element receives keyboard focus, the focus indicator is easy to see (not entirely hidden behind other elements).

Understanding Success Criterion 2.4.11: Focus Not Obscured (Minimum)

Implementation guidance

When an interactive element receives keyboard focus, the focus must be easy to see (not entirely hidden behind elements such as cookie banners, sticky headers or footers).

When implementing content such as headers, footers and banners, make sure page content is shifted accordingly and there is no overlap with the focused element. Alternatively restrict keyboard focus to the banner to prevent user from interacting with the underlying page.

How to test with a visual check

If a cookie banner is present, tab around before you dismiss it, to make sure focus indicator does not disappear behind it. Clear your cookie cache to make the banner reappear if necessary.

Then tab around the page to make sure focus indicator does not disapear behind other elements, such as sticky headers or footers.

Input Modalities

2.5.1 - Pointer gestures

Any 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 communicated to screen reader users.

Helpful links

Home Office Design System - Pointer gestures

2.5.2 - Pointer cancellation

Any 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.

There are some limited exceptions to this requirement where a down-key event is part of the expected behaviour. However, we don’t anticipate acceptable uses in the Home Office. If you have a requirement for down-key events, please discuss with the Accessibility Assurance team.

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

For 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

Any functionality that is initiated by tilting or shaking (etc) a device, must be able to be initiated by a button, or other control.

Users must be able to switch off motion actuation.

Understanding Success Criterion 2.5.4: Motion Actuation

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

Any functionality that requires dragging or swiping must be able to be initiated by a button, or other control.

Understanding Success Criterion 2.5.7: Dragging Movements

Implementation guidance

If you are using elements that rely on a dragging movement for operation, like swipeable carousels, maps that rely on dragging for panning or any drag-and-drop functionality, provide a button or other control that doesn’t require dragging.

How to test with a visual check

Identify controls or content which requires dragging, for example drag-and-drop, drag to move position or slider control.

Check if alternatives exist, for example drag-and-drop can be done by assigning an ordering, changing position can be done by arrow 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 communicated to screen reader users.

2.5.8 - Target size

The interactive area of a component must be at least 24 by 24 CSS pixels or have sufficient spacing around it.

Understanding Success Criterion 2.5.8: Target Size (Minimum)

Implementation guidance

Ensure that all interactive elements, apart from links within text, are at least 24 x 24 CSS pixels in size.

Alternatively, ensure that interactive element and area around it meets the required size of 24 x 24 CSS pixels and does not intersect with another interactive element (for smaller components this might also include area around it to the combined size of 24 x 24 CSS pixels).

If the element does not meet those size requirements, make sure there is another way to achieve the same outcome using another element that does.

How to test with a manual check

Use the bookmarklet to check that interactive areas of components are either 24 x 24 CSS pixels, or have at least that much space around them in total to avoid clashing with other interactive areas (24×24 Pixel Cursor Bookmarklet).

Interactive elements could include buttons, radio buttons, checkboxes and carousel controls.