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.
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:
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.
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.
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.
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.
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:
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.
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:
There are testable success criteria for each guideline, which are divided in three levels:
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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.
Not true. Around 15% of the world's population has some kind of disability, and this number is unfortunately growing.
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.
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.