In the course of 12+ years providing accessibility clinics, the Web Access team at Berkeley has seen many inaccessible implementations of relatively standard functionality. We see some of the same coding issues over and over again.
The biggest offenders are:
- Re-implementing functions that are natively accessible in HTML;
- Interfering with keyboard use;
- And using ARIA in ways that make things worse.
We’ve put together a checklist that you can use to review your code and avoid these common pitfalls.
If you are using a front-end JS framework, or building a web application on top of a third-party platform, you may not have direct access to the HTML and/or DOM that is generated for your site. In that case, you may need to use an automated inspection tool that runs on the DOM. See the Automated code inspection section for details.
- HTML5 Validator: This validator checks your generated source code for validity. You can point it to a URL, upload a file, or paste source code.
- The First Rule of ARIA: is, "Don’t use ARIA." Official guidance from the W3C on how to use and not use ARIA.
- To ARIA! The Cause of, and Solution to, All Our Accessibility Problems: Blog post from WebAIM about common misuses of ARIA, and also ARIA patterns that are helpful and should be used more often.
- ARIA design patterns: The W3C provides patterns and reference implementations for many of the complex ARIA roles. If you’re using these roles, start with the implementations from this documentation and work from there.