A web page is not accessible only because images have alternative text. In this article, let's take a closer look at what makes a web application accessible and how to implement it.

What is Accessibility?

Accessibility is the method used to make an application usable for as many people as possible, taking into account any limitations and difficulties that users might have. We tend to think of this as allowing people with disabilities to access applications, which is a misconception. The internet is meant to be universal. It's not about allowing — it's about including!

Although users with disabilities experience direct benefits from accessible applications, other audiences can also be favored by using them, such as mobile users or users on slow networks. In general, applying accessibility principles tends to improve the overall experience and make applications more performant and easy to use. Additionally, accessible applications:

1. Are more findable, thanks to their optimized content structure;
2. Improve a company's public image, conveying good ethics and morals;
3. Comply with the law in several places.

Types of Disabilities

When considering web accessibility, it is important to keep in mind a wide range of disabilities. The key is to empathize with these users and think about how they access the web. The main types of disabilities are described below.

Visual Impairments

This category includes people with blindness, color blindness, and low vision. People with these disabilities commonly rely on physical or software magnifiers, screen readers, and voice commands.

Hearing Impairments

This group includes deaf people or people with hard-of-hearing problems. Some of these users rely on assistive devices, such as ear devices, but these are not widely used. To overcome this limitation, textual descriptions are often provided for visual media and simplified language is used in text.

Mobility Impairments

This group includes people with movement-related limitations, such as paralysis, loss or weakness in limbs, or hardware limitations. Users with mobility impairments often interact with web pages using a keyboard.

Cognitive Impairments

Implementing Accessibility into a Project

One common error when creating or making an application accessible is thinking that it is a feature that can be concluded in a few sprints. In reality, it is the opposite. Accessibility is an ongoing project that needs to be tackled every new sprint, just like automated tests. Importantly, accessibility should be accounted for from the early stages of a project. When implemented later, it will require more time and effort, increasing costs.

It is not only up to developers to bring accessibility to a website. All teams involved should be aware of their role in making this happen:

1. Content creators should generate broad and easy-to-consume media. Use simple plain-language text, videos with transcriptions, and images with descriptions. Furthermore, content should be lean and focused.
2. UI/UX designers should build consistent and predictable layouts, caring for the relationship between pages and sections, and striving for simple and standardized components.
3. Product managers should account for accessibility tasks when planning interactions. Making the importance of accessible products clear to stakeholders is also another important job in this role.
4. Finally, developers should build applications using all the available tools and techniques regarding accessibility, always testing thoroughly and trying to avoid personal biases.

Like any other feature, accessibility implementations should be tested. Alongside manual tests performed by developers, companies can employ people with real disabilities to enhance the testing process, as they will be free from any biases, or hire specialized third-party services. Still, numerous tools available in the market help automate at least part of the testing workflow, increasing fault tolerance. The key here is trying to think of how a disabled person would use the website.

One last and important point: good is better than perfect. There’s no need to set up the most complete solution. Implementations can start small and basic, improving over time. A 100% accessible application is a utopia, but we should always strive for it as a goal.

Guidelines

The WCAG (Web Content Accessibility Guidelines) is a very detailed set of technology-agnostic guidelines created by the W3C to help improving accessibility in websites. These guidelines are the best means of checking accessibility implementations conformance. They are separated in four categories:

1. Perceivable content should be distinguishable by any user;
2. Operable anyone should be able to interact with the application;
3. Understandable pages should give proper feedback on what’s happening;
4. Robust application should be flexible and adaptable to any way users could use it.

There are testable success criteria for each guideline, which are divided in three levels:

1. A essential support, provides basic interaction with the application;
2. AA ideal support, backs diverse situations not covered by level A criteria; often required by legal authorities;
3. AAA specialized support, covers specific use cases.

Although the WCAG document is far from being short read, there are some websites across the web that summarize the guidelines into checklists, like The A11y Project and WebIAM. An important fact, the WCAG is not a definitive guide. Some countries and states might have specific requirements regarding accessibility. These recommendations can be great start, though.

Tools

In the last few years many accessibility tools have been released, fortunately, making it easier to implement and test accessibility in web pages. Moreover, there are long-time tools often ignored that can greatly help in this task.

Development Tools

eslint-plugin-jsx-a11y

Many modern web application projects rely on node.js as their base environment. These projects can use the eslint-plugin-jsx-a11y package to identify accessibility issues in HTML and JSX code.

axe-core

The axe-core package provides an API that can be used to perform a variety of automated accessibility tests. This package can be incorporated into scripts and CI pipelines. The company behind this library also provides other additional solutions for accessibility testing.

@storybook/addon-a11y

Users of the Storybook component library can use the @storybook/addon-a11y package to gain accessibility insights about their components.

Google’s Lighthouse

Lighthouse is an open-source tool built by Google for improving the quality of web pages. This tool is built into Chromium-based browsers but can also be used as a standalone script, Node.js module, web UI, or CI pipeline job.

Accessibility Inspector

Modern major browsers include an accessibility inspector built into their developer inspection tools. This tool provides accessibility information for every element in the DOM tree.

Semantic HTML

The HTML standard provides a number of elements that represent a piece of data. These elements hold semantic value, meaning that their data has a specific role. Take the <nav> element, for example. This element indicates that it contains navigation links. Semantic HTML helps screen readers describe to users what kind of content they are navigating and also improves SEO.

WAI-ARIA

The WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) is a specification created by the W3C that defines a set of new HTML attributes and properties to provide additional semantics and improve accessibility information when needed. Take a tab component, for example. There is no built-in HTML element for this kind of data structure. So a developer can add role="tablist" and role="tabpanel" to the tab elements to inform screen readers that they represent a tab component.

There are other techniques described in the WCAG guidelines that can help increase the accessibility support for a web page. For example, the Page Titled criteria describes how the HTML <title> element adds a title to a web page document, and the Bypass Blocks criteria defines how to build a mechanism for skipping certain blocks of content.

Testing Tools

Screen Readers

Screen readers are software primarily used by visually impaired users to understand what is being displayed in the browser and how they are interacting with it. This tool reads aloud to the user the content on the screen and where they are currently navigating. There are a handful of screen readers available as standalone apps, browser extensions, and built-in software in OS.

The Keyboard

Many users rely only on the keyboard to navigate and interact with websites. When programming web pages, developers should test navigation and interaction with elements using only the keyboard.

Online Accessibility Tools

There are many online tools available these days that help test accessibility conformance in live websites. The WAVE (Web Accessibility Evaluation Tool) is a good suite of tools that can identify accessibility issues and errors in web pages. The user provides a URL, the suite loads the page, and generates a thorough report containing several insights about elements' accessibility support.

Accessibility Myths

There are multiple myths involving the implementation of accessible applications. These are some of the most common ones:

#1 “Accessibility can be added in a few sprints before the release”

Nope. Maybe specific things, such as adding a few labels or descriptions, but complex elements and interactions require good planning before development starts. Postponing accessibility to the end of a sprint or project might require full codebase refactoring.

#2 “Making an application accessible is costly”

Again, if considered from the beginning of a project, this may not hold true. Also, when the team has the proper skills and after it becomes a habit, the development time tends to change little.

#3 “Accessibility affects only a few users”

Not true. Around 15% of the world's population has some kind of disability, and this number is unfortunately growing.

#4 “Making my website accessible doesn’t worth it”

Unfortunately, this is still held true by many companies' heads. First off, websites should be accessible by everyone as part of the Web's intrinsic universality. This is in the roots of its conception. Secondly, accessibility brings more users, revenue, and better reputation. Plus, overall product quality tends to increase together. It is important to notice that numerous countries and states have laws forcing websites to be inclusive. At the end, profit should not come before doing the right thing.

Conclusion

This article is a high-level overview of what accessibility is, its value for companies and society, and how to implement it. Although the hands-on work can be more challenging, as each company has its own particularities, the first steps are straightforward. Make it crystal clear to the involved teams the importance of accessible applications and their roles in making it happen, define the basic accessibility support level and incorporate it into the application roadmap, adopt the right tools and techniques, and keep improving. It can be a tough endeavor initially but, with time and effort, results will be seen, and accessibility will naturally become part of the workflow.

References

1. “What is Accessibility?”, MDN
2. “Introduction to Accessibility”, W3C
3. “Accessibility is not a Project to be Completed”, Yan and Coffee’s Blog
4. “Including Accessibility from the Start in your Projects”, Hi Interactive
5. “Accessibility Myths”, A11y Myths
6. “Accessibility”, React.js Docs
7. “Understanding WCAG 2.0”, W3C
8. “What is Accessibility Testing?”, Guru99
9. “Semantics Glossary”, MDN
10. “WAI-ARIA Basics“, MDN
11. “A11y Project Checklist”, The A11y Project