WCAG 2.2 Explained: What Website Accessibility Means for Your Business

What is WCAG?

WCAG stands for Web Content Accessibility Guidelines.

It is the main international standard used to make websites, portals, apps and digital content more accessible to people with disabilities.

The latest version in the WCAG 2 series is WCAG 2.2. W3C describes WCAG 2.2 as a wide range of recommendations for making web content more accessible.

For most business websites and digital services, the practical target is WCAG 2.2 Level AA.

What does website accessibility mean?

Website accessibility means designing and building digital content so that as many people as possible can use it, including people with visual, hearing, physical, cognitive, speech or neurological disabilities.

It also benefits people in temporary or situational circumstances, such as someone using a mobile phone outdoors, recovering from an injury, dealing with poor internet, using assistive technology or struggling with a complex form.

An accessible website should not depend on a single way of using it.

navigate without a mouse
read content with a screen reader
understand forms and error messages
zoom text without breaking the layout
see sufficient colour contrast
use clear buttons and links
avoid being trapped in pop-ups or menus
pause, stop or control moving content
complete key tasks without unnecessary barriers

What is WCAG 2.2?

WCAG 2.2 is a set of accessibility success criteria created by the World Wide Web Consortium, known as W3C.

W3C explains that WCAG documents show how to make web content more accessible to people with disabilities, and that WCAG 2.2 is designed to be backwards compatible with WCAG 2.1 and WCAG 2.0. W3C also encourages use of the latest version of WCAG.

That means if a website is designed to meet WCAG 2.2, it is generally being assessed against the most current WCAG 2 standard.

The three WCAG levels: A, AA and AAA

Level A is the minimum level. It covers essential accessibility requirements.
Level AA is the usual target for business, public-sector and service-based websites. It includes Level A and adds more requirements around areas such as contrast, navigation, forms, errors and responsive behaviour.
Level AAA is the highest level. It can be useful for certain types of content, but it is not always realistic or required across an entire website.

What changed in WCAG 2.2?

WCAG 2.2 builds on WCAG 2.1. It adds additional success criteria, with particular focus on areas such as focus visibility, dragging movements, target size, consistent help, redundant entry and accessible authentication.

In practical terms, WCAG 2.2 places more attention on common real-world barriers, including:

buttons and links that are too small
focus indicators being hidden by sticky headers or overlays
drag-and-drop features without alternatives
users being forced to enter the same information repeatedly
help options moving around between pages
login processes that rely too heavily on memory or cognitive tasks

The four WCAG principles

WCAG is organised around four core principles, often shortened to POUR.

1. Perceivable

Users must be able to perceive the information on the website. This includes things like text alternatives for images, captions for video, readable colour contrast and content that still works when resized or zoomed.

2. Operable

Users must be able to operate the interface. This includes keyboard navigation, visible focus states, avoiding keyboard traps, giving users enough time and making sure interactive elements can actually be used.

3. Understandable

Users must be able to understand the content and how the website works. This includes plain language, predictable navigation, clear labels, helpful error messages and consistent layouts.

4. Robust

The website must be built properly enough to work with different browsers, devices and assistive technologies. This includes semantic HTML, correct labels, sensible use of ARIA, and code that can be interpreted reliably by screen readers and other tools.

Why WCAG matters for business websites

Accessibility affects more than legal compliance.

An inaccessible website can lose enquiries, frustrate users, increase support requests and create reputational risk. It can also exclude people who are actively trying to buy, apply, book, register, pay or contact your organisation.

For commercial websites, these issues are not just technical defects. They are conversion barriers.

forms that cannot be completed by keyboard
poor colour contrast
missing image descriptions
vague link text such as click here
confusing error messages
pop-ups that trap users
PDFs that cannot be read properly
menus that do not work on mobile
payment or login journeys that fail with assistive technology

WCAG and the law

Accessibility requirements vary depending on the organisation, sector and country.

In the UK, public-sector websites and mobile apps are subject to accessibility regulations. GOV.UK states that the Public Sector Bodies Accessibility Regulations require public-sector websites and mobile apps to be made more accessible by making them perceivable, operable, understandable and robust, and that an accessibility statement must be included and updated.

Private-sector businesses may not always have the same specific website regulations as public-sector bodies, but accessibility still matters from a legal, ethical and commercial perspective, especially where services are used by the public or by people with disabilities.

For any organisation, the safest approach is to treat WCAG 2.2 Level AA as the practical accessibility benchmark for modern digital services.

What WCAG means during a website project

A WCAG-aware website project should consider accessibility from the start, not at the final testing stage.

That means accessibility should influence:

wireframes
design systems
colours and typography
navigation
content structure
forms
error handling
buttons and links
mobile layouts
PDFs and downloads
video and media
development standards
testing and QA

Practical examples of WCAG-friendly design and development

A WCAG 2.2 AA-focused project should include checks such as:

For portals and web applications, extra attention should be given to authentication, dashboards, file uploads, account management, notifications and session expiry.

using proper heading structure
writing descriptive page titles
making links meaningful
ensuring text contrast is strong enough
making all key journeys usable by keyboard
giving every form field a visible label
making errors clear and helpful
ensuring focus states are visible
avoiding colour-only status messages
making content responsive and usable at zoom
providing alt text for meaningful images
avoiding inaccessible PDFs where HTML would be better
testing forms, menus, modals and payment journeys
checking third-party tools such as chat widgets, booking systems or embedded maps

Can a website be WCAG compliant?

A website can be tested against WCAG criteria, but claims need to be worded carefully.

It is better to say that a website has been designed and tested against WCAG 2.2 Level AA, or that specific templates and user journeys have been audited against WCAG 2.2 Level AA.

Avoid vague claims such as fully accessible or 100% WCAG compliant.

Accessibility is affected by scope, content, third-party tools, future updates and user needs. A responsible accessibility claim should state the standard, level, date, pages or journeys tested, and any known limitations.

Accessibility is an ongoing responsibility

A website can become less accessible over time if new content is added without care.

That is why accessibility should be part of ongoing website maintenance, not just launch.

A good accessibility process includes regular checks, content editor guidance, testing after major changes and a clear route for users to report accessibility problems.

uploading inaccessible PDFs
adding images without alt text
embedding third-party widgets
changing colours without checking contrast
adding new forms without proper labels
publishing videos without captions
changing navigation without keyboard testing

Final thoughts

WCAG 2.2 gives organisations a clear framework for making websites and digital services more accessible.

For most business websites, portals and service platforms, WCAG 2.2 Level AA is the right practical target.

It helps improve usability, reduce barriers, support more customers and create better digital experiences for everyone.

Accessibility is not just a technical checklist. It is part of good digital service design.

For organisations working with vulnerable customers, WCAG 2.2 should also be considered alongside wider inclusive service standards such as ISO 22458.

Sources and further reading

Author

Danni Kennerly

UX Designer and Developer · Danni works across user experience, design and development, helping websites feel clearer, smoother and easier for real people to use.