Website Accessibility Audit: A Practical WCAG 2.2 Guide

What should a website accessibility audit cover?

Start with one task that matters: requesting a demo, buying a product or creating an account. Can someone complete it without a mouse, distinguish the controls and understand how to correct a mistake?

A website accessibility audit checks whether people with disabilities can use your content and functionality. This founder-friendly version focuses on five common sources of friction: contrast, keyboard access, image alternatives, forms and visible focus.

Use the World Wide Web Consortium’s Web Content Accessibility Guidelines, WCAG 2.2, as your reference. Level AA is a common target; meeting it requires satisfying both Level A and Level AA criteria. The checks below cover useful starting points, not every requirement.

A quick audit finds barriers. It does not certify compliance. Automated tools miss issues that require human judgment, and legal obligations depend on your circumstances and jurisdiction.

Which pages and tools should you start with?

Test a complete journey rather than only your homepage. Include the page where visitors arrive, the page where they decide and the form where they act. Add shared components such as navigation, cookie banners and dialogs.

Choose examples with different layouts and interactions. For a small SaaS site, that might mean the homepage, pricing page, signup flow and account dashboard. For a shop, include a product page, cart and checkout.

Run automated checks on interactive states too, including open menus and validation errors. Scanning the initial page alone misses content that appears later.

Keep broader usability observations separate from accessibility findings. The UX audit template can help organize both without treating every confusing design choice as a WCAG failure.

How do you check text and control contrast?

Measure actual foreground and background colors with a contrast checker. Start with body text, navigation, button labels, form instructions and error messages. Pale gray text on white is a useful place to look, but appearance alone cannot establish a pass or failure.

W3C’s WCAG 2.2 sets these thresholds:

Those thresholds come from WCAG, not a design preference. Large text is defined in points, so do not assume ordinary paragraph text qualifies because it looks generous on your screen.

Check text over photographs and gradients against the background immediately behind it. A combination that works in one position may fail when the image crops on mobile. A solid text background or consistent overlay is often easier to maintain.

Inspect hover, focus and error states as well as the default view. Disabled controls have contrast exceptions, but an intentionally low-contrast active control does not become exempt because it looks disabled.

Finally, check whether color carries meaning alone. An error needs wording or another visible cue, not just a red border. A chart needs labels, patterns or another way to distinguish its data.

Can someone complete your main task with only a keyboard?

Put the mouse aside. Start at the top of the page and use Tab to move forward and Shift+Tab to move backward. Use Enter to activate links and buttons; native buttons also support Space.

Follow the real journey. Open navigation, choose a plan, complete the form and submit it. Record any point where you cannot continue.

Look for these failures:

• An interactive element never receives keyboard focus.
• Focus moves through the page in an order that makes the task confusing.
• A menu or dialog opens but cannot be operated or dismissed with the keyboard.
• A sticky banner covers the control you are trying to use.

Not every interface uses Tab for every item. Radio groups, tabs and other composite widgets can use arrow keys internally. Compare custom behavior with established W3C WAI-ARIA Authoring Practices rather than assuming every arrow-key interaction is broken.

A modal dialog should move focus inside when opened, keep background content out of its active keyboard sequence and provide a keyboard-accessible way to close it. On closing, focus should return to the trigger or another logical place. Escape is the expected dismissal pattern for many dialogs.

Prefer native links, buttons and form controls. Making a generic container respond to a mouse click does not automatically give it keyboard behavior, a useful role or an accessible name.

Are focus states visible and unobscured?

Keyboard access is not enough if users cannot see where they are. The focus indicator is the outline, underline or other visual treatment showing which element will receive their next action.

Tab through the page while watching the indicator. If it disappears on a dark section, blends into a button or gets clipped by a container, record the exact component and state.

W3C’s WCAG 2.2 Focus Visible, Level AA, requires a visible keyboard focus indicator. Focus Not Obscured (Minimum), also Level AA, requires that an element receiving keyboard focus is not entirely hidden by author-created content.

That second requirement matters for sticky headers, cookie notices and floating chat panels. As a practical design goal, keep the whole focused control visible, even though the minimum criterion addresses complete obstruction.

Do not remove the browser outline without providing a reliable replacement. Use a distinct indicator that survives light and dark backgrounds, and check its contrast under the applicable Non-text Contrast requirements. WCAG’s separate Focus Appearance criterion is Level AAA; do not present all of its specifications as AA requirements.

While inspecting controls, check target size. W3C’s WCAG 2.2 Target Size (Minimum), Level AA, generally calls for targets at least 24 by 24 CSS pixels, with exceptions including spacing and inline links. Tiny adjacent icon buttons deserve particular attention.

Does each image have the right text alternative?

The question is not simply whether an image has an alt attribute. It is whether someone who cannot see the image gets the information or function they need.

Inspect images in their page context. The same image may need different treatment depending on why it appears.

For a bag product page, “Black backpack with side bottle pocket” is more useful than “product-photo-final.” Do not pack keywords into the description.

An empty alt attribute is not the same as a missing one. Missing alternatives can leave screen reader users hearing filenames or other unhelpful output. Decorative images should be intentionally marked as decorative.

Check icons and background images too. A search icon button still needs an accessible name such as “Search.” If a CSS background image contains essential information, provide that information in accessible page content.

Can people understand, complete and correct your forms?

Submit the form empty, then submit it with a deliberate mistake. This reveals whether the interface explains what it needs or merely refuses to continue.

Every field needs an accessible name. In most ordinary forms, use a persistent visible label correctly associated with its control. Placeholder text is not a substitute: it disappears during entry and can make reviewing answers harder.

Put format instructions before users need them. If a date requires a particular format, show that format alongside the field. Identify required fields in text or explain any symbol you use.

Errors should name the problem and suggest a correction when possible. “Enter an email address in the format name@example.com” helps more than “Invalid input.” Keep valid entries intact so people do not have to reconstruct the form.

Check that assistive technology can discover the errors. Associate field-level messages with their controls. For longer forms, a linked error summary can help people move directly to the fields requiring attention. Dynamic feedback may need an appropriate announcement mechanism; changing text visually does not guarantee a screen reader will announce it.

Also test password managers and paste. W3C’s WCAG 2.2 Accessible Authentication (Minimum), Level AA, limits authentication steps that require cognitive function tests unless specified alternatives or assistance mechanisms are available. Blocking password paste can remove an important assistance mechanism.

For forms that also lose visitors without clear errors, use the CRO audit checklist to investigate persuasion and friction separately. A conversion problem and an accessibility failure can overlap, but they are not interchangeable.

What can automated tools miss?

An automated checker can identify some missing labels, detectable contrast failures and invalid accessibility attributes. It cannot reliably decide whether an image description is useful, whether focus follows a sensible task sequence or whether an error message explains the fix.

Treat each reported issue as something to verify. A clean scan is not evidence that the whole site meets WCAG 2.2 AA.

Add a screen reader check using VoiceOver on macOS or NVDA on Windows. Learn its basic navigation commands, then inspect headings, links, controls and form feedback. If unfamiliar output seems wrong, investigate before labeling it a site defect: screen reader interaction differs from ordinary keyboard navigation.

The quick audit also leaves other areas to examine, including zoom and reflow, captions, motion, document structure and touch interactions. For a formal evaluation, use someone with accessibility testing experience and include people with disabilities in usability testing where possible.

How should you prioritize and retest the fixes?

Prioritize by blocked tasks, reach and frequency, not by the order a scanner lists issues. A keyboard trap in checkout usually needs attention before an isolated image description on an old article.

For each issue, record the URL, interaction state, reproduction steps, observed behavior, expected behavior and relevant WCAG criterion where known. Assign an owner and define what passing the retest means.

After changing a shared component, check it in different layouts and states. A focus ring that works on the homepage may disappear inside a dark modal.

Repeat the relevant checks whenever you change navigation, forms, checkout or your component library. Add them to your regular website audit checklist so accessibility is part of shipping changes, not an occasional cleanup project.