You understand the importance of accommodating users with disabilities, and you’ve started taking steps to improve your website.
You’ve audited your content for conformance with the Web Content Accessibility Guidelines (WCAG), the consensus standards for digital accessibility. You’ve discussed website accessibility with your developers and designers, and you’re ready to start addressing the barriers that affect your real-life users.
Great work — but remember, accessibility remediation carries unique challenges. The process can be tricky, especially if your website has complex features, and in some cases, “fixing" an issue could create new problems. Before you begin accessibility remediation, make sure you’re avoiding some of the most common mistakes.
1. Don’t rely on automated accessibility tools alone
Automated accessibility testing tools are inexpensive, easy to use, and reasonably accurate for diagnosing many WCAG success criteria. However, “reasonably accurate" isn’t a great goalpost: Automated tools miss many of the most frustrating accessibility issues. For example:
- Automated tools can detect missing alternative text (also called alt text). However, artificial intelligence can’t accurately determine whether the alt text is relevant, concise, and useful for human users.
- Automated tools can’t detect all semantic HTML issues such as misused subheading tags, inaccurate title tags, and other semantic markup mistakes.
- Automated tools can’t detect images of text, which fails WCAG Success Criteria (SC) 1.4.5, “Images of Text.”
- Automated tools can’t determine the visibility of keyboard focus indicators, which could cause content to fail WCAG SC 2.4.7, “Focus Visible.”
Human testers — preferably people with disabilities — can find these issues and provide guidance for fixing them. If your organization can’t afford to hire independent auditors, at the bare minimum you’ll need to train developers to manually test content.
Related: What’s the Difference Between Manual and Automated Accessibility Testing?
2. Don’t ignore the experiences of real-life users when fixing problems
The goal of a web accessibility audit isn’t to earn WCAG conformance; the goal is to provide better content for all users. WCAG is simply a tool for determining whether you’re reaching that goal. Get into the habit of asking questions during remediation.
- Will this change make my website more perceivable, operable, understandable, or usable?
- Could “fixing" a problem create another problem?
- Am I making assumptions about how people with disabilities use the internet?
That last question is especially important. Your accessibility improvements should enhance the experiences of all users, not just a certain group of individuals. Some people with vision disabilities use screen readers to browse the web; others use screen magnifiers or other assistive tools. Some users with hearing disabilities prefer to read captions on videos, while others prefer transcripts.
WCAG is a helpful resource for building accessibility improvements that work for everyone. However, remediation requires careful consideration of each problem, and if you’re not thinking about your users, you’re bound to make mistakes.
Related: When User Testing for Accessibility, Involve People with Disabilities
3. Don’t hide important content from screen reader users
WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications), CSS, and HTML5 can be used to “hide" content from screen readers and other assistive technologies.
In certain situations, hiding elements is helpful. For example, if a website has navigation buttons that are helpful for sighted users but redundant for screen reader users, aria-hidden could be used to prevent screen reader software from announcing the unnecessary controls.
However, in most situations, hiding content from a particular group of users is bad practice — particularly if that content includes essential interactive elements. Some quick tips to keep in mind:
- In most situations, every visible element on your page should be available to screen reader users. If an element is redundant, consider removing it rather than hiding it.
- Use appropriate methods to hide your content. If you’re hiding content from all users, CSS or HTML is appropriate. To hide content from screen reader users, ARIA’s aria-hidden attribute is preferable.
- Don’t hide inaccessible elements simply because you can’t think of another way to fix them. Contact your accessibility partner or review WCAG to make sure you’re remediating effectively.
- Use caution when hiding controls. For example, if a video player’s playback buttons are invisible until a user hovers over a certain part of a screen, some users may have trouble finding or operating the controls. Look for alternatives to hidden controls, and if you really need to use them, provide users with an option to keep the controls visible.
In some situations, you may want to add content specifically for screen reader users. For example, your site might present information in a way that works well for sighted users, but creates confusion for people who don’t perceive the content visually. WebAIM (Web Accessibility In Mind)’s article “CSS in Action: Invisible Content Just for Screen Reader Users" is an excellent resource for these scenarios.
Related: What WAI-ARIA “Hidden" Warnings Mean For Your Website
4. Don’t overthink your accessibility improvements
Sure, you can add WAI-ARIA markup to make sure assistive technologies can understand your website — but WAI-ARIA requires expert knowledge and accurate testing.
Native HTML is powerful, widely supported, and easy to use. In fact, the first rule of WAI-ARIA usage is to use semantic HTML wherever possible — in other words, don’t use ARIA unless you really need it.
If you try to write clean, simple code, you’ll spend less time on remediation (and less money). While some complex content requires creative solutions, the simplest accessibility improvement is usually the best option.
For more remediation guidance, contact the Bureau of Internet Accessibility and schedule a consultation.
