Skip to content

Latest commit

 

History

History
275 lines (146 loc) · 14.8 KB

06-accessibility-checklist.md

File metadata and controls

275 lines (146 loc) · 14.8 KB

A simple accessibility checklist

This checklist aims to help you and your team create accessible products. It's heavily inspired by Vox Media's Accessibility Guidelines.

Semantics and structure

Use the correct HTML element

Browsers build the accessibility tree by making assumptions about page elements and the sort of content they are likely to contain.

Using the correct HTML elements helps the browser make sense of your page, and helps assistive technology users navigate it more easily.

Resources:

Use HTML landmarks

Assistive technology may make use of ARIA landmark roles or HTML5 landmark elements for navigation. These allow users to quickly jump between page sections.

There are 8 landmark roles. Most browsers implicitly detect these roles if you use the correct HTML5 semantic element, but you may need to add the appropriate ARIA role= if you have to support an older browser.

If you use more than one landmark of the same type, give each landmark a unique label so that screen reader users can tell them apart easily.

Resources:

Provide skip links to bypass repetitive content

Not all users are able to easily navigate by landmarks. Multiple navigation links typically found at the top of a document all have to be laboriously tabbed through using a keyboard, on every page the user visits.

To help them out you can add a "Skip Navigation" link to the top of each page which, when activated, will take them to the main section of the page.

The Elements Design System includes a skip link implementation that you can use in your own project(s).

Resources:

Declare a language attribute

Declaring a language attribute on the HTML element allows a screen reader to read out text with correct pronunciation. It also helps search engines return language-specific results.

If you include text on a page that uses a different language to the main document (e.g. your HTML lang is en and you are including a passage in jp), also identify that text with its own lang attribute.

We do this:

<p>This document has the lang="en" attribute, and this text matches the document language.</p>
<p lang="jp">このテキストは日本語です</p>

Resources:

Use a logical source order

Your page should still make sense when you look at it without CSS. This is a core progressive enhancement technique.

Don't surprise users by using CSS to make changes to apparent source order, e.g. by using floats and absolutely-positioned elements.

Flexbox and CSS grids are particularly vulnerable to apparent source order surprises, and you should take extra care when using them.

Resources:

Use headings correctly

The HTML5 outline algorithm can't yet be relied on to convey information to users. Freely use HTML5 sectioning elements, but use headings to define the structure of your document. In basic terms this means one H1 per page! See our HTML markup house style for more information on the outline algorithm and why we don't use multiple level one headings.

Use an appropriate heading for each section. You can visually hide headings, but make sure they're still accessible to screen reader users.

Don't skip heading levels.

Resources:

Use progressive enhancement

Progressive enhancement means starting with a logical and semantic HTML document with all key functionality, then enhancing it with an aesthetic layer (CSS) and behavioural layer (JavaScript). It has benefits beyond accessibility but is a key starting point for creating accessible experiences.

Resources:

Media

Audio or video elements must be accessible

This could involve adding captions to videos, providing transcripts of audio content, including audio description on videos, or including a text alternative for videos that have no audio track.

Automatic captions (e.g. those provided by YouTube) are insufficient for accessibility compliance.

Provide text alternatives for images

Alt attributes should describe the image they're applied to. E.g. the alt attribute for a photograph should describe what's happening in the photograph, not just say "photograph".

Screen reader users prefer alt text to be short and informative. Avoid redundant phrases like "image of...", and try to keep the total text under 125 characters. Don't use the longdesc element for longer descriptions - its browser support is patchy and there are better-supported alternatives.

If an image provides no information, is purely decorative, and can't be moved from HTML into CSS, an empty alt attribute (alt="") is preferred.

Resources:

Colours

Use adequate colour contrast

Text and images of text must have a colour contrast ratio of at least 4.5:1.

Don't use confusable colours. Make sure your choices can be perceived by people with colour blindness.

Resources:

Don't convey information with colour alone

Use text equivalents or semantic emphasis like <strong> or <em> when conveying important information to users. No hyperlinks may be indicated by text color alone. Except in special cases, such as options in navigation menus, use an underline.

Resources:

Interactivity

Give enough time to read and use content

Let the user pause, stop, or hide content that moves, blinks, scrolls, or automatically updates.

Resources:

Disable webfonts and animations when prefers-reduced-motion is selected

Operating systems allow users to indicate that they prefer reduced motion. This is helpful for users with vestibular disorder, anxiety, dizzyness, etc. This choice is exposed in browsers by using the prefers-reduced-motion media query.

Make sure that all animations, including loading of webfonts (which can cause FOUT), are disabled when prefers-reduced-motion is selected.

Resources:

Design for device independence

Make sure users can interact with your page using the keyboard alone.

Don't rely on device-dependent event handlers (e.g. onhover) as the sole method to convey information or to complete tasks.

Make sure interactable elements are large enough for touchscreen users to easily access controls. Leave enough space around controls so that they don't overlap with other touch targets.

Resources:

Give context and orientation information

Give users a way to know where they are in a set of related pages (e.g. the Steps Left pattern).

Make sure the currently-focused element has a focus ring, and make sure the focus sequence is logical.

Avoid opening links in new windows

This can be disorientating to screen reader users or users with cognitive disabilites.

If you must do it, warn the user before they click on the link that it'll open in a new window. You can use visible text like "opens in a new window" or a visual icon. If you choose to use an icon, make sure it's accessible to screen reader users.

Resources:

Forms

Labels and context

  • Associate all form controls with appropriate labels.
  • Use fieldsets or optgroups to group related controls.

Don't use HTML5 input placeholders for important information

Input placeholders disappear when the user begins typing, may be mistaken for a value, and may not provide adequate context.

Never put user instructions in input placeholders - always use a label. The HTML5 specification clarifies that a placeholder should not be used as an alternative to a label.

Resources:

Help users make the most of autocomplete and autofill

By default, browsers remember information that users submit into input fields. The browser can then suggest possible completions for fields that the user has started typing in (autocomplete) or pre-populate certain fields when the page loads (autofill). This behaviour can be turned off in HTML with the autocomplete="false" attribute.

Don't indiscriminately disable autocomplete for input fields. The default autocomplete and autofill behaviours are useful for many users with and without disabilities.

For example, autocomplete helps users with motor disabilities by reducing the amount of typing they need to do in input fields. Autofill can help users with cognitive disabilities by automatically filling in common information like addresses or telephone numbers.

Don't disable autocomplete on sensitive fields like username and password fields. Any security benefits of doing this is negligible compared to the benefits of users' in-browser password managers, and has a direct negative impact on accessibility. Read the note on autofill in the secure markup guide for more on that.

For fields where the user is expected to input information about themselves, use a valid autocomplete value if one exists - this helps make form filling software more effective. The HTML specification provides a list of valid autocomplete values.

Don't use autocomplete values on input fields where the user is expected to input one-time information about somebody else (e.g. a teacher filling out a form with the details of a list their students).

Resources:

Content

Use link text that makes sense out of context

Screen reader users may navigate a page by links alone. Avoid link text that says "click here", or context-free text like "More details" repeatedly applied to a list of links.

Resources:

Use tables appropriately

Don't use tables for layout. If a data table lacks important characteristics like <th> elements, some assistive technology may treat it as though it's a layout table and read its contents linearly. This can make it much more difficult for a screen reader user to understand.

Resources: