Blog / friday roundup
The accessibility tools we reach for
The browser extensions, the screen reader and the one free habit we open first when a site owner needs a straight answer about accessibility.
Accessibility work tends to reach our support desk sideways. Someone gets a procurement questionnaire from a larger client, or a complaint lands in the contact form, or an Ontario business reads up on its AODA obligations and suddenly wants to know what the site actually does for people using assistive technology. We host the site, so we cannot fix your markup for you, but we have watched enough owners work through this to know which tools give a straight answer and which ones sell a feeling. Here is what we open first.
Your own keyboard
Before installing anything, put the mouse down and press Tab through your home page. You are watching for two things: whether the focus outline stays visible as it moves, and whether it ever gets stuck or vanishes behind a sticky header. Most of the serious problems we see on small-business sites turn up this way in under a minute, usually a slider or a cookie banner that traps focus and will not give it back. No tool reports it as clearly as your own hands.
WAVE, from WebAIM
The WAVE browser extension lays icons directly over your page: missing alt text, headings out of order, form inputs with no label attached. It evaluates the page inside your browser rather than sending anything to a server, which matters when you are checking a staging site or a logged-in area. We point owners at this one rather than developers, because the output is visual and the problem sits on the element that caused it. Expect a wall of icons on the first run, then work down from the errors and leave the alerts for later.
axe DevTools
axe sits in the browser's developer tools beside the console, and it is what our more technical clients settle on. Its reporting is conservative, so when it flags something it is usually a real failure rather than a guess, and every result names the rule that was broken. If you are handing a list of fixes to a developer, this is the list that comes back with the fewest arguments attached.
Lighthouse, already in your browser
Chrome ships Lighthouse in the same developer panel most people already open for speed testing. The accessibility score is a rough signal rather than a verdict, and a perfect hundred does not mean a site is usable by anyone. Where it earns its place is catching regressions: run it before and after a theme change and you will see what the new template quietly broke. Treat the number as a smoke alarm rather than an inspection.
The WebAIM contrast checker
Colour contrast is the most common failure we see, and it is nearly always a brand colour used as body text, or the pale grey placeholder text a designer fell in love with. Paste in two colours and it tells you plainly whether the combination passes. Write the result down somewhere your team can find it, because the next person to touch the stylesheet will reach for that same pretty grey. If you are theme shopping while you are at it, our notes on lightweight WordPress themes apply here as well, since simpler templates tend to leave your contrast decisions alone.
An actual screen reader
No automated tool can tell you whether a page makes sense read aloud. NVDA from NV Access is free and runs on Windows, and VoiceOver is built into macOS, so this costs nothing except an afternoon of feeling uncomfortable. Turn one on, close your eyes for the first minute of your home page, and listen to how the navigation and the image descriptions actually land. This is usually where an owner discovers that every product photo announces itself as "IMG underscore 4471", which is the other half of the image habits we wrote about earlier.
The W3C markup validator
Valid markup is not the same thing as an accessible site, but broken markup is where assistive technology tends to fall over. Duplicate IDs, unclosed elements and stray tags left behind by an editor confuse screen readers in ways that are miserable to trace from the front end. You can check by URL, by file upload or by pasting the source in directly. On WordPress the culprit is almost always a page builder or a shortcode from a plugin that was removed years ago.
One caution before you spend money on this. The overlay widgets that promise a compliant site from a single line of JavaScript are not well regarded by the people who actually use screen readers every day, and in our experience they have never fixed a problem that the tools above would not have found first. Work the list, fix the markup underneath, and the improvement stays fixed through your next theme update. If something on the server side gets in your way while you are in there, our support team will take a look at it with you.