AccessibilityAccessibility Standard

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

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.

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.

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.

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.

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.

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

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

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

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

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.

Unless the service is a series of steps, there must be different ways for people to locate and navigate content.

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.

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

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

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

For user interface components with labels that include text or images of text, the Accessible name contains the text that is presented visually.

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.

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.

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

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.

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

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

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

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.

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.

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

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.

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

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.

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