It’s awesome to build sites that are inclusive and accessible to everyone. There are at least six key areas of disability we can optimize for: visual, hearing, mobility, cognition, speech and neural. Many tools and resources can help here, even if you’re totally new to web accessibility.
Over 1 billion people live with some form of disability. You might have been in a loud room at some point trying to hear the conversation around you or in a low-lighting condition trying to find something in the dark. Do you remember the frustration you felt with that circumstance? Now, imagine if that temporary condition was permanent. How different would your experience on the web be?
To be accessible, sites need to work across multiple devices with varying screen-sizes and different kinds of input, such as screen readers. Moreover, sites should be usable by the broadest group of users, including those with disabilities. Here are a sample of just a few disabilities your users may have:
| Vision | Hearing | Mobility |
|---|---|---|
| – Low vision – Blind – Color blind – Cataracts – Sun glare |
– Hard of hearing – Deaf – Noise – Ear infection |
– Broken arm – Spinal cord injury – Limited dexterity – Hands full |
| Cognitive | Speech | Neural |
| – Learning disabilities – Sleepy or distracted – Migraine – Autism – Seizure |
– Ambient noise – Sore throat – Speech impediment – Unable to speak |
– Depression – PTSD – Bipolar – Anxiety |
Visual issues range from an inability to distinguish colors to no vision at all.
-
Ensure a minimum contrast ratio threshold is met for text content.
-
Avoid communicating information using solely color and ensure that all text is resizable.
-
Ensure all user interface components can be used with assistive technologies such as screen readers, magnifiers and braille displays. This entails ensuring that UI components are marked up such that accessibility APIs can programmatically determine the role, state, value and title of any element.
Tip: Inspect element in Chrome, Edge and Firefox DevTools displays a tooltip of CSS properties that includes a quick check for color contrast ratio.
I personally live with low-vision and am embarrassed to say, I’m that person that always zooms in on sites, their DevTools and terminal. While supporting zoom is almost never at the top of anyone’s list, optimizing for low-vision users is always appreciated… 🤓
Hearing issues mean a user may have issues hearing sound emitted from a page.
-
Make the content understandable using text alternatives for all content that is not strictly text.
-
Ensure you test that your UI components are still functional without sound.
Mobility issues can include the inability to operate a mouse, a keyboard or touch-screen.
-
Make the content of your UI components functionally accessible from a keyboard for any actions one would otherwise use a mouse for.
-
Ensure pages are correctly marked up for assistive technologies; these users may use technologies such as voice control software and physical switch controls, which tend to use the same APIs as other assistive technologies like screen readers.
Cognitive issues mean a user may require assistive technologies to help them with reading text, so it’s important to ensure text alternatives exist.
- Be mindful when using animations. Avoid a visual presentation that is repetitive or flashing as this can cause some users issues.
The prefers-reduced-motion CSS media query allows you to limit animations and autoplaying videos for users who prefer reduced motion.
/*
If the user expressed a preference for reduced motion, don't use animations on buttons.
*/
@media (prefers-reduced-motion: reduce) {
button {
animation: none;
}
}
- Avoid interactions that are timing-based.
This may seem like a lot of bases to cover, but we’ll walk through the process for assessing and then improving the accessibility of your UI components.
Tip: Some great accessibility do’s and don’ts digital posters are available by the Gov.uk accessibility team for spreading awareness of best practices in your team:
Are your UI components accessible?
Summary (tl;dr)
When auditing your page’s UI components for accessibility, ask yourself:
-
Can you use your UI component with the keyboard only? Does it manage to focus and avoid focus traps? Can it respond to the appropriate keyboard events?
-
Can you use your UI component with a screen reader? Have you provided text alternatives for any information which is presented visually? Have you added semantic information using ARIA?
-
Can your UI component work without sound? Turn off your speakers and go through your use cases.
-
Can it work without color? Ensure your UI component can be used by someone who cannot see colors. A helpful tool for simulating color blindness is a Chrome extension called SEE, (try all four forms of color blindness simulation available). You may also be interested in the Daltonize extension which is similarly useful.
-
Can your UI component work with high-contrast mode enabled? All modern operating systems support a high contrast mode. High Contrast is a Chrome extension available that can help here.
Native controls (such as and ) have accessibility built-in by the browser. They are focusable using the tab key, respond to keyboard events (like Enter, space and arrow keys), and have semantic roles, states and properties used by accessibility tools. The default styling should also meet the accessibility requirements listed above.
Custom UI components (with the exception of components that extend native elements like ) do not have any built-in functionality, including accessibility, so this needs to be provided by you. A good place to start when implementing accessibility is to compare your components to an analogous native element (or a combination of several native elements, depending on how complex your component is).
Tip: Most browser DevTools support inspecting the accessibility tree of a page. In Chrome, this is available via the Accessibility tab in the Elements panel.
Firefox also has an Accessibility panel and Safari exposes this information in the Element’s panel Node tab.
The following is a list of questions you can ask yourself when attempting to make your UI components more accessible.
Can your UI component be used with the keyboard alone?
Ideally, ensure that all functionality in your UI component can be reached by a keyboard. During your UX design, think about how you would use your element with the keyboard alone, and figure out a consistent set of keyboard interactions.
Firstly, ensure that you have a sensible focus target for each component. For example, a complex component like a menu may be one focus target within a page, but should then manage focus within itself so that the active menu item always takes focus.
Managing focus within a complex element
Using tabindex
The tabindex attribute allows elements / UI components to be focused using the keyboard. Keyboard-only and assistive technology users both need to be able to place keyboard focus on elements in order to interact with them. Native interactive elements are implicitly focusable, so they don’t need a tabindex attribute unless we wish to change their position in the tab order.
There are three types of tabindex values:
-
tabindex=”0″ is the most common, and will place the element in the “natural” tab order (defined by the DOM order).
-
a tabindex value greater than 0 will place the element in a manual tab order — all elements in the page with a positive tabindex value will be visited in numerical order before elements in the natural tab order.
-
a tabindex value equal to -1 will cause the element to be programmatically focusable, but not in the tab order.
For custom UI components, always use tabindex values of 0 or -1, as you won’t be able to determine the order of elements on a given page ahead of time — and even if we did, they may be subject to change. A tabindex value of -1 is particularly useful for managing focus within complex components as described above.
Also ensure that focus is always visible, whether by allowing the default focus ring style, or applying a discernible focus style. Remember not to trap the keyboard user — focus should be able to be moved away from an element using only the keyboard.
You may also be interested in the roving tabindex or aria-activedescendant approaches, covered over on MDN.
Using autofocus
The HTML autofocus attribute allows an author to specify that a particular element should automatically take focus when the page is loaded. It is already supported on all web form controls, including . To autofocus elements in your own custom UI components, call the focus() method supported on all HTML elements that can be focused (e.g document.querySelector('myButton').focus()).
Adding keyboard interaction
Once your UI component is focusable, try to provide a good keyboard interaction story when a component is focused, by handling appropriate keyboard events — for example, allow the user to use arrow keys to select menu options, and space or enter to activate buttons. The ARIA design patterns guide provides some guidance here.
Finally, ensure that your keyboard shortcuts are discoverable. For example, a common practice is to have a keyboard shortcut legend (on-screen text) to inform the user that shortcuts exist. For example, “Press ? for keyboard shortcuts”. Alternatively a hint such a tooltip could be used to inform the user about the shortcut existing.
The importance of managing focus cannot be understated. One example is a navigation drawer. If adding a UI component to the page you need to direct focus to an element inside of it otherwise users may have to tab through the entire page to get there. This can be a frustrating experience, so be sure to test focus for all keyboard navigable components in your page.
Tip: You can use Puppeteer to automate running keyboard accessibility tests for toggling UI states. WalkMe Engineering have a great guide on this I recommend reading.
// Example for expanding and collapsing a category with the spacebar key
const category = await page.$(`.category`);
// verify tabIndex, role and focus
expect(await page.evaluate(elem => elem.getAttribute(`role`), category)).toEqual(`button`);
expect(await page.evaluate(elem => elem.getAttribute(`tabindex`), category)).toEqual(`0`);
expect(await page.evaluate(elem => window.document.activeElement === elem, category)).toEqual(true);
// verify aria-expanded = false
expect(await page.evaluate(elem => elem.getAttribute(`aria-expanded`), category)).toEqual(`false`);
// toggle category by press space
await page.keyboard.press('Space');
// verify aria-expanded = true
expect(await page.evaluate(elem => elem.getAttribute(`aria-expanded`), category)).toEqual(`true`);
Can you use your UI component with a screen reader?
Around 1–2% of users will be using a screen reader. Can you determine all important information and interact with the component using the screen reader and keyboard alone?
The following questions should help guide you in addressing screen reader accessibility:
Do all components and images have meaningful text alternatives?
Wherever information about the name or purpose of an interactive component is conveyed visually, an accessible text alternative needs to be provided.
For example, if your
Any UI component which displays an image should provide a mechanism for providing alternative text for that image, analogous to the alt attribute.
Do your components provide semantic information?
Assistive technology conveys semantic information which is otherwise expressed to sighted users via visual cues such as formatting, cursor style, or position. Native elements have this semantic information built-in by the browser, but for custom components you need to use ARIA to add this information in.
As a rule of thumb, any component which listens to a mouse click or hover event should not only have some kind of keyboard event listener, but also an ARIA role and potentially ARIA states and attributes.
For example, a custom
A range slider component
role="slider" aria-valuemin="1" aria-valuemax="5"
aria-valuenow="2.5">
Can users understand everything without relying on color?
Color shouldn’t be used as the only means of conveying information, such as indicating a status, prompting for a response or distinguishing a visual custom component. For example, if you created an
Is there sufficient contrast between the text/images and the background?
Any text content displayed in your component should meet the minimum (AA) contrast bar. Consider providing a high-contrast theme which meets the higher (AAA) bar, and also ensure that user agent style sheets can be applied if users require extreme contrast or different colors. You can use this Color Contrast Checker as an aid when doing design.
Is the moving or flashing content in your components stoppable and safe?
Content that moves, scrolls or blinks that lasts for anything more than 5 seconds should be able to be paused, stopped or hidden. In general, try to flash no more than three times per second.
Accessibility Tooling
A number of tools are available that can assist with debugging the accessibility of your visual components.
-
Axe provides automated accessibility testing for your framework or browser of choice. Axe Puppeteer can be used for writing automated accessibility tests.
-
The Lighthouse Accessibility audits provide helpful insights for discovering common accessibility issues. The accessibility score is a weighted average of all accessibility audits, based on Axe user impact assessments. For monitoring accessibility via continuous integration, see Lighthouse CI.
-
Tenon.io is useful for testing common accessibility problems. Tenon has strong integration support across build tools, browsers (via extensions) and even text editors.
-
There are many library and framework specific tools for highlighting accessibility issues with components. e.g web.dev covers using eslint-plugin-jsx-a11y to highlight accessibility issues for React components in your editor:
If you use Angular, codelyzer provides in-editor accessibility audits too:
-
You can examine the way that assistive technologies see web content by using Accessibility Inspector (Mac), or Windows Automation API Testing Tools and AccProbe (Windows). Additionally you can see the full accessibility tree that Chrome creates by navigating to chrome://accessibility.
-
The best way to test for screen reader support on a Mac is using the VoiceOver utility. You can use ⌘F5 to enable/disable, Ctrl Option ←→ to move through the page and Ctrl Shift Option ↑↓ to move up/down tree. For more detailed instructions, see the full list of VoiceOver commands and the list of VoiceOver Web commands.
-
tota11y is a useful visualiser for assistive technology issues built by Khan Academy. It’s a script that adds a button to your document that triggers several plugins for annotating things like insufficient contrast ratio and other a11y violations.
-
On Windows, NVDA is a free, open source screen reader which is fully featured and rapidly gaining in popularity. However, note that it has a much steeper learning curve for sighted users than VoiceOver.
-
ChromeLens helps develop for the visually impaired. It’s also got great support for visualising keyboard navigation paths http://chromelens.xyz/
- ChromeVox is a screen reader which is available as a Chrome extension, and built in on ChromeOS devices.
We still have a long way to go improving accessibility on the web. Per the Web Almanac:
- 4 out of every 5 sites have text which easily blends into the background, making it unreadable.
- 49.91% of pages still fail to provide alt attributes for some of their images
- Only 24% of pages that use buttons or links include textual labels with these controls.
- Only 22.33% of pages provide labels for all their form inputs.
To learn more about accessibility fundamentals to help us improve the above, I recommend the Accessible to all docs on web.dev. There’s much we can do to build experiences that are more inclusive of everyone.
