Here's the uncomfortable truth: most test suites never ask whether a person can complete a task. They find buttons by CSS class, click them with a phantom mouse, and happily pass a form with no labels, a "button" you can't reach by keyboard, and a success message nobody hears. Scanners check pages, not journeys. And the one method that does test journeys, expert use case testing with assistive technology, is so slow it gets done once before launch, if at all.

This session introduces UCDL, a new language for writing accessibility use cases as plain, readable steps, and a runner that turns them into automated tests. Every element is found the way assistive technology finds it: by role and accessible name. If a screen reader can't find it, neither can the test.

We'll take a passing test, rewrite it, and watch it fail in all the right places. Then we'll check what a screen reader actually announced, run a journey with the mouse banned, and squeeze it into a 320-pixel viewport.

You'll leave knowing why your current tests miss the barriers that matter most, and how to write task-level accessibility tests that your QA team, developers and product owners can all read.