# Event website usability session with disabled attendees

Copy this page for the study. Keep participant contact and any agreed recording consent in your approved research system, not in this shared worksheet. Replace example tasks and links with the actual event. Never ask a participant to make a real purchase or send a real request solely for a test.

## Study setup

| Field | Decision |
| --- | --- |
| Event and test page URL | |
| Journey boundary, including external checkout | |
| Study goal and tasks in scope | |
| Facilitator and observer | |
| Test account or sandbox confirmation path | |
| Participant contact and data-retention owner (reference only) | |
| Preferred device, browser, assistive technology and communication format | |
| Remote/in-person access arrangements and break/stop method | |
| Recording choice and compensation agreed (reference only) | |

## Neutral opening script

“We are testing this event website, not you. Please use it in the way you normally would. You may pause, ask for clarification, skip a task or stop. I may ask what you expected at a particular step. We will not make a real purchase or send a real attendee message today.”

## Task cards — adapt to the event

1. **Event essentials:** Starting from the invitation URL, find the event date, time zone and location. What information would you need before travelling?
2. **Arrival/access:** Find the route, entry or accessibility information you would use. If it is missing, show where you expected it.
3. **Registration:** Find a suitable registration or ticket option and progress to the safe test confirmation. Do not use a real payment method.
4. **Request help:** Find how to ask an organizer a question or request an accommodation, if that path exists. Do not submit a real attendee request unless the team has arranged a safe test route.

Do not coach a click path. Ask “What did you expect to happen?” only when useful. Let the participant use their chosen tools. Agree beforehand how a task can be paused or stopped.

## Observation log

| Participant code | Task | Device/browser/assistive technology context | What happened (observation) | Barrier or uncertainty | Workaround or help needed | Reached goal? | Suspected cause (separate hypothesis) | Owner | Fix/retest date |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| | | | | | | | | | |

## Handoff and report limits

- Record the tested URL, version, task, test environment and any external provider boundary for each issue.
- Group repeated barriers by attendee task, not by an assumed disability category.
- Mark the owner, next action and retest evidence. Offer a reliable alternative contact route for a blocked live journey.
- Report number and range of participants and the setup. Do not generalize a few observations to everyone or claim that these sessions replace technical accessibility evaluation.