According to the World Health Organization’s World Report on Disabilities, over one billion people globally live with some form of disability. That’s 15% of the population. In the United States, the numbers are even higher—the CDC estimates that over 25% of the population has a disability. Those disabilities take many forms, with the most common being physical, cognitive, hearing, and speech disabilities.
Having a disability can affect how people interact with the web. Someone with a visual disability might use a screen reader, while someone with a physical disability may use voice control software to navigate. And as our UX Book Club learned in Designing Interface Animation, someone with a vestibular disorder might need a way to turn off or reduce animation (including parallax) to avoid becoming dizzy.
Websites that are not properly designed and developed for accessibility could prevent tens of millions of people in the United States alone from performing daily tasks such as checking their bank accounts or buying a pair of jeans. This is why it is important to include accessibility in our daily work and not as an afterthought.
While many accessibility issues should be addressed in the design phase, designers are currently unable to make their designs directly interact with the technologies people use to access the web. Translating design into code is the developer’s role, and executing it correctly can determine whether or not a user gets the experience they need.
Code is the seam layer between our product and user agents. There are many common user agents that most people are aware of, such as browsers, keyboards, and screen readers. But there are also many other technologies out there, and more are being developed every day.
This is where the Web Content Accessibility Guidelines (WCAG) principle of Robust comes in. The accessibility guidelines we are expected to follow exist to make sure what we produce “maximize(s) compatibility with current and future user agents, including assistive technologies.” It’s essentially a contract with the creators of those technologies. If they can depend on our code to be written according to the guidelines, then they know how to develop their technologies to work with that code.
What can we do to make sure that we are meeting the requirements of that contract?
Build Accessibility into the Process
Collaborate with UX, Designers, and Content Creators
Developers, designers, and content creators each have different considerations for accessibility, but they are part of the same team. Establishing good processes for collaboration between these roles can have a huge impact on the accessibility of your product, and can also make it easier for those people to perform their jobs well.
Having developers sync up with designers when a product is still in the design phase allows for early discussion around accessibility. This is the time to talk about the expected interactions, provide clarification on the design, and surface any potential accessibility issues. At this stage, designers can communicate their reasoning behind the design and developers can provide insight into any issues they see with being able to implement the design in a way that is accessible.
This is also an excellent time to collaborate with content creators as well. While developers may be aware that they need to include attributes like alt text or aria labels, content creators can help to ensure that the content that goes into those attributes will be useful to our users. In the context of a design system team, they can also write documentation to help content creators on subscribing teams create accessible content for their particular use case.
Another chance for developers, designers, and content creators to work as a team to detect any accessibility issues is before release. By scheduling pairing sessions to review the project together, they can make sure that accessibility requirements have been met as expected, and make refinements before the code goes into production. The team at Deque has an excellent talk about designer/developer collaboration if you are looking for a good model.
Capture Requirements
Not every developer is an expert in accessibility—or is even aware of accessibility requirements that they need to meet. If you are a tech lead or in another position where you will be capturing requirements, include accessibility as part of those requirements. This can include a description of expected behavior, a link to related WCAG guidelines and company guidelines, solutions for meeting the guidelines, and steps for testing.
Placing this information directly in the JIRA story (or similar) is also a great opportunity for sharing knowledge with other members of the development team. It will help them understand what is expected and expose them to resources that will help them better understand accessible development for the future.
Whatever you do, don’t create separate “accessibility” cards. Accessibility is not a “nice to have” feature—it is a core part of your product. Creating separate accessibility cards is a surefire way for accessibility to be placed on the back burner, add to tech debt, and cause rework for your team down the road. And while accessibility issues will still likely come up from time to time, don’t rely on receiving an accessibility bug report to address accessibility issues. Ideally, serving our users should be why we develop accessibly, but not having an accessible product can open the company up to legal action as well.
Write Good Documentation
Writing documentation that clearly defines the expected behavior of a component can help current and future developers understand what makes that component accessible. This can prevent developers from introducing new accessibility bugs in the future.
Accessibility considerations that should be documented are similar to those that should be captured as requirements—a description of expected behavior, links to related WCAG and company guidelines, and steps for testing.
This documentation can live in READMEs, Storybook, or in the company’s design system documentation. Many design systems, including Adobe Spectrum and REI Cedar, add accessibility directly in the documentation for each component.
Test
There are more tools than ever available for accessibility testing. Deciding which tools you will use and building an accessibility testing strategy into your process will help you to catch more accessibility issues more consistently.
Accessibility linters, such as the axe accessibility linter can help remind you about easy-to-detect accessibility issues, such as missing alt text, right in your code editor. Browser-based testing tools like axe or Lighthouse are useful for catching the majority of programmatically detectable accessibility issues.
There are also tools to help with writing unit tests and continuous integration tools, such as axe-core/cli and pa11y that you can integrate into your pipeline.
No single automated tool currently available will catch every accessibility issue. Using a combination of tools and techniques at different stages of the development process will allow your team to detect and remediate more issues.
The limitation of automated testing tools is that they only work for issues that can be programmatically detected, which account for 30-50% of accessibility issues. A good accessibility testing strategy also includes manual testing. At the bare minimum, developers should incorporate keyboard testing in their processes as well.
If you understand how to use a screen reader, conducting screen reader testing can also be valuable. However, screen reader testing should be approached with the understanding that the experience of someone who uses a screen reader on a daily basis is much different from someone who doesn’t. The ultimate test is whether the product works for real users with disabilities.
Advocate for Accessibility
We recognize that not every organization currently focuses on accessibility as they should. But whether you are new to accessibility or an expert, there are many ways that you can still advocate for accessibility within your company or organization.
Share Your Knowledge
Everyone has something to teach, so even if you aren’t an expert, sharing what you do know can help bring attention to digital accessibility issues and spark an interest in others to make their code more accessible.
Taking the time to pair with developers on an accessibility issue is a great way to share knowledge. This pairing time could be with someone who is new to accessibility, as part of a PR review, or with someone who is more experienced than you as a way to learn more.
There are also ways to build knowledge sharing into the PR Process. When opening a pull request, make sure to include steps for testing for accessibility in your validation steps. This will help developers without accessibility knowledge understand how the component is expected to work. If they are uncertain if it is functioning as expected, this is a good time to offer to pair.
If you are reviewing another developer’s PR, view it as an opportunity to help others learn more about writing accessible code. This is another great time to initiate the pairing sessions mentioned previously. You can show them the issue that you found, explain the impact of the issue, and help them learn the proper techniques for resolving the issue.
Finally, if your team has weekly demos or learning sessions, that’s a perfect opportunity to showcase accessibility to the larger team.
Learn More (Or Know Where to Go For Help)
If you are new to accessibility, trying to figure out where to start your learning journey may feel daunting. The official WCAG guidelines are technically dense documents, and while they will guide you, later on, trying to read them is probably not a good way to start.
A better approach might be to start with understanding the concepts and working with other developers to learn how to implement solutions.
If you already have a good foundation in accessibility, realize that, like many things in the industry, it is a constantly evolving subject. New testing tools have been created within the past few years, and the CSS spec was updated with accessibility in mind. Keeping up with the latest available tools will allow developers to continue to make their products as accessible as possible.
Fortunately, digital accessibility is starting to get the attention it needs, so more resources are becoming available. This year’s axe-con conference was a rich resource for up-to-date accessibility knowledge, and Global Accessibility Awareness Day has numerous events each year.
Conclusion
The importance of digital accessibility cannot be overstated. Leaving people out of digital experiences can mean leaving them out of many experiences entirely. Implementing accessible solutions is not always easy, but neither is solving many of the other problems we encounter as developers—and it is just as important. The reason we develop with accessibility in mind is to serve the people who are our users, and continuing to strive toward accessible digital experiences is one of the most important roles we have as developers.
