What Does a WCAG 2.2 Accessibility Audit Actually Include?

What is WCAG 2.2?

WCAG stands for Web Content Accessibility Guidelines.

The guidelines are developed through the W3C's Web Accessibility Initiative and provide an internationally recognised framework for improving the accessibility of web content.

WCAG 2.2 is organised around four principles.

Web content should be:

Perceivable

Users need to be able to perceive the information.

For example, important images may need text alternatives, video content may need captions, and text needs sufficient contrast.

Operable

Users need to be able to operate the interface.

For example, someone who cannot use a mouse should still be able to navigate menus, activate buttons and complete forms using a keyboard.

Understandable

Content and interactions should behave predictably and provide enough information for users to understand what is happening.

Robust

The website should be implemented in a way that can work reliably with different browsers and assistive technologies.

WCAG contains testable success criteria at three levels:

Level A

Level AA

Level AAA

Level AA is the level most organisations normally encounter when accessibility standards are specified.

For UK public-sector websites and mobile applications, GOV.UK currently identifies WCAG 2.2 Level AA as the technical accessibility standard used under the Public Sector Bodies accessibility regulations. (gov.uk)

Private-sector businesses need to consider a different legal context.

The Equality Act 2010 applies to service providers and includes duties relating to disabled people and reasonable adjustments. Government guidance states that service providers must think ahead and take reasonable steps to address barriers that impede disabled people. (gov.uk)

That does not mean every UK private-sector website is automatically subject to exactly the same WCAG 2.2 AA statutory regime as a public-sector website.

However, WCAG provides a highly useful technical benchmark for identifying and fixing digital accessibility barriers.

For businesses operating internationally, additional accessibility requirements may also apply depending on the markets and services involved.

Why run an accessibility audit?

There are several reasons.

The first is straightforward:

More people should be able to use your website.

Accessibility improvements can make it easier for customers to:

• find information;
• compare services;
• fill in forms;
• make purchases;
• book appointments;
• contact your company;
• manage accounts.

Many accessibility improvements also benefit people who do not identify as disabled.

Clear form labels help everyone.

Readable contrast helps somebody using a phone outdoors.

Large touch targets help somebody using a mobile device one-handed.

Captions help someone watching video in a noisy environment.

Clear error messages help almost every user.

There are also commercial and operational reasons.

A business may be spending money sending traffic from SEO or Google Ads to a page that some visitors cannot successfully use.

If the CTA is not keyboard accessible or the form cannot be understood by a screen reader, improving campaign targeting will not solve that problem.

Accessibility is therefore not just a compliance exercise.

It is part of website quality.

An automated accessibility score is not an accessibility audit

This distinction is important.

Tools such as browser auditing software can detect many useful issues.

They may identify:

• missing image alternatives;
• certain colour-contrast failures;
• form inputs without labels;
• duplicate IDs;
• invalid ARIA relationships;
• some semantic problems.

These tools are extremely valuable.

But W3C explains that accessibility evaluation tools cannot check every accessibility requirement automatically and may sometimes produce false or misleading results. (w3.org)

Consider a button labelled:

“Click here”

An automated tool might confirm that the button has an accessible name.

A human reviewer may recognise that the name provides almost no useful information about what will happen.

Or consider an image with:

alt="picture"

Technically, an alt attribute exists.

That does not mean the alternative text is useful.

A proper audit combines tools with human judgement.

1. Define the scope of the audit

Before testing anything, decide what needs to be audited.

A website with 3,000 pages does not necessarily require a human tester to inspect every page individually.

Instead, auditors normally identify representative page types and important user journeys.

For a service business, the sample might include:

• homepage;
• service page;
• contact page;
• blog article;
• lead-generation landing page;
• search page;
• privacy or policy page.

For an ecommerce business:

• homepage;
• category;
• product;
• search;
• basket;
• checkout;
• customer account;
• returns process.

For a membership platform:

• login;
• registration;
• dashboard;
• profile;
• subscription management;
• core application workflows.

The audit should particularly prioritise high-value customer journeys.

If customers cannot complete checkout, that should take priority over a minor problem in an old blog archive.

2. Test keyboard navigation

Keyboard testing is one of the most valuable parts of an accessibility audit.

Some people cannot use a mouse.

They may navigate using:

• keyboard;
• switch device;
• voice control;
• specialised input hardware.

Try using the website without touching the mouse.

Use keys such as:

Tab

Shift + Tab

Enter

Space

Escape

Arrow keys

depending on the component.

You should be able to reach and operate interactive functionality.

W3C's WCAG includes requirements around keyboard accessibility and avoiding keyboard traps. (w3.org)

The audit should test:

• navigation;
• buttons;
• links;
• dropdowns;
• forms;
• accordions;
• tabs;
• modal windows;
• filters;
• cookie controls;
• video players;
• carousels;
• chat widgets.

3. Check visible keyboard focus

Being able to tab through the interface is not enough.

The user also needs to know where they are.

When you press Tab, the focused element should have a clear visual indicator.

For example, a button might show a visible outline.

WCAG requires visible keyboard focus, and WCAG 2.2 introduced additional criteria around focus behaviour and appearance. W3C explains that visible focus is particularly important because keyboard users need to identify which control will be activated next. (w3.org)

An audit should look for:

• invisible focus;
• extremely low-contrast focus;
• focus hidden behind sticky headers;
• focus hidden by cookie banners;
• logical focus order;
• focus jumping unexpectedly.

A common design mistake is:

outline: none;

without providing an accessible alternative focus style.

That can make a visually polished interface significantly harder to use.

4. Check for keyboard traps

A keyboard trap occurs when a user can enter an interface component using the keyboard but cannot leave it normally.

This can happen in:

• modal windows;
• video players;
• widgets;
• embedded tools;
• navigation menus.

For example, pressing Tab might repeatedly cycle through controls inside a widget with no way to return to the page.

The audit should deliberately test entry and exit behaviour.

5. Test navigation menus

Modern navigation menus can become accessibility problems because they often rely on complex JavaScript.

Test whether menus can be:

• reached by keyboard;
• opened;
• navigated;
• closed;
• understood by assistive technology.

Check mobile navigation separately.

A hamburger menu that works perfectly with touch may not work correctly using keyboard controls or screen-reader navigation.

6. Review headings

Headings do more than make text visually larger.

They provide structure.

Screen-reader users can navigate through headings to understand a page quickly, much as a sighted visitor visually scans section titles.

W3C notes that headings help people understand and navigate content and are particularly useful for screen-reader users as well as people with cognitive or reading disabilities. (w3.org)

An audit should look for:

• missing page headings;
• headings used only for visual styling;
• illogical hierarchy;
• empty headings;
• headings that do not describe the following section.

Avoid treating accessibility as a simplistic rule such as:

“Every page may have only one H1.”

The more important objective is meaningful semantic structure.

7. Review page titles

Each page should have a useful page title.

Someone using assistive technology may rely on it to understand which page is currently open.

Titles also matter for browser tabs and search results.

An audit may identify pages using titles such as:

Home

Page 1

Services

where a more descriptive title would provide useful context.

8. Test image alternative text

Images need different treatment depending on their purpose.

An image may be:

• informative;
• decorative;
• functional;
• a chart;
• a linked image.

An audit should not simply count how many images contain alt attributes.

It should assess whether the text alternative communicates the purpose of the image.

W3C describes alternative text as a way of conveying the purpose of images for people who cannot see them. (w3.org)

For example:

Poor:

alt="image123.jpg"

Poor:

alt="business people"

Potentially better:

alt="Marketing team reviewing website analytics dashboard"

if that information is relevant to the surrounding content.

Decorative images may appropriately use empty alternative text so they do not create unnecessary screen-reader noise.

Context matters.

9. Review icons

Icons are frequently overlooked.

A button may display only:

🔍

A sighted user understands that it means search.

A screen reader needs a meaningful accessible name.

The same issue can occur with:

• menu icons;
• account icons;
• social links;
• close buttons;
• download icons;
• carousel controls.

The audit should check what assistive technology actually receives.

10. Test colour contrast

Text needs sufficient contrast against its background.

WCAG 2.2 includes minimum contrast requirements, including a general 4.5:1 ratio for normal text, with specific exceptions and different requirements for large text. (w3.org)

Common problems include:

• light grey text on white;
• text over photographs;
• pale brand colours;
• low-contrast placeholder text;
• disabled-looking active buttons;
• weak footer text.

Do not assume a colour combination is acceptable because it looks readable on a designer's monitor.

Test it.

11. Do not communicate information through colour alone

Imagine a form showing:

Green border = valid

Red border = error

A user who cannot distinguish the colours may miss the meaning.

Provide another indicator.

For example:

Email address is invalid

with an icon or clear text.

The same principle applies to:

• charts;
• status dashboards;
• pricing comparisons;
• calendars;
• required fields.

Colour can reinforce information.

It should not be the only way the information is communicated.

12. Test zoom and text resizing

Many people enlarge websites.

Test what happens when users:

• zoom the browser;
• increase text size;
• use a narrow viewport.

Check whether:

• content overlaps;
• buttons disappear;
• navigation becomes unusable;
• horizontal scrolling appears unnecessarily;
• text becomes clipped;
• forms break.

Responsive design is closely related to accessibility.

A site can be technically “mobile responsive” while still failing badly when somebody enlarges text.

13. Test forms carefully

Forms are one of the most commercially important areas of an accessibility audit.

W3C specifically identifies labels, instructions and error handling as important aspects of accessible forms. (w3.org)

Check:

• contact forms;
• quote forms;
• checkout;
• newsletter signup;
• account registration;
• booking forms;
• login;
• application forms.

14. Every form control needs a meaningful label

A placeholder is not necessarily a replacement for a label.

Consider:

[ Email address ]

Once the user starts typing, the placeholder disappears.

Someone with cognitive difficulties may forget what information the field requires.

Screen-reader behaviour may also depend on the implementation.

W3C's form guidance recommends properly associated labels and warns against relying on disappearing placeholder text for essential instructions. (w3.org)

A better pattern normally includes a persistent label:

Email address

[________________]

15. Test required fields

Users should be told clearly which information is required.

Do not rely exclusively on:

• colour;
• visual position;
• unexplained symbols.

If an asterisk is used, explain it.

For example:

* Required field

W3C's accessibility checks specifically include clear marking of required fields. (w3.org)

16. Test form errors

Submit the form incorrectly.

What happens?

A useful error should explain:

• what is wrong;
• where the problem is;
• how to fix it.

Poor:

There were errors.

Better:

Enter an email address in the format [email protected].

Also check whether keyboard and screen-reader users are informed that an error occurred.

An error displayed visually at the top of the page is not useful if focus remains at the bottom and assistive technology is unaware of it.

17. Test autocomplete and input purpose

For common personal information, correct HTML autocomplete values can help browsers and assistive technology identify expected information.

This may apply to fields such as:

• name;
• email;
• telephone;
• address.

Good implementation can make forms significantly easier to complete.

18. Audit buttons and links

Links and buttons have different purposes.

A link normally navigates somewhere.

A button normally performs an action.

JavaScript implementations sometimes use a generic <div> or <span> styled to look clickable.

That can create accessibility problems because the element may not behave properly with keyboard navigation or assistive technology.

Prefer native semantic elements where possible.

Check link text too.

A page containing six links all saying:

Read more

may provide poor context when a screen reader presents them as a list.

More descriptive labels can help.

19. Check touch-target size

WCAG 2.2 added a Level AA success criterion covering minimum target size in many circumstances.

W3C explains that small interactive targets placed close together can be particularly difficult for users with limited dexterity or fine-motor control. (w3.org)

This frequently affects mobile interfaces.

Look at:

• close buttons;
• pagination;
• menu icons;
• carousel controls;
• filters;
• checkboxes;
• small text links.

A tiny × in the corner of a popup may be easy for a designer using a mouse but frustrating for somebody with limited hand control on a mobile screen.

20. Test dragging interactions

WCAG 2.2 also introduced criteria addressing dragging movements.

If functionality requires dragging, users should generally have an alternative way to perform that function with a single-pointer action where the criterion applies.

W3C gives examples such as providing buttons or controls that allow movement without requiring a drag gesture. (w3.org)

This can affect:

• sliders;
• drag-and-drop interfaces;
• sortable lists;
• maps;
• product customisers.

21. Test accessible authentication

Login systems can create accessibility barriers.

Examples include requiring users to:

• remember complex passwords without assistance;
• solve cognitive puzzles;
• transcribe difficult verification codes.

WCAG 2.2 introduced requirements around accessible authentication.

An audit should review login, MFA and account-recovery flows rather than testing only public pages.

Passkeys and password managers can also change the design of accessible authentication experiences.

22. Test screen-reader behaviour

A meaningful audit should include assistive-technology testing on representative workflows.

Screen readers may include products such as:

• NVDA;
• JAWS;
• VoiceOver;
• TalkBack.

The exact testing matrix depends on the website, users and project scope.

The purpose is not merely to hear the page read aloud.

The tester should assess whether the interface makes sense.

Can the user:

• understand page structure;
• identify navigation;
• find headings;
• understand links;
• operate forms;
• receive validation errors;
• use menus;
• recognise dialogs;
• understand dynamic updates?

23. Check semantic HTML before adding ARIA

ARIA stands for Accessible Rich Internet Applications.

ARIA can provide accessibility information for custom components.

It is useful.

It is also frequently misused.

Developers sometimes create custom controls using generic HTML and then add large amounts of ARIA to reproduce behaviour that native HTML already provides.

Where possible:

Use the correct HTML element first.

A real <button> already provides useful behaviour.

A clickable <div> requires considerably more work to behave like one.

Accessibility audits should therefore identify both missing semantics and unnecessary or incorrect ARIA.

24. Test modal windows

Modals are common sources of accessibility problems.

When a modal opens:

• focus should move appropriately;
• background content should not remain confusingly interactive;
• keyboard focus should remain logically within the dialog;
• the user should be able to close it;
• focus should return appropriately afterwards.

Cookie settings, booking dialogs and promotional popups deserve particular attention because they frequently appear before users can interact with the main page.

25. Audit cookie banners

Cookie banners can themselves become accessibility barriers.

Test whether the consent interface can be used through:

• keyboard;
• screen reader;
• zoom;
• mobile.

Check:

• focus visibility;
• button labels;
• modal behaviour;
• preference controls;
• text contrast;
• ability to reopen settings.

A website should not make privacy controls difficult to access for disabled visitors.

26. Test carousels and sliders

Carousels can create multiple problems.

Check:

• keyboard control;
• accessible labels;
• pause functionality where appropriate;
• focus;
• automatic movement;
• screen-reader announcements.

Avoid assuming that the carousel library is accessible simply because it is popular.

27. Check automatically moving content

Movement can make websites harder for some users to read or operate.

This includes:

• carousels;
• animations;
• tickers;
• autoplay video;
• automatically updating content.

Depending on the implementation and duration, users may need methods to pause or control movement.

Animation can be part of good design.

It should not make the interface unusable.

28. Check reduced-motion preferences

Some users configure their device to request reduced motion.

Modern CSS supports:

prefers-reduced-motion

Websites with significant animation should consider whether motion can be reduced appropriately for these users.

This is especially relevant for:

• parallax effects;
• large transitions;
• animated scrolling;
• zoom effects;
• moving backgrounds.

29. Audit video content

Video accessibility may require:

• captions;
• transcripts;
• audio description depending on the content;
• accessible player controls.

Automatically generated captions can be a useful starting point but should be reviewed.

An inaccurate caption can materially change meaning.

30. Check audio

Audio that begins unexpectedly can be disruptive, particularly for screen-reader users whose software is also producing audio.

Users should have meaningful control over audio playback.

31. Audit PDFs and downloadable documents

Accessibility does not stop at HTML pages.

If an important journey sends users to a PDF, that document may also need accessibility consideration.

Check documents for:

• selectable text;
• reading order;
• headings;
• tagged structure;
• table structure;
• image alternatives;
• form fields.

A perfectly accessible landing page leading to an inaccessible application PDF has not solved the user's problem.

32. Test tables

Tables should be used for genuine tabular data rather than page layout.

For data tables, check whether:

• header cells are identified;
• row and column relationships are understandable;
• captions or descriptions are useful;
• complex tables make sense with assistive technology.

Very wide tables also need careful mobile treatment.

33. Check language

The page's primary language should be identified programmatically.

This helps screen readers pronounce content correctly.

If part of a page changes language, that may also need appropriate markup.

This matters more than people sometimes realise.

A screen reader using English pronunciation rules for a French sentence may produce extremely poor output.

34. Review instructions that rely on visual position

Instructions such as:

“Click the green button on the right.”

can create problems.

What if:

• the user cannot perceive colour;
• the responsive layout moves the button below;
• a screen reader user cannot interpret “right” meaningfully?

Better instructions identify the control itself:

Select “Request a Quote”.

35. Check content readability

WCAG accessibility is not synonymous with plain English, but understandable content is part of accessible digital design.

Business websites should review:

• unnecessarily complex sentences;
• unexplained acronyms;
• ambiguous instructions;
• inconsistent terminology;
• dense blocks of text.

This can particularly help people with cognitive, learning or language-related difficulties.

It can also improve conversion for everybody else.

36. Test search

If site search is an important feature, test:

• form label;
• keyboard access;
• results headings;
• result links;
• empty results;
• filters.

A customer who relies on search because navigation is difficult should not encounter another inaccessible interface.

37. Audit product filters

Ecommerce filters can be complex.

Check:

• checkboxes;
• sliders;
• dropdowns;
• dynamic results;
• result counts;
• focus changes;
• mobile filter dialogs.

If selecting a filter refreshes the product list, assistive technologies may need enough information to understand that content has changed.

38. Audit checkout

Checkout should receive special attention because accessibility barriers here have direct commercial consequences.

Test:

• address fields;
• delivery selection;
• payment options;
• coupon codes;
• validation;
• order review;
• confirmation.

Third-party payment interfaces can also affect accessibility.

The fact that a component comes from an external supplier does not make the customer experience irrelevant.

39. Check third-party widgets

Businesses increasingly embed:

• booking calendars;
• live chat;
• maps;
• review widgets;
• payment systems;
• social feeds.

A third-party component can introduce barriers even when the rest of the website is accessible.

Audit the actual customer journey, not only the code your own developers control.

If an inaccessible third-party tool is business-critical, you may need to discuss alternatives with the provider or offer another way to complete the task.

40. Accessibility overlays are not a substitute for fixing the site

Some services offer a small accessibility widget that promises to modify the website automatically.

Businesses should be cautious about treating this as equivalent to accessibility remediation.

Accessibility needs to exist in:

• HTML;
• components;
• content;
• design;
• keyboard behaviour;
• forms;
• workflows.

A widget cannot reliably correct every structural or interaction problem.

W3C's central point remains relevant: automated technology alone cannot determine or guarantee accessibility. (w3.org)

Fix the underlying website.

What changed in WCAG 2.2?

WCAG 2.2 became a W3C Recommendation in October 2023 and added several success criteria compared with WCAG 2.1. (w3.org)

Some of the newer areas include:

• focus not being obscured;
• stronger focus appearance considerations;
• dragging alternatives;
• minimum target size;
• consistent help;
• reducing repeated entry;
• accessible authentication.

These additions reflect real-world barriers in modern websites and applications.

For businesses auditing an older website last checked against WCAG 2.1, the newer criteria should be reviewed.

Accessibility testing should include people, not only criteria

Standards are essential because they provide objective requirements.

But conformance testing and usability testing are not identical.

A technically conforming interface can still be confusing.

W3C encourages organisations to involve users with disabilities in evaluation because their experience can identify issues that formal testing alone may not reveal. (w3.org)

For large or important digital services, testing with disabled users can therefore add significant value.

How should accessibility issues be prioritised?

A useful audit should not simply list failures in numerical order.

Prioritise by severity and business impact.

A possible structure is:

Critical

The user cannot complete an essential task.

Examples:

• checkout inaccessible by keyboard;
• login impossible with assistive technology;
• booking form unusable;
• keyboard trapped inside modal.

High

A major barrier affects important content or workflows.

Examples:

• form labels missing;
• navigation difficult with screen reader;
• critical controls have no accessible name;
• severe contrast failure.

Medium

The issue creates meaningful difficulty but does not completely prevent the task.

Examples:

• inconsistent headings;
• unclear links;
• moderate focus problems.

Low

Smaller issues and best-practice improvements.

Prioritisation helps development teams focus on actual barriers rather than chasing the easiest warnings first.

The report should explain how to fix each problem

Poor audit report:

WCAG 1.3.1 failure.

Useful audit report:

The newsletter email field has no programmatically associated label. Screen-reader users hear only “edit text” and may not know what information is required. Add a visible <label> associated with the field's ID.

The report should ideally include:

• affected URL;
• affected component;
• WCAG criterion;
• severity;
• explanation;
• reproduction steps;
• recommended fix;
• screenshots or code examples where useful.

Developers need enough information to reproduce the problem.

Reusable components should be fixed first

If the same inaccessible button exists on 500 pages, you do not need 500 independent fixes.

Fix the component.

Common global components include:

• navigation;
• footer;
• forms;
• CTA buttons;
• cards;
• accordions;
• modals;
• cookie banner.

Component-level remediation can solve many problems efficiently.

This is one reason accessibility should be part of a design system.

Accessibility should become part of development QA

Running an accessibility audit every three years and then forgetting about accessibility is inefficient.

New problems will appear as soon as:

• a new template launches;
• a developer adds a component;
• marketing installs a widget;
• content editors publish inaccessible material.

A better process incorporates accessibility into regular development.

For example:

Design

Check contrast, focus, target size and interaction behaviour.

Development

Use semantic HTML and accessible components.

Automated testing

Catch common problems during deployment.

Manual QA

Use keyboard and assistive-technology checks.

Content

Review headings, alt text and links.

Periodic audit

Perform deeper evaluation.

Accessibility becomes maintenance rather than an emergency project.

What should business owners ask an accessibility auditor?

Before commissioning an audit, ask:

1. Which WCAG version and conformance level are you testing?
2. How do you select the pages being audited?
3. Do you test complete user journeys?
4. Is testing automated, manual or both?
5. Do you perform keyboard testing?
6. Do you use screen readers?
7. Which browser and assistive-technology combinations do you test?
8. Do you test mobile interfaces?
9. Do you test forms and error handling?
10. Do you test third-party components?
11. Do you provide severity ratings?
12. Does the report explain how developers should fix each issue?
13. Is retesting included after fixes?
14. Can you help developers understand unclear findings?
15. Do you distinguish WCAG failures from best-practice recommendations?

Be wary of promises such as:

“We scan your site and certify it accessible in five minutes.”

Accessibility is more complex than that.

How much of the website should be audited?

For a very small website, reviewing every major page may be realistic.

For larger websites, use representative sampling.

The sample should include:

• different templates;
• different components;
• important traffic pages;
• major conversion journeys;
• unusual functionality.

For example, testing ten blog articles built from the same template may add little after the template's behaviour is understood.

Testing one article, one product page, the checkout and the customer account may reveal much more.

Should accessibility be audited before or after a redesign?

Ideally, both accessibility review and accessible design should happen before development is complete.

W3C recommends evaluating accessibility early and throughout design and development because problems are generally easier to address earlier. (w3.org)

Imagine discovering after launch that:

• the brand's main colour combination fails contrast;
• the custom menu cannot be operated by keyboard;
• the entire form component needs rebuilding.

These changes are more expensive after hundreds of pages have been created.

Accessibility should be included in:

• design;
• component development;
• content;
• QA.

What WCAG conformance actually means

A website does not become “90% WCAG compliant” in a formal conformance sense because an automated tool returned a score of 90.

W3C explains that conformance is based on satisfying applicable success criteria at a defined level. (w3.org)

This is why statements such as:

“Our website is 97% accessible”

need context.

What was tested?

Against which standard?

Using which method?

Which pages?

Which assistive technologies?

What remains unresolved?

A useful accessibility report should make its methodology clear.

Is WCAG 2.2 AA legally required for every UK business?

Not in the same direct way that it is specified for UK public-sector websites and apps under the public-sector accessibility regime.

Public-sector organisations are subject to specific accessibility regulations and GOV.UK identifies WCAG 2.2 AA as the current technical standard. (gov.uk)

Private-sector service providers need to consider duties under the Equality Act 2010, including reasonable adjustments for disabled people. The 2026 Equality Act Code of Practice also discusses duties applying to service providers and the need to avoid disadvantage for disabled people. (gov.uk)

WCAG is therefore a highly useful technical framework for private organisations, but businesses should avoid oversimplified claims that one standard automatically describes every legal obligation in every circumstance.

Where legal interpretation matters, obtain appropriate specialist advice.

Accessibility has a commercial benefit even without a compliance deadline

There is another reason businesses should care.

You have already paid to attract the visitor.

Imagine spending money on:

• Google Ads;
• SEO;
• social advertising;
• email;
• content.

A potential customer arrives.

They want your service.

But they cannot:

• open the menu;
• read the text;
• use the form;
• select a date;
• complete checkout.

That is not only an accessibility problem.

It is a conversion problem.

Improving accessibility can therefore support the same objective as CRO:

Remove unnecessary barriers between the customer and the action they want to complete.

Accessibility and SEO overlap—but are not the same thing

Some accessible practices can also support SEO.

Examples include:

• semantic headings;
• meaningful page titles;
• useful link text;
• image alternatives;
• logical site structure.

But accessibility should not be treated as an SEO trick.

A website can rank well while being inaccessible.

A website can also be accessible without ranking well.

The objectives overlap in some implementation areas but remain distinct.

Build accessible websites because users need them.

Accessibility and AI-generated websites

As AI website builders and coding assistants become more common, accessibility review becomes more important rather than less.

AI can generate:

• HTML;
• React components;
• CSS;
• forms;
• navigation;
• dashboards.

It can also generate inaccessible code.

A component may look correct while using:

• inappropriate ARIA;
• invalid semantics;
• poor keyboard behaviour;
• low contrast;
• inaccessible custom controls.

AI can assist development.

It should not eliminate QA.

The same principle applies to AI-generated content.

Automatically generated image descriptions, headings or form copy should be reviewed where accuracy matters.

A practical accessibility audit checklist

A comprehensive audit should normally consider areas such as:

Structure

• Page titles
• Heading hierarchy
• Landmarks
• Semantic HTML
• Page language

Keyboard

• Keyboard navigation
• Visible focus
• Logical focus order
• Keyboard traps
• Modal behaviour

Navigation

• Menus
• Breadcrumbs
• Search
• Skip links
• Consistent navigation

Forms

• Labels
• Instructions
• Required fields
• Errors
• Autocomplete
• Keyboard behaviour

Visual presentation

• Text contrast
• Non-text contrast
• Zoom
• Reflow
• Text resizing
• Colour dependence

Images and media

• Alternative text
• Captions
• Transcripts
• Audio controls
• Decorative images

Interactive components

• Buttons
• Links
• Tabs
• Accordions
• Carousels
• Dialogs
• Tooltips
• Filters

WCAG 2.2 interaction areas

• Focus not obscured
• Focus appearance
• Dragging alternatives
• Target size
• Consistent help
• Repeated entry
• Accessible authentication

Assistive technology

• Screen-reader navigation
• Form interaction
• Dynamic updates
• Accessible names
• Status messages

Documents

• PDFs
• downloadable forms
• spreadsheets where relevant

Third parties

• Cookie CMP
• booking platform
• payment provider
• live chat
• maps
• embedded tools

Mobile

• touch targets
• orientation
• responsive reflow
• screen reader
• zoom

Passing an automated scan covers only part of this list.

What happens after the audit?

The audit is not the final objective.

Remediation is.

A useful sequence is:

1. Fix critical blockers.

Prioritise essential tasks customers cannot complete.

2. Fix reusable components.

Navigation, forms and shared design components often remove multiple issues at once.

3. Resolve high-impact page issues.

Prioritise core service, ecommerce and lead-generation pages.

4. Retest.

A code change can fix one accessibility issue while introducing another.

5. Document remaining exceptions.

Understand what is still unresolved and why.

6. Improve the development process.

Prevent the same problems returning.

Without these steps, an audit can become an expensive PDF nobody uses.

Accessibility is ongoing website maintenance

Websites change continuously.

Marketing publishes new pages.

Developers release features.

Plugins update.

Third-party widgets change.

New PDFs are uploaded.

An accessible website can become less accessible over time.

This means accessibility should eventually become part of:

• website maintenance;
• design systems;
• development standards;
• content guidelines;
• release QA.

The goal is not to perform one heroic remediation project every few years.

It is to make inaccessible features less likely to enter production in the first place.

What a good WCAG 2.2 audit should ultimately tell you

A business owner should be able to read the final report and understand:

Which users are affected?

What prevents them completing a task?

Which WCAG requirement is relevant?

How serious is the problem?

How should the development team fix it?

Which issues should be fixed first?

That is far more useful than:

Accessibility score: 82/100.

Accessibility is not really about the score.

It is about whether people can use the website.

A technically sophisticated interface that excludes customers from submitting an enquiry is not successful.

A visually impressive checkout that cannot be completed without a mouse is not successful.

A perfect Lighthouse score does not prove that a screen-reader user can book an appointment.

That is why a proper accessibility audit combines standards, automated testing, manual evaluation and real user journeys.

London Digital Works provides website accessibility, security, privacy, website maintenance and development support for businesses that want to identify and remove barriers from their digital services.

For organisations unsure where to begin, a WCAG 2.2 accessibility audit can provide a practical roadmap: identify the highest-impact barriers, fix shared components first, retest important journeys and build accessibility into ongoing website maintenance rather than treating it as a one-off exercise.

Sources

W3C Web Accessibility Initiative — Web Content Accessibility Guidelines 2.2 The official WCAG 2.2 technical standard covering accessibility requirements for web content. (w3.org)

W3C Web Accessibility Initiative — Evaluating Web Accessibility W3C guidance explaining why accessibility evaluation should combine tools with knowledgeable human assessment and why no automated tool can determine accessibility on its own. (w3.org)

W3C Web Accessibility Initiative — What's New in WCAG 2.2 Official explanation of new WCAG 2.2 criteria, including changes relating to focus, target size, dragging, authentication and consistent help. (w3.org)

W3C Web Accessibility Initiative — Easy Checks W3C guidance covering practical accessibility checks including headings, image alternatives, colour contrast, keyboard access, focus and forms. (w3.org)

W3C Web Accessibility Initiative — Form Accessibility Guidance covering labels, instructions, validation and accessible form implementation. (w3.org)

W3C Web Accessibility Initiative — Target Size WCAG 2.2 guidance explaining why small pointer targets can create barriers for people with limited dexterity or fine-motor control. (w3.org)

W3C Web Accessibility Initiative — Dragging Movements WCAG 2.2 guidance covering accessible alternatives to interactions that require dragging. (w3.org)

W3C Web Accessibility Initiative — Understanding Conformance Official guidance explaining WCAG conformance levels and how success criteria are used when determining conformance. (w3.org)

GOV.UK — Public Sector Website and Mobile Application Accessibility Monitoring Current UK government guidance identifying WCAG 2.2 Level AA as the technical standard used for public-sector website and mobile-app accessibility monitoring. (gov.uk)

GOV.UK — Accessibility Requirements for Public Sector Websites and Apps Government guidance covering accessibility obligations for UK public-sector websites and applications. (gov.uk)

GOV.UK — Equality Act Guidance for Service Providers Government guidance explaining the duty on service providers to anticipate barriers affecting disabled people and consider reasonable adjustments. (gov.uk)

GOV.UK — Equality Act 2010 Code of Practice for Services, Public Functions and Associations, 2026 Current guidance on Equality Act duties affecting service providers and reasonable adjustments for disabled people. (gov.uk)