Website accessibility used to be treated by most UK SMBs as a nice-to-have. Two things have changed that. The W3C published WCAG 2.2 as a recommendation in October 2023, making it the working standard for any organisation taking accessibility seriously. The European Accessibility Act came into force across member states on 28 June 2025, applying to any business above the small-business threshold trading into the EU. UK businesses with EU customers are in scope; UK public-sector sites have been in scope since 2018 under the Public Sector Bodies Accessibility Regulations. The combined effect: accessibility is now a baseline expectation across most of the commercial UK web.
What WCAG 2.2 actually is
WCAG 2.2 is the W3C’s Web Content Accessibility Guidelines version 2.2, published as a Recommendation on 5 October 2023. It is an additive update to WCAG 2.1 — every 2.1 success criterion is still in 2.2, with nine new criteria added and one removed (4.1.1 Parsing, which is now considered obsolete). For UK organisations meeting WCAG 2.1 AA today, achieving WCAG 2.2 AA requires implementing the nine new criteria; the existing 2.1 work transfers cleanly.
The nine new WCAG 2.2 success criteria
(1) 2.4.11 Focus Not Obscured (Minimum) AA — when an element receives focus, it must not be entirely hidden by author-created content (sticky headers, cookie banners, modals). (2) 2.4.12 Focus Not Obscured (Enhanced) AAA — the stricter version, no part hidden. (3) 2.4.13 Focus Appearance AAA — focus indicators must meet specific size and contrast thresholds. (4) 2.5.7 Dragging Movements AA — any drag interaction must have a single-pointer alternative. (5) 2.5.8 Target Size (Minimum) AA — interactive targets at least 24×24 CSS pixels unless inline or otherwise exempted. (6) 3.2.6 Consistent Help A — help mechanisms (contact, FAQ, chat) appear in consistent order across the site. (7) 3.3.7 Redundant Entry A — information previously entered in a process is auto-populated or available for selection. (8) 3.3.8 Accessible Authentication (Minimum) AA — no cognitive function test (memorising password, solving puzzle) required for authentication unless there is an alternative. (9) 3.3.9 Accessible Authentication (Enhanced) AAA — the stricter version applies to any cognitive test.
The 2.1 baseline that still applies
The five most-failed WCAG 2.1 AA criteria in UK SMB audits, all of which still apply in 2.2. (1) 1.4.3 Contrast Minimum — text must meet 4.5:1 contrast against background for normal text, 3:1 for large text. The most common failure: pale grey body text on white. (2) 1.4.11 Non-text Contrast — UI components and graphical objects must meet 3:1 contrast. The most common failure: low-contrast form field borders. (3) 2.4.7 Focus Visible — every interactive element must have a visible focus indicator. The most common failure: CSS resets that remove outlines without replacing them. (4) 1.3.1 Info and Relationships — semantic structure must be programmatically determinable. The most common failure: headings used for visual styling rather than document structure. (5) 4.1.2 Name, Role, Value — every interactive element must have an accessible name. The most common failure: icon-only buttons without aria-label.
The European Accessibility Act and the UK
The EAA came into force across EU member states on 28 June 2025 and applies to products and services placed on the EU market by businesses above the EU small-business threshold (10+ staff or €2m+ turnover). UK businesses are in scope if they trade goods or services into the EU. The Act applies to e-commerce sites, ticketing systems, banking services, e-books and consumer electronics among other categories. The accessibility requirement is functionally aligned with WCAG 2.1 AA at minimum; member states have implemented through national legislation with varying enforcement mechanisms. For UK SMBs with EU customers, the practical impact is that WCAG 2.1 AA compliance is now a commercial requirement, not just an ethical one.
The accessibility statement
WCAG 2.2 requires an accessibility statement on every public-facing website that claims compliance. The statement should cover: the WCAG version and conformance level claimed (typically 2.2 AA), known compliance gaps and remediation timelines, the feedback channel for accessibility issues, and the date the statement was last reviewed. UK public-sector sites must follow the GOV.UK accessibility statement template under PSBAR; commercial sites have more flexibility but the same essential structure applies.
The audit process we run
Two-stage. Automated scan first via axe DevTools, WAVE and Lighthouse Accessibility — catches roughly 30-40% of WCAG failures and produces the first triage list. Manual audit second, covering keyboard navigation on every page, screen-reader testing (NVDA on Windows, VoiceOver on macOS and iOS), colour-contrast on text and UI components, focus-management on dynamic content, form-error handling, and the specific 2.2 additions (drag alternatives, target sizes, authentication paths). The manual audit catches the 60-70% the automated tools miss. Allow 4-12 hours of senior engineer time depending on site size; deliverable is a prioritised remediation list with WCAG references for each issue.
The five highest-leverage fixes
(1) Colour contrast — usually the largest single category of issues, and fixable in a single sweep through the colour tokens in the design system. (2) Focus indicators — typically a single CSS rule applied across the site, but it has to be visible and meet the 2.2 appearance criterion. (3) Form labels — every form field with a proper associated label, not placeholder-only. (4) Heading structure — convert any visual-only heading styling to actual heading elements, and remove headings used purely for visual styling. (5) Image alt text — descriptive alt where the image conveys content, empty alt where the image is decorative. These five together typically resolve 60-80% of WCAG failures on a typical SMB site.
The harder fixes
Three categories that need more thought. Drag interactions — anything in the UI built around drag-and-drop needs a single-pointer alternative under 2.2 criterion 2.5.7; the typical fix is to add explicit add/remove buttons next to the drag handles. Authentication — passwords requiring memorisation and CAPTCHAs requiring cognitive tests are now restricted under 3.3.8 and 3.3.9 unless an alternative is offered; the typical fix is to add passkey/WebAuthn support, biometric authentication or magic-link login. Modal and overlay focus management — focus must be trapped inside the modal while open and returned to the trigger element on close; getting this right requires careful JavaScript rather than just CSS.
Tooling that genuinely helps
axe DevTools (free Chrome extension) — the best automated scanner for the daily development workflow. WAVE (free WebAIM tool) — useful complement to axe with a different rule set. NVDA (free Windows screen reader) — the screen reader to test against. VoiceOver (built into macOS and iOS) — the second screen reader. Polypane (paid browser) — accessibility-first browser with built-in audit tooling that catches what other tools miss. Stark (paid Figma plugin) — contrast and accessibility checking in the design tool before code is written.
What "compliant" actually means
WCAG 2.2 AA conformance is binary at the per-criterion level — you either meet the criterion or you do not. Site-level conformance is making the claim that every page meets every AA-level criterion in scope. Most commercial UK sites can reach this with 1-3 weeks of focused remediation work plus an ongoing discipline of checking new content and code against the criteria as it ships. The accessibility statement is the public record of that claim; making the claim without backing it up is now a meaningful legal and reputational exposure.