Website Accessibility: A Practical WCAG Checklist

Accessibility problems are rarely visible to the people who build a website. The design looks clean, the pages load, and the forms work with a mouse. Meanwhile, a visitor using a screen reader hears "button, button, button" with no labels, someone navigating by keyboard cannot see where they are on the page, and a reader with low vision cannot make out pale grey text. Website accessibility means designing and building so that people with disabilities can perceive, understand, navigate and use the site. It also tends to make sites easier for everyone. This guide explains the standard most teams work to, the issues that cause most problems, how to test, and how to build accessibility into everyday work rather than treating it as a one-off audit.

The standard: WCAG 2.2

The Web Content Accessibility Guidelines, published by the W3C, are the most widely used reference. The current version, WCAG 2.2, extends WCAG 2.1, and the W3C advises using it to maximise future applicability. Its success criteria are grouped under four principles, often summarised as perceivable, operable, understandable and robust, and each criterion has a level: A, AA or AAA.

Most organisations target level AA, which includes all level A and AA criteria. Accessibility may also be a legal requirement for your organisation, depending on where you operate and what you provide; check your obligations with a qualified adviser. This guide is practical guidance, not legal advice.

The issues that cause most website accessibility problems

A small number of problems account for much of the difficulty people face. From WCAG 2.2:

• Text alternatives: non-text content, such as images that convey information, needs a text alternative (1.1.1, level A). Decorative images should be hidden from assistive technology.
• Colour contrast: normal text needs a contrast ratio of at least 4.5:1, and large text at least 3:1 (1.4.3, level AA).
• Keyboard access: all functionality must be operable through a keyboard (2.1.1, level A), with no traps where focus cannot move away.
• Visible focus: keyboard users must be able to see which element has focus (2.4.7, level AA). Removing focus outlines for appearance is a common failure.
• Labels and headings: headings and labels must describe topic or purpose (2.4.6, level AA), and form fields need labels that are announced with them.
• Resizing and reflow: text must be resizable up to 200 percent without loss of content or function (1.4.4), and content should work without two-dimensional scrolling at a width equivalent to 320 CSS pixels (1.4.10), both level AA.
• Target size: pointer targets should be at least 24 by 24 CSS pixels, with exceptions such as adequate spacing (2.5.8, level AA, new in WCAG 2.2).

What WCAG 2.2 added

WCAG 2.2 introduced several new criteria worth knowing, because older checklists will miss them. They include Focus Not Obscured (Minimum), so focused elements are not hidden behind sticky headers or cookie banners; Dragging Movements, so actions that need dragging have a single-pointer alternative; Target Size (Minimum); Consistent Help, so help options appear in the same place across pages; Redundant Entry, so users are not asked to re-enter information they already provided in the same process; and Accessible Authentication (Minimum), which limits reliance on cognitive tests such as remembering or transcribing during login.

Build accessibility into design and code

Accessibility is cheapest when it is part of normal work:

• Design: choose colour palettes that meet contrast requirements, design visible focus states, and make sure meaning is never conveyed by colour alone
• Content: write descriptive link text and headings, add alternative text when publishing images, and use plain language
• Code: use native HTML elements, such as button, a and label, before custom widgets; structure pages with headings and landmarks; and only use ARIA attributes when native elements cannot do the job
• Components: build accessible patterns once, in a shared component library, so every page inherits them

Our guide to mobile-first web design covers designing for small screens, which overlaps with many accessibility needs, such as readable text and adequate tap targets.

Test with tools and people

Automated tools catch some issues quickly, such as missing alternative text, low contrast and missing form labels. They cannot judge whether alternative text is meaningful or whether a page makes sense when read aloud. Combine:

• Automated checks in the build pipeline and during development
• Manual keyboard testing: tab through every page, operate every control, and check focus is always visible
• Screen reader testing of key journeys, such as navigation, search, forms and checkout
• Zoom testing at 200 percent and at narrow widths
• Where possible, feedback from people who use assistive technology every day

Worked example: a practical accessibility checklist

The table below is a starting checklist for a typical business website, based on WCAG 2.2 level AA. It is not a complete list of criteria; use the full standard for conformance claims.

CheckWCAG referenceHow to testInformative images have meaningful alternative text1.1.1 (A)Inspect images; listen with a screen readerText contrast meets 4.5:1, or 3:1 for large text1.4.3 (AA)Contrast checker on text and backgroundsEverything works by keyboard2.1.1 (A)Tab through each page and use every controlFocus is always visible and not hidden by sticky elements2.4.7 (AA), 2.4.11 (AA)Tab through with banners and headers presentHeadings and labels describe their purpose2.4.6 (AA)Review heading outline; check form labelsText resizes to 200 percent without loss1.4.4 (AA)Zoom browser to 200 percentNo sideways scrolling at 320 CSS pixels width1.4.10 (AA)Narrow the window or zoom to 400 percentTap targets at least 24 by 24 CSS pixels or spaced2.5.8 (AA)Inspect small icons and inline controlsLogin does not rely on memory or transcription tests3.3.8 (AA)Walk through login and password reset

Running this checklist on each new template, and on a sample of pages after major changes, catches most regressions.

Keep it accessible over time

Sites change weekly, and accessibility can erode just as quickly. Assign an owner, include accessibility checks in the definition of done for new features, train content editors on alternative text and headings, and publish an accessibility statement explaining your target, known issues and how users can report problems. Our guide to client portal design shows how designing around user needs extends to logged-in areas.

Common website accessibility mistakes

• Removing focus outlines without a visible replacement
• Pale grey text on white backgrounds
• Clickable elements built from generic elements without keyboard support
• Form fields with placeholder text instead of labels
• Relying only on automated tools
• Treating accessibility as a one-off audit before launch

Frequently Asked Questions

What is website accessibility?

It is designing and building websites so that people with disabilities, including those using screen readers, keyboards or magnification, can perceive, understand, navigate and use them.

Which accessibility standard should a website follow?

Most organisations target WCAG 2.2 level AA. The W3C advises using WCAG 2.2, the current version. Check whether specific legal requirements apply to you.

What is the minimum colour contrast for text?

Under WCAG 2.2 level AA, normal text needs a contrast ratio of at least 4.5:1, and large text at least 3:1.

Can automated tools make a site accessible?

They help catch common issues but cannot judge meaning or usability. Combine them with keyboard, screen reader and zoom testing, and feedback from real users.

Make your website usable by everyone

We build and fix websites to meet WCAG 2.2 level AA, with accessible components and testing built into delivery. See our custom app development services, or talk to us about accessibility.

About the Author

Manav Sharma is the founder of Insyrge and a CRM solutions architect. He works across Zoho, Salesforce, HubSpot, Odoo and more, designing the CRM setups, integrations and automations that keep sales and operations teams working from the same data.