How to write user stories for accessibility
Posted on by Leon Hampson
A user story usually focuses on the value a software feature will deliver to an end-user, and an accessibility user story is no different. Whether you need to write an accessibility user story to fix issues found in an accessibility review, as part of a business case, or as part of your service delivery plan, there’s not much that you need to do differently.
Your end-user might have a persona that differs from some of your other user personas, have different needs, or interact differently from how other users interact with your product. Technical or QA requirements may be slightly different or more detailed than you might be used to providing, but the basic outline is the same:
- Start with the user persona
- Identify the desired outcome or the user’s goal
- Define the benefit or value to them
As you move on from the high-level acceptance criteria to refining the detail, you can then start identifying any requirement for specialist coding knowledge, for example, WAI-ARIA, or testing criteria needed to meet your Definition of Done. To do this you will need to understand how people with disabilities browsing with assistive technologies navigate and experience the web.
Remember, understand the feature from the perspective of the end-user and the benefits they will receive, just as you would with any user story.
Allocating time and resources to accessibility planning in your development lifecycle also benefits your business. As well as resulting in a more inclusive product, it can help avoid expensive mistakes which need to be remedied when accessibility is only considered after a feature has been released. This is especially true if accessibility standards haven't been met which might result in a legal case being brought forward.
Examples of accessibility user stories
Below are some examples of accessibility user stories you might find helpful. Each user story is a response to a particular issue but focuses on the user, their needs, and the benefit they gain from the feature.
Visible indication of keyboard focus
As a keyboard-only user, I want to know where I am on the screen so that I can perform an action or navigate to other areas of the site.
In this example, an accessibility review found that active links and buttons had no visible indication of keyboard focus. As a result, people browsing with a keyboard can find it difficult to navigate or use buttons when they don’t know which element has focus.
The following video shows how you can test visible focus as well as keyboard order.
British Sign Language (BSL) version of "Quick accessibility test: Keyboard support"
Text descriptions for images
As a screen reader user, I want to hear the text equivalent for each image button so that I will know what function it performs.
In this example, an accessibility review found that the icons on a mobile navigation menu had no accessible name or text description, making images inaccessible for people browsing with a mobile screen reader. As a result, screen reader users are unable to navigate using the menu as they didn’t know the purpose of the links.
Use of colour
As a user who is colour blind, I want links to be distinguishable on the page so that I can find the links and navigate the site.
In this example, the accessibility review found there were no underlines or borders for links so they are only identified by a colour change from the surrounding text. Colour-blind users and users with low vision can't access colour and meaning and can find it difficult to distinguish colour differences, especially if there isn’t a strong colour contrast between the text and the link. As a result, they will find it difficult to perceive the links.
Conclusion
In conclusion, accessibility user stories are just like any other user story and focus on the value and benefits a feature will provide to people who might use your product in different ways. Understanding how people will use your product or site using accessible personas makes it easier to understand how to bring those benefits to them, and to the business.
Further reading
- Stories of Web Users, by the Web Accessibility Initiative
- Creating accessibility personas, by UX Design
- Experience the web as personas with access needs, by the Government Digital Service
- Accessibility personas in detail, by Alice Crowther
- Why the Three-Part User Story Template Works So Well, by Mountain Goat Software
- Developing Accessible User Stories, by Accessibility.com
- Improving accessibility with accessibility acceptance criteria, by the Government Digital Service
Find out more about accessibility assessments at TetraLogical and how people with disabilities browse the web using assistive technologies.
Updated Thursday 2 March 2023.
Contact us
We like to listen. If you have a project, product, problem, or idea that you want to discuss, get in touch!
Comments