In agile development, user stories capture what a user does or needs to do with the website or application. These “stories” are the basis for defining the functions that the system must provide and concisely captures the who, what and why or of the requirement.
User Stories are written from the perspective of a customer and all audiences including people with disabilities should be included. These stories are not expected to be a full and complete set of requirements but rather they are a starting place for conversation and help shift the focus from writing about the requirements to talking about them. Including user stories from people with disabilities ensures that their requirements are considered.
Key Components of User Stories
- The user
- The outcome when interacting with the system
- The value this interaction
How to Write User Stories
User stories usually take on one of three different formats:
- As a <user role>, I want <goal/desire> so that <benefit>
- As a <user role>, I want <goal/desire>
- In order to <receive benefit> as a <role>, I want <goal/desire>
Examples of User Stories for Web Accessibility
Below are a few examples of some generic user stories. These should be customized for your product.
The keyboard-only user relies on the keyboard to navigate the website pages and activate elements on the page. This user does not use a mouse.
- As keyboard-only user, I want to be able to reach the main navigation links with a keyboard so that I can determine the different areas of the site.
- As keyboard-only user, I want the ability to reach all links (text or image), form controls and page functions, so that I can perform an action or navigate to the place I choose.
- As a keyboard-only user, I want the ability to use the enter key to open the selected link so that every link on a page is accessible using a keyboard as it would be with a left mouse click.
- As keyboard-only user, I want to know where I am on the screen at all times so that I know what I can do and how to do it.
Screen Reader User
A screen reader is a tool that produces an auditory version of the page for users who are blind or who have low-vision. Screen readers use the underlying code of the page to communicate page content, information about the type of elements on the page such as headings, form labels etc. so that these users can effectively use and interact with the website.
- As a screen reader user, I want to hear the text equivalent for each image conveying information so that I don’t miss any information on the page.
- 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.
- As a screen reader user, I want to understand know what each form label is for each form field so that I can effectively enter the correct information in the form.
- As a screen reader user, I want to know what the column and row headers for each table cell so that I can understand the meaning of the data.
User with Low-Vision
- As a user who has trouble reading due to low vision, I want to be able to make the text larger on the screen so that I can read it.
User with Color-blindness
- As a user who is color blind, I want to have access to information conveyed in color so that I do not miss anything and I understand the content.
- As a user who is color blind, I want to links to be distinguishable on the page so that I can find the links and navigate the site.
- As a user who is color blind, I want to know what fields are required so that I can fill out the form.
Hearing Impaired User
- As a user who is hearing-impaired, I want a transcript of the spoken audio so that I can have access to all information provided in audio clips.
- As a user who is hearing-impaired, I want to turn on video captions so that I can understand what is being said in videos.
These are just a few examples of how to include people with disabilities into your user stories. In the next post, we will discuss creating acceptance criteria for each of the user stories.