Incorporating Accessibility in Your Agile User Stories

Like many organizations, New Editions has shifted to an Agile development methodology over the past few years. The business reasons are plentiful: quicker delivery and shorter release time for systems; greater collaboration and input among development team members and product owners; and earlier and more frequent review and feedback from clients and end users.

The Agile development methodology is not without its challenges. One major issue we and our clients have faced is ensuring accessibility throughout the process. Some of the key integration points for accessibility in Agile development include iterative testing, design and architecture, and incorporation of accessibility in the development team’s “definition of done.” However, as with development for any system, ensuring accessibility begins with requirements.

In most Agile development methodologies, requirements are created in the form of user stories. User stories represent written blueprints for a system that you are developing. They contain the essence of what needs to be accomplished from a particular system user type’s perspective. A user story follows a standard format:

As a [specific user type], I want [a goal] so that I can [achieve a specific benefit].

Each user story also includes acceptance criteria, which describe all of the elements that are required to satisfy the story or, in a sense, to make it true. You can find examples of user stories and acceptance criteria at tech.gsa.gov.

When creating user stories, it is important to consider accessibility and Section 508 compliance for your system users with disabilities. There are many ways to go about doing this, and you should consult with other members of your Agile team to determine which method is best for the team. Some methods you should consider include:

• Option 1 – Adding accessibility requirements to your acceptance criteria
• Option 2 – Creating specific stories for disability user types
• Option 3 – Creating broad stories for all users with disabilities

Using Option 1, if your user story references a save function, you may wish to consider adding accessibility requirements to your acceptance criteria, like the following:

User Story: As a [specific user type], I want a “save my work” function so that I can [achieve a specific benefit].

Acceptance Criteria:

• The save function (e.g., button) must be in a color that has high contrast with its background.
• The save function must have an accessible label.
• The save function must be focusable.
• The save function must be keyboard accessible.

Using the same example for Option 2, you may wish to consider adding accessibility requirements to your user-specific acceptance criteria, like the following:

User Story: As a blind user, I want to save my work so that I can [achieve a specific benefit].

Acceptance Criteria:

• The save function (e.g., button) must have an accessible label (e.g., using ‘label for=’, ‘aria-label=’, or other semantically appropriate programmatic association).

User Story: As a deaf user, I want to save my work so that I can [achieve a specific benefit].

Acceptance Criteria:

• If the save function provides audible indication of save status (e.g., audible warning on save error, audible confirmation of save), then the system must also provide a visual indication of the same status notification.

Using the same example for Option 3, you may wish to consider adding accessibility requirements to your user acceptance criteria, like the following:

User Story: As an individual with a disability, I want to be able to have an accessible experience on the system so I can fully take advantage of all features and functions.

Acceptance Criteria:

• Where content tab order affects understanding of the content, the programmatic tab order must match the visual tab order.
• All graphic elements must have alt text.
• All headings must be marked programmatically and in the correct hierarchy.

Regardless of which option you chose, the goal is to ensure accessibility requirements that are incorporated in your user stories and/or acceptance criteria, just as you would for any other requirements (functional, security, performance, external interface, etc.). For those of you who have developed systems in the past, as you are likely painfully aware, without properly documenting all of your system requirements, your end product will be deficient. Without documenting accessibility requirements properly, your systems will be non-compliant with Section 508, and more importantly, unusable/inaccessible to your system users with disabilities.

For more information on other ways to ensure accessibility throughout the Agile development process, read our Agile Accessibility presentation New Editions presented at the ICT Accessibility Testing Symposium, held Oct. 25-27, 2017 in Washington, DC. The presentation provides an overview of Agile development for IT accessibility practitioners, key integration points for accessibility within Agile, as well as some of the accessibility-related implications of Agile development versus more traditional waterfall development lifecycles.