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.
As I am based in Australia, I’d like to acknowledge the Traditional Owners of the lands on which I’m hosting this meeting today.
I’d like to pay our respects to Elders past and present, and extend to all First Nations people present today.
In my case, I am on the lands of the Cammeraygal people of the Eora Nation.
If you know the traditional owners of the land that you are on today - anywhere in the world, please feel free to share in chat.
We will probably have a 5 min break around the hour mark.
During this session, I’ll invite you to take part in a series of short activities.
I’ll ask you to respond in the chat, but you can raise your hand if you’d prefer to answer verbally.
Please use whichever participation method works best for you.
The activities are voluntary, so you do not need to take part if you would prefer not to.
These slides are a single HTML file, which you can access any time.
I’m going to do a quick overview of the broader concept of acceptance criteria for those who may be unfamiliar.
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 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.
Documents that give AI task-specific instructions, workflows, tools, and best practices.
In this session, we’ll explore two levels of accessibility acceptance criteria:
We’ll also look at when each level should be used, why both are important, and how they work together to support accessible digital experiences.
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 to support a user’s goal.
User flows are end‑to‑end sequences of pages, states, or interactions that guide a user through completing a task or achieving an outcome.
Each step in a flow can involve multiple components or pages working together.
Testable checks that apply to full pages or complete user flows (e.g. sign-up, checkout).
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.
Testable checks for reusable interface components (e.g. buttons, form fields, modals, and carousels).
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:
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.
For our activity soon, 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 our example group - people with reduced movement - this could include:
In this step, we think from the user’s perspective to help identify barriers these users may face.
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!”.
I will ask you to rewrite each potential barrier as short questions with a clear pass/fail outcomes.
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? (PASS/FAIL)
CAPTCHA barriers
Can CAPTCHA or verification steps 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)
Blocked paste functionality
Can users paste information such as passwords or verification codes into relevant fields? (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)
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)
It is possible to move to and away from all interactive elements without becoming trapped.
Is there a way for keyboard users to skip repeated content and move directly to the main content or form? (PASS/FAIL)
There is a way to skip repeated content and move directly to the main content or form.
I will ask you to convert each test question into a positive statement - the final acceptance criteria.
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.
Do users have 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.
Do users have enough time to complete tasks without unexpected timeouts or session expiry? (PASS/FAIL)
Keyboard focus remains visible and moves predictably after actions are completed.
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.
Does keyboard focus move correctly through each step of the login process? (PASS/FAIL)
Keyboard focus moves correctly through each step of the login process.
Can users paste information such as passwords or verification codes into relevant fields? (PASS/FAIL)
Information such as passwords or verification codes can be pasted into relevant fields.
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.
I will ask you to add a series of simple steps that could be used to test our acceptance criteria.
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)
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: