Fixing web accessibility issues is important — but it’s equally important to fix problems the right way.
Without a clear remediation strategy, your “fix" may create other accessibility barriers that impact users with disabilities. You might over-engineer your solutions, putting far more resources towards remediation than necessary. Perhaps most importantly, if you don’t understand how your decisions affect your users, you’re far more likely to make mistakes.
To build a better approach, ask yourself these questions before getting started.
1. Why does this accessibility barrier need to be fixed?
This may sound like an obvious question, but pay attention to your answer. Are you thinking about compliance, or are you thinking about your real-life users?
Accessibility remediation usually begins when developers identify violations of the Web Content Accessibility Guidelines (WCAG), the international consensus standards for accessibility. WCAG is an important tool — but it’s most helpful when you focus on the objective of each WCAG requirement.
For example, many accessibility tools will generate warnings when encountering aria-hidden attributes, since that attribute may violate WCAG when used improperly. Unfortunately, tools may generate those warnings even when the aria-hidden attribute is used appropriately.
If you understand how aria-hidden affects the experiences of assistive technology (AT) users, you can quickly determine whether a problem actually exists. However, if you’re fixing an issue because your automated testing tool told you to fix it, you’re on the wrong track.
2. What is the simplest way to address the issue?
Some accessibility barriers require complex solutions, but in most situations, the simplest fix is the best option.
Many people with disabilities use screen readers and other assistive technologies (AT) to access the web. As we’ve discussed in other articles, assistive software works best when presented with plain, old semantic HTML.
While WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) and other tools are sometimes necessary, HTML enjoys wide support. If you can fix a problem with basic adjustments to your HTML/XHTML markup, that’s typically where you should start.
3. Is this a high-impact issue?
Every accessibility barrier should be addressed eventually. With that said, if your website has a major barrier that affects a large percentage of users with disabilities, you should probably focus on that issue before fixing low-impact problems.
To develop a strategy that works, read: Web Accessibility Remediation: A Quick Guide for Getting Started.
4. What are my assumptions about users with disabilities?
Everyone makes assumptions, which is why it’s a good idea to involve individuals who have disabilities in your remediation process.
It’s important to remember that people with disabilities use a wide range of tools and approaches when accessing the internet. Some people with low vision may use screen readers. Others may use screen magnifiers, and others may not use any AT at all. Some people use a keyboard alone to navigate the web, while others use eye-tracking devices, head pointers, trackballs, or refreshable braille displays.
The goal of digital accessibility is to accommodate every person, regardless of their abilities. When fixing an issue, ask yourself whether you’re making assumptions about user behavior — and whether those assumptions are true.
5. How can I prevent similar problems from happening in the future?
For long-term digital compliance, you need to understand why an accessibility issue occurred and what you could have done differently.
Let’s say you’re fixing keyboard accessibility issues on your website’s forms. Keyboard accessibility issues are common, and even talented developers occasionally make mistakes — but if you’ve found a keyboard trap, it’s a good indication that you need to test your content more thoroughly in the future.