WCAG 2.1 AA is now the de facto accessibility standard in the EU for most commercial websites. A site that fails it exposes the business to three kinds of loss: 15 to 20 percent of users with disabilities who cannot use the offer, legal risk under the European Accessibility Act from June 2025, and weaker positions in Google (a11y signals are part of Page Experience). This article breaks down a WCAG 2.1 AA audit into elements a decision-maker can grasp: what, why, how, how much.
WCAG 2.1 AA in 2026: who MUST, who should
The European Accessibility Act (EAA) entered into force on 28 June 2025 and imposes accessibility duties on B2C products and services across the EU. Specifically: e-commerce, banking, transport, telecommunications, e-books, ATM machines. The full list lives in Annex I of the directive. Penalties: in Poland up to 100 000 PLN per incident, in Germany up to 250 000 EUR per incident, plus the option to halt EU sales of the product.
The Polish Web Accessibility Act of 2019 (the Act on digital accessibility of websites and mobile applications of public sector entities) imposes WCAG 2.1 AA on public institutions, education, healthcare, local government. Penalties: up to 50 000 PLN, plus disciplinary action against responsible officers. An accessibility audit is also required before public procurement for IT projects.
The private B2B sector is not formally covered by the EAA, but there are two reasons why a WCAG audit makes sense: first, a B2B client in the public sector requires supplier compliance (we must hold an audit to apply to public tenders). Second, US lawsuit risk (ADA Title III) for firms with US clientele grows 25 percent year over year, with 4500 federal court cases related to website accessibility in 2024.
Practically every corporate website that wants to be perceived as professional in 2026 should include a WCAG 2.1 AA audit as part of a full website audit. We include accessibility in Tier 2 and Tier 3 audits by default.
An additional angle for DACH clients: the German Behindertengleichstellungsgesetz (BGG) plus the federal BITV 2.0 (Barrierefreie-Informationstechnik-Verordnung) impose stricter requirements on public sector and regulated industries. For DE clients we always check BITV 2.0 compliance as a delta on top of the WCAG 2.1 AA baseline.
The four POUR principles
WCAG 2.1 organises 78 success criteria into 4 principles: Perceivable, Operable, Understandable, Robust. The POUR acronym helps memorise and structure the audit.
Perceivable: the user must be able to perceive information through at least one of their senses. Concrete items: alt text for images (screen reader), captions for video (deaf users), color contrast of 4.5:1 minimum for text under 18pt (low vision users), do not use color alone as the indicator (color-blind users), audio alternative for audio-only content.
Operable: the user must be able to operate the interface through different input modalities. Concrete items: keyboard navigation (every action reachable from the keyboard, logical tab order), focus visible (every focused element has a visible indicator), skip links (skip to main content at the page top), no seizure triggers (no flashing content above 3 Hz), enough time (extendable timeouts), consistent navigation.
Understandable: the user must understand information and operation. Concrete items: a language attribute set on the html element (for example pl or en), readable language (clear messages, short sentences), predictable navigation (consistent structure across pages), input assistance (clear error messages, recovery hints), every form field having a clearly associated label.
Robust: content must be compatible with assistive technologies (NVDA, JAWS, VoiceOver). Concrete items: semantic HTML (button vs div, nav vs div, header vs div), valid HTML (no nested interactive elements, proper attribute usage), ARIA when building a custom widget (role, state, properties), status messages with live regions so the screen reader announces them.
POUR organises 50 success criteria into the WCAG 2.1 AA level (plus 25 at the A level). AA is the legal compliance baseline in the EU under the EAA. AAA (another 28 criteria) is aspirational, practically impossible without restricting functionality (it requires, for instance, sign language interpretation for every video). Our audit covers A plus AA, and flags AAA optionally as a nice-to-have.
The most common findings in audits
From 50+ WCAG audits between 2023 and 2025, recurring findings emerge. These five categories cover roughly 80 percent of all issues.
First: missing alt text for images. WCAG 1.1.1 requires a text alternative for every non-text content. In practice only 3 percent of sites in our sample had every image with a correct alt text. Common problems: WordPress media library without alt text on upload (the developer does not enforce it), decorative images with meaningful alt (empty alt is the right value for decorative), informative images with generic alt like “image” or the filename.
Second: color contrast too low. WCAG 1.4.3 requires 4.5:1 contrast for normal text, 3:1 for large text (18pt regular or 14pt bold). In our sample 30 percent of sites had at least one text-on-background contrast below 4.5:1. Common problems: gold accent on cream background (a brand mix of navy plus cream plus gold), placeholder text in form fields, disabled button state, footer links on a dark background.
Third: missing labels for form fields. WCAG 1.3.1 and 4.1.2 require every form input to have a clearly associated label. 25 percent of sample sites lacked proper labels, used placeholder as the label (anti-pattern, placeholder disappears on focus), or used a visually hidden label without an accessible name for the screen reader.
Fourth: missing focus indicator. WCAG 2.4.7 requires a visible focus indicator for every focusable element. The default browser focus ring (the blue outline in Chrome) is acceptable, but developers often strip it without replacement. 25 percent of sample sites had focus visibility issues.
Fifth: heading hierarchy chaos. WCAG 1.3.1 requires a logical heading order (H1, then H2, then H3, no skipping levels). 35 percent of sample sites had heading hierarchy issues: multiple H1, an H3 right after H1 with no H2 in between, H2 used as a visual style instead of structure. These problems are invisible to sighted users, but dramatic for a screen reader user who relies on heading navigation for orientation.
Beyond the top five: missing video captions, missing skip links at the page top, focus order out of sync with visual order after a responsive breakpoint, missing landmark roles (nav, main, header, footer in semantic HTML5 tags), keyboard traps in custom modal components (focus stuck inside the modal, no way to escape). Each of these problems can block a critical path for a screen reader user.
A practical observation from audits: WordPress sites running a default theme (Twenty Twenty-Four, Astra Pro) start at 60 to 70 percent WCAG compliance out-of-the-box. Custom themes without accessibility-first design start at 30 to 50 percent. Custom themes with accessibility-first design (the child theme pattern we use) start at 85 to 95 percent. An investment in accessibility-first design during the project phase cuts audit findings and remediation cost by 50 to 70 percent.
Tools: automated vs manual
A WCAG audit uses both automated and manual tools. Automated tools detect about 30 to 50 percent of issues, manual testing detects the rest. Skipping manual testing creates a false sense of compliance.
The Lighthouse a11y audit in Chrome DevTools is the first stop. It detects about 30 percent of typical issues: missing alt text, color contrast violations, ARIA misuse, form labels. Plus it compiles a developer-ready report. Limitation: it scans only the current DOM state, it does not catch issues that appear after interaction (modal open, accordion expand, AJAX content load).
Axe DevTools browser extension (Deque Systems) is the industry standard. Detects about 50 percent of issues, better than Lighthouse at analysing ARIA and complex interactions. The Free version is sufficient for most audits, the Pro version ($240 per year per user) adds guided manual tests and automated scanning in CI/CD.
Pa11y CLI is an automated tool for CI/CD integration. Runs axe-core in headless Chrome, exports JSON results. We use Pa11y in the deploy pipeline for automatic regression detection: every pull request runs Pa11y and fails if a new accessibility issue lands.
The WAVE tool (WebAIM) is another popular browser extension with visual highlighting of issues in the page context. Good for client education (you show a screen with the issues coloured), weaker for a detailed technical audit than axe.
Manual screen reader testing is mandatory for the 50 percent of issues that auto tools will not detect. NVDA (free, Windows) is the gold standard, JAWS (paid, Windows) is dominant in enterprise. VoiceOver (free, macOS and iOS) is for testing the Apple ecosystem. Our audit always covers at least 30 minutes of NVDA testing on critical paths.
A concrete manual test protocol: navigate the whole site keyboard-only (Tab/Shift+Tab/Enter/Escape/Arrow keys), verify every interactive element is reachable and operable, verify focus is visible on every element, run NVDA across critical paths (hero CTA, contact form submit, navigation menu), verify that landmarks are properly announced. The average runtime of this protocol is 45 to 60 minutes per audit.
Additional test: 200 percent browser zoom, verify content remains readable without horizontal scroll, that navigation still works, that there is no content overlap. WCAG 1.4.10 Reflow requires support for a 320 CSS pixel viewport without horizontal scroll, which in practice means 100 percent zoom on a 320px viewport or 400 percent zoom on a 1280px viewport.
Color contrast: the most common fail
Color contrast is the single most common WCAG violation in audits. It is easy to measure, easy to fix, but often neglected in the design phase.
Requirements: 4.5:1 contrast for text under 18pt regular weight or 14pt bold weight (normal text). 3:1 for text 18pt+ or 14pt bold (large text). 3:1 for UI components and graphical objects (icons, button borders).
Measurement tools: WebAIM Contrast Checker (webaim.org/resources/contrastchecker) for quick manual checks, the Stark Figma plugin for the designer workflow, the Chrome DevTools color picker which shows the contrast ratio inline on hover over text, the Lighthouse a11y audit which auto-flags violations.
Brand colors often trigger issues. Our own studio brand is navy plus cream plus gold accent. Practical tests: gold accent (#C9A961) on cream background (#F8F5EB) has contrast 2.8:1, which fails for normal text. Solution: a gold-dark variant (#8B6F2F) with contrast 5.2:1 for CTA buttons and links. A disabled button state must also hold at least 4.5:1 contrast if it contains label text.
Tooling tip: the Stark Figma plugin can auto-check completed designs and flag color violations before handoff to the developer. We recommend a Stark setup in every Figma project with handoff to dev.
Forms accessibility
Forms are the most critical path for accessibility, because they directly translate into business outcomes (lead capture, contact, checkout). Our audit dedicates 1 to 2 hours of manual form testing.
First rule: every form field should have a clearly associated label that is also visible to a sighted user. Do NOT use placeholder text as a label; it disappears on focus and the screen reader will not read it.
Second rule: group related fields together with a visible group title (for example a checkbox group “I consent to X, Y, Z” presented as a single named group). The screen reader announces the group name plus the current option name, giving context.
Third rule: error messages should be programmatically associated with the input they describe, so the screen reader reads them when the user lands on the field. Plus error styling that uses more than color alone (icon plus red border plus text “Field required” instead of a red border by itself).
Fourth rule: required indicator not by color alone. Asterisk plus text “Required” or a required marker that is also announced by the screen reader. Sighted users see the asterisk, screen reader users hear “required”.
Fifth rule: success message focus management. After submit, focus moves to the success message so the screen reader announces it. Plus visible confirmation, not just the form disappearing.
Compliance audit deliverable
Our WCAG audit deliverable is structured by standard. The client leaves the audit with a clear plan and a fix quote.
The PDF report contains findings per WCAG criterion (A and AA level), categorised as blocker (P0) / major (P1) / minor (P2). Per finding: WCAG criterion ID (for example 1.4.3 Contrast Minimum), screenshot with the problematic element highlighted, conformance status (pass/fail), recommendation with concrete code or solution, estimated fix time.
Plus a summary table: total findings per category, per priority, per area (header/footer/forms/content). Plus comparison against 2 competitors (Tier 3 only). Plus an optional fix quote as a separate backlog (our implementation rates: 200 PLN/h, 50 percent of the audit cost credited towards the rebuild if we continue).
The audit also covers an accessibility statement template (mandatory for public institutions in PL, a good practice for all). The statement contains: declared conformance level, list of known issues, contact for reporting accessibility problems, improvement plan (timeline).
Plus optionally: 1 to 2 hours of consulting call to review the report with the client, refine the fix scope, decide whether we implement or the client has its own dev team. Plus 30 days of email support for follow-up questions on specific findings.
FAQ
What is the price of a WCAG audit?
1500 to 3000 PLN for a typical SMB site (10 to 30 pages). Our Tier 2 (1500 PLN) covers a basic WCAG audit as part of a broader site audit. Tier 3 (3000 PLN) or a dedicated WCAG audit (2000 to 2500 PLN) for a deeper dive with manual screen reader testing and remediation roadmap.
Is WCAG AAA needed?
AAA is the highest level and is practically impossible to achieve for a typical site (for example it requires sign language interpretation for every video). AAA is needed only for public sector institutions in some countries (for example UK government services). In the EU, AA is the standard, AAA is not formally required.
Is Apple VoiceOver enough for testing?
It complements but does NOT replace NVDA and JAWS. NVDA (free, Windows) is the gold standard for testing, used by 41 percent of screen reader users globally (WebAIM 2024 survey). JAWS is used by 53 percent. iOS VoiceOver is used by 70 percent of mobile screen reader users. Our audit covers at minimum NVDA plus VoiceOver mobile.
Is compliance categorical or a gradient?
WCAG AA is pass/fail per success criterion. The site either meets 1.4.3 Contrast Minimum or it does not. Overall conformance is typically expressed as the percent of criteria passed: “90 percent conformance” means 90 percent of the 50 AA criteria fully passed. Our audit reports per criterion plus an aggregate score for the decision-maker.
If you want a WCAG 2.1 AA audit for your site, drop us a line with the page URL. Tier 2 audit (1500 PLN) covers a basic WCAG audit as part of a broader site audit. Standard turnaround 5 to 7 business days. For compliance projects with a deadline (before a certification audit, for instance), please give early notice with at least a 2 week lead time. A dedicated WCAG audit as a standalone deliverable is priced between 2000 and 2500 PLN.