Audit of website accessibility according to WCAG
A user with a visual impairment cannot fill out a form on your site—the submit button is inaccessible via keyboard, and the screen reader doesn't announce errors. According to WebAIM statistics, 96% of the million home pages contain WCAG errors. We identify such barriers and provide precise instructions to eliminate them, so your site meets the WCAG 2.2 standard at level AA. Ignoring accessibility risks not only losing audience but also legal penalties: fines in the US can reach $50,000 for a first violation, and in Europe up to €75,000 under GDPR (for government sites). Savings from timely remediation can be up to $10,000.
An accessibility audit is not a one-time check but the embedding of an inclusive culture into the development process. Manual testing reveals twice as many errors as automated testing, so we combine both approaches. Timely auditing helps avoid litigation and increases user loyalty.
Why WCAG AA is not just a checkbox?
Government websites in many countries are required to comply with WCAG AA. Commercial projects follow it de facto: it reduces legal risks and expands the audience by 15–20%. The current version of the standard—WCAG 2.2—includes new criteria: focus indication (2.4.13), target size (2.5.8), and input persistence (2.5.7). Our audit covers all these requirements.
How we test accessibility: from automation to manual testing
Automated scanning identifies about 30–40% of violations: missing alt texts, low contrast, incorrect heading structure, missing ARIA attributes. We use axe-core, Lighthouse, and Pa11y.
# axe-core CLI npm install -g @axe-core/cli axe https://mysite.com --reporter=json > axe-report.json Manual testing is mandatory. We check keyboard navigation, screen reader compatibility (NVDA + Firefox, VoiceOver + Safari, TalkBack + Android). Modal windows, forms, custom components—each interactive element goes through 20+ tests. For example, when checking alt texts we note: <img src="banner.jpg" alt="Website accessibility audit: 30% discount"> — correct alt, while an empty alt on a decorative image is an error.
Focus traps in modal windows are one of the most common errors. Correct React code:
const Modal = ({ isOpen, onClose, children }) => { const modalRef = useRef(null); useEffect(() => { if (isOpen) { const previouslyFocused = document.activeElement; modalRef.current?.focus(); return () => { previouslyFocused?.focus(); }; } }, [isOpen]); return ( <div ref={modalRef} role="dialog" aria-modal="true" aria-labelledby="modal-title" tabIndex={-1}> {children} </div> ); }; Comparison of testing methods
| Method | Errors detected | Time | Example tools |
|---|---|---|---|
| Automated | 30–40% | Minutes | axe, Pa11y, Lighthouse |
| Manual | 60–70% | Hours–days | Keyboard, NVDA, VoiceOver |
| Combined | ~95% | 1–3 days | Our standard process |
What we check: key WCAG AA criteria
| Criterion | Requirement | Common mistake |
|---|---|---|
| 1.1.1 Alt Text | All images have alt | Decorative images missing alt="" |
| 1.3.1 Info and Relationships | Structure conveyed semantically | <div> instead of <button>, <nav>, <main> |
| 1.4.3 Contrast | 4.5:1 for text, 3:1 for large text | Gray text on white background |
| 2.1.1 Keyboard | Everything operable via keyboard | Missing focus on custom dropdowns |
| 2.4.7 Focus Visible | Visible focus indicator | outline: none without alternative |
| 3.3.1 Error Identification | Form errors described in text | Color-only error indication |
| 4.1.2 Name, Role, Value | ARIA for custom components | Missing role/aria-label on icon buttons |
How to fix typical errors?
Icon button without description:
// BAD <div onClick={handleDelete}><TrashIcon /></div> // GOOD <button onClick={handleDelete} aria-label="Delete record"><TrashIcon aria-hidden="true" /></button> Skip navigation link:
<a href="#main-content" class="skip-link">Skip to main content</a> <style> .skip-link { position: absolute; left: -9999px; } .skip-link:focus { left: 0; top: 0; z-index: 9999; } </style> Report structure
- Full list of violations mapped to WCAG criteria (critical, serious, moderate).
- Screenshots and HTML selectors for each problematic element.
- Fix recommendations with ready-to-use code examples.
- Manual testing checklist for developers.
- Integration recommendations for CI/CD (Playwright, axe).
Example entry:
- Violation: Missing alt text on image (1.1.1).
- Selector:
#main img.banner. - Priority: Critical.
- Recommendation: Add
alt="Banner: 30% discount on winter collection".
What is included in the audit process?
- Analytics — identify key pages and scenarios (up to 20 pages in 1 day).
- Automation — run axe/Pa11y, collect 30–40% of errors (1 hour).
- Manual testing — keyboard, screen readers, logical order (1–2 days).
- Report — structured list with priorities.
- Recommendations — ready fixes with code (2–3 days).
Timeline and cost
Audit of a site up to 20 pages takes 2–3 business days. Cost is determined individually based on complexity and number of interactive scenarios. Order an accessibility audit—we will prepare a detailed report and help implement fixes. Contact us for a consultation.
Our experience: 5+ years in web accessibility, 100+ projects audited for banks, government agencies, and e-commerce. We guarantee WCAG AA compliance.