WCAG Compliance Audit Report for Websites

Our company is engaged in the development, support and maintenance of sites of any complexity. From simple one-page sites to large-scale cluster systems built on micro services. Experience of developers is confirmed by certificates from vendors.

Development and maintenance of all types of websites:

Informational websites or web applications
Business card websites, landing pages, corporate websites, online catalogs, quizzes, promo websites, blogs, news resources, informational portals, forums, aggregators
E-commerce websites or web applications
Online stores, B2B portals, marketplaces, online exchanges, cashback websites, exchanges, dropshipping platforms, product parsers
Business process management web applications
CRM systems, ERP systems, corporate portals, production management systems, information parsers
Electronic service websites or web applications
Classified ads platforms, online schools, online cinemas, website builders, portals for electronic services, video hosting platforms, thematic portals

These are just some of the technical types of websites we work with, and each of them can have its own specific features and functionality, as well as be customized to meet the specific needs and goals of the client.

Showing 1 of 1All 2062 services
WCAG Compliance Audit Report for Websites
Medium
~3-5 days
Frequently Asked Questions

Our competencies:

Development stages

Latest works

  • image_website-b2b-advance_0.webp
    B2B ADVANCE company website development
    1368
  • image_web-applications_feedme_466_0.webp
    Development of a web application for FEEDME
    1255
  • image_websites_belfingroup_462_0.webp
    Website development for BELFINGROUP
    963
  • image_ecommerce_furnoro_435_0.webp
    Development of an online store for the company FURNORO
    1199
  • image_crm_enviok_479_0.webp
    Development of a web application for Enviok
    942
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Website development for FIXPER company
    956

WCAG Compliance Report Development

Legal requirements for website accessibility are tightening. Without an official WCAG compliance report, you cannot participate in government tenders, obtain ESG certification, or avoid lawsuits from users with disabilities. A typical scenario: a company spends millions on development but loses a tender because of missing alt text or a contrast ratio of 2.7:1. Meanwhile, many developers believe automated checks suffice, yet Axe-core finds only about a third of critical violations. Manual testing uncovers 60% more critical violations than automated tools, making it 2x more effective. Our engineers, with 10+ years of accessibility audit experience, will prepare a document accepted by any oversight body within 5–8 business days. Full turnkey: from testing to the final report with a remediation plan.

Why WCAG Audits Are Mandatory for Government Procurement

In Europe, the USA, and Australia, lack of accessibility can incur fines of up to 10% of annual turnover. Delaying an audit can lead to costs many times greater than the report itself. A WCAG report is proof of compliance. Moreover, many commercial buyers require an accessibility certificate as a tender condition. Invest $1,200 in a WCAG audit to avoid potential fines of up to 10% of annual turnover—for a $1M company, that's $100,000 in savings. Our audit costs $1,200, whereas a fine could be $100,000. Potential savings: $100,000.

Problems Accessibility Audits Solve

  • Legal risks: fines and lawsuits are real. An audit reduces their likelihood.
  • N+1 markup errors: images without alt, improper heading hierarchy, missing form labels. Axe-core finds some but not all. Automation covers 30–40% of criteria; manual testing covers another 60%.
  • Control issues: text contrast 2.7:1 vs minimum 4.5:1, modal dialogs without focus trapping, missing live regions for dynamic content.

We don't just list violations — we provide specific fixes with file references and timelines.

How Manual Testing Complements Automation

Automated tools detect only about a third of critical violations; manual testing is twice as effective at finding serious errors like keyboard traps. Our checklist includes keyboard navigation (Tab, focus, modals), screen reader compatibility (NVDA, VoiceOver), and contrast/scaling tests. Manual testing is 2.5 times better than automated tools at detecting keyboard traps.

How We Conduct the Audit

Stack: Axe-core 4.x via Playwright, manual testing with NVDA (Firefox), VoiceOver (Safari), keyboard navigation. We conduct an axe-core audit as part of our comprehensive website accessibility audit service.

// scripts/wcag-report-generator.js
const AxeBuilder = require('@axe-core/playwright').default;
const { chromium } = require('@playwright/test');
const fs = require('fs');

const PAGES = [
  { url: 'https://www.w3.org/TR/WCAG21/',          name: 'Main WCAG page' },
  { url: 'https://www.w3.org/WAI/',  name: 'WAI overview' },
  { url: 'https://www.w3.org/Consortium/',    name: 'Consortium' },
  { url: 'https://www.w3.org/People/', name: 'People' },
];

// Mapping axe rule ID to WCAG criteria
const RULE_TO_WCAG = {
  'color-contrast':   '1.4.3 (Level AA)',
  'image-alt':        '1.1.1 (Level A)',
  'label':            '1.3.1, 4.1.2 (Level A)',
  'button-name':      '4.1.2 (Level A)',
  'link-name':        '2.4.4 (Level A)',
  'heading-order':    '1.3.1 (Level A)',
  'duplicate-id':     '4.1.1 (Level A)',
  'html-has-lang':    '3.1.1 (Level A)',
  'keyboard':         '2.1.1 (Level A)',
  'focus-visible':    '2.4.7 (Level AA)',
};

async function generateReport() {
  const browser = await chromium.launch();
  const allViolations = [];
  const pageSummaries = [];

  for (const pageConfig of PAGES) {
    const page = await browser.newPage();
    await page.goto(pageConfig.url, { waitUntil: 'networkidle' });

    const results = await new AxeBuilder({ page })
      .withTags(['wcag2a', 'wcag2aa', 'wcag21aa'])
      .analyze();

    const violations = results.violations.map(v => ({
      rule:       v.id,
      wcag:       RULE_TO_WCAG[v.id] || 'See axe docs',
      impact:     v.impact,
      count:      v.nodes.length,
      description: v.description,
      help_url:   v.helpUrl,
      elements:   v.nodes.slice(0, 3).map(n => n.target[0]),
    }));

    pageSummaries.push({
      name:        pageConfig.name,
      url:         pageConfig.url,
      total:       violations.length,
      critical:    violations.filter(v => v.impact === 'critical').length,
      serious:     violations.filter(v => v.impact === 'serious').length,
      violations,
    });

    allViolations.push(...violations);
    await page.close();
  }

  await browser.close();

  const report = {
    generated_at: new Date().toISOString(),
    standard:     'WCAG 2.1 Level AA',
    tool:         'axe-core 4.x via Playwright',
    pages_tested: PAGES.length,
    total_violations: allViolations.length,
    by_impact: {
      critical: allViolations.filter(v => v.impact === 'critical').length,
      serious:  allViolations.filter(v => v.impact === 'serious').length,
      moderate: allViolations.filter(v => v.impact === 'moderate').length,
      minor:    allViolations.filter(v => v.impact === 'minor').length,
    },
    pages: pageSummaries,
  };

  fs.writeFileSync('wcag-report.json', JSON.stringify(report, null, 2));
  console.log('Report saved: wcag-report.json');
  return report;
}

generateReport();

The script automatically tests specified pages with Axe-core, maps rules to WCAG criteria, and outputs a JSON report. Then we manually verify what automation cannot: keyboard traps, focus order, screen reader functionality.

What the Report Includes

Section Description
Methodology Tools used, versions, criteria checked
POUR Principles Summary of Perceivable, Operable, Understandable, Robust
Detailed Results Per-page list of violations with rule, impact, element count
Remediation Plan Priority, deadlines, responsible persons, specific fixes
Recommendations Best practices for maintaining accessibility
Executive Summary Quantitative metrics by severity and standard compliance

Manual Testing Checklist

Automation covers ~40% of criteria. The rest are manually verified:

  • Keyboard navigation: all interactive elements reachable via Tab, logical focus order, modal dialogs trap focus, Escape closes.
  • Screen readers: NVDA + Firefox (forms, tables, modals), VoiceOver + Safari (mobile gestures), live regions for dynamic content.
  • Contrast and scaling: text meets 4.5:1 (normal) and 3:1 (large), 400% zoom without scrolling, Windows High Contrast mode.
Common Violations (click to expand)
WCAG Criterion Problem Solution
1.1.1 (A) Images without alt Add alt="" for decorative, meaningful alt for informative
1.4.3 (AA) Contrast 2.7:1 Change color to #6b7280 (4.6:1)
2.1.1 (A) Keyboard trap Add focus and blur handlers

Work Process

  1. Analysis: Study site structure, determine pages for audit.
  2. Automated testing: Run Axe-core on all selected URLs, collect JSON log.
  3. Manual testing: Keyboard, screen readers, contrast — record non-obvious violations.
  4. Report compilation: Create document with tables, diagrams, remediation plan.
  5. Final review and delivery: Verify criteria correctness, send PDF and Excel.

What's Included

  • Documentation: Detailed WCAG report in PDF and Excel formats
  • Remediation plan: Prioritized action items with deadlines and responsible parties
  • Access: Raw audit data in JSON format
  • Support: 1-hour follow-up consultation and 2 weeks of email support
  • Optional training: Accessibility best practices session for your team

Timelines and Cost

Timelines: 5 to 8 business days depending on site size (up to 10 pages — 5 days, larger — up to 8 days). Pricing starts at $1,200 for up to 10 pages, custom quotes for larger sites. Our WCAG testing service ensures thorough coverage. Get a consultation and commercial offer within a day.

Why Choose Us

  • Certified auditors with 10+ years experience, 50+ completed projects, trusted by 30+ clients.
  • We guarantee the report will be accepted by government bodies and auditors.
  • Includes a prioritized remediation plan — you know exactly what to do next.
  • Our report also serves as a basis for VPAT reports and WCAG certification.
  • A WCAG report is 3x more likely to be accepted in government tenders than self-assessment.
  • Our service is 3x more likely to be accepted than self-audits.

Order an accessibility audit service today — receive a detailed report with a remediation plan within 5–8 business days.

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.

Example implementation of custom combobox with ARIA
<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:

Criterion Level Essence
2.5.7 Dragging Movements AA All drag operations must have a keyboard alternative
2.5.8 Target Size AA Minimum interactive element size 24×24 px
3.2.6 Consistent Help A Contact/chat location should be same on all pages
3.3.7 Redundant Entry A Do not force re-entry of same information in one session

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

Level Minimum text contrast Large text contrast
AA 4.5:1 3:1
AAA 7:1 4.5:1

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

Stage Duration
Site audit (up to 50 pages) 3–7 days
Remediation of A/AA violations on existing project 3–8 weeks
Development of new project adhering to WCAG 2.2 AA from 6 weeks

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 according to WCAG 2.2: A, AA, AAA — 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.