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.
Internal Server Error
The server encountered an internal error and was unable to complete your request. Either the server is overloaded or there is an error in the application.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.