Typical scenario: after launching a site, 20% of users cannot complete an order due to missing alt texts and incorrect focus. Or a regulatory body requires compliance with WCAG 2.1 AA. We conduct an accessibility audit: automated and manual testing, a detailed report, and a remediation plan.
WCAG 2.1 AA is an international standard mandatory for government sites in the EU (EN 301 549) and USA (Section 508). Level AA includes 50+ criteria covering perceivability, operability, understandability, and robustness. Our experience shows: manual testing identifies twice as many issues as automated tools, so we use both approaches.
Reasons for a WCAG 2.1 AA audit
Legal requirements aren't the only reason. An accessible site reaches audiences with disabilities (about 15% of the population). It also improves SEO: search engines factor in semantic structure and alt texts. Plus, it serves as proof of compliance during inspections.
Problems we solve
- Insufficient text contrast (SC 1.4.3) – gray text on white often falls below 4.5:1, common on buttons and tooltips.
- Missing
alton images – especially on product pages where screen readers cannot convey visual info. - Custom UI components (selects, sliders) lacking keyboard support and ARIA attributes – e.g., a datepicker without ARIA label or wrong role.
- Forms using placeholder instead of
<label>– screen readers can't identify fields, and text disappears on input. - Focus order not matching visual flow – users get lost during tabbing.
Here is a real case: on a fintech startup landing page, a custom dropdown did not open options when using keyboard keys. Our audit revealed missing aria-expanded and keydown handlers. Fix took 2 hours, but before that 30% of users with motor impairments could not select a tariff.
Audit process
- Automated scan using axe-core, WAVE, and Pa11y.
- Manual keyboard and screen reader testing (NVDA, JAWS, VoiceOver).
- Report generation with prioritized issues and code examples.
- Delivery of remediation plan with effort estimates.
- Optional implementation of fixes.
Automated tools (find ~30% of issues)
We use axe DevTools, Lighthouse, and Pa11y. Example axe-core integration:
// axe DevTools – Chrome/Firefox extension // Run on each page: F12 → Accessibility // axe-core via Playwright npm install -D @axe-core/playwright // audit.spec.ts import { test, expect } from '@playwright/test'; import AxeBuilder from '@axe-core/playwright'; const pagesToAudit = ['/about', '/contact', '/login', '/dashboard']; for (const path of pagesToAudit) { test(`${path} has no WCAG 2.1 AA violations`, async ({ page }) => { const baseUrl = process.env.BASE_URL || 'https://your-site.com'; await page.goto(`${baseUrl}${path}`); const results = await new AxeBuilder({ page }) .withTags(['wcag2a', 'wcag2aa', 'wcag21aa']) .analyze(); expect(results.violations).toEqual([]); }); } # WAVE https://wave.webaim.org/ # Pa11y pa11y --standard WCAG2AA <site-url> --reporter html > report.html # Lighthouse lighthouse <site-url> --only-categories=accessibility --output html Manual testing (60-70% of issues)
- Navigate entire user flow using only keyboard
- Test with NVDA + Chrome / JAWS + IE / VoiceOver + Safari
- Test at 200% and 400% zoom (SC 1.4.10 Reflow)
- Test in Windows High Contrast Mode
- Disable CSS – structure should remain meaningful
The irreplaceable role of manual testing
Automation finds syntactic errors: missing alt, low contrast, missing roles. But it cannot assess whether tab order makes sense or dynamic changes are announced correctly. For example, when a modal opens, the screen reader should hear its heading, and after closing, focus should return to the triggering element. This only manual testing can verify.
Comparison of automated vs manual testing
| Aspect | Automated tools | Manual testing |
|---|---|---|
| Issue detection | ~30% | 60-70% |
| Time to run | Minutes | Hours |
| Types of errors found | Syntactic, contrast | Logical, semantic, navigational |
| Cost | Low | High (requires expert) |
Combining both approaches yields maximum coverage. Manual testing finds twice as many issues as automation, especially with dynamic content.
What's included in the audit
- Full report listing each WCAG 2.1 AA violation
- Prioritization (Critical, Major, Minor) with impact explanation
- Screenshots and HTML paths to problem elements
- Remediation recommendations with code examples
- Implementation plan with effort estimates
- One-hour online consultation upon completion
- Optional fix implementation (additional cost)
Typical findings on Russian sites
- Missing
langattribute on<html>element - Low contrast gray text on white background
- Custom selects and dropdowns without keyboard support
- Forms using placeholder instead of
<label> - Sliders and carousels without control buttons
- Disabled zoom (
maximum-scale=1)
How quickly can violations be fixed?
Timeline depends on scope and complexity. Simple fixes (adding alt, fixing contrast) take a day. Deep component refactoring with ARIA updates may take weeks. We provide a step-by-step plan and can implement the fixes ourselves.
Audit timeline
| Site size | Duration |
|---|---|
| Landing page (5–10 pages) | 2-3 days |
| Corporate site (20–50 pages) | 4-7 days |
| SaaS / web app | 7-14 days |
| Fixes based on findings | 1.5x the audit duration |
Our team includes IAAP Certified Accessibility Specialists with over 5 years of experience, having completed 100+ audits. We follow a comprehensive accessibility checklist covering all WCAG 2.1 AA criteria. Starting from $500 for a 5-page audit. Order an accessibility audit for your site – we will estimate the work in 1 day and prepare a commercial proposal. You will also receive a consultation on fixing priorities.







