Common Accessibility Problems to Avoid

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:

1. Google Lighthouse — the built-in Chrome audit. Good for a baseline accessibility pass alongside performance.
2. 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.