Accessibility success criteria
As an organisation, we have a legal obligation to ensure the digital products and services we produce are accessible to anyone who requires them.
The list below covers the success criteria to meet certain levels (A, AA or AAA) across a range of principles. For a more detailed overview of what accessibility is and how we can implement accessible features, read our guidance and best practice or visit the WCAG website.
WCAG | Feature | Level | Success Criteria | Covered by |
---|---|---|---|---|
PerceivableInformation and UI components must be presentable to users in ways they can understand. | ||||
1.1.1 | Non-text-content | A | Non-text content should have a text alternative that serves the equivalent purpose, except for the following cases:
| Developers, Content Designers/Editors |
Time-based mediaAlternatives to time-based media should be provided | ||||
1.2.1 | Time based media (audio, video) | A | An alternative to time-based media should be provided that presents equivalent information | Video/Creative |
1.2.2 | A | Captions should be provided for prerecorded audio content | Video/Creative | |
1.2.3 | A | Audio descriptions should be provided for prerecorded video content | Video/Creative | |
AdaptableIt should be possible to present content in different ways without losing information or structure | ||||
1.3.1 | Info and relationships | A | Information, structure and relationships conveyed through presentation should be available in text or implemented in a way that assistive technologies can understand | Content Designers/Editors, Developers and UX |
1.3.2 | Meaningful sequence | A | Screen-readers should follow a meaningful reading sequence | Developers (with aid by UX) |
1.3.3 | Sensory characteristics | A | Instructions provided for understanding or operating content should not rely solely on sensory characteristics of components such as:
| UX and Content Designers/Editors |
1.3.4 | Orientation | AA | The visibility or operation of content should not be restricted to a single display orientation | Developers |
1.3.5 | Inputs | AA | Input fields that collect information about the user should be implemented in a way that assistive technologies can identify their purpose | Developers (+ UX for design) |
1.3.6 | UI components and icons | AAA | UI components, icons and regions should be implemented in a way that assistive technologies can identify their purpose | Developers (+UX and Creative to supply icons) |
DistinguishableIt should be easy for users to distinguish content, including separating foreground from background | ||||
1.4.3, 1.4.6 | Text/ Typography | AA, AAA | Text should have a contrast ratio of at least 4.5:1 (AA) or 7:1 (AAA), except for the following cases:
| UX |
1.4.4 | AA | Content should retain meaning when magnified to 200% | Developers (handled in build) | |
1.4.5 | AA | Images of text should be avoided with no exception unless technologies being used cannot achieve the visual presentation. In which case only used for pure decoration or where a particular presentation of text is essential to the information being conveyed | Creative (but enforced by all disciplines) | |
1.4.8 | AAA | Blocks of text should:
| ||
1.4.12 | AA |
| UX | |
1.4.13 | Additional content shown on hover/focus | AA |
| Developers (with aid by UX) |
OperableUser interface components and navigation must be operable | ||||
2.1.1 | Keyboard | A | All functionality should be available through keyboard input | Developers |
2.1.2 | A | There should be no keyboard traps | Developers | |
Enough timeProvide users enough time to read and use content | ||||
2.2.1 | Timed content | A | Users should be provided enough time to read content | UX |
For each time limit set on content at least one of the following should be available:
Exceptions:
| ||||
2.2.2 | Moving, blinking, scrolling or auto-updating content | A | For any moving, blinking or scrolling information that
there should be a mechanism for the user to pause, stop, or hide it, unless it is essential. For any auto-updating information that
there should be a mechanism for the user to pause, stop, or hide it or to control the frequency of the update, unless the auto-updating is essential | UX & Creative (with aid of Developers) |
2.2.3 | Timing of interaction | AAA | Content that requires timed interaction should not be an essential part of the activity presented to the user, except for non-interactive synchronised media and real-time events | |
2.2.4 | Interruptions | AAA | Interruptions, such as updates from the author/server, can be postponed or suppressed by the user, except interruptions involving an emergency | |
2.2.5 | Data persistence | AAA | When an authentication session expires, the user should be able to continue the activity without loss of data after re-authenticating | |
2.2.6 | AAA | Users are warned of the duration of any user inactivity that could cause data loss, unless the data is preserved for more than 20 hours | ||
Seizures and Physical reactionsDo not design content in a way that is known to cause seizures or physical reactions | ||||
2.3.1, 2.3.2 | Physical reactions/Seizures | A, AA | Web pages should not contain anything that flashes more than three times in any one second period | Creative, UX and Developers |
2.3.3 | AAA | It should be possible to disable any motion animation triggered by interaction | ||
NavigableProvide ways to help users navigate, find content, and determine where they are | ||||
2.4.1 | Navigable | A | A mechanism should be available to bypass blocks of content that are repeated on multiple pages | Developers |
2.4.2 | A | Web pages should have titles that describe their topic or purpose | Content Designers/Editors | |
2.4.3 | A | Focusable components receive focus in an order that preserves meaning and operability | Developers (aided by UX) | |
2.4.4 | A | It should be possible to determine the purpose of each link from the link text alone | Content Designers/Editors | |
2.4.5 | AA | More than one way is available to locate a webpage within a set of web pages. Except where the web page is the result of, or a step in, a process | See comment | |
2.4.6 | AA | Headings and labels should describe their topic or purpose | Content Designers/Editors & UX | |
2.4.7 | AA | Keyboard focus indicator should be visible | Developers & UX (See comment) | |
2.4.8 | AAA | Information about the user’s location within a set of web pages is available | ||
2.4.9 | AAA | Each link should be identifiable by its link text alone | ||
2.4.10 | AAA | Section headings and titles are used to organise the content | ||
Input ModalitiesMake it easier for users to operate functionality through various inputs beyond keyboard | ||||
2.5.1 | Pointer gestures | A | All functionality that uses multipoint or path-based gestures for operation can be operated with a single pointer without a path-based gesture, unless a multipoint or path-based gesture is essential | Developers |
2.5.2 | A | For functionality that can be operated using a single pointer, at least one of the following should be true:
| Developers | |
2.5.3 | Labels | A | For UI components that have labels, such as input fields, their HTML name attribute should contain the same text that is presented visually | Developers & Content Designers/Editors |
2.5.5 | Buttons | AAA | The size of targets should be at least 44x44px (or equivalent), except when:
| |
2.5.6 | Input mechanisms | AAA | Web content should not restrict a user's input mechanisms, except when restriction is:
| |
ReadableMake text content readable and understandable. | ||||
3.1.1 | Language | A | The default human language of each page should be programmatically determined in a way that assistive technologies understand | Developers |
3.1.2 | AA | The human language of each passage or phrase should be programmatically determined in a way that assistive technologies understand, except for:
| See comment | |
3.1.3 | AAA | A mechanism should be available for identifying specific definitions of words or phrases | ||
3.1.4 | AAA | A mechanism should be available for expanding meaning of abbreviations | ||
PredictableMake Web pages appear and operate in predictable ways | ||||
3.2.1 | On focus | A | When a UI component receives focus, it should not cause a major change in the content of the web page | Developers (checked by UX/QA) |
3.2.2 | On input | A | Changing the setting of any UI component should not cause a major change in the content of the web page, unless the user has been advised of the behaviour before using the component | See comment |
3.2.3 | Consistent navigation | AA | Navigation mechanisms should be consistent across all pages | UX & Developers |
3.2.4 | Consistent components | AA | Components that have the same functionality should be identified consistently across all pages | UX & Developers (refer to up to date Pattern Library) |
3.2.5 | Content changes on request | AAA | Major changes in the content of the web page are initiated only by the user request or a mechanism is available to turn off such changes | |
3.3.1 | Error identification | A | If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text | UX, Content Designers/Editors, Developers |
3.3.2 | Labels | A | Content that requires user input should have labels or instructions | Content Designers/Editors & UX |
3.3.3 | Error suggestions | AA | If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardise the security or purpose of the content | UX & Content Designers/Editors (implemented by Developers) |
3.3.4, 3.3.6 | Error prevention | AA, AAA | At least one of the following should be true…
(AAA) For all Web pages that require the user to submit information…
| Developers |
3.3.5 | Help | AAA | Help text that provides information related to the function currently being performed should be available | |
RobustContent must be robust and compatible enough that it can be interpreted by a wide variety of current and future user agents, including assistive technologies | ||||
4.1.1 | Markup | A | Markup should be valid and well formed. Except where the specifications allow these features, elements should:
| Developers |
4.1.2 | A | The name and role should be programmatically determined for each UI component. | Developers & UX | |
4.1.3 | Status Messages | AA | Status messages should be presented to the user by assistive technology without receiving focus i.e. using role | Developers & UX |
Other accessibility guides
Related
Read our other content guides
Read our brand guidelines
Contact us
Have a question or comment about accessibility or other digital topic? Found a bug? Or maybe you’d like to contribute to the framework? Use our contact form to get in touch.