AccessibilityAccessibility Standard

As a public body, the Home Office has a legal responsibility to ensure that the digital services and systems we control are accessible to the widest possible group of people.

To provide consistency for users and product teams, we’ve developed a Home Office Accessibility Standard. This closely aligns with the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA but simplifies and focuses on the areas most likely to present challenges for Home Office users.

Version number Date Description Author
1 01/11/2020 First published version Yacoob Woozeer
1.1 01/08/2021 Updated based on peer review by TetraLogical David Caldwell



Requirement reference Requirement
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.

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.

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.

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.

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 semanatic HTML headings to structure your page. Heads should cascade from H1-H6. Each page must have at least a Level 1 Heading (H1).

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.

1.3.1e - Info and relationship - Landmarks

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

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.

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.

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.

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.

1.4.1 - Use of colour

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

1.4.2 - Audio control

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

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.

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

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.

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.

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.

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.

1.4.13 - Content on hover or focus

Ensuring that extra content eg 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


Requirement reference Requirement
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.

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.

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.

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 (e.g. in settings), turn it off, delay it, or extend the length of time.

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.

2.3.1 - Three flashes or below

A page must not contain content that flashes more than three times a second.

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

2.4.2 - Page title

Each page must have a unique title that indicates its topic or purpose.

2.4.3 - Focus order

It must be possible to navigate through content in a way that makes sense.

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.

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.

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.

2.4.7 Focus visible

It must be easy to tell which element has keyboard focus.

2.5.1 Pointer gestures

Any functionality which requires a multipoint or path based gestures has an alternative single pointer, non path-based gesture.

2.5.2 Pointer cancellation

Any script triggering must be done on the ‘up’ event – not the ‘down’ event.

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.

2.5.4 Motion actuation

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


Requirement reference Requirement
3.1.x - Language of page and parts

The written language of the page must be identified in the code of the web page.

Where multiple written languages are included on a single page, the individual written language must be indentified in the code of the web page.

3.2.1 On Focus

When a keyboard user focuses on a control it must not cause a change of context, such as loading a new page/tab.

3.2.2 On Input

Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behaviour before using the component.

3.2.3 Consistent navigation

When ways to navigate content are repeated on multiple pages, they must be presented in a consistent manner.

3.2.4 Consistent identification

When features with the same functionality are used in multiple places, they must be identified in a consistent way.

3.3.1 Error identification

When an error occurs the user is informed what caused the error, and the error is described in text in an accessible way.

3.3.2 Labels or instructions

When data must be entered in a specific format or in a particular way, clear instructions must be associated with the form field. Password fields should allow a user to view and check the entry.

3.3.3 Error Suggestions

When data must be entered in a specific format or in a particular way, clear instructions must be associated with the form field. Password fields should allow a user to view and check the entry.

3.3.4 Error prevention

All transactions should be reversible, or confirmation must be required before submission.


Requirement reference Requirement
4.1.1 Parsing

The code of the page must not cause browser or assistive technology conflicts. This ensures that content and functionality is presented in a way that works reliably across all supported browsers and assistive technologies.

4.1.2 Name, Role, Value

All interactive components must have an accessible name and role, and the state of the component must be communicated to assistive technologies.

4.1.3 Status messages

There are different situations where a page needs to dynamically display a status message. These messages need to be conveyed to assistive technology users, even when they don’t receive focus. Where possible, you should avoid disturbing the user’s place in a page.

Meet user needs

Requirement reference Requirement
5.1.1 User Research Participants

When doing user research, make sure to include users with disabilities (at least 1 out of every 5 participants).

Get in touch

If you’ve got a question or suggestion share it on the Home Office DDaT Slack channel #ask-accessibility or email