User stories

Elements of user stories

Essentially, user stories are short, simple descriptions to:

• capture what users need to do with our product or service
• help the team focus on each task
• generate a to-do list (product backlog).

User stories are always written from the perspective of the user(s), so they must include people with different access needs.

Writing inclusive user stories

One of the benefits of user stories is that they can be written at varying levels of detail. For example, a user story can be written to cover a larger, more general issue (this is called an ‘epic’), which then can be split into multiple smaller user stories before it’s worked on.

This same approach can be applied to accessibility considerations within user stories; start with larger epics such as:

• As someone who cannot see, I want to understand if this product is suitable for me, so I can choose to find out more about it.

This can then be broken down into multiple smaller user stories for the team to work on.

For example:

• As a screen reader user, I want to hear the text equivalent for the infographic, so that I don’t miss any information on the page.

Please note that the epic is deliberately not focused on a disability. It can be applied equally to someone who is permanently blind, as to someone who’s operating a screen in bright sunlight. This highlights the fact that accessible design applies to all – not just disabled users.

Acceptance criteria

We should also write acceptance criteria for each user story. These act as a checklist to prove the product or service is doing its job and meeting user needs.

The best acceptance criteria are specific and testable. They should also be revisited and refined as the project progresses and more is learnt. Their usual format is:

• It’s done when…

Accessibility-specific acceptance criteria

If we can see there is a high risk of introducing a barrier to accessibility we should add accessibility requirements to the acceptance criteria.

This ensures that when the story is marked as ‘done’, it’s ‘done’ for everyone in that specific situation.

It’s essential that these criteria are revisited as the product is iterated. That’s to avoid ‘accessibility regressions’, or breaking the accessibility as you go. Please note, if we have broken it, we’ll need to write more criteria to fix it!