An accessibility audit evaluates your product against WCAG guidelines to identify barriers for users with disabilities.
An accessibility audit is a structured evaluation of your product against the Web Content Accessibility Guidelines (WCAG) — the international standard governing how digital products serve users with disabilities. Audits combine automated tooling with human testing across keyboard navigation, screen readers, color contrast, and assistive technology. The compliance stakes are real: the EU Accessibility Act (effective June 2025) mandates WCAG 2.1 AA for most consumer products, and US ADA litigation against inaccessible websites has grown steadily for a decade.
WCAG 2.1/2.2 defines three levels: A (minimum), AA (industry standard, and what regulations reference), AAA (aspirational, not fully achievable for all content types). AA is the correct target for almost every commercial product. It covers the four principles — Perceivable, Operable, Understandable, Robust (POUR) — through about 50 success criteria spanning color contrast, keyboard access, screen reader support, form labels, motion sensitivity, and more. Level A alone is not enough for compliance in most jurisdictions and will not survive a plaintiff-side accessibility lawsuit.
Automated scanners — axe-core, WAVE, Lighthouse — catch 30-40% of accessibility issues: missing alt text, insufficient color contrast, missing form labels, broken ARIA. They are essential but insufficient. They cannot detect: whether alt text is meaningful ('image1234.jpg' passes a tool that checks for presence), whether keyboard focus order is logical, whether ARIA is used correctly (misused ARIA is worse than no ARIA), whether the UI is usable with a screen reader in practice. Treat automated tools as a floor, not a ceiling.
A real audit includes: (1) full keyboard navigation of every flow — no mouse allowed, tab through everything, verify focus is always visible and never trapped. (2) screen reader testing on VoiceOver (macOS/iOS), NVDA (Windows), and TalkBack (Android) through core flows. (3) 400% zoom test — layout must remain usable, no horizontal scrolling. (4) prefers-reduced-motion test — animations should respect the OS setting. (5) forms with intentional errors to verify error announcements. Manual testing takes 3-10 days for a typical SaaS product per audit cycle.
Options in increasing depth/cost. (a) Internal team using axe DevTools and manual checklist — good for shift-left, insufficient as sole audit. (b) Accessibility consulting firms (Deque, TPGi, Level Access, Fable) — thorough audits with prioritized findings and legal-defensible documentation. (c) Testing with disabled users (Fable, AccessWorks) — the highest signal, catches real usability issues automated tools and consultants both miss. Best practice for a serious accessibility program: a11y engineer in-house + annual consulting audit + ongoing disabled-user testing on critical flows.
An audit produces a report; the audit's value comes from what you actually fix. Prioritize by impact × frequency: issues on high-traffic screens with severe blocking impact go first. Track findings in your normal issue tracker with a11y labels and definition-of-done that includes verification. Publish an accessibility statement documenting known limitations and remediation timelines. Silent lists of unresolved a11y findings are common; they're also exhibit A when litigation happens. Owning the gaps publicly and demonstrating remediation progress is meaningfully protective.
Investor directory · Fundraising library · Articles A–Z · Company funding database