inclusive-user-stories
starsforks
How to install inclusive-user-stories?
owl-listener/inclusive-design-skills/inclusive-user-stories
$npx -y skills add Owl-Listener/inclusive-design-skills --skill inclusive-user-storiesWrite user stories that account for disability and diverse abilities from the start. Use when writing user stories, acceptance criteria, jobs to be done, or requirements. Triggers on: user story, user stories, acceptance criteria, jobs to be done, JTBD, requirements, as a user I
SKILL.md
| 1 | # Inclusive User Stories |
| 2 | |
| 3 | Write user stories where accessibility is part of the acceptance |
| 4 | criteria from the start — not added later as a separate ticket. |
| 5 | |
| 6 | ## The Problem |
| 7 | |
| 8 | Most user stories are written as: |
| 9 | "As a user, I want to filter search results so I can find what I need." |
| 10 | |
| 11 | This assumes a user who can see the filters, click small targets, |
| 12 | read the labels, and process the results visually. It silently |
| 13 | excludes anyone who interacts differently. |
| 14 | |
| 15 | ## The Fix |
| 16 | |
| 17 | Don't write separate "accessibility stories." Build inclusion into |
| 18 | every story's acceptance criteria. |
| 19 | |
| 20 | ## Story Structure |
| 21 | |
| 22 | ### The Story |
| 23 | Keep the standard format: |
| 24 | "As a [user], I want to [action] so that [outcome]." |
| 25 | |
| 26 | But be specific about the user when it matters: |
| 27 | - "As a keyboard-only user, I want to filter results using arrow |
| 28 | keys and Enter so that I can narrow my search without a mouse." |
| 29 | - "As a screen reader user, I want filter changes to be announced |
| 30 | so that I know the results have updated." |
| 31 | |
| 32 | ### Inclusive Acceptance Criteria |
| 33 | |
| 34 | For every user story, add these checks to the acceptance criteria: |
| 35 | |
| 36 | **Keyboard:** |
| 37 | - [ ] Feature is fully operable with keyboard alone |
| 38 | - [ ] Focus order is logical |
| 39 | - [ ] Focus is visible on every interactive element |
| 40 | |
| 41 | **Screen reader:** |
| 42 | - [ ] All controls have accessible names |
| 43 | - [ ] State changes are announced |
| 44 | - [ ] Dynamic content updates use aria-live |
| 45 | |
| 46 | **Visual:** |
| 47 | - [ ] Information is not conveyed by colour alone |
| 48 | - [ ] Text meets minimum contrast (4.5:1 for normal, 3:1 for large) |
| 49 | - [ ] Content is readable at 200% zoom |
| 50 | |
| 51 | **Motor:** |
| 52 | - [ ] Touch targets are at least 44×44px |
| 53 | - [ ] No time-dependent interactions without alternatives |
| 54 | - [ ] No precision-dependent interactions without alternatives |
| 55 | |
| 56 | **Cognitive:** |
| 57 | - [ ] Instructions are in plain language |
| 58 | - [ ] Error messages explain what to do, not just what went wrong |
| 59 | - [ ] User can undo or recover from mistakes |
| 60 | |
| 61 | ## Patterns for Common Stories |
| 62 | |
| 63 | ### "As a user, I want to complete a form" |
| 64 | Add: |
| 65 | - Labels are visible and associated with fields |
| 66 | - Required fields are indicated visually and programmatically |
| 67 | - Errors appear inline next to the field, not just in a banner |
| 68 | - Form can be completed with keyboard, touch, or voice |
| 69 | |
| 70 | ### "As a user, I want to view a dashboard" |
| 71 | Add: |
| 72 | - Data is not conveyed by colour alone (patterns, labels, values) |
| 73 | - Charts have text summaries |
| 74 | - Dashboard is navigable by keyboard with logical tab order |
| 75 | - Key metrics are announced to screen readers |
| 76 | |
| 77 | ### "As a user, I want to receive a notification" |
| 78 | Add: |
| 79 | - Notification is visual AND programmatically announced |
| 80 | - User can control notification preferences |
| 81 | - Notification does not disappear before it can be read |
| 82 | - Notification does not block other interactions |
| 83 | |
| 84 | ## How to Audit Existing Stories |
| 85 | |
| 86 | 1. Read each story and ask: who does this exclude? |
| 87 | 2. Check acceptance criteria for keyboard, screen reader, visual, |
| 88 | motor, and cognitive requirements |
| 89 | 3. Flag any story that assumes a single input method or sense |
| 90 | 4. Add missing criteria — don't create separate stories |
| 91 | |
| 92 | ## Assessment Questions |
| 93 | |
| 94 | 1. Do acceptance criteria include keyboard, screen reader, and |
| 95 | cognitive requirements? |
| 96 | 2. Are accessibility criteria part of the definition of done? |
| 97 | 3. Has each story been checked for assumptions about ability? |
| 98 | 4. Are there any stories that only work for one input method? |
People who liked this also viewed
6 picksType
- find-skillsHelps users discover and install agent skills when they ask questions like "how do I do X", "find a skill for X", "is there a skill that can...", or express interest in extending capabilities. This skSkillsJul 2026
- grill-meA relentless interview to sharpen a plan or design.SkillsJul 2026
- vercel-react-best-practicesVercel's official collection of agent skillsSkillsJul 2026
- improve-codebase-architectureScan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.SkillsJul 2026
- setup-matt-pocock-skillsConfigure this repo for the engineering skills — set up its issue tracker, triage label vocabulary, and domain doc layout. Run once before first use of the other engineering skills.SkillsJul 2026
- triageMove issues and external PRs through a state machine of triage roles — categorise, verify, grill if needed, and write agent-ready briefs.SkillsJul 2026
