Website Accessibility Checklist: Practical WCAG 2.2 Checks for Business Sites

A practical website accessibility checklist based on WCAG 2.2: keyboard access, focus, contrast, images, forms, headings, motion and how to test with free tools and real assistive technology.

A website accessibility checklist makes sure people with disabilities can use your site: every function works with a keyboard, focus is always visible, text has sufficient contrast, images have meaningful alt text, forms have labels and clear errors, headings are structured, motion can be reduced, and the site works with screen readers. WCAG 2.2 level AA is the usual benchmark.

Accessibility is part of how I define “finished” on a project, alongside speed and security. This guide supports my landing page structure pillar, because an inaccessible page also converts worse for everyone.

What does website accessibility mean?

It means people with visual, hearing, motor or cognitive disabilities can perceive, understand, navigate and interact with the site, including with assistive technologies such as screen readers, screen magnifiers, voice control and keyboard-only navigation. WCAG organises this into four principles: perceivable, operable, understandable and robust.

Why it matters for business

  • More people can use and buy from your site.
  • Many accessibility fixes (clear labels, contrast, structure) also improve conversion and SEO.
  • Legal requirements are growing; the European Accessibility Act covers e-commerce from 28 June 2025, and other regions have their own rules.

1. Keyboard access

  • Every link, button, menu, form field and modal reachable with Tab.
  • Logical tab order following the visual order.
  • No keyboard traps; modals close with Escape and return focus.
  • A “Skip to content” link as the first focusable element.
  • Custom controls (sliders, tabs, accordions) work with keyboard keys as expected.

2. Visible focus

  • Focus indicator clearly visible on all interactive elements.
  • Focus not hidden behind sticky headers or cookie banners (a WCAG 2.2 criterion: Focus Not Obscured).

Removing outlines for mouse clicks while keeping them for keyboard users:

a:focus:not(:focus-visible),
button:focus:not(:focus-visible) { outline: none; }

a:focus-visible,
button:focus-visible {
  outline: 3px solid var(--focus, #0ea5a4);
  outline-offset: 3px;
}

This keeps the site tidy for mouse users without breaking keyboard navigation.

3. Colour and contrast

  • Normal text contrast at least 4.5:1; large text at least 3:1.
  • UI components and meaningful graphics at least 3:1 against adjacent colours.
  • Information never conveyed by colour alone (errors need text, links in body text need underline or another cue).
  • Both light and dark modes checked if the site has them.

4. Images and media

  • Informative images have alt text describing their purpose.
  • Decorative images have empty alt (alt="").
  • Logos’ alt text is the company name.
  • Images of text avoided; where used, the text is in the alt.
  • Videos have captions; audio has transcripts.
  • No autoplaying media with sound.

5. Structure and semantics

  • One h1 per page and a logical heading order.
  • Landmarks: header, nav, main, footer.
  • Lists marked up as lists, tables as tables with headers.
  • lang attribute set on html, and on passages in another language; dir="rtl" for Arabic.
  • Links with descriptive text, not “click here.”
  • Buttons are button elements, links are a elements.

6. Forms

  • Every field has a visible label connected to the input.
  • Required fields indicated in text, not only by colour or asterisk.
  • Errors identified in text, next to the field, and announced to screen readers.
  • Input purposes identified with autocomplete where applicable.
  • No cognitive puzzles required to log in or submit (WCAG 2.2: Accessible Authentication), or an alternative is provided.

See contact form best practices.

7. Target size and touch

  • Interactive targets at least 24×24 CSS pixels or with enough spacing (WCAG 2.2 Target Size Minimum, AA).
  • Drag interactions have a single-pointer alternative (WCAG 2.2: Dragging Movements).

Covered in more depth in the mobile-first design checklist.

8. Motion and timing

  • Respect reduced motion preferences:
@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
    scroll-behavior: auto !important;
  }
}
  • Carousels can be paused; nothing flashes more than three times a second.
  • Time limits can be extended or are not used.
  • Scroll-driven effects never hide content from users who disable motion.

9. Zoom and reflow

  • Page usable at 200% zoom and at 320 CSS pixel width without two-dimensional scrolling.
  • User zoom not disabled in the viewport meta tag.
  • Text spacing can be increased without content overlapping.

10. Dynamic content

  • Modals use proper roles and manage focus.
  • Status messages (added to cart, form sent) announced via live regions.
  • Menus expose aria-expanded state.

How to test

  1. Automated scan: WAVE, axe DevTools or Lighthouse on key templates. Fix all clear errors.
  2. Keyboard pass: put the mouse away and complete key tasks.
  3. Screen reader pass: VoiceOver on macOS/iOS, NVDA on Windows, TalkBack on Android. Navigate by headings and landmarks, fill a form.
  4. Zoom and reflow: 200% zoom and a narrow window.
  5. Real users: if possible, test with people who use assistive technology daily.

Automated tools catch only a portion of issues; manual testing finds the rest.

About overlay widgets

Accessibility overlay plugins add a toolbar but cannot fix missing labels, keyboard traps or poor structure in the underlying code. Many disabled users and experts criticise them. Fix the source instead.

Common mistakes

  • Removing focus outlines entirely.
  • Icon-only buttons without accessible names.
  • Placeholder text used as labels.
  • Low-contrast grey text for “elegance.”
  • Animations that cannot be turned off.

If you want an accessibility review of your site with prioritised fixes, contact me. It pairs well with a technical SEO audit.

Frequently asked questions

What is WCAG 2.2?

The Web Content Accessibility Guidelines 2.2 are a W3C Recommendation published in October 2023. They build on WCAG 2.1 and add criteria such as focus not obscured, target size minimum and accessible authentication.

Is website accessibility a legal requirement?

It depends on where you operate and who you serve. For example, the European Accessibility Act applies to many consumer products and services, including e-commerce, from 28 June 2025. Check the rules that apply to your business.

Can an accessibility overlay plugin make my site compliant?

Overlay widgets cannot fix underlying code problems such as missing labels or keyboard traps, and many accessibility experts advise against relying on them. Fix the site itself.

What is the best free website accessibility checker?

Tools such as WAVE, axe DevTools and Lighthouse's accessibility audit are widely used. Use them together with manual keyboard and screen reader checks, since automated tools miss many issues.

Muhamed Ahmed

Ecommerce & Web Solutions Developer

I'm Muhamed Ahmed, an ecommerce and web solutions developer with 15 years of experience building fast, secure online stores and websites on WooCommerce, WordPress and custom Laravel platforms. I write about website speed, SEO, automation and conversion.

All articles Work with me

Related articles