Common Accessibility Problems to Avoid
Explore web accessibility best practices, common pitfalls and practical solutions for building more inclusive websites.
Notes from spending a chunk of 2020 getting better at accessibility — the issues that came up repeatedly, and what to do about them.
Tools worth using
Two that earn their place:
- Google Lighthouse — the built-in Chrome audit. Good for a baseline accessibility pass alongside performance.
- Microsoft Accessibility Insights — browser extension with a fast pass and a much more thorough assessment organised by category (keyboard, focus, landmarks, and so on).
Automated tests aren't enough
Passing Lighthouse doesn't mean a page is accessible. On one slider we shipped, the images weren't wrapped in interactive elements, and aria-hidden="true" conflicted with focusable children inside. Lighthouse was happy. A keyboard user wasn't.
Manual testing catches what audits miss
Unplug the mouse. Tab through the page. The things to check:
- Is every interaction reachable and usable without a mouse?
- Is it always obvious which element is focused?
- Does the focus order follow the visual order?
A few rules that save time
Don't remove focus styles. Stripping :focus outlines takes away the only signal keyboard users have. Restyle, don't remove.
Trap focus in modals. When a dialog opens, focus should stay inside until it closes. David Clark's Focus Trap library handles this cleanly.
Avoid "click here" links. Screen readers read links out of context. Rewrite the link text, or use aria-label.
Use ARIA where semantics aren't enough. aria-label, aria-labelledby, and role fill in the gaps that HTML can't describe on its own.
The point
Automated tools plus keyboard and screen reader testing. Audits on their own don't prove a site is accessible.
