Scenarios Framework

This page explains how we use scenarios inside GitHub’s accessibility program: how they’re defined, how they connect to audits and testing, and how they help teams ship better experiences for all developers.

What is a scenario?

A scenario is a short, plain‑language description of a task a user can complete on GitHub. It describes a single, focused moment in the user experience that we can design, test, track, and refine over time. The scenarios framework provides the rules and systems for identifying, documenting, and tracking these scenarios.

• Product‑specific: Describes what users can do in GitHub, not a generic pattern.
• UI‑agnostic: Describes the user’s task, not a specific screen or control.
• Task‑oriented: Represents a complete, meaningful flow from the user’s point of view.

Examples include:

• Sign in to GitHub as an existing member
• Create an issue in a repository
• Post a comment on an issue
• Add a member to an organization
• Filter the list of issues by project
• Approve a pull request
• Inspect the commit history of a repository

For accessibility, each scenario is something we can:

• audit end-to-end with assistive technologies
• connect to bugs, research, and user feedback
• use as a shared reference across product, design, and engineering
• track over time as features evolve or new interfaces ship
• compare across the platform to spot inconsistencies or gaps

How to use scenarios

• Prepare a list of scenarios and use it as a checklist of user tasks that need to be designed.
• Ask Copilot to suggest additional scenarios, including edge cases you might not have considered. GitHub staff can do this using the dedicated Copilot Space (Internal only).
• Check individual scenarios against Primer’s accessibility guidelines.
• For AI features, evaluate each scenario against the Copilot Accessibility Principles.
• Write end‑to‑end accessibility tests for each scenario, prioritizing core scenarios.