Testing accessibility with tools and assistive technology

0:00 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.

0:41 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.

1:23 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.

2:04 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.

2:49 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.

3:37 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.

4:15 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.

4:55 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.

5:39 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.

6:22 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.

7:03 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.

7:40 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.