Accessibility Checklist
Use this checklist to help build accessibility standards into your process, to check and record progress.
Global code
- Default language Use a <lang> attribute on the <html> element of each web page.
- Semantic HTML Use the correct HTML elements for our content
- Unique page title element Ensure that each web page has a unique title element that describes the page's content/topic.
Keyboard navigation
- Focus state Keyboard focus around interactive elements should always be visible as you tab through the elements.
- Keyboard interaction All focusable interactive elements are operable with a keyboard and can be navigated to and from using the Tab key
- Logical Tab order Interactive elements need to receive keyboard focus in a logical reading order when navigating with the Tab key.
Minimum contrast ratio
- Text contrast Ensure a contrast ratio of at least 4.5:1 between text (and images of text) and the background behind the text, and at least 3:1 for large text (18 point or 14 point bold)
Multi device responsive design
- Text resizing Except for captions and images of text, text can be resized without assistive technology up to 200% without any loss of content or functionality and without overlapping with other content.
- Touch targets Touch targets are large enough (48x48dp) for reliable interaction of interface controls through click and touch.
Moving, flashing, or blinking content
- Content flash No page content flashes/flickers more than 3 times per second
- Stop motion For any moving, blinking, scrolling or auto-updating information (e.g., a ticker) that starts automatically, lasts more than five seconds, and is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it.
Headings
- Clear headings If headings are provided, they need to be clear and descriptive.
- Sequential headings Heading tags (h1, h2, etc.) appear in descending, sequential order within the web page/DOM tree.
Forms, labels, and errors
- Form errors Provide accessible error handling
- Form labels Associate clear labels or instructions with every form control that require user input
- Forms keyboard accessible Check that all form controls are keyboard accessible
Written material (copy)
- Clear content Content should be written as clearly and simply as possible.
- Meaningful link text Link texts should be meaningful when read out of context
Image text alternatives
- Image alt text Images have text alternatives that describe the image or the function of the image
Semantics and ARIA
The Web Accessibility Initiative’s Accessible Rich Internet Applications specification (WAI-ARIA, or ARIA) defines a way to make web content and web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies. Dynamic error messages and live content updates can be called out to screen readers, buttons can be linked to the content they affect and many other helpful states can be expressed on a code level.
When to use ARIA
- Use native HTML elements or attributes first. In the case that the semantics you are looking for is not available in HTML, then use ARIA to communicate the semantics. For example, a complex tabbed-interface has no semantic equivalent with HTML, but an ARIA
role="tablist"and its related attributes can be added to provide this detail to screen readers. - When it is not possible to style the native HTML element (exceptional cases), then it is okay to construct the custom element and style and provide the semantics to the element by using ARIA.
How ARIA works
It works by allowing you to specify attributes that modify the way an element is translated into the accessibility tree. One of the core aspects of the ARIA system is its collection of roles, states and properties. A role in accessibility terms amounts to a shorthand indicator for a particular UI pattern. ARIA provides a vocabulary of patterns we can use via the role attribute on any HTML element. ARIA does not add new functionality and is meant to act only as an extra descriptive layer for screen readers. ARIA is also beholden to its host language and must adhere to the rules of what elements it can, and cannot, be used on.
Resources
- WAI-ARIA Overview (W3C)
- Using ARIA (W3C)
- Top 5 rules of ARIA
- ARIA Authoring Practices document (W3C best practices for using ARIA roles and properties)
- Landmark Roles Design Patterns
- Native HTML Use native HTML elements or attributes first before using ARIA