Accessibility Tips for Web Developers

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