---
title: "Testing accessibility with tools and assistive technology"
description: "Automated tools catch some issues, not all Automated accessibility checkers are fast and useful, but they detect only a portion of WCAG issues — often…"
url: https://optimizeall.com/learn/ui-ux-design-basics-for-marketers/accessibility-testing
updated: 2026-10-05
---

UI/UX Design Basics for Marketers · Accessibility essentials (WCAG basics) · lesson 18 of 21 · 10 min

# Testing accessibility with tools and assistive technology

## Automated tools catch some issues, not all

Automated accessibility checkers are fast and useful, but they detect only a portion of WCAG issues — often cited as a minority. They can't judge whether alt text is meaningful, whether headings make sense, or whether a flow is understandable. Combine automated, manual and user testing.

## Layer 1: automated checks

Tools include browser extensions and built-in audits (for example, Lighthouse in Chrome DevTools, axe-based extensions, WAVE). They flag issues like:

- Missing alt attributes.
- Low contrast text.
- Missing form labels.
- Empty links or buttons.
- Incorrect ARIA usage.
- Missing page language.

Run them on key templates and pages, and after major changes.

## Layer 2: manual checks anyone can do

**Keyboard test (10 minutes):**

1. Put the mouse aside.
2. Press Tab from the top of the page. Can you see where focus is at every step?
3. Can you reach and operate every link, button, menu, form field, accordion and modal?
4. Is the focus order logical?
5. Can you close pop-ups with Escape and return to where you were?
6. Is focus ever hidden behind sticky elements?

**Zoom and reflow test:**

- Zoom the browser to 200% and 400%. Does content reflow into a single column without horizontal scrolling (except for things like data tables)? Is anything cut off?

**Contrast spot-check:** use a color picker/contrast tool on text over images and buttons.

**Content review:** are headings logical? Is alt text meaningful? Is language plain?

**Motion check:** turn on your device's "reduce motion" setting — do animations calm down?

## Layer 3: screen reader basics

Screen readers read the page aloud and let users navigate by headings, links, landmarks and form fields. Free or built-in options include:

- **VoiceOver** (built into Apple devices).
- **TalkBack** (built into Android).
- **NVDA** (free for Windows); **Narrator** (built into Windows).

A basic screen-reader test:

1. Turn on the screen reader and listen to the page from the top.
2. Navigate by headings — do they outline the page?
3. Navigate by links — are they descriptive out of context?
4. Complete the main form — are labels, errors and confirmation announced?
5. Check that images have sensible descriptions and decorative images are skipped.

It feels awkward at first; even basic familiarity reveals major issues. Remember that experienced screen-reader users navigate much faster and differently than beginners.

## Layer 4: testing with disabled users

Nothing replaces feedback from people who use assistive technology daily. Options:

- Include disabled participants in usability tests (recruit through disability organizations or specialist recruitment services; pay participants fairly).
- Ask for feedback via an accessibility statement with a contact method.
- Commission expert audits for major launches or regulated contexts.

## Accessibility statement

An accessibility statement explains your commitment, the standard you aim for (e.g. WCAG 2.2 AA), known limitations, and how to contact you for help or to report problems. It's required for some public-sector sites and good practice for everyone.

## Building accessibility into the workflow

```
Where accessibility fits
Brief:        Include WCAG 2.2 AA as a requirement
Design:       Contrast, target size, focus states, heading structure in wireframes
Content:      Alt text, captions, plain language, link text
Build:        Semantic HTML, labels, keyboard support
QA:           Automated scan + keyboard test + screen-reader smoke test
Launch:       Accessibility statement updated
Ongoing:      Monitor feedback; re-test templates after changes
```

## Worked example: a booking widget

An automated scan shows zero errors. A keyboard test reveals the date picker can't be operated without a mouse, and focus disappears when the booking modal opens. A screen-reader test finds the time slots are announced only as "button". Fixes: keyboard-operable date picker (or a simple date input alternative), focus moved into the modal and trapped, accessible names like "Book 3:00 p.m. Thursday, June 12". A disabled tester later confirms the flow works.

## Common mistakes

- Treating a clean automated scan as proof of accessibility.
- Never testing with a keyboard.
- Using third-party widgets (chat, booking, cookie banners) without checking their accessibility.
- No way for users to report problems.

## Hands-on: automate a first-pass scan with axe-core and Playwright

If your team has a developer or a technical marketer, you can add an automated accessibility scan to your launch checklist. This uses the open-source axe-core engine through its Playwright integration. It catches common, detectable issues; it does not prove a page is accessible.

```bash
npm init -y
npm install --save-dev @playwright/test @axe-core/playwright
npx playwright install chromium
```

```javascript
// a11y.spec.js — run with: npx playwright test a11y.spec.js
const { test, expect } = require('@playwright/test');
const AxeBuilder = require('@axe-core/playwright').default;

const PAGES = (process.env.A11Y_URLS || 'https://example.com/').split(',');

for (const url of PAGES) {
  test(`axe scan: ${url}`, async ({ page }) => {
    await page.goto(url, { waitUntil: 'networkidle' });
    const results = await new AxeBuilder({ page })
      .withTags(['wcag2a', 'wcag2aa', 'wcag21a', 'wcag21aa', 'wcag22aa'])
      .analyze();
    for (const v of results.violations) {
      console.log(`${v.impact} | ${v.id} | ${v.help} | ${v.nodes.length} element(s)`);
    }
    expect(results.violations).toEqual([]);
  });
}
```

Set the pages to check with an environment variable, for example `A11Y_URLS=https://example.com/,https://example.com/pricing npx playwright test a11y.spec.js`. Treat failures as a to-do list, then continue with the manual layers below.

No-code alternatives: the axe DevTools and WAVE browser extensions, and the Accessibility section of a Lighthouse report in Chrome DevTools.

## Screen reader quick-reference for a first test

| Screen reader | Turn on/off | Read next item | Jump by heading |
|---|---|---|---|
| VoiceOver (macOS) | `Cmd + F5` | `VO + Right Arrow` (VO = `Ctrl + Option`) | Rotor: `VO + U`, then choose Headings |
| VoiceOver (iPhone) | Settings → Accessibility → VoiceOver (or triple-click the side button if set as a shortcut) | Swipe right | Rotor gesture, then swipe down |
| TalkBack (Android) | Settings → Accessibility → TalkBack (or volume-key shortcut if enabled) | Swipe right | Reading controls, then swipe |
| NVDA (Windows) | `Ctrl + Alt + N` (if the desktop shortcut is enabled) | `Down Arrow` | `H` |
| Narrator (Windows) | `Ctrl + Win + Enter` | `Caps Lock + Right Arrow` | `H` |

Shortcuts can vary with versions and settings; check the vendor's current help pages if a shortcut doesn't respond.

## An accessibility statement template

```text
Accessibility statement for [site]
We aim to meet WCAG 2.2 Level AA. Last reviewed: [month year].
How we test: automated scans, manual keyboard and zoom checks, screen-reader testing, and feedback from users.
Known limitations: [e.g., older PDF brochures are not fully accessible; accessible versions on request].
Contact: [email/phone/WhatsApp]; we aim to respond within [n] working days.
If you're not happy with our response: [escalation route, and any regulator where applicable].
```

## How to measure success

Track automated violations per key template (trend toward zero on new pages), keyboard and screen-reader task success in your manual tests, the number of issues found by disabled testers, and response times to accessibility feedback.

## Summary

Layer automated scans, manual keyboard, zoom and content checks, basic screen-reader tests and testing with disabled users. Publish an accessibility statement and build checks into every stage of your workflow.

## Video lecture: Testing accessibility with tools and assistive technology

Lecture coming soon · 12 chapters · about 8 minutes. Read the full transcript below.

1. Testing accessibility
2. Why layers?
3. Layer 1: automated checks
4. Layer 2: manual checks
5. Layer 3: screen reader basics
6. Layer 4: disabled users
7. Worked example 1: booking widget
8. Worked example 2: training provider (illustrative)
9. Watch me do it: three layers
10. Accessibility statement + workflow
11. Common mistakes and measures
12. Recap and try this now

## Lecture transcript

### Testing accessibility

An automated accessibility scan shows zero errors. The team celebrates. Then someone tries to book an appointment using only a keyboard, and gets stuck on the date picker. A screen reader announces every time slot as just button, button, button. The scan was right about what it checked. It simply can't check everything. In this lecture, you'll learn the four layers of accessibility testing: automated scans, manual checks anyone can do, basic screen reader testing, and testing with disabled users. Plus how to automate a scan in your launch checklist and publish an accessibility statement.

### Why layers?

Why do you need layers? Because automated tools can detect only a portion of WCAG issues. They can tell you an image has no alt attribute. They can't tell you whether the alt text makes sense. They can flag low contrast. They can't tell you whether your checkout is understandable. Think of it like a car inspection. A machine can measure the tire pressure and the emissions. But you still need someone to drive the car and notice the steering pulls to the left. Automated scans are the machine. Manual and user testing are the test drive.

### Layer 1: automated checks

Layer one: automated checks. Browser extensions like axe DevTools and WAVE, and the accessibility section of a Lighthouse report, flag missing alt attributes, low contrast text, missing form labels, empty links or buttons, incorrect ARIA usage and a missing page language. Run them on your key templates, and after major changes. If you have a developer, you can build it into your launch checklist with Playwright and the open source axe-core engine. The script in the lesson scans a list of pages and prints each violation with its impact and the number of affected elements.

### Layer 2: manual checks

Layer two: manual checks anyone can do. First, the ten minute keyboard test. Put the mouse away. Press tab from the top. Can you always see where focus is? Can you reach and operate every link, button, menu, form field, accordion and pop-up? Is the order logical? Can you close pop-ups with escape and return to where you were? Is focus ever hidden behind sticky elements? Then zoom the browser to two hundred and four hundred percent. Does content reflow into one column without horizontal scrolling? Then spot-check contrast on text over images, and turn on reduce motion to see if animations calm down.

### Layer 3: screen reader basics

Layer three: screen reader basics. Screen readers read the page aloud and let people jump by headings, links, landmarks and form fields. You already have one. VoiceOver is built into Apple devices. TalkBack is built into Android. Narrator is built into Windows, and NVDA is free for Windows. A basic test: turn it on and listen from the top. Jump by headings. Do they outline the page? Jump by links. Do they make sense out of context? Complete the main form. Are labels, errors and the confirmation announced? It feels awkward at first. Remember, experienced users are much faster than you. Even so, your first test will reveal major issues.

### Layer 4: disabled users

Layer four: testing with disabled users. Nothing replaces feedback from people who use assistive technology every day. Include disabled participants in your usability tests, recruited through disability organizations or specialist recruitment services, and pay them fairly for their time and expertise. Offer a feedback route in an accessibility statement. And for major launches or regulated contexts, commission an expert audit. Here's the key idea. Your own screen reader test tells you about obvious barriers. A skilled daily user tells you what it's actually like to use your site.

### Worked example 1: booking widget

Worked example one, simple. A booking widget. The automated scan shows zero errors. The keyboard test reveals the date picker can't be used without a mouse, and focus disappears when the booking pop-up opens. The screen reader test finds every time slot announced only as button. The fixes: a keyboard-operable date picker, or a simple date input as an alternative. Focus moved into the pop-up and kept there while it's open. And accessible names for each slot, like book three p m, Thursday June twelfth. Then a disabled tester confirms the flow works.

### Worked example 2: training provider (illustrative)

Worked example two, a business scenario with illustrative details. A government-funded training provider in the US must meet WCAG two point one AA for its public courses under the ADA Title two rule, and it wants to reach two point two anyway. The digital team adds the Playwright and axe scan to every release, runs a keyboard and zoom check on each new template, and books quarterly sessions with three disabled testers through a disability organization. The first round finds a registration form where errors aren't announced, and a video player without caption controls. Both are fixed before the compliance date.

### Watch me do it: three layers

Watch me do it. In a terminal, I install Playwright and the axe integration, then run the scan script with two URLs from an environment variable: the homepage and the pricing page. It reports two violations on pricing. A serious contrast failure on six elements, and a critical missing form label on one. I log them. Then I put the mouse away and tab through pricing. The plan toggle can't be reached. The scan didn't catch that. Finally, I turn on VoiceOver, jump by headings, and hear two headings called untitled. Three layers, three different kinds of problems.

### Accessibility statement + workflow

Finally, publish an accessibility statement. It explains your commitment, the standard you aim for, like WCAG two point two AA, when you last reviewed the site, how you test, known limitations, and how people can contact you for help or to report problems, with a response time. It's required for some public sector sites and good practice for everyone. And build accessibility into your workflow: in the brief, in design, in content, in build, in QA before launch, and in ongoing monitoring. Accessibility that's checked once decays. Accessibility that's part of the process lasts.

### Common mistakes and measures

Common mistakes. Treating a clean automated scan as proof of accessibility. Never testing with a keyboard. Using third-party widgets like chat, booking or cookie banners without checking their accessibility. Having no way for users to report problems. And testing once before launch, then never again. How do you measure success? Automated violations per key template, trending toward zero on new pages. Keyboard and screen reader task success in your manual tests. Issues found by disabled testers. And how quickly you respond to accessibility feedback.

### Recap and try this now

Let's recap. Layer your testing. Automated scans catch some issues fast. Manual keyboard, zoom and contrast checks catch many more. Basic screen reader tests reveal how your page actually sounds. And disabled users tell you what it's really like. Publish an accessibility statement, and build checks into every stage. Try this now. Do a keyboard test and a two hundred percent zoom test on your key page. Then try one task with your phone's built-in screen reader. Record three issues, and draft a short accessibility statement using the template.

## Key takeaways

- Automated tools catch only a portion of issues — combine with manual and user testing.
- A 10-minute keyboard test reveals many serious barriers.
- Built-in screen readers (VoiceOver, TalkBack, Narrator) and free NVDA enable basic testing.
- Include disabled users in testing and publish an accessibility statement with contact details.

## Try it

Do a keyboard test and a 200% zoom test on your key page, then try one task with your phone's built-in screen reader. Record three issues and draft a short accessibility statement.

- [Previous: A practical accessibility checklist for marketers](https://optimizeall.com/learn/ui-ux-design-basics-for-marketers/accessibility-checklist-for-marketers)
- [Next: Running lightweight usability tests](https://optimizeall.com/learn/ui-ux-design-basics-for-marketers/usability-testing)
- [All lessons of UI/UX Design Basics for Marketers](https://optimizeall.com/learn/ui-ux-design-basics-for-marketers)