The Ultimate Guide to Accessibility for UX Teams

What is web accessibility?

According to the W3C, web accessibility means that websites, tools, and technologies are designed and developed so that people with disabilities can use them. More specifically, people can:

perceive, understand, navigate, and interact with the Web
contribute to the Web

The Fields of Accessibility

There are three main fields of study when speaking about accessibility:

Universal Design:
- Universal Design is the design of products and environments that are made be usable by all people, without the need for adaptation or specialized design.
- It focuses on design for as most users as possible, but isn’t providing support for additional edge cases.
- Universal Design Overview: One design solves for as many people as possible.
Inclusive Design
- Inclusive design is a methodology focusing on making experiences accessible to ALL people with a wide range of human diversity (such as different races, genders, ages, socioeconomic status, disabilities, education level, etc.)
- Inclusive Design Overview: Multiple design solutions and edge cases are created to cater to specific user’s needs.
Accessibility Design
- Accessibility design is a subset of inclusive design.
- Accessibility design focuses specifically on users with disabilities, and designing better experiences for them.
- Accessibility Overview: Multiple design solutions and edge cases focused solely on making better experiences for disabled demographics.
- This is the focus of this article – designing experiences to be better for users within disabled demographics.

Why is web accessibility important?

According to the CDC, there is currently 61 million people in the US with a disability. That means that 26% of our US population is disabled. Those statistics mean that as a designer or developer, if you are not accounting for web accessibility in your projects, 1 out of every 4 of your users won’t be able to use your website. That’s a huge portion of your user base, and for an e-commerce platform, a 26% decrease in your user base affects your bottom line – a direct 26% potential monetary profit loss.

Different Types of User Disabilities

The 61 million people in the US with disabilities don’t all have the same disability type. This means that implementing web-accessibility in a project is not a one-stop solve-all solution. The types of disabilities that can hinder a user’s access to the information on your website comes in many forms, including but not limited to:

Permanent Disabilities:

Some more frequently recognized disabilities are permanent and well-known illnesses, such as:

Loss of Vision: There are over seven different types of color blindness (such as protanopia, deuteranopia, and tritanopia) and four different levels of visual impairment that can affect how a user views (or doesn’t view) your website.
Loss of Mobility: For users with slow mobility responses, significant loss of mobility, or even the complete absence of limbs, it’s more difficult to navigate websites with traditional methods of mice and keyboards – or for phone users to tap or drag items across a screen.
Loss of Voice: users that have lost their voice may have a hindered experience when using voice command software, such as Siri, Alexa, or even live in-game chat conversations.
Cognitive Disabilities: There are many types of mental disabilities that can inhibit a user’s perception of the content on your web page. Think of traditional disabilities such as autism, ADHD, OCD, but also less-thought of cognitive disabilities such as foreign language barriers that may reduce a user’s ability to fully understand your website’s content.

Temporary Disabilities:

Permanent diseases aren’t the only type of disability. Even some people who are typically considered non-disabled in their day-to-day lives might have barriers to using your experience based on temporary disabilities such as:

Having to wear an arm / finger cast for a few months that limits touch and mobility
Having an ear infection for a few weeks that reduces your ability to hear
Recovering from having your tonsils removed and not having your full range of voice back yet

Situational Disabilities:

Sometimes users can be disabled because of a situation happening around them, such as:

Carrying a baby with one arm
Forgetting their glasses at home and having reduced vision
Being at a loud event that limits their hearing abilities
Visiting a foreign country and not being able to understand the language set in user experiences that are automatically set based on their location

How to Implement Accessibility into Your User Experiences

To make a user experience more accessible, you will select one of three sets of guidelines (based on your user experience type) established by the W3C. Once you meet a certain number of the guidelines, your digital product will be awarded a level of accessibility conformance (A,AA, or AAA).

The Governing Groups Behind Accessibility Implementation:

Before we start talk about the the details of how to implement web accessibility, let’s first start with who is behind this initiative. There’s quite a few acronyms for the organizations, projects, and guidelines themselves, so let’s break those down first.

W3C – The World Wide Web consortium (W3C) is the organization that sets the internationally recognized standards for web accessibility compliance.
WAI – The W3C’s initiative for creating the guidelines is called the Web Accessibility Initiative (WAI).
WCAG – The actual accessibility guidelines most UX teams use are called the Web Content Accessibility Guidelines (WCAG).
- There are multiple incremental versions of the WCAG, with each version expanding on the last. The latest version is WCAG 2.2, as of April 2022.
- A new WCAG 2.3 release is expected for 2022.

The 3 types of accessibility guidelines

There are three main guidelines that are recognized internationally:

WCAG (Web Content Accessibility Guidelines) – covers guidelines for all web content and applications – on mobile, television, and other delivery channels.
- Most websites and apps follow the WCAG so it’s one of the most widely known guidelines by UX design teams.
- The WCAG has been around for more than two decades, and was first published in May, 1999.
ATAG (Authoring Tool Accessibility Guidelines) – applies to any website or CMS that provides users the opportunity to generate content
- Ex: If users can add content, upload images/videos, comment on forums, etc, you’ll use the ATAG to better implement accessibility for this use case.
- Most applicable to product design teams.
UAAG (User Agent Accessibility Guidelines) – for browsers, browser extensions, media players, and readers
- Most applicable to product designers working on browsers and plugins

Once you find the appropriate set of guidelines for your user experience type, you follow the guidelines in POUR order until you reach a level of conformance.

The Three WCAG Levels of Conformance:

Once you meet a certain number of guidelines, you will be rewarded a level of conformance from WCAG. There are three levels of web accessibility conformance that you can achieve from WCAG. Each level assumes you covered all the guidelines from the previous levels before advancing to the next one.

A Level: The baseline for all websites to adhere by. Easiest level of difficulty to implement, with less guidelines to follow.
AA Level: Includes A-level guidelines, plus many more detailed design-specific guidelines. Mid-level of difficulty to implement.
AAA Level: Includes all previous levels’ guidelines plus more advanced details that now include animations and content.

The W3C also supplies conformance logos you can add to your site based on the level of conformance you’ve achieved.

Using WCAG

WCAG Implementation Order: POUR

The accessibility guidelines are ordered under four principles, referred to as POUR. There are four principles that organize the many guidelines set by the W3C. Essentially, to be accessible a website must be:

P – Perceivable – users must be able to perceive the information being presented. It can’t be invisible to all of their senses.
O – Operable – users must be able to operate the interface. The interface cannot require interaction that a user cannot perform.
U – Understandable – the content or operation of the user interface cannot be beyond a user’s understanding.
R – Robust – the content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.

A screenshot of WCAG’s POUR principles outlined in the WCAG Quick Reference guide.

WCAG Filters

To find and filter the guidelines listed in WCAG even further, you can use some of the built in filters. You can focus on specific department tags, filter by specific components, of even by conformance level.

Department Tag Filters:
- Focus on development, interaction, content or visual design elements
Component Tag Filters:
- Easily find specific accessibility guidelines for components like captchas, carousels, buttons, etc
Conformance Level Filters:
- Filter by compliance levels (A-AAA)

The lefthand menu shows what WCAG’s filter panel looks like, with options to filter out by conformance level, and field focus (design, development, etc)

Parts of a Guideline

Let’s focus on a single guideline. Each guideline consists of five parts: name, number, level, criteria, and techniques.

A screenshot of the first guideline, WCAG 1.1

Guideline Name:

Each guideline has a unique name.
The name is in reference to the area in your digital experience that you are trying to be more accessible.
- Ex: non-text content, form labels, etc.

Guideline Number:

Each guideline has a unique number. The number is the unique identifier for the guidelines.
- Ex: 1.1.1, 1.1.2, etc.

Guideline Level:

The level of compliance this guidelines will help you achieve (A,AA,AAA)

Guideline Criteria:

The description that follows a guideline name is called the criteria. This is the sentence that tells you what you have to do to meet the level of compliance for this criteria.
Ex:
- Guideline: 1.4.2 Audio Control, Level A
- Criteria: If any audio on a Web page plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level.

Guideline Techniques:

You can fulfill the requirements inside of criteria a lot of different ways!
Depending if your guideline refers to design, content, or engineering, or even the type of technology used to build the experience (HTML, JavaScript, etc) there will be a list of suggested techniques that concretely describe implementations you can complete to satisfy the criteria for a guideline.
You don’t have to abide by all the techniques related to one criteria. Just one will suffice. Example:
- Guideline: 1.4.2 Audio Control, Level A
- Criteria: If any audio on a Web page plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level.
- Technique: G171: Playing sounds only on user request

The Laws Behind Accessibility in User Experiences

It’s important to know that the WCAG are not laws. They are guidelines. They are not enforceable by any policeable group. However, each country does have its own set of laws in terms of how accessibility is adhered to in that country. The WCAG is just the list of guidelines people use in order to adhere to the accessibility laws upheld by their countries.

Accessibility Laws in the US

Section 508 of the Rehabilitation Act of 1973

Section 508 speaks to the accessibility of federal websites.
It requires “Federal agencies to make their electronic and information technology (EIT) accessible to people with disabilities” – this includes internal and external-facing electronic information.
Federal agencies must ensure that this technology is accessible to employees and members of the public with disabilities to the extent it does not pose an “undue burden.”

Americans with Disabilities Act (ADA) of 1990

The Americans with Disabilities Act (ADA) is a federal civil rights law that prohibits discrimination against people with disabilities in everyday activities.
The ADA guarantees that people with disabilities have the same opportunities as everyone else to:
1. Enjoy employment opportunities, purchase goods and services, and participate in state and local government programs.

Americans with Disabilities Act (ADA) of 1990 – Title III

The ADA is split up into five titles in order to cover all aspects of “everyday activities”
The most relevant one for web accessibility is Title III, in concern to businesses that are open to the public.
1. “Businesses must provide people with disabilities an equal opportunity to access the goods or services that they offer.”
2. In court it was determined that physical stores with online storefronts also need to make their online equivalents accessible.

Accessibility Laws Internationally

There are over 20 countries (and unions) that have their own laws calling for accessibility in digital products, including:

European Union – Web and Mobile Accessibility Directive
United Kingdom – Equality Act of 2010
China – Law on the Protection of Persons with Disabilities 1990
Australia – Disability Discrimination Act 1992 (DDA)
India – Rights of Persons with Disabilities Act, 2016 (RPD)

The WAI has a great list of countries with accessibility laws available.

A preview of the international accessibility laws table data from WCAG

Conclusion:

As designers and developers, we need to make sure we design experiences with all these users’ limitations in mind. Considering the magnitude of users you are accounting for, the large variety of disabilities you should account for, and the intricacies of meeting the W3C’s accessibility guidelines, and all national and international laws for web accessibility, I consider the most important rule for web accessibility is that web accessibility is not an after-thought.

Implementing web accessibility is a multi-role interdisciplinary process that must be carefully thought out at the start of a project, not post-launch. Designers need to set up developers for success by choosing appropriate colors, fonts, and layouts. Developers need to use user-friendly development practices and clean, accessible, and navigable code. Content creators need to write clear, and concise copy that is easily understandable by most users. As you can see, accessibility is a team-wide effort, but with a little up-front effort and cross-discipline communication, it can be achieved.

Resources to Keep Learning:

If you’re interested in more resources, here are some of my favorite talks, courses, articles, and resources on web accessibility I’ve encountered over the years: