SPACEBAR to move forward through slides.
SHIFT & SPACEBAR to move backwards through slides.
LEFT ARROW & RIGHT ARROW to move through sections.
ESC to see overview and ESC again to exit.
F to enter presentation mode and ESC to exit.
One key problem I see is teams tacking on a statement to their “definition of done” like:
“Must be WCAG 2.2 compliant”.
This is too broad and too vague to test as a single acceptance criterion.
This is the opposite of good practice.
So, what's this session about?
I'll show you how to write clear, precise and meaningful accessibility acceptance criteria.
And these accessibility acceptance criteria can be used on pages, flows and even components.
Acceptance criteria are specific, clear, and testable conditions that a product, feature, or user story must meet to be accepted as complete.
Align the team on what needs to be delivered.
Confirm when a feature or story is complete.
Clarify what’s in/out, reducing scope creep.
Help developers build the right thing.
Provide a checklist for testers to verify success.
Easy to read and understand.
Each point can be verified.
Written from the end-user’s perspective.
No ambiguity about what must be done.
Accessibility acceptance criteria are just a subset of normal acceptance criteria.
They define the accessibility requirements that must be met for a product or feature to be considered accessible.
Used to confirm accessibility requirements have been met before work is considered complete.
Added to stories to define accessibility expectations before work begins.
Help designers define accessible interactions, layouts, and content behaviours.
Provide developers with clear, testable accessibility expectations during implementation.
Support testers in verifying accessibility requirements consistently.
Define reusable accessibility requirements for shared patterns and components.
Included in AI prompts to help generate designs, code, and content that consider accessibility requirements from the start.
Added to skills.md files to provide consistent accessibility guidance and expectations for AI-assisted workflows and development tools.
In this session, we’ll explore two levels of accessibility acceptance criteria:
Pages are complete views or screens that present content, functionality, or interactions within a digital product.
They often bring multiple components together into a single layout.
User flows are end‑to‑end sequences of pages, states, or interactions.
These flows guide users through completing tasks or achieving outcomes.
Each step in a flow can involve multiple components or pages working together.
To ensure accessibility is considered and tested across entire journeys, not just individual components.
All interactions — including navigation, opening/closing elements, entering data, and submission — can be completed using only a keyboard
Many teams focus heavily on individual UI components — and that’s important.
In fact, we’ll be covering component-level accessibility criteria a bit later.
But there are also critical accessibility issues that only surface at the page or user-flow level.
These can affect how people navigate, understand, and interact with your product as a whole — not just one element at a time.
Making it harder to understand page structure for screen reader users.
Such as modals or dynamic content not receiving focus.
Where source order, focus order, and visual reading order are misaligned.
Causing disorientation for users relying on predictability.
Particularly in multi-step flows like forms or checkouts.
Making it harder for screen reader users to identify where they are.
Especially in dynamic content like popups or menus.
Due to too many competing elements or unclear tasks on a single page.
Such as sessions that expire mid-task without alerting the user.
These types of issues can’t be caught by checking individual components in isolation.
That’s why writing acceptance criteria at the page or flow level is such a valuable practice.
UI components are distinct interface elements that perform a specific function within a digital interface.
They are the building blocks of websites and applications, designed to be reused in different contexts.
To ensure accessibility is considered and tested for all components, regardless of where or how they’e used.
The dropdown can be opened using keyboard controls (e.g. Tab + Enter or Space)
There are many ways to create accessibility acceptance criteria for pages and user flows.
The following steps can be used to teach you how to write robust and inclusive critera.
As you get more confident, you’ll find you can move through these steps more quickly.
You may end up being able combine some steps—but the thinking behind each step is still important!
It helps make sure we’re considering a range of different users and their needs.
Framing accessibility as a question (“Can this be done with a keyboard?”) feels more natural than writing formal criteria upfront.
Each test forces you to think about real-world usability and edge cases.
These test questions become a ready-made checklist for quality assurance and user acceptance testing — especially across full flows.
We will use a simple contact form flow:
https://intopia.github.io/exercise/testing-contact-form.html
When writing accessibility acceptance criteria, the order in which we consider user groups matters.
Ideally, we should focus first on the appearance and usability of the component, then move toward more technical or structural aspects.
That’s why I recommend this order:
Start with people with varied learning or cognition.
If a component doesn't work for this group, it likely has fundamental issues with content, clarity, or UX.
These problems should be resolved before moving on — otherwise, you're building accessibility on a weak foundation.
Then consider people with reduced colour vision and reduced vision.
These groups help you assess the visual presentation of the component — including contrast, layout, text size, and use of colour.
Finally, focus on people with reduced movement and people with no vision.
These groups help you uncover technical and structural issues, like keyboard operability, focus order, screen reader compatibility, and correct semantic markup.
We will focus on people with reduced movement.
For this step, we want to understand how people interact with the page or flow.
Each user group may rely on different assistive technologies, settings, or preferences to access digital content.
For people with reduced movement, technologies could include:
In this step, we think from the user’s perspective to help identify barriers these users may face when using our Contact form page.
Now we need to write each potential barrier as a short question with a clear pass/fail outcome.
Each test question should be phrased so that when someone tests it and the outcome is accessible, they can confidently say: “Yes, it passes!”
If the answer is “No”, that’s a clear sign of a failure — something is missing or needs fixing.
Are instructions, labels, and feedback easy to understand? (PASS/FAIL)
A pass would mean “Yes, instructions and labels are easy to understand!”.
A fail would mean “No, instructions and labels are NOT easy to understand!”.
Incorrect focus order
Does keyboard focus move through the page in a logical and meaningful order? (PASS/FAIL)
Keyboard traps
Can keyboard users move to and away from all interactive elements without becoming trapped? (PASS/FAIL)
Missing skip mechanisms
Is there a way for keyboard users to skip repeated content and move directly to the main content or form? (PASS/FAIL)
Auto-focus issues
Does focus remain stable and predictable while interacting with the page? (PASS/FAIL)
Custom controls that are not keyboard accessible
Can all custom controls be accessed and operated using only the keyboard or voice control? (PASS/FAIL)
CAPTCHA barriers
Can CAPTCHA be completed using only the keyboard? (PASS/FAIL)
Timeouts or session expiry
Do users have enough time to complete tasks without unexpected timeouts or session expiry? (PASS/FAIL)
No visible indication of the current field
Is the currently focused element always clearly visible? (PASS/FAIL)
Inconsistent keyboard interactions
Do interactive elements follow expected keyboard interactions and behaviours? (PASS/FAIL)
Multi-step login flows with poor focus management
Does keyboard focus move correctly through each step of the login process? (PASS/FAIL)
Next, we need to reframe each test from a question into a positive statement.
These statement become your final acceptance criterion.
Does keyboard focus move through the page in a logical and meaningful order? (PASS/FAIL)
Does Keyboard focus moves through the page in a logical and meaningful order.
Can keyboard users move to and away from all interactive elements without becoming trapped? (PASS/FAIL)
Can Keyboard focus moves through the page in a logical and meaningful order.
Is there a way for keyboard users to skip repeated content and move directly to the main content or form? (PASS/FAIL)
Is There is a way to skip repeated content and move directly to the main content or form.
Does focus remain stable and predictable while interacting with the page? (PASS/FAIL)
Focus remains stable and predictable while interacting with the page.
Can all custom controls be accessed and operated using only the keyboard? (PASS/FAIL)
All custom controls can be accessed and operated using only the keyboard.
Can CAPTCHA or verification steps be completed using only the keyboard? (PASS/FAIL)
CAPTCHA or verification steps can be completed using only the keyboard.
Is there enough time to complete tasks without unexpected timeouts or session expiry? (PASS/FAIL)
There is enough time to complete tasks without unexpected timeouts or session expiry.
Is the currently focused element always clearly visible? (PASS/FAIL)
The currently focused element is always clearly visible.
Do interactive elements follow expected keyboard interactions and behaviours? (PASS/FAIL)
Interactive elements follow expected keyboard interactions and behaviours.
We now have test questions and acceptance criteria for each potential barrier.
The final step is to create some simple steps to test each criterion.
These steps can be used by QA, or anyone else in the team, to determine whether the criteria pass or fail.
Acceptance criteria: Keyboard focus moves through the page in a logical and meaningful order.
Test question: Does keyboard focus move through the page in a logical and meaningful order? (PASS/FAIL)
But how do QAs test it?
Ideally, we should provide them with some simple tests!
Acceptance criteria: It is possible to move to and away from all interactive elements without becoming trapped.
Test question: Can keyboard users move to and away from all interactive elements without becoming trapped? (PASS/FAIL)
Acceptance criteria:There is a way to skip repeated content and move directly to the main content or form.
Test question: Is there a way for keyboard users to skip repeated content and move directly to the main content or form? (PASS/FAIL)
Acceptance criteria:There is enough time to complete tasks without unexpected timeouts or session expiry.
Test question: Do users have enough time to complete tasks without unexpected timeouts or session expiry? (PASS/FAIL)
For our login screen, focussing on people with limited movement, we now have the following information for each potential barrier:
We can now repeat steps 2-7 for each user group.
This is a complete set of ready-to-use page and user-flow acceptance criteria.
Most of the time, you’ll be working with pages, flows, or existing components from your design system.
You may not often need to design or build new components.
But there are key moments where component-level thinking becomes essential.
Component-level criteria give you the tools to define, evaluate, and request accessible behaviour at any level.
We use the same steps from page and user-flow criteria — but with a different lens.
Let’s look at how these steps change when we focus on a component.
For page and user-flow level acceptance criteria, we looked at full screens or user journey (e.g., “Book a flight”).
For component level acceptance criteria, we will zoom in on individual reusable elements — buttons, modals, tab sets, carousels, autocompletes, etc.
This step is the same at both levels.
For page and user-flow level acceptance criteria, we focused on task completion, maintaining context, feedback, and orientation.
For component level acceptance criteria, we look at three things.
(e.g. open/close, show suggestions, validate input, announce its state)
(keyboard, screen reader, voice control, switch control, zoom, large text)
(key presses, gestures, navigation steps, announcements, state changes)
To write good component level criteria, you need to consider how different input methods behave.
For page and user-flow level acceptance criteria, we looked at barriers that affect the overall journey.
For component level acceptance criteria, barriers become more technical and specific.
Let’s explore barriers that affect each group.
<div> used instead of <button>).As before we need to write each potential barrier as a short question with a clear pass/fail outcome.
Each test question should be phrased so that when someone tests it and the outcome is accessible, they can confidently say: “Yes, it passes!”
Because components are the foundation of every interface, their test questions need to be far more rigorous than page or user-flow checks.
Many accessibility criteria are objective — such as colour contrast, keyboard access, and ARIA roles.
These must be written in a way that is explicit, measurable, and produces a clear pass/fail result.
However, criteria for people with varied learning or cognition are different.
These criteria are often UX-based and rely on clarity, predictability, and comprehension — all essential, but not always binary.
These checks still matter just as much, but their pass/fail outcome depends on UX judgement rather than a strict numerical threshold.
These steps remain the same at both levels: