A practical WCAG 2.2 website audit beyond colour contrast

An accessibility audit can begin with colour and end with an automated score. That is convenient, but incomplete. A tool can identify some missing labels, contrast failures and structural errors. It cannot reliably decide whether focus order makes sense, whether an error helps somebody finish a form, or whether a screen-reader user understands a state change.

WCAG 2.2 is a standard containing testable success criteria, not a list of decorative improvements. For a business owner, the useful translation is into customer tasks: finding a service, comparing options, booking, buying, signing in and making contact. A credible audit therefore combines automation, manual review, a representative sample, and — where the risk warrants it — evaluation with people who use different assistive technologies.

Define scope before counting defects

“The website is WCAG compliant” is meaningful only with a scope, standard version, conformance level, date and evaluation method. A changing service cannot be represented by one scan of its homepage.

Record the following before testing:

• the WCAG version and target level, such as WCAG 2.2 AA;
• included domains, languages and environments;
• important page types, components and content formats;
• critical journeys such as contact, booking, payment and password recovery;
• browsers, devices and assistive technologies used;
• excluded areas and limitations of the sample.

A representative sample needs different templates, states and tasks. A validation error, open menu, modal and filtered result are as relevant as the initial page state.

Use four complementary audit layers

Each layer answers a different question. A strong automated score cannot replace the layers below it.

Automation is an effective regression filter. Run it regularly, but do not interpret a percentage as the share of user needs met. One inaccessible payment control can matter more than dozens of minor warnings on an informational page.

The website audit provides a useful automated first pass. Follow it with manual testing of the real customer journeys.

Keyboard and focus expose interaction structure

Put the mouse aside. Use Tab, Shift+Tab, Enter, Space, arrow keys and Escape. Confirm that every action is reachable, focus remains visible, order follows the intended task, and no component creates a trap.

WCAG 2.2 added success criterion 2.4.11 Focus Not Obscured (Minimum) at Level AA. An item receiving keyboard focus must not be entirely hidden by author-created content such as a sticky banner or consent panel. This is one reason to test a moving interface rather than a static screenshot.

Document a reproducible condition: URL, viewport, component state, input and expected result. “Menu inaccessible” is a weak development task. “After the menu opens, focus remains behind the overlay and Escape does not close it” supports a concrete repair and regression test.

Contrast needs context

At Level AA, WCAG 2.2 requires at least 4.5:1 for ordinary text and 3:1 for large text. Graphical objects needed to identify controls and states also have requirements, subject to the standard's exceptions.

Use the contrast checker for an individual colour pair and the accessible colour palette generator to develop a brand scale. A two-colour calculation does not cover gradients, text over photography, transparency, hover, focus and disabled states, or forced-colour modes.

Check that meaning does not depend on colour alone. A red border without an error message may be hard to perceive and gives no repair instruction. A chart should distinguish series through labels, patterns or shapes as well as hue.

Test zoom, reflow and target size

Zoom text to 200% and inspect a viewport equivalent to a narrow screen. Content should not disappear, overlap or require two-dimensional scrolling where the standard does not permit it. Headers, tables, sticky bars and forms inside modals commonly fail under these conditions.

WCAG 2.2 introduced the Level AA success criterion 2.5.8 Target Size (Minimum). In general, a pointer target should be at least 24 by 24 CSS pixels or meet an exception such as sufficient spacing. This is not a request to enlarge every icon mechanically. The active area, neighbouring targets and component context all matter.

Small delete icons, carousel dots and crowded footer links deserve testing on a touch device. A control that works with a precise mouse may still create expensive mistakes for a thumb or a person with limited dexterity.

Follow forms from empty state to success

A form is a process, not a collection of labelled inputs. Complete it with a keyboard and, where included in scope, a screen reader. Submit empty and invalid values, repair them, and confirm the success state.

Check whether:

• every field has a persistent, programmatically connected name;
• an instruction appears before the point where it is needed;
• the required format is not communicated only by a placeholder;
• an error identifies the field, problem and a possible correction;
• focus moves predictably to a summary or the first error after submission;
• success is announced without requiring a visual search;
• paste and password managers are not blocked without a defensible reason.

WCAG 2.2 adds criteria covering redundant entry and accessible authentication. In practice, inspect whether a journey asks people to recall or re-enter information the system can provide, and whether a cognitive-function test is the only authentication route without an accepted alternative.

Review content, semantics and dynamic states

Headings should express structure rather than merely produce larger type. “Learn more” might be understandable in one paragraph but loses meaning when several identical links are listed together. Alternative text depends on purpose: decoration may need an empty alt, a chart needs its information represented, and a product photograph needs a useful distinction.

Check the document language and passages in another language. Inspect dynamic communication: filtering results, adding an item, saving, and network failure. Visible text appearing on screen is not proof that an assistive technology announced it.

Plain language also affects completion. A technically associated label can still be unclear, and an accurate error code can still be useless to a customer. Review content within the task rather than as isolated strings.

Prioritise impact rather than occurrence count

Give every finding three dimensions:

1. task impact — does it block, seriously hinder or mildly inconvenience?
2. reach — is it one description or a shared component across hundreds of pages?
3. repair risk — is it a local content fix or a behavioural change used throughout the product?

Address barriers that block critical journeys and systemic defects in the design system first. Complete easy improvements promptly, but do not let a high count of small wins conceal an inaccessible checkout or enquiry form.

A useful issue includes evidence, the related criterion, location, reproduction steps, user impact, a proposed repair and a retest method. Retest after release: closing a ticket is not evidence that the barrier has gone.

W3C also recommends involving disabled and older users because usability problems can remain invisible to conformance checking alone. User evaluation and standards evaluation serve different purposes; include both when the service, audience and risk justify them.

If the work needs to connect an audit with component redesign and regression testing, review my design and development services. You can also describe the critical journey and service scope to begin with a representative sample rather than an automated promise of certification.

Sources

• W3C WAI: What's New in WCAG 2.2
• W3C: Web Content Accessibility Guidelines 2.2
• W3C WAI: Easy Checks — A First Review of Web Accessibility
• W3C WAI: Involving Users in Evaluating Web Accessibility
• W3C WAI: Template for Accessibility Evaluation Reports