Website Accessibility Checklist: A Plain-English Guide to WCAG 2.2

Published October 16, 2026 · Last updated October 16, 2026 · By the WebSolutions LLC team

An accessible website is one that people can use whether they see, hear, move or process information differently. That includes people who use screen readers, people who navigate with a keyboard or switch device instead of a mouse, people with low vision who zoom in, and anyone using a phone in bright sunlight. Accessibility is also good practice for search, usability and conversions, because the same fixes make pages clearer for everyone. This checklist translates the main requirements of the Web Content Accessibility Guidelines into plain English for business websites.

This guide is practical information, not legal advice. If you have a specific legal question about your obligations, speak to a qualified adviser.

What is WCAG?

The Web Content Accessibility Guidelines (WCAG) are published by the World Wide Web Consortium (W3C). The current version, WCAG 2.2, became a W3C Recommendation in October 2023 and builds on WCAG 2.0 and 2.1, so a site that meets 2.2 also meets the earlier versions' requirements, apart from one criterion about parsing that 2.2 removed as obsolete. The guidelines are organised around four principles: content must be perceivable, operable, understandable and robust. Each success criterion has a level, A, AA or AAA. Level AA is the target most organisations and most accessibility policies refer to.

Why accessibility matters for a business website

• Customers. If a visitor cannot use your contact form or checkout, you lose the enquiry or sale.
• Legal expectations. In the United States, the Department of Justice's guidance on web accessibility and the ADA explains that businesses open to the public must make their websites accessible to people with disabilities, and it points to WCAG as helpful guidance. In the European Union, the European Accessibility Act sets accessibility requirements for a range of products and services, including e-commerce.
• Search and usability. Clear headings, descriptive links and text alternatives also help search engines understand the page, which is why accessibility appears in our technical SEO audit checklist.

Perceivable: can people see and hear the content?

• Text alternatives for images. Every meaningful image needs alt text that says what the image communicates. Decorative images should have an empty alt="" so screen readers skip them. Logos that link to the homepage need alt text such as the company name.
• Colour contrast. WCAG level AA asks for a contrast ratio of at least 4.5:1 for normal body text and 3:1 for large text. Check your colours with a tool such as the WebAIM contrast checker. Light grey text on white and white text over photos are the most common failures.
• Do not rely on colour alone. An error shown only by turning a field red, or a link shown only by colour, will be missed by some users. Add text, an icon or an underline.
• Captions and transcripts. Videos with speech need captions, and audio content needs a transcript.
• Text that resizes. Pages should still work when users zoom to 200 percent, and content should reflow on narrow screens without horizontal scrolling.

Operable: can people use it without a mouse?

• Full keyboard access. Put your mouse away and press Tab through the page. Every link, button, menu and form field should be reachable and usable, in a logical order, and you should never get stuck inside a widget.
• A visible focus indicator. As you tab, you should always see where you are. Removing the browser's focus outline without replacing it is a common and serious failure. WCAG 2.2 also asks that the focused element is not hidden behind sticky headers or cookie banners.
• Target size. WCAG 2.2 introduced a minimum target size: interactive targets should generally be at least 24 by 24 CSS pixels, or have enough spacing around them. Tiny icon links in footers and close buttons on pop-ups often fail.
• A skip link. A "Skip to main content" link at the top saves keyboard users from tabbing through the whole menu on every page.
• No time traps or flashing. Give people enough time to complete forms, let them pause carousels and auto-playing media, and avoid content that flashes more than three times per second.

Understandable: is it clear what to do?

• Set the page language with the lang attribute so screen readers pronounce content correctly.
• Label every form field. Use a visible <label> tied to each input. Placeholder text alone disappears as soon as someone types and is often low contrast.
• Helpful error messages. Say what went wrong and how to fix it, next to the field, in text. "Please enter an email address in the format name@example.com" is far more useful than "Invalid input".
• Consistent navigation. Keep menus and help links in the same place on every page.
• Plain language. Short sentences, clear headings and descriptive link text such as "Read our maintenance checklist" instead of "click here".

Robust: does it work with assistive technology?

• Use real HTML elements. A <button> works with a keyboard and a screen reader by default; a clickable <div> does not.
• Logical headings. One H1 per page, then H2 and H3 in order. Screen reader users often jump between headings to scan a page.
• Use ARIA carefully. ARIA attributes can fill gaps for custom widgets, but MDN's ARIA guide recommends using native HTML elements whenever they exist. Incorrect ARIA can make a page harder to use than no ARIA at all.

How to test your website

1. Run an automated checker on your main templates. Automated tools catch problems such as missing alt text, low contrast and unlabelled fields, but they cannot judge whether alt text is meaningful or whether a flow makes sense.
2. Do a keyboard-only pass through your homepage, a service page and your contact form.
3. Try a screen reader. NVDA on Windows, VoiceOver on Mac and iPhone, and TalkBack on Android are free. Listen to how your headings, links and form read out.
4. Zoom to 200 percent and check the layout on a phone.
5. Use the W3C's Easy Checks as a structured first review, then fix issues on templates so the fix applies site-wide.

Be cautious with products that promise instant compliance through a single script or overlay. They cannot fix underlying problems such as missing labels in your forms or poor heading structure, which need changes in the site itself.

Keep accessibility in your routine

Accessibility is not a one-time project. New pages, images, plugins and campaigns can introduce new problems. Add a quick accessibility check to your website maintenance checklist, write alt text when you upload images, and test new templates with a keyboard before launch. Faster pages also help people on older devices and assistive technology, so see our website speed optimization guide too.

Our UI/UX design and web development services build these checks into every project. Read our FAQs or contact us if you would like help reviewing your site.