Uxr Accessible Sessions

---
name: uxr-accessible-sessions
description: Plans research sessions disabled people and older users can take part in, with recruiting on purpose, access needs asked in advance, their own assistive technology, consent in accessible formats, session adjustments and an analysis note on not generalising. Use for "run uxr-accessible-sessions", "include disabled participants", "accessible research sessions", "screen reader users in testing", "access needs for participants", "research with older users", "no disabled person in the sessions", part of the UX Research with Claude Pack by Polar Bear.
---

# Accessible Research Session Plan

## When To Use
No disabled person has ever been in a session, and accessibility rules may apply to the product; which ones and how, check with a qualified adviser. Run this before recruiting for a study, so access is designed in rather than patched on the day. It answers: how do we reach disabled people and older users, what do we ask them in advance, and how do we change the session so they can take part as themselves?

## When Not To Use
This is not an accessibility audit and never certifies conformance; a conformance review needs a specialist. If the sessions are planned and you need the tasks and script, use Usability Test Plan, then adapt it with this plan.

## Inputs
- The research plan or recruitment brief, and the session format (remote, their place, a lab)
- The tasks or topics you plan to cover, and the consent form you use today
Anonymise first: replace names with P1, P2, remove contact details, employers and anything that identifies a person.
If you have none of this, I start from the study goal and the session format, and mark the output as a first draft.

## Approach
W3C Web Accessibility Initiative, Involving Users in Evaluating Web Accessibility, with the GOV.UK Service Manual page Running research sessions with disabled people. The judgment: people use their own assistive technology and settings, ideally where they normally use them, and one or two people never stand for all disabled people. The failure it prevents: a borrowed screen reader on a lab machine, a participant fighting unfamiliar settings, and a finding that says "screen reader users cannot do this" from one session.

## Workflow
1. Ask three questions: what session format is planned, which parts of the product or service the study covers, and who owns recruitment and consent.
2. Recruit on purpose: say in the brief that disabled people and people with limited digital skills are welcome, name channels that reach them, and aim for a spread of access needs (vision, hearing, motor, cognitive, older users). The user sets the numbers.
3. Ask access needs in advance, as an open question: format of materials, timing, breaks, interpreters or supporters, location, anything else that helps. Collect only what runs the session; never record a diagnosis.
4. Assistive technology: theirs, with their settings, at their place or remote on their own setup where possible. A lab setup is the fallback, never the default.
5. Consent in accessible formats: easy read, large print, screen reader friendly, verbal. Agree a supporter's or interpreter's role in advance, and that the participant still speaks for themselves. Who may consent on someone's behalf: check with your privacy lead or a qualified adviser.
6. Session adjustments: longer slots, fewer tasks, breaks, the moderator's pace, captions or sign language where needed. Pilot the setup before the first session.
7. Analysis note in every output: findings stated per person and need, never generalised to a group. Access needs are health data in many cases, which is special category data: check with your privacy lead or a qualified adviser.

## Output Format
```markdown
# Accessible Research Session Plan
**Study:** [name] | **Format:** [remote / their place / lab] | **Owner:** [role]
## Recruiting
| Access need spread | Channel | Owner | Wording in the brief |
|---|---|---|---|
| [vision / hearing / motor / cognitive / older users] | [channel] | [role] | [welcome line] |
## Access needs asked in advance
- [Open question text] | Stored under: [data handling plan reference]
## Per participant setup
| Participant | Assistive technology (theirs) | Location | Consent format | Supporter or interpreter | Adjustments |
|---|---|---|---|---|---|
| [P1] | [as told by P1] | [place] | [format] | [role agreed] | [breaks, length, pace] |
## Pilot
- [Date, setup tested, what changed]
## Analysis note
Findings are stated per person and need; [n] of [N] participants is never read as all disabled people.
## Decision
[Research lead] confirms recruitment channels and adjustments by [date]; for legal and consent questions, check with your privacy lead or a qualified adviser.
```

## Done When
- The brief welcomes disabled people and older users, with named channels
- Every participant has their own setup, consent format and adjustments recorded before the session
- The analysis note and the adviser check are in the output

## Quality Bar
- Access needs are asked openly and kept only to run the session, never as a diagnosis
- Their own assistive technology first; a lab setup is a stated fallback
- No statement of what any accessibility law requires; check with a qualified adviser
- Disabled people take part themselves; Claude never simulates how someone with a disability would use the product

## Next
Run uxr-usability-test-plan (Usability Test Plan) to adapt the tasks and script for these sessions.

## About the makers

This pack is made by Polar Bear, a consultancy built by ex-McKinsey founders with a dream to make AI work for People, not instead of them. We help our clients build people systems and AI-first ways of working, and we run our own company on Claude. If your team has outgrown the self-serve version, message Pauline (linkedin.com/in/paulinebertry).