WCAG 2.2 Accessibility: What It Means for Your Website and Why It Matters

Web accessibility is the practice of designing and building websites that can be used by people with disabilities — including those who are blind or have low vision, are deaf or hard of hearing, have motor impairments, or have cognitive disabilities. It’s not a niche concern: roughly one in five people in the UK has a disability, and many others benefit from accessible design as a side effect (captions help people watching in noisy environments; keyboard navigation helps power users).

WCAG — the Web Content Accessibility Guidelines — is the international standard that defines what accessible means in practice. The current version is WCAG 2.2, published in 2023. This guide explains the four core principles, the most important success criteria, and what practical changes they require on a typical business website.

The Four Principles of WCAG (POUR)

WCAG 2.2 is built on four principles, summarised by the acronym POUR: Perceivable — information must be presentable in ways all users can perceive. This includes providing text alternatives for images (alt text), captions for video, and sufficient colour contrast. Operable — users must be able to operate all interface components. This means everything must be keyboard-navigable (not mouse-dependent), no content should flash more than three times per second (seizure risk), and users must have enough time to complete tasks. Understandable — content and interfaces must be understandable. This covers clear language, predictable navigation, and helpful error messages on forms. Robust — content must be interpreted reliably by assistive technologies. This means using valid, semantic HTML and ARIA roles correctly.

Each principle contains specific success criteria rated at three levels: A (minimum), AA (standard requirement for most organisations), and AAA (enhanced). WCAG 2.1 Level AA is the baseline that most legal frameworks and government contracts specify. WCAG 2.2 AA adds nine new criteria to the 2.1 standard, primarily focused on cognitive accessibility and mobile usability.

Key Requirements That Affect Most Websites

The criteria that most commonly require changes on business websites: Alt text (1.1.1) — all meaningful images need descriptive alt text; decorative images should have empty alt attributes (alt=""). Colour contrast (1.4.3) — text must have a contrast ratio of at least 4.5:1 against its background (3:1 for large text). Many brand colour combinations fail this test. Keyboard access (2.1.1) — all interactive elements (menus, forms, carousels, modals) must be operable using a keyboard alone. Focus visible (2.4.7) — the keyboard focus indicator must be visible — never suppress it with outline:none without providing an alternative. Error identification (3.3.1) — form errors must be identified in text, not colour alone.

WCAG 2.2 adds new criteria including Focus Not Obscured (the focused element can’t be fully hidden by sticky headers), Dragging Movements (any drag-based interaction must have a pointer alternative), and Target Size Minimum (click targets must be at least 24×24 CSS pixels). These additions particularly affect mobile and touchscreen usability.

Legal Requirements in the UK

In the UK, the Equality Act 2010 requires that services — including websites — are accessible to people with disabilities. While there is no specific penalty scale for inaccessible websites, businesses have lost tribunals and settled claims related to inaccessible web services. Public sector bodies have stronger statutory duties under the Public Sector Bodies Accessibility Regulations 2018, which require WCAG 2.1 AA compliance and a published accessibility statement.

For private sector businesses, the practical risk is reputational and commercial as much as legal. An inaccessible website excludes a meaningful proportion of potential customers. It also affects SEO — many accessibility best practices (semantic HTML, descriptive alt text, clear heading structure) overlap directly with SEO best practices. At Xpose, accessibility is built into our design and development process from the start — it’s far more cost-effective to build accessibly than to retrofit it after launch.