Skip to main content

Accessibility Bytes No. 15: Capture ICT Accessibility with Purpose-Built User Stories

Did you know that writing accessibility-focused user stories can help you build high-quality, Section 508-conformant products from the very start—without costly retrofits later?

User stories are a staple of agile development, but when they specifically address accessibility needs, they guide designers, developers, and testers toward creating ICT that works for everyone.

Hand of project manager writing on white board cycle of scrum iteration for team and scrum master.
Figure 1. Illustration of a scrum iteration on a whiteboard.

How to Write an Accessibility-Centered User Story

User stories define the “what” and “how” to address Section 508 conformance during design, development, and testing, and when writing backlog items.

Use this format:

As a [user type or user need],
I want [an goal, action or function],
so that [benefit or achievement].

Example 1: Keyboard User 

User Story: As a keyboard user, I want to be able to access and activate all interactive content such as form fields, buttons, and links so that I can successfully complete forms.

Acceptance Criteria: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user’s movement and not just the endpoints [WCAG SC 2.1.1]; There are no keyboard traps on the page [WCAG SC 2.1.2].

Example 2 : Color Vision Deficiency

User Story: As a user who relies on high contrast, I want to view text with sufficient contrast against backgrounds so I can read content easily.

Acceptance Criteria: All text meets contrast ratios of at least 4.5:1 for normal text and 3:1 for large text (text that is 14-point bold or larger, or 18 point or larger) [WCAG SC 1.4.3].

Why This Works

  • Integrates with workflow – Keeps accessibility in scope during design, coding, and testing.
  • Clear and testable – Specifies the “what,” “who,” and “why,” making accessibility measurable.
  • Prevents rework – Reduces last-minute fixes by including accessibility early.

Quick Steps to Get Started

  1. Identify a user need – For example, “user who relies on a screen reader.”
  2. Define the goal – What must they be able to do?
  3. State the benefit – Why does it matter?
  4. Add acceptance criteria – Link to WCAG or Section 508 standards.
  5. Include it in your backlog – Make it part of your agile process.
TIP: Embed accessibility conformance into your team’s “definition of done” so it’s always part of the finished product.

For more information on creating user stories for accessible ICT—including sample user stories for each disability type—visit Sample User Stories for Accessible ICT.

Reviewed/Updated: January 2026

Section508.gov

An official website of the General Services Administration

Looking for U.S. government information and services?
Visit USA.gov