Web Accessibility Testing: A Developer's Guide
A practical accessibility testing workflow combining automated checks, keyboard testing, and screen readers to catch real WCAG issues.
8 min read - Updated 2026-06-15
Use this guide as a compact release reference, then validate the same breakpoints in Sizzy with synchronized devices and screenshot evidence.
Automated tools catch the obvious
Start with automated scanners like axe, Lighthouse, or WAVE. They quickly flag missing alt text, low contrast, missing form labels, and invalid ARIA. But automation only catches around a third of WCAG issues - it can't judge whether alt text is meaningful or whether the tab order makes sense. Treat automated passing as the floor, not the finish line.
Run axe, Lighthouse, or WAVE for a fast baseline
They catch contrast, labels, alt text, and ARIA errors
Automation finds only ~30-40% of real issues
Passing automated checks is necessary, not sufficient
Test with a keyboard and a screen reader
The issues that matter most need a human. Unplug the mouse and navigate the whole flow with Tab, Enter, Escape, and arrow keys - if you can't complete a task, neither can keyboard users. Then run a screen reader to hear how the page is announced. These two passes catch the high-impact problems automation misses.
Keyboard-only pass through every interactive flow
Confirm visible focus indicators throughout
Screen-reader pass to check announcements and order
Verify focus management in modals and menus
Don't forget responsive accessibility
Accessibility and responsiveness intersect: text must remain readable when zoomed to 200%, tap targets need ~44px on touch screens, and reflow must not require horizontal scrolling at narrow widths. Testing these across viewports is part of WCAG. Sizzy lets you check zoomed and mobile widths alongside desktop so reflow and tap-target rules hold everywhere.
Text stays readable at 200% zoom (WCAG reflow)
Touch targets meet the ~44px minimum
No horizontal scroll at 320px width
Content order remains logical across breakpoints
Release checklist
An automated scan passes as the baseline.
Every flow is completable with the keyboard alone.
A screen-reader pass confirms sensible announcements.
Zoom, reflow, and tap-target rules hold across widths.
Frequently asked questions
What's the best way to test accessibility?
Combine three passes: an automated scanner (axe, Lighthouse, or WAVE) for a baseline, a keyboard-only pass through every flow, and a screen-reader pass. Automation alone catches only about a third of WCAG issues.
Do automated accessibility tools catch everything?
No. Automated tools reliably catch contrast, missing labels, alt text, and invalid ARIA, but they can't judge meaningful alt text, logical tab order, or whether a flow is usable. Manual keyboard and screen-reader testing is essential.
Is responsive design part of accessibility?
Yes. WCAG requires content to reflow without horizontal scrolling at narrow widths, remain readable at 200% zoom, and provide adequate tap-target sizes - all of which depend on responsive testing across viewports.
Related guides
Benji
Your life OS
The companion app that keeps every area of your world in sync.
Zero to Shipped
Ship products, not side projects
The ultimate Next.js boilerplate for building and launching real products.
DMX
Mindful Twitter/X
The intentional X client for macOS. Reclaim your attention span.
Sotto
Voice-to-text for macOS
Speak naturally. Type instantly. 100% local & private.
Passlock
Password manager with willpower
Lock passwords with time delays, word challenges, or hand the keys to someone you trust.
Glink
Changelogs that slap
Beautiful changelogs and roadmaps for your product.
JoinRepo
GitHub access control
Monetize your GitHub repositories with ease.
Tubely
YouTube Studio for Mac
Manage multiple YouTube channels in one native app.
JustWrite
Distraction-free writing
A minimal writing app that helps you focus on what matters.