WCAG 2.1 AA Website Accessibility Audit & Report

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 alt on 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

1. Automated scan using axe-core, WAVE, and Pa11y.
2. Manual keyboard and screen reader testing (NVDA, JAWS, VoiceOver).
3. Report generation with prioritized issues and code examples.
4. Delivery of remediation plan with effort estimates.
5. 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

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 lang attribute 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

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.

Website Accessibility: WCAG, Screen Readers, Keyboard Navigation

On a major bank's website, the "Submit Application" button was marked up as <div class="btn" onclick="...">. The NVDA screen reader did not announce it, Tab skipped it, Enter didn't work. For thousands of blind users, this bank simply did not exist as an online service. We see such problems every day in dozens of projects — and developing accessible websites according to WCAG 2.2 AA has become the only way to avoid discrimination and legal risks. Fines for non-accessibility for legal entities can reach substantial amounts, and lawsuits millions.

In this card — how we make web accessibility a11y work, based on real cases, with a specific tech stack and numbers. No generic phrases.

Why is Semantic Markup the Foundation of Web Accessibility (a11y)?

Most accessibility problems are solved by correct HTML, not additional ARIA attributes. <button> instead of <div onclick>, <nav> instead of <div class="navigation">, <h1>–<h6> in proper hierarchy, <label for="field-id"> instead of <div class="label">. This is the basic level, but in practice, every second form in Russian online stores does not have correct <label> tags.

ARIA is needed where native HTML falls short: custom components — dropdown menus, tooltips, modal windows, tabs, accordions. And here the complexity begins.

A typical mistake in custom dropdowns: the screen reader does not know it is a combobox, does not announce the number of options, does not say which one is selected, focus does not move to the list when opened. Proper implementation:

• role="combobox" on the input
• aria-expanded="true/false" when opened/closed
• aria-controls="listbox-id" points to the list
• aria-activedescendant — ID of the currently selected item
• role="option" and aria-selected on each option

This is not theory; it is tested with a screen reader. NVDA + Chrome or VoiceOver + Safari is a mandatory part of QA.

<div role="combobox" aria-expanded="false" aria-controls="listbox-1" aria-activedescendant="" tabindex="0">
  <label for="input-1">Select city</label>
  <input id="input-1" type="text" role="combobox" aria-autocomplete="list" />
  <ul id="listbox-1" role="listbox" aria-label="Cities">
    <li role="option" aria-selected="false" id="opt-1">Moscow</li>
    <li role="option" aria-selected="false" id="opt-2">St. Petersburg</li>
  </ul>
</div>

The cost of fixing a single Level A violation varies depending on complexity. Implementing a11y from the design stage reduces the refactoring budget by 2–3 times compared to retrofitting a finished site.

How to Properly Build Keyboard Navigation?

Tab order should match the visual order of elements. If in HTML the "Cancel" button comes before "Confirm", but CSS swaps them — the keyboard user is confused.

Focus trap in modal windows. When a modal opens, Tab should cycle only within it. When closing, return focus to the element that opened the modal. Without this, the user ends up at the top of the page after closing.

tabindex="-1" — element does not enter Tab sequence but can receive focus programmatically. Used for elements that receive focus via JavaScript (section headings after anchor navigation).

tabindex="1" and above is almost always an error. Explicit order breaks natural order and creates unpredictable behavior. Control order via DOM, not tabindex.

Skip links — a "Skip to content" link, hidden visually, visible on Tab. Allows screen reader users to skip repetitive navigation.

Color and Contrast: Requirements and Common Violations

WCAG 2.2 AA requires contrast 4.5:1 for normal text, 3:1 for large text (18px+ or 14px+ bold). AAA requires 7:1 and 4.5:1.

The most common violations: gray placeholder in inputs (#999 on white = 2.9:1), light gray secondary text, white text on pastel backgrounds.

Color should not be the sole indicator: "required fields are red" without an asterisk — violation for color blind users.

Testing tools: axe DevTools, WAVE, Accessibility Inspector in Chrome DevTools. axe-core integrates into Playwright tests: automatic check of 80+ rules on every deployment. Manual testing finds about 60% more errors than automated.

What Is Important About Media Content and Dynamics?

Images without alt — a common basic failure. alt should be meaningful: not alt="image_123.jpg", but a description of content relevant to context. Decorative images — alt="" (empty, not missing attribute).

Video should have captions. YouTube auto-captions are not a standard; they make mistakes. WebVTT files with correct captions for all educational and marketing video content.

Animations — a problem for users with vestibular disorders. @media (prefers-reduced-motion: reduce) — media query that disables or slows animations for users with that OS setting.

What Changed in WCAG 2.2?

Version 2.2 came into effect with new criteria:

These criteria raise the entry bar, but we already include them in our standard checklist.

Audit and Remediation

Automated tools find about 30–40% of violations. The rest is only manual testing. Minimum scenario: go through the entire critical user flow (registration, purchase, form) using only keyboard and screen reader.

Process

1. Automated audit — axe-core, Lighthouse, WAVE — outputs 80+ rules.
2. Manual testing — NVDA, VoiceOver, keyboard — 2–3 days for a typical site.
3. Violation prioritization — P1 (blocks usage), P2 (creates difficulties), P3 (enhancements).
4. Fixing — iteratively, integrate checks into CI via Playwright + axe.
5. Re-audit — close all P1/P2 before release.
6. Documentation and handover — report with results, maintenance recommendations, team training.

Results and Scope

• Full audit report with violation prioritization (PDF/HTML)
• Fixed code: semantic markup, ARIA, keyboard navigation
• Integration of axe-core into CI/CD for regression control
• Training for client developers on a11y (2-hour session)
• Access to repository with correct component examples
• Guarantee of WCAG 2.2 AA compliance at time of delivery

Timeline

Budget is calculated individually after the audit. Contact us — we will evaluate your project in 1 day. Get a consultation and free checklist when ordering an audit.

Experience and Guarantees

We have been working in web accessibility a11y for over 8 years. Completed more than 50 projects for banks, retail, and government. Certified specialists (IAAP CPACC, WAS). We guarantee passing a third-party audit or will fix for free.

WCAG 2.2 Standard — official W3C recommendation defining web content accessibility requirements.

Wikipedia: Web Content Accessibility Guidelines
Wikipedia: ARIA

— web accessibility levels a11y per version 2.2.

Order an audit now — get a checklist and preliminary estimate for free. Contact us – we will respond within an hour.