Developer
Accessibility Audit Checklist for Production Websites
Accessibility audits are production quality audits. They expose broken navigation, missing labels, ambiguous controls, invisible focus states, weak contrast, and error flows that fail under real input conditions. A usable audit combines automated checks with keyboard testing and manual review of the highest-risk journeys.
Try our Accessibility CheckerStart with the critical journey, not a random page
Audit the path users actually rely on: landing page to sign-up checkout support form docs search dashboard action or report sharing. Static rules are useful but they do not prove that a keyboard user can complete the task or that a screen-reader user hears enough context to make the right decision.
Check document structure and landmarks
Every page should have one clear H1 headings in logical order a main landmark meaningful navigation labels and no heading levels used purely for visual sizing. Screen-reader users navigate by headings and landmarks; broken hierarchy turns a simple page into an unordered list of fragments.
Verify labels, names, and descriptions
Inputs need labels icon-only buttons need accessible names links need purpose without surrounding visual context and dynamic status regions need text that explains what changed. Placeholder text is not a label. A button named 'click here' is not a useful control. Error messages should identify the field and the fix.
Keyboard and focus testing
Use Tab Shift+Tab Enter Space Escape and arrow keys where appropriate. Focus must be visible move in a logical order stay trapped inside modals while open return to the trigger after close and never disappear behind sticky headers or off-screen content. Dropdowns and command palettes should be usable without a mouse.
Color, contrast, and state dependence
Text and important controls need sufficient contrast in normal hover active disabled success warning and error states. Do not use color alone to communicate status. Pair color with text icon shape or position so users with low vision or color-vision differences still understand the result.
Dynamic content and loading states
A page can pass static checks and still fail when data loads. Spinners need accessible status text form submission failures need focus management result cards need stable dimensions and live updates should not unexpectedly steal focus. Test slow network and empty/error states not only the happy path.
Release verification
Before release run an automated scan tab through the core journey zoom to 200% test mobile layout verify visible focus and inspect at least one screen-reader pass on the key workflow. Record the exact pages tested and the defects fixed so accessibility does not reset to zero on the next redesign.
FAQ
Can automated accessibility tools prove a site is accessible?+
No. Automated tools catch many structural defects but keyboard behavior focus management copy clarity and screen-reader comprehension still need manual verification.
What should block release?+
Block release when users cannot complete a critical journey by keyboard key controls have no accessible name focus becomes trapped or lost contrast hides important text or error messages do not explain how to recover.
Want to verify your setup?
Run the check now