Inclusive Design Sprints: A Step-by-Step Framework

A design sprint compresses months of debate, prototyping, and testing into a structured timeframe, typically five days. An inclusive design sprint applies the same time-boxed intensity but centers disability and accessibility from the start. The result is a prototype that has been evaluated against the needs of the widest possible range of users before a single line of production code is written.

Why Standard Design Sprints Miss Accessibility

The original Google Ventures design sprint model focuses on speed: understand, sketch, decide, prototype, test. Accessibility is not mentioned. In practice, this means sprint teams recruit non-disabled testers, build prototypes that rely on mouse interaction and visual cues, and make decisions that create accessibility debt before the project has formally begun.

An inclusive design sprint corrects this by modifying participant selection, prototyping methods, and testing protocols.

Day 1: Understand

Activities

• Map the user journey with accessibility barriers explicitly marked. Where do screen reader users lose context? Where does keyboard focus get trapped? Where does cognitive complexity spike?
• Invite a subject matter expert from the disability community or an accessibility specialist to present the current state of barriers.
• Review relevant WCAG 2.2 success criteria for the product area being explored.
• Create a sprint question that includes accessibility. Example: “Can a first-time user who is blind complete account setup without sighted assistance?”

Inclusive additions

• Prepare inclusive personas before the sprint begins. Each persona should specify assistive technology and interaction patterns.
• Ensure the sprint room and materials are accessible: large print, digital copies, captioned video, wheelchair-accessible space.

Day 2: Sketch

Activities

• Each participant sketches solution concepts independently. This is standard sprint methodology.
• Add a constraint: each sketch must annotate how a screen reader user, a keyboard-only user, and a user with low vision would interact with the solution.
• Use accessibility annotation templates that call out heading structure, focus order, alt text, and ARIA roles.

Inclusive additions

• If a disabled participant is in the sprint, ensure they can sketch using their preferred tools (digital whiteboard, voice notes, dictation).
• Consider co-design principles to ensure disabled participants are creators, not just consultants.

Day 3: Decide

Activities

• The team reviews all sketches, votes on the strongest solutions, and creates a storyboard for the prototype.
• Apply an accessibility filter to each decision point: does this interaction pattern have a known accessibility implementation? Does it follow the W3C ARIA Authoring Practices Guide?
• If the chosen direction introduces a custom widget (carousel, drag-and-drop, date picker), identify the accessible implementation pattern before proceeding.

Day 4: Prototype

Activities

• Build a prototype that is testable with assistive technology. This is the hardest part and the most important.
• For web products, use semantic HTML in the prototype rather than flat images. Tools like Figma prototypes are not screen-reader testable, but coded prototypes in HTML/CSS are.
• If a fully coded prototype is not feasible, prepare a parallel walkthrough: a facilitator describes each screen to screen reader testers while they interact with a simplified accessible version.
• Ensure keyboard focus is managed throughout the prototype flow.

Inclusive additions

• Test the prototype internally with a screen reader before Day 5. Fix show-stopping navigation issues so that test participants can engage meaningfully with the concept, not just report that the prototype is broken.

Day 5: Test

Activities

• Test with five users, at least two of whom have disabilities and use assistive technology. Recruit participants in advance through organizations like Fable or AccessWorks (Knowbility).
• Observe how assistive technology users navigate the prototype. Where do they get lost? Where do they succeed easily? What workarounds do they invent?
• Document each barrier with its WCAG criterion, severity, and design implication.

Inclusive additions

• Compensate disabled testers fairly (see our guide on user testing with people with disabilities).
• Allow extra time for sessions with assistive technology users. Screen reader navigation takes longer in unfamiliar interfaces.
• Debrief with the full sprint team, highlighting accessibility findings alongside general usability findings.

After the Sprint

The sprint produces a tested prototype and a list of validated accessibility requirements. Feed these into your accessibility roadmap and your development team’s agile workflows. Document decisions in your accessibility documentation.

Facilitation Tips

Running an inclusive sprint requires thoughtful facilitation. Review our guide on inclusive design workshop facilitation for detailed advice on:

• Making activities accessible to participants with different abilities
• Managing group dynamics when lived experience and technical expertise are both in the room
• Adapting sprint exercises for remote and hybrid formats

Key Takeaways

• Standard design sprints ignore accessibility. Inclusive design sprints build it into every day.
• Recruit disabled participants for Day 5 testing, and ideally include disabled team members throughout.
• Prototype with semantic HTML when possible so assistive technology can interact with the prototype.
• Annotate sketches with accessibility information: heading order, focus management, ARIA roles.
• Feed sprint findings into roadmaps, backlogs, and agile workflows to sustain momentum.

Sources

• https://www.w3.org/WAI/ARIA/apd/ — W3C ARIA Authoring Practices Guide for evaluating accessible interaction patterns during sprint decisions
• https://makeitfable.com/ — Fable platform for recruiting disabled testers for Day 5 usability testing
• https://knowbility.org/programs/accessworks — AccessWorks by Knowbility, accessibility testing panel for sprint user testing
• https://www.w3.org/TR/WCAG22/ — WCAG 2.2 success criteria reviewed during Day 1 planning