99% of the user stories I've read assume one kind of user. It's always someone using a mouse, seeing the screen clearly and moving through the product in the "normal" way.
Reality is different. People use products in ways you never planned for. Some will use a keyboard exclusively. Some use screen readers that read content aloud. Some have motor impairments and rely on switch controls. Some are on a phone in bright sunlight, squinting at low contrast text.
I always thought accessibility problems start out as wrong assumptions, not as broken design or code. If the user story only describes the happy path, the only way you could possibly ship something that works without excluding people is by sheer accident.
When you write accessibility into the user story itself, you force the person doing the work to think about those different ways people will use the product. Acceptance criteria turn accessibility from a vague goal into a built-in requirement.
Alright, enough theory! Let's instead work through an example.
Take this user story:
As a user, I want to filter products by category.
Technically, it's correct and I can even see how someone would design it, code it and test it. The task definition is complete and as long as you know what you're doing, you'll probably come up with a working solution.
But the user story has a critical flaw. It's missing the user's context. Who is the user? How are they going to use the new filters?
Here's the same user story re-written:
As a user who uses only keyboard navigation, I want to filter products by category using the Tab key and keyboard shortcuts so that I can browse efficiently without a mouse.
Alright, now there are some requirements in there, so design, development and QA all know what kind of interaction has to work.
But I don't think we've made it any better. Because now we have a different problem. What about users with a mouse? Or those with a screen reader or other assistive tech? Would you write a user story for each input method?
Absolutely not! The only thing you'll accomplish is cluttering up your backlog. That's how you make accessibility seem like extra work! The point is not "support every device as a separate story," but rather to make sure the feature works for the different ways people use it.
The best pattern is then to write the story around the goal, then add accessibility criteria that cover the interaction needs across methods. In our example, the story needs to describe filtering products and the acceptance criteria should say it must work with keyboard, screen reader, touch and mouse.
As a user, I want to filter products by category.
Acceptance criteria:
- The filter can be reached and operated with a keyboard.
- The current selection is announced by a screen reader.
- Focus remains visible and logical throughout the interaction.
- The feature works without requiring hover.
- The control is usable with touch and mouse.
This keeps the story readable while making accessibility testable.
Over the years, I tested different variations of how to write acceptance criteria that make sense, are easy to read and understand and give enough information without overwhelming. Here are the guidelines that I've settled on so far.
- Good acceptance criteria are specific. But not overly specific. There's no need to say the focus outline needs to be exactly 2px. Visible focus is enough. See the next guideline for an addendum.
- Good acceptance criteria are objectively verifiable. Bad: "Text is readable." Good: "Text contrast ratio is at least 4.5:1 for normal text."
- Good acceptance criteria describe outcomes, not solutions. Bad: "Use ARIA labels on buttons." Good: "Screen readers announce the purpose and current state of every button."
- Good acceptance criteria are based on real user needs. Work with documented user scenarios from people who use assistive technology. Don't guess! Ask!
If you're still writing "make sure it's accessible" into user story requirements, you're not gaining anything. No one can agree on what that means, so they can't execute. Acceptance criteria that fit these guidelines will solve that.
If you're new to this, don't try to write every story so that it covers everything at once. You'll just waste time racking your brain. Start by adding one accessibility angle to each new story. Then add two or three acceptance criteria that cover the most likely barriers.
That's enough to make accessibility visible without making the process heavy.