Process

Accessibility in Agile and Scrum Workflows

By EZUD Published · Updated

Accessibility in Agile and Scrum Workflows

Agile development moves fast. Sprints are short, backlogs are long, and teams optimize for velocity. Accessibility can feel like friction in this system, but only when it is treated as an afterthought. When accessibility is woven into agile ceremonies and artifacts, it becomes part of the team’s rhythm rather than a disruption.

Accessibility in the Definition of Done

The single most impactful change an agile team can make is adding accessibility to the definition of done. If a story is not accessible, it is not done. This means:

  • The feature is keyboard navigable.
  • Screen reader announcements are correct and complete.
  • Color contrast meets WCAG 2.2 Level AA ratios.
  • Automated accessibility scans (axe-core, Pa11y) return zero critical violations.
  • Any applicable WCAG success criteria have been manually verified.

When accessibility is in the definition of done, it is no longer a separate workstream that competes with features. It is a quality attribute of every feature.

Backlog Refinement

During backlog refinement (grooming), the team examines upcoming stories and adds detail. This is where accessibility requirements should be specified:

  • Acceptance criteria. Add accessibility-specific acceptance criteria to each story. Example: “The date picker is operable with keyboard using the pattern described in the W3C ARIA Authoring Practices Guide.”
  • WCAG mapping. For complex features, note which WCAG 2.2 success criteria are relevant. This helps developers and testers know what to build and check.
  • Estimation. Include accessibility effort in story point estimates. Teams that exclude it consistently underestimate work and then skip accessibility under time pressure.

If your team uses an accessible design system, many components will already meet WCAG requirements, reducing per-story effort.

Sprint Planning

During sprint planning, ensure that:

  • Stories selected for the sprint have accessibility acceptance criteria defined.
  • If the sprint includes a new interactive pattern (modal, combobox, drag-and-drop), allocate time for implementing and testing the accessible version.
  • If the sprint includes accessibility remediation work from a previous audit or bug triage, size and prioritize those items alongside feature work.

Daily Standup

Accessibility does not need a separate standup, but it should surface in the regular one:

  • “I am implementing keyboard navigation for the filter panel and have a question about focus management.”
  • “I ran axe on the new dashboard and found three contrast issues. I will fix them this morning.”
  • “I need screen reader testing support for the notification component. Can someone pair with me?”

When accessibility is a normal part of standup conversation, it becomes a normal part of development.

Sprint Review and Demo

Include accessibility in sprint demos:

  • Demonstrate keyboard navigation of new features.
  • Show a screen reader interacting with new content or components.
  • Present before-and-after comparisons for remediation work.

This builds organizational awareness and gives stakeholders confidence that accessibility is progressing.

Retrospective

Ask accessibility-specific retro questions periodically:

  • Did any accessibility issues slip through to QA that should have been caught earlier?
  • Are acceptance criteria specific enough for accessibility requirements?
  • Do we need additional training or tools to improve our accessibility practice?

Handling Accessibility Bugs

Accessibility bugs should be triaged using the same severity system as other bugs, with additional consideration for user impact:

  • Critical: A user relying on assistive technology cannot complete a core task.
  • Major: A user can complete the task but with significant difficulty or confusion.
  • Minor: A best-practice violation that does not block task completion.

See accessibility bug triage and prioritization for a detailed framework.

Accessibility Stories vs. Embedded Accessibility

Some teams create dedicated “accessibility stories” (e.g., “Add ARIA labels to the search form”). This can work for remediation, but for new features, accessibility should be embedded in the feature story, not separated. Separating it signals that accessibility is optional and creates the risk that it will be deprioritized when time runs short.

The exception is large-scale remediation efforts following an audit or remediation plan, where dedicated stories help track progress.

Scaling Across Teams

In organizations with multiple scrum teams, consistency requires coordination:

Key Takeaways

  • Add accessibility to the definition of done so it ships with every feature.
  • Write accessibility acceptance criteria during backlog refinement, not after development.
  • Include accessibility effort in story point estimates.
  • Demo accessibility alongside features in sprint reviews.
  • Embed accessibility in feature stories for new work; use dedicated stories only for remediation.

Sources

More in Process

Inclusive Design Process Guide: Building Accessibility Into Every Stage Guide Continuous Accessibility Monitoring Accessibility in Design Reviews Nothing About Us Without Us: The Principle That Shapes Inclusive Design

View all Process articles →