Accessibility testing for WCAG basics

Accessibility problems lock real people out of your product, and many of them are easy to find and fix. This page covers the WCAG checks a careful browser pass can do, what it cannot replace, and a ready task for your AI beta tester.

Who it’s for

  • Teams that want to catch the most common accessibility barriers before launch
  • Products preparing for a formal accessibility audit
  • Designers checking contrast, focus styles and labels
  • Public sector, education and e-commerce sites with legal requirements

Updated 2026-10-19.

What this kind of accessibility test covers

The Web Content Accessibility Guidelines (WCAG) are the standard most laws and procurement rules point to (the current version is WCAG 2.2, published by the W3C). WCAG 2.2 has three levels, A, AA and AAA, and AA is the usual target. A browser-based accessibility testing pass checks the issues that can be observed directly on the page: keyboard use, focus, contrast, labels, alt text, headings and zoom. It finds many of the barriers that come up in practice, quickly and repeatedly.

What it does not replace: testing with people who use screen readers, switch devices, voice control or magnification every day, and a full audit by an accessibility specialist. If you need a conformance statement or have legal obligations, use this test to fix the obvious issues first, then bring in experts and users of assistive technology.

Why accessibility belongs in every beta test

Accessibility problems are bugs. A modal you cannot close with the keyboard, a form field without a label, or gray text nobody can read in sunlight blocks real people from using your product, just like a crash would. Folding accessibility checks into each beta test catches these regressions when they are cheap to fix, instead of in a yearly audit.

How to run a basic accessibility test

  1. Pick the key flows: home page, signup, login, the core task and checkout or contact.
  2. Unplug the mouse. Complete each flow with the keyboard only: Tab, Shift+Tab, Enter, Space, arrow keys and Escape.
  3. Check what you see: contrast, focus indicators, color-only meaning and motion.
  4. Zoom to 200% and narrow the window to about 320px wide, then repeat the main flow.
  5. Inspect structure: headings, labels, alt text, button names and the page language.
  6. Trigger errors in every form and check how they are shown and linked to fields.
  7. Record each issue with page, element, who it affects and a suggested fix.

Accessibility checklist

Keyboard and focus

  1. Every interactive element (links, buttons, menus, form fields, modals, custom dropdowns) can be reached with Tab and used with Enter or Space.
  2. The focus indicator is clearly visible on every element. Removing the outline without a replacement is one of the most common failures.
  3. Focus order follows the visual order.
  4. No keyboard traps: you can always Tab out of a widget, and Escape closes modals and menus.
  5. Opening a modal moves focus into it; closing it returns focus to the button that opened it.
  6. A "Skip to content" link appears on pages with long navigation.
  7. Focused elements are not hidden behind sticky headers or cookie banners.

Visual checks

  • Contrast: normal text needs at least 4.5:1 against its background, large text and interface components at least 3:1. Placeholder text and disabled-looking buttons often fail.
  • Color alone: errors, required fields and chart series must not be shown by color only.
  • Zoom and reflow: at 200% zoom text stays readable, and at a 320px-wide viewport content reflows without horizontal scrolling.
  • Target size: buttons and links are large enough to hit, with space between them.
  • Motion: animations respect reduced-motion settings, and nothing flashes rapidly.

Structure and labels

  • One clear h1 per page and a logical heading order (h2, h3) without skipped levels used for styling.
  • Images: meaningful images have alt text that says what matters; decorative images have empty alt text.
  • Form fields have visible labels connected to the input, not just placeholders.
  • Error messages are linked to their fields and announced, not only shown in red.
  • Buttons and links have names that make sense out of context (not five links called "Click here").
  • Icon-only buttons have an accessible name.
  • The page has a language attribute and a descriptive title.

Example bug report

Title: Signup modal traps keyboard focus; cannot be closed without a mouse
Environment: Firefox 131, macOS 14, 1280px wide, keyboard only
WCAG: 2.1.2 No Keyboard Trap (Level A), 2.4.3 Focus Order (Level A)
Steps to reproduce:
1. On the home page, Tab to "Start free" and press Enter
2. Press Tab repeatedly inside the signup modal
3. Press Escape
Expected: focus cycles inside the modal, Escape closes it and focus
          returns to "Start free"
Actual: focus moves to links behind the modal, which stay invisible;
        Escape does nothing. The close button is a div with no name.
Affects: keyboard users, screen reader users, switch users
Severity: High (blocks signup for keyboard users)
Suggested fix: use a dialog with focus management, make close a real
               button labeled "Close"

Common mistakes

  • Relying only on an automated scanner. Scanners catch missing alt text and some contrast issues but cannot tell whether focus order makes sense or a modal is usable.
  • Testing only the home page while barriers sit in the signup or checkout flow.
  • Fixing symptoms page by page instead of the shared component that causes them.
  • Adding alt text like "image" or repeating the file name.
  • Treating a clean automated report as proof of compliance.

What to fix first

  1. Blockers in key flows: keyboard traps, unlabeled form fields, buttons that cannot be reached, errors that are not announced.
  2. Issues in shared components: navigation, buttons, form inputs and modals, where one fix repairs every page.
  3. Readability: contrast failures, text that breaks at 200% zoom, missing focus styles.
  4. Structure and polish: heading order, link wording, decorative image handling.

Turning findings into fixes

Report each issue with the page, the element, the WCAG success criterion it relates to when known, who it affects (keyboard users, low-vision users, screen reader users) and a suggested fix. Group repeated issues: one missing focus style in a shared component is one fix, not forty bugs.

Doing it manually vs with an AI beta tester

A manual keyboard-and-zoom pass by someone on your team is a great habit and takes little time per flow. The hard part is doing it on every release, so regressions slip back in.

An AI beta tester like betatest.ing can run the same keyboard, focus, contrast, labeling and zoom checks in a real browser on each release or on a schedule, and file each issue with steps, severity, the related WCAG criterion when it is clear, annotated screenshots and a recording. That makes accessibility part of regular regression testing instead of a one-off project.

It is no substitute for a certified accessibility audit or for testing with people who use assistive technology every day. Use it to catch the observable basics early, and rely on experts and real users for conformance and for how your product actually feels to use.

The test task

What you send your AI beta tester. It works out the steps and tests like a real user.

Do an accessibility pass of [SITE URL] against WCAG 2.2 AA basics on these pages: [PAGES TO CHECK]. Use only the keyboard first: Tab through each page and check every link, button, menu, form field and modal can be reached and used, the focus indicator is always visible, the focus order makes sense, there are no keyboard traps, Escape closes dialogs and focus returns after closing, and a skip link exists. Then check text and component contrast (4.5:1 for normal text, 3:1 for large text and UI parts), information shown by color only, 200% zoom and a 320px-wide viewport, headings (one h1, logical order), alt text on images, visible labels on form fields, error messages tied to fields, link and button names, icon-only buttons, the page language and title. Log each issue with the page, the element, the related WCAG criterion when you know it, who it affects and a suggested fix, with an annotated screenshot. Group issues that come from the same component. End with a report that scores the site and lists the 5 most impactful fixes, and note that a full audit needs testing with assistive technology users.

Fill in your details

Here, or later in the chat with your tester.

  • [SITE URL] The site or app to check, e.g. https://example.com
  • [PAGES TO CHECK] e.g. "home, signup, the main dashboard page and checkout"

What the AI beta tester checks

  • Keyboard access to every interactive element
  • Visible focus indicator and logical focus order
  • Keyboard traps, Escape and focus return on modals
  • Text and component contrast against WCAG AA ratios
  • Information conveyed by color alone
  • 200% zoom and reflow at 320px width
  • Headings, page title and language attribute
  • Alt text, form labels, error messages and button names

What you get

  • Accessibility issues with page, element, WCAG criterion and suggested fix
  • Annotated screenshots of each barrier
  • Issues grouped by shared component so fixes are not duplicated
  • A report with a score and the 5 most impactful fixes

How to run it with betatest.ing

  1. Add your site as a project
  2. Paste the task and list the pages that matter most
  3. Send it; the tester checks keyboard, visuals and structure in a real browser
  4. Fix the top issues, then re-run to confirm
  5. Plan testing with assistive technology users for a full audit

Tips

  • Start with shared components (header, buttons, forms, modals): one fix there repairs every page
  • Never remove focus outlines without a visible replacement
  • Check placeholder text and disabled buttons for contrast: they fail often
  • Re-run the pass after each design system change

Accessibility testing: FAQ

Does this make my site WCAG compliant?

No single test can promise that. This pass finds many common barriers you can see in a browser. Conformance needs a full audit, including testing with screen reader, keyboard-only and other assistive technology users.

Does the tester use a screen reader?

It checks what screen readers rely on, such as labels, alt text, headings and accessible names, but it is not a replacement for testing with people who use screen readers daily.

Which WCAG version should I target?

WCAG 2.2 at level AA is the common target today. Many laws and policies still reference 2.1 AA, which 2.2 builds on.

What contrast ratio do I need?

At level AA, 4.5:1 for normal text and 3:1 for large text and for interface components such as input borders and icons.

How often should I check accessibility?

Every time you change shared components or add a new flow, and on a schedule so regressions are caught early.

Are automated accessibility checkers enough?

No. Automated scanners are useful for catching things like missing alt text, missing labels and some contrast problems, but they can't judge whether focus order makes sense, whether a modal is usable with a keyboard or whether alt text is meaningful. Combine a scanner with a manual or AI-run keyboard and zoom pass, and with testing by assistive-technology users.

What accessibility issues should I fix first?

Start with blockers in your key flows: keyboard traps, unreachable buttons, unlabeled form fields and errors that aren't announced. Then fix shared components such as navigation, inputs and modals, because one fix repairs every page that uses them. Contrast and structure issues come next.

Should accessibility be part of my beta test?

Yes. Accessibility barriers are bugs that stop real people from using your product, and they're cheapest to fix before launch. Adding a keyboard, contrast and zoom pass to each beta test also catches regressions that a yearly audit would miss.

Related beta testing guides

  • Form validation testing — Forms are where users give you their data, and where broken validation quietly loses leads, orders and signups. This page lists the edge cases worth trying on every form and a ready test task for your AI beta tester.
  • Responsive design testing — Most layouts are designed on a wide screen and break quietly on a phone. This page explains which widths to test, the layout bugs that come up again and again, and a task your AI beta tester can run at phone and tablet sizes.
  • UX review — A UX review looks past bugs to the experience itself: what confuses people, what slows them down, and what is missing. This page covers a practical review framework and a test task your AI beta tester can run on your product.
  • Website beta testing — A website beta test is a run-through of your site by someone who has never seen it, before real visitors do. This guide covers what breaks most often on marketing and content sites, how to set up the test, and a ready-to-run task your AI beta tester can start on right now.
  • Free tool: Free website test — Enter a URL, get an instant report: SEO basics, mobile, security headers, broken links and a score.

More in by test type