Web Accessibility Cheat Sheet
Checklist of things to consider to improve the accessibility of your website
December 27th, 2021
Table of Contents
TL;DR
Use Lighthouse to check your website's accessibility. You will see the same exact information in the Accessibility report.
Introduction
Accessibility is the practice of making your websites usable by as many people as possible. We traditionally think of this as being about people with disabilities, but the practice of making sites accessible also benefits other groups such as those using mobile devices, or those with slow network connections.
You might also think of accessibility as treating everyone the same, and giving them equal opportunities, no matter what their ability or circumstances. Just as it is wrong to exclude someone from a physical building because they are in a wheelchair (modern public buildings generally have wheelchair ramps or elevators), it is also not right to exclude someone from a website because they have a visual impairment. We are all different, but we are all human, and therefore have the same human rights.
To learn more, check this page where I copy pasted the content above.
ARIA (Accessible Rich Internet Applications)
Accessible Rich Internet Applications (ARIA) is a set of attributes that define ways to make web content and web applications (especially those developed with JavaScript) more accessible to people with disabilities.
It supplements HTML so that interactions and widgets commonly used in applications can be passed to assistive technologies when there is not otherwise a mechanism. For example, ARIA enables accessible navigation landmarks in HTML4, JavaScript widgets, form hints and error messages, live content updates, and more.
Warning: Many of these widgets were later incorporated into HTML5, and developers should prefer using the correct semantic HTML element over using ARIA, if such an element exists. For instance, native elements have built-in keyboard accessibility, roles and states. However, if you choose to use ARIA, you are responsible for mimicking (the equivalent) browser behavior in script.
Here are some accessibility guidelines related to ARIA:
[aria-*]attributes match their roles
Each ARIA role supports a specific subset of aria-* attributes. Mismatching these invalidates the aria-* attributes.
[aria-hidden="true"]is not present on the document<body>
Assistive technologies, like screen readers, work inconsistently when aria-hidden="true" is set on the document <body>.
button,link, andinputelements have accessible names
When an element doesn't have an accessible name, screen readers announce it with a generic name, making it unusable for users who rely on screen readers.
meter,progressbar,tooltip,treeitem, andmenuitemelements have accessible names
When an element doesn't have an accessible name, screen readers announce it with a generic name, making it unusable for users who rely on screen readers.
[aria-hidden="true"]elements do not contain focusable descendents
Focusable descendents within an [aria-hidden="true"] element prevent those interactive elements from being available to users of assistive technologies like screen readers.
[role]s have all required[aria-*]attributes
Some ARIA roles have required attributes that describe the state of the element to screen readers.
[role]values are valid
ARIA roles must have valid values in order to perform their intended accessibility functions.
[aria-*]attributes have valid values
Assistive technologies, like screen readers, can't interpret ARIA attributes with invalid values.
[aria-*]attributes are valid and not misspelled
Assistive technologies, like screen readers, can't interpret ARIA attributes with invalid names.
- Elements with an ARIA
[role]that require children to contain a specific[role]have all required children.
Some ARIA parent roles must contain specific child roles to perform their intended accessibility functions.
[role]s are contained by their required parent element
Some ARIA child roles must be contained by specific parent roles to properly perform their intended accessibility functions.
- ARIA toggle fields have accessible names
When a toggle field doesn't have an accessible name, screen readers announce it with a generic name, making it unusable for users who rely on screen readers.
- Custom controls have ARIA roles
Custom interactive controls have appropriate ARIA roles.
- ARIA IDs are unique
The value of an ARIA ID must be unique to prevent other instances from being overlooked by assistive technologies.
- Custom controls have associated labels
Custom interactive controls have associated labels, provided by aria-label or aria-labelledby.
Navigation
Navigation is the way users find and traverse the different pages available on your site. For this reason, it is imperative that navigation is accessible. By their nature, links are tab-able and all keyboard users and screen readers will read them–so, if your navigation is coded with links, a screen reader should find them.
Here are some accessibility guidelines related to navigation:
- HTML5 landmark elements are used to improve navigation
Landmark elements (<main>, <nav>, etc.) are used to improve the keyboard navigation of the page for assistive technology.
- The page contains a heading, skip link, or landmark region
Adding ways to bypass repetitive content lets keyboard users navigate the page more efficiently.
[accesskey]values are unique
Access keys let users quickly focus a part of the page. For proper navigation, each access key must be unique.
- Visual order on the page follows DOM order
DOM order matches the visual order, improving navigation for assistive technology.
- The page has a logical tab order
Tabbing through the page follows the visual layout. Users cannot focus elements that are offscreen.
- No element has a
[tabindex]value greater than 0
A value greater than 0 implies an explicit navigation ordering. Although technically valid, this often creates frustrating experiences for users who rely on assistive technologies.
- Interactive controls are keyboard focusable
Custom interactive controls are keyboard focusable and display a focus indicator.
- The user's focus is directed to new content added to the page
If new content, such as a dialog, is added to the page, the user's focus is directed to it.
- User focus is not accidentally trapped in a region
A user can tab into and out of any control or region without accidentally trapping their focus.
- Buttons have an accessible name
When a button doesn't have an accessible name, screen readers announce it as "button", making it unusable for users who rely on screen readers.
Semantic structure
Structural, semantic HTML is the key starting point toward good accessibility practices. When a screen reader, or any sort of assistive device scans a web page, it gets information about the Document Object Model (DOM), or the HTML structure of the page. No styles or JavaScript will be read by a screen reader.
Here are some accessibility guidelines related to semantic structure:
- Heading elements appear in a sequentially-descending order
Properly ordered headings that do not skip levels convey the semantic structure of the page, making it easier to navigate and understand when using assistive technologies.
- Lists contain only
<li>elements and script supporting elements(<script> and <template>)
Screen readers have a specific way of announcing lists. Ensuring proper list structure aids screen reader output.
- List items
<li>are contained within<ul>or<ol>parent elements
Screen readers require list items (<li>) to be contained within a parent <ul> or <ol> to be announced properly. Learn more.
<dl>'s contain only properly-ordered<dt>and<dd>groups,<script>,<template>or<div>elements.
When definition lists are not properly marked up, screen readers may produce confusing or inaccurate output.
- Definition list items are wrapped in
<dl>elements
Definition list items (<dt> and <dd>) must be wrapped in a parent <dl> element to ensure that screen readers can properly announce them.
- Cells in a
<table>element that use the[headers]attribute refer to table cells within the same table.
Screen readers have features to make navigating tables easier. Ensuring <td> cells using the [headers] attribute only refer to other cells in the same table may improve the experience for screen reader users.
<th>elements and elements with[role="columnheader"/"rowheader"]have data cells they describe.
Screen readers have features to make navigating tables easier. Ensuring table headers always refer to some set of cells may improve the experience for screen reader users.
Visual
Here are some accessibility guidelines related to visual consideration:
- Background and foreground colors have a sufficient contrast ratio
Low-contrast text is difficult or impossible for many users to read.
[user-scalable="no"]is not used in the<meta name="viewport">element and the[maximum-scale]attribute is not less than 5.
Disabling zooming is problematic for users with low vision who rely on screen magnification to properly see the contents of a web page.
Language
Here are some accessibility guidelines related to language:
<html>element has a valid value for its[lang]attribute
Specifying a valid BCP 47 language helps screen readers announce text properly.
<html>element has a[lang]attribute
If a page doesn't specify a lang attribute, a screen reader assumes that the page is in the default language that the user chose when setting up the screen reader. If the page isn't actually in the default language, then the screen reader might not announce the page's text correctly.
[lang]attributes have a valid value
Specifying a valid BCP 47 language on elements helps ensure that text is pronounced correctly by a screen reader.
Forms
Forms are constantly being used to collect information from users: signing up for something, buying something, asking a question, or contacting someone. Since forms are so commonly used, it is imperative to make forms accessible for all users.
Here are some accessibility guidelines related to forms:
- No form fields have multiple labels
Form fields with multiple labels can be confusingly announced by assistive technologies like screen readers which use either the first, the last, or all of the labels.
- Form elements have associated labels
Labels ensure that form controls are announced properly by assistive technologies, like screen readers.
Alternate Text
Alternative text is a textual substitute for non-text content in web pages.
Alternative text serves several functions:
- Screen readers announce alternative text in place of images, helping users with visual or certain cognitive disabilities perceive the content and function of the images.
- If an image fails to load or the user has blocked images, the browser will present the alternative text visually in place of the image.
- Search engines use alternative text and factor it into their assessment of the page purpose and content.
Here are some accessibility guidelines related to alternate text:
- Image elements have
[alt]attributes
Informative elements should aim for short, descriptive alternate text. Decorative elements can be ignored with an empty alt attribute.
<input type="image">elements have[alt]text
When an image is being used as an <input> button, providing alternative text can help screen reader users understand the purpose of the button.
<object>elements have[alt]text
Screen readers cannot translate non-text content. Adding alt text to <object> elements helps screen readers convey meaning to users.
- Links have a discernible name
Link text (and alternate text for images, when used as links) that is discernible, unique, and focusable improves the navigation experience for screen reader users.
Other accessibility considerations
- Document has a
<title>element
The title gives screen reader users an overview of the page, and search engine users rely on it heavily to determine if a page is relevant to their search.
- The document does not use
<meta http-equiv="refresh">
Users do not expect a page to refresh automatically, and doing so will move focus back to the top of the page. This may create a frustrating or confusing experience.
[id]attributes on active, focusable elements are unique
All focusable elements must have a unique id to ensure that they're visible to assistive technologies.
<frame>or<iframe>elements have a title
Screen reader users rely on frame titles to describe the contents of frames.
<video>elements contain a<track>element with[kind="captions"]
When a video provides a caption it is easier for deaf and hearing impaired users to access its information.
- Interactive elements indicate their purpose and state
Interactive elements, such as links and buttons, should indicate their state and be distinguishable from non-interactive elements.
- Offscreen content is hidden from assistive technology
Offscreen content is hidden with display: none or aria-hidden=true.