Improve accessibility with user stories and acceptance criteria

On this page:


Overview

Accessibility should be considered as early in the design and development process as possible. User stories and acceptance criteria can be used in both design and development phases when creating digital products. Including accessibility in user stories and acceptance criteria keeps accessibility in focus at all stages of design and development.

Benefits

User stories from people with disabilities and people who use assistive technology:

  • Include accessibility in the acceptance criteria and "definition of done" for a project
  • Enhance quality control or quality assurance testing for accessibility
  • Help team members consider accessibility as they design and develop
  • Lead to a better, more usable product

User stories

A user story is a simple description of a feature told from the perspective of the user. User stories keep the focus on the users and user goals while also meeting business needs:

As a [specific user type], I want/need [desire], so that I can have [achieve specific benefit].

Job stories

A job story is an alternative format to a user story that may work better for some teams:

When [situation], I want to [motivation], so that I can [expected outcome].

Acceptance criteria

Acceptance criteria are the set of criteria that must be completed for a feature to be considered "done". User stories influence acceptance criteria.

There are two main ways of writing acceptance criteria: as a scenario or as a list.

The scenario format usually follows the pattern Given – When – Then.

Scenario: [situation]

Given I am [specific user type],
When [situation],
Then [expectation],
And [additional expectation].

Examples

There are two methods for including accessibility in your user stories and acceptance criteria:

  1. Create specific accessibility acceptance criteria (A11yAC) based on existing user stories that do not focus on disability
  2. Write a generic user story to cover a variety of disabilities

Example 1: Accessibility acceptance criteria based on existing user stories

Job story format

When search results are returned, I want to know how many results there are, so that I can change my search terms if needed.

A11yAC list for job story

  • Search, filters, and results can be navigated using keyboard only.
  • User is aware when results appear if using a screen reader.
  • User is aware of the number of results if using a screen reader.
  • User is aware when results appear if using screen magnification.
  • User is aware of the number of results if using screen magnification.
  • Text should have a contrast ratio of at least 4.5:1.

Example 2: User story for a specific disability

User story format

As a non-sighted screen reader user, I need informative images to include descriptive alt text, so that I have the same information as a sighted person.

A11yAC scenario for user story

A blind screen reader user can understand information in an informative image.

Given I am a blind screen reader user,
And I come across an image that provides visual users with information,
When I navigate to the image,
Then I hear the image role,
And I hear the alt text describing the image.

Example 3: Generic user story for a variety of disabilities

User story format

As a user with a disability, I need forms to be accessible, so that I can complete them accurately.

A11yAC list for user story

  • Form fields use an appropriate form element or input type.
  • Form fields include all appropriate states and properties.
  • Form fields have a visible label directly above the field.
  • Labels are connected to the field, such as with <label for=[id]> or through aria-labelledby.
  • Labels persist and stay visible when the field is focused and active.
  • Form field descriptions are connected to the field, such as with aria-describedby.
  • Form field descriptions, including formatting instructions, are not provided through placeholder text.
  • Required fields are indicated visually and through the code (such as with a required attribute).
  • Form fields have a vivid visual focus indicator.
  • Form fields use expected keyboard interactions.
  • Multiple errors are indicated in a list at the top of the form, including the number of errors.
  • Keyboard focus moves to a single field in error or to the list of errors if there are multiple errors.
  • Each form field in error has a visible in-line error message located immediately below the field.
  • In-line error messages are connected to the form field with aria-describedby.
  • Error messages clearly and concisely describe the error and suggest how to correct the error.
  • All form fields, labels, and error messages have a color contrast ratio of at least 4.5:1 against the background.

Best practices

Be flexible and consider prototyping or iterations when first using these tools. Choose a format and method that works for your team.

  • Write user stories and accessibility acceptance criteria for both the design and development phases of a project.
  • Include user stories and A11yACs for people who have multiple types of disabilities.

This is document biaw in the Knowledge Base.
Last modified on 2023-07-14 15:27:06.