Help us improve
Share bugs, ideas, or general feedback.
From inclusive-personas
Writes user stories with built-in accessibility acceptance criteria covering keyboard, screen reader, visual, motor, and cognitive needs.
npx claudepluginhub owl-listener/inclusive-design-skills --plugin inclusive-personasHow this skill is triggered — by the user, by Claude, or both
Slash command
/inclusive-personas:inclusive-user-storiesThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Write user stories where accessibility is part of the acceptance
Audits user stories for disability inclusion gaps and adds missing acceptance criteria for keyboard, screen reader, visual, motor, and cognitive accessibility.
Writes user stories with INVEST-compliant acceptance criteria in Given/When/Then format. Activates during product backlog grooming, sprint planning, or feature refinement.
Generates user stories via 3 C's and INVEST criteria with titles, descriptions, design links, and acceptance criteria. For feature breakdown into sprint-sized backlog items.
Share bugs, ideas, or general feedback.
Write user stories where accessibility is part of the acceptance criteria from the start — not added later as a separate ticket.
Most user stories are written as: "As a user, I want to filter search results so I can find what I need."
This assumes a user who can see the filters, click small targets, read the labels, and process the results visually. It silently excludes anyone who interacts differently.
Don't write separate "accessibility stories." Build inclusion into every story's acceptance criteria.
Keep the standard format: "As a [user], I want to [action] so that [outcome]."
But be specific about the user when it matters:
For every user story, add these checks to the acceptance criteria:
Keyboard:
Screen reader:
Visual:
Motor:
Cognitive:
Add:
Add:
Add: