After our post on the European Accessibility Act, several people asked for something more hands-on. Fair enough. Here are the fixes we make most often on client sites, roughly in order of how often we find the problem.
WCAG 2.2 became a W3C Recommendation in late 2023 and added a few new success criteria. We've marked those as (new in 2.2).
1. Add real alt text
Every meaningful image needs alt text that describes it. Decorative images (background patterns, dividers) should have an empty alt="" so screen readers skip them. Don't start with "image of", just describe the thing.
2. Fix colour contrast
Light grey text on a white background is the most common failure we see. Normal text needs a contrast ratio of at least 4.5:1. Browser DevTools will tell you the ratio when you inspect a text element.
3. Label every form field
Placeholder text is not a label. It disappears when you start typing and many screen readers don't read it reliably. Use a proper <label> connected to each input.
4. Make focus visible
Tab through your site with the keyboard. Can you always see where you are? Many sites remove the focus outline because a designer found it ugly. Put it back, styled nicely if you like, but visible.
5. Don't hide focus behind sticky elements (new in 2.2)
WCAG 2.2 adds "Focus Not Obscured". If you have a sticky header or a cookie banner, make sure it doesn't cover the element that currently has keyboard focus. Adding scroll-padding-top to the page often solves this for sticky headers.
6. Make tap targets big enough (new in 2.2)
The new "Target Size (Minimum)" criterion asks for interactive targets of at least 24 by 24 CSS pixels, or enough spacing around smaller ones. Tiny social icons and close buttons are the usual offenders. We aim for 44 pixels on mobile anyway, because fingers aren't precise.
7. Offer alternatives to dragging (new in 2.2)
If something can only be done by dragging, like a slider or a sortable list, provide a way to do it with simple clicks or taps too. Not everyone can drag accurately.
8. Don't make people re-enter information (new in 2.2)
"Redundant Entry" says that if a user has already provided information in the same process, you should fill it in or let them select it. The classic example is a checkout that asks for your address twice when billing and shipping are the same. A simple "same as shipping" checkbox fixes it.
9. Use headings in order
One <h1> per page, then <h2> for sections, <h3> within those. Screen reader users jump between headings to scan a page, the same way sighted users skim. Don't pick heading levels based on how big the text looks; use CSS for that.
How to test quickly
- Run Lighthouse in Chrome DevTools and look at the Accessibility section.
- Install the axe DevTools browser extension for a more detailed scan.
- Unplug your mouse and try to complete your main user journey with only the keyboard.
- Turn on your phone's screen reader (TalkBack or VoiceOver) and try your homepage for five minutes.
That last one is humbling the first time. It's also the fastest way to understand why this stuff matters.
