How to test event accessibility with disabled attendees before opening

You've checked the venue, booked the access services and added an accessibility section to the ticket page. Then someone tries to book using their usual screen reader and can't work out which ticket includes the workshop. Or they reach the venue through the entrance you described, only to find the registration queue blocking the route.

These are problems you want to discover while you can still change the event. Invite disabled people who could realistically attend to try the important parts of the experience, pay them for their contribution, and assign someone to fix and retest each barrier. Start before ticket sales where possible, then check the physical setup again before opening the doors.

The useful question is whether someone can do what they came to do under the conditions you're providing. A conversation about whether your plans sound welcoming won't answer that. You need people trying real tasks, with their usual tools and support, while your team observes what works and where the arrangements fail.

This guide explains how to organise that work without turning participants into unpaid consultants or asking a small group to approve your whole event. We'll follow an invented paid conference through recruitment, booking tests, a venue rehearsal and the decisions that follow. The aim is a better event and an honest account of what you've checked.

Decide what you need to learn before recruiting anyone

Write the decisions down first. Perhaps you're choosing between two booking arrangements for companion tickets. Perhaps you need to know whether the proposed arrival route makes sense to a first-time visitor. Or you're unsure whether someone can follow a workshop while using captions and switching between the presentation and activity materials.

Each question needs a task and a point when you can still act on the answer. Finding that the registration instructions are confusing before launch gives you time to rewrite and test them. Discovering that a temporary structure creates a physical barrier may require a production change, supplier involvement and a different schedule. Don't book testing so late that a major finding becomes everybody's unwanted surprise.

Give the programme a named owner with access to the people who can approve changes. They don't need to solve every problem themselves. They do need to bring a booking issue to the platform team, a route issue to the venue and a staffing issue to the producer, then follow each one through. A list of comments with no decision-maker attached won't improve the experience.

Our fictional example is Canal Forum, a conference selling 300 paid admissions. It includes talks and a practical workshop in the same venue. The team wants to test whether prospective attendees can understand the offer, book, retrieve their tickets, reach the rooms and take part. These details are invented to explain the method, not taken from a customer event.

Canal Forum separates those questions into an early booking round and a later venue round. Some people could contribute to both if separately agreed and budgeted. The team leaves time after each round for changes and a further check. That time belongs in the production plan before invitations go out.

Ask the venue when you can access the rooms for this work and what that booking includes. You may need furniture, someone authorised to operate equipment and a venue contact present. A free hour in an empty room isn't equivalent to a rehearsal of the planned arrangement. Confirm any extra charges and access hours before inviting participants, so the session you described is the session you can deliver.

Combine participant testing with a proper accessibility review

Your team should fix obvious known problems before inviting people to encounter them. Check that the access information exists, the booking links work and the proposed test route is safe to use. Bring in an appropriately experienced specialist where you need technical or physical access expertise. Participants shouldn't have to spend their session proving that a door you've already identified as unusable is unusable.

The W3C Web Accessibility Initiative's guidance on involving users in accessibility evaluation recommends combining user involvement with standards evaluation. It also cautions against generalising one person's experience to other disabled people. Its guidance concerns the web; the same distinction is useful when planning your event tests. First-hand experience and a technical assessment answer different questions.

Someone can explain exactly where they lost their place in your checkout without being responsible for diagnosing the code. A specialist can investigate that issue and examine other pages for the same fault. Likewise, a participant can explain that a route is exhausting or hard to find while a competent venue adviser assesses the physical arrangement and possible changes.

Use the wider event accessibility checklist to organise the arrangements themselves. This testing programme adds evidence about using them. Keep both records available, because a working booking task doesn't establish that your venue arrangements are suitable, and a checked venue doesn't establish that somebody can buy a ticket.

Agree the limits of the work in plain words. You might be observing selected booking tasks with particular devices and reviewing an agreed route through a proposed layout. That is useful evidence. It isn't a certification covering every disability, every room or every future version of the event. Keep the description accurate when reporting to colleagues as well as when writing public copy.

Recruit people around the tasks and access needs

Start with the people who could use the event. A paid professional conference needs prospective attendees who understand why someone would book that programme. Their access requirements matter, and so do their familiarity with conferences, confidence using online services and reasons for attending. Recruiting only people who already know your team can hide the questions a new buyer would ask.

The UK Government's Service Manual recommends recruiting actual or likely users in its guide to finding research participants. It also discusses incentives and additional participation expenses. That is guidance for government service research, rather than a prescribed event recruitment scheme. For your event, use it to think through who needs to be involved and what taking part will cost them.

Make a simple recruitment brief. Describe the event, the activities you want people to try, the proposed dates and the contribution you're asking for. Explain which ways of using the service you want to understand. For example, booking with a screen reader, navigating without a mouse, reading enlarged text or following written instructions when processing a lot of information is difficult.

For the physical visit, consider the actual route, facilities and programme. You may need input about mobility, fatigue, hearing, vision or sensory conditions. People can have several access needs at once. A set of labels isn't a complete recruitment plan, and one participant shouldn't be asked to represent everyone who shares a label.

Canal Forum initially budgets for six adult participants, four in the booking round and two in the venue round. Six is an invented starting allocation, not a recommended universal sample or a promise that every important issue will be found. The team reviews which tasks and experiences that recruitment actually covers. If an important question remains untested, it records the gap and arranges further work rather than describing the group as representative of everybody.

Use appropriate recruitment partners when you need help, including organisations with relevant disabled members or experienced research recruiters. Ask what they will do, what they charge and how invitations will be shared. Don't ask an organisation to hand over its members' private details. Let interested people choose whether to contact you or agree to an introduction.

Pay for the contribution and make participation possible

Offer payment that reflects the work, and agree it before the session. Explain the amount, method and payment date in a format people can use. Don't substitute a ticket to the event unless that arrangement has been freely agreed and is suitable for the person. Someone helping you improve a commercial event shouldn't have to become your customer to receive something for their time.

Budget separately for what enables participation. Travel, communication support, a personal assistant or a different session format may be necessary. Ask what the person needs and agree the practical arrangements. A payment for research time doesn't automatically cover a taxi or an interpreter, and an invitation is of little use if somebody must pay those costs upfront without knowing when they'll be reimbursed.

Here is Canal Forum's fictional testing budget, entirely in USD. Six initial participant payments of $100 cost $600. The team allows $450 for agreed participation support and $180 for travel. Six staff hours running sessions and reviewing notes at $40 per hour add $240. The initial allowance is therefore $1,470. These are invented planning figures, not market rates or a recommendation about fair payment in your location.

The team also reserves a separate $300 for a focused retest, one booking session and one venue session. That consists of two participant payments of $60, $100 for support and two staff hours at $40. The combined testing allowance is $1,770. It assumes the stated amounts cover the relevant charges and makes no assumption about recovering tax. Quotes and participants' actual requirements would replace these allowances before approval.

This example assumes the venue makes the rehearsal space and planned equipment available without an additional hire charge. Recruitment is handled within the stated staff time. If either assumption is wrong for your event, add the missing cost before approving the budget. Support and travel are allowances to confirm, not reasons to refuse arrangements somebody needs because their quote exceeds your first estimate.

The cost of changing the event is separate. If testing reveals a booking problem, a staffing gap or an unsuitable route, someone still needs to approve and deliver the response. Don't spend the entire access budget collecting findings and leave nothing available to act on them. Our event accessibility budgeting guide explains how to plan provision while requirements are still developing.

Agree what happens if the event team cancels, a participant becomes unwell or a session stops early. Payment shouldn't depend on praise, successful task completion or tolerating discomfort. If the participant has questions about how the payment affects their own circumstances, give accurate payment details so they can obtain appropriate advice. Don't promise that a particular payment method has no consequences.

Make the invitation as usable as the event you want to test

Send the practical information early enough for someone to decide whether to participate. State who is organising the work, why you're doing it, what they'll be asked to try and which parts can be changed around their needs. Include the proposed duration, location or remote connection, payment and contact details. Ask how they prefer to communicate.

Your invitation can sound ordinary. For example, explain that you're preparing a paid conference and want to understand whether people can use its booking information and planned venue arrangements. Say that honest accounts of difficulties are useful and that you won't be assessing the participant's abilities. Describe the actual activities instead of asking them to help you make the event "fully inclusive".

Check the recruitment process itself. Can someone express interest without making a phone call? Can they read the information without opening a difficult attachment? Does the form ask for unnecessary medical history? You need enough information to arrange suitable tasks and support, not a detailed account of a person's health. Explain why you ask each question that might feel personal.

For a venue visit, share checked arrival information, the meeting point, toilet arrangements and what will happen if plans change. Ask whether transport or assistance needs agreeing beforehand. A participant should have a way to reach an actual person if they arrive and the expected entrance is closed. The same care applies when a remote session's joining link fails.

Confirm support directly with the person who will use it. Don't assume that booking an interpreter settles the session format or that a companion can answer every question for them. Ask about breaks, communication and whether there are activities they don't want to attempt. That conversation helps you plan a session they can use without putting them under pressure to explain everything twice.

Agree consent and keep personal information out of general production records

Before collecting research notes or recording anything, explain what information you want, why you want it and who will see it. Get the participant's informed agreement in a form they can understand and use. Being able to sign a printed form shouldn't be the condition for contributing. Prepare an appropriate accessible alternative and keep a record of the agreement.

The Service Manual's guidance on informed consent for research covers explaining the activities, observers, recordings, uses of the findings and withdrawal. Use those points when preparing your own information. Participation consent and the legal requirements for handling personal information need appropriate local review, especially if health information is involved. A generic form doesn't settle those responsibilities.

Separate permissions where the purposes differ. Someone may agree to notes but decline video. They may agree that a booking specialist can see a description of a problem with identifying details removed while declining use of their face or voice in a staff presentation. Research participation doesn't give you permission to publish a testimonial, add someone to marketing or use a recording in sponsor content.

Keep identifiable recruitment details in a restricted location. The production issue list normally needs the affected task, conditions, observed barrier and responsible owner. It doesn't need the participant's diagnosis or contact information. A participant code can help you match an observation to the relevant consent record without copying a name into every supplier conversation.

Set and communicate a retention plan, including how someone can contact you about their information. Decide who handles a withdrawal request and what they will do with the relevant notes or recordings. Avoid describing information as anonymous if your team can still identify the person from it. Restricting access and removing names are useful steps, but they don't make every detailed account anonymous.

Write tasks that reveal the experience

Ask people to do something meaningful. "Tell us whether this page is accessible" asks for a broad judgment and gives you little to investigate. "Find out whether this admission includes the practical workshop and explain what you would book" reveals whether the offer and controls make sense. Let the participant use the information available to an ordinary buyer.

Prepare a small set of tasks around the decisions you identified. For Canal Forum, the booking work includes understanding the programme, finding access information, selecting the relevant admission, asking an access question and retrieving a test ticket. The venue work includes reaching the meeting room, locating a suitable place to participate, following an activity and finding the way out after the session.

Write down what a completed task means before the session. Retrieving a ticket might mean finding the confirmation message, following the ticket link and locating the ticket that would be shown at the door. It doesn't mean the facilitator opens it on the participant's behalf and then asks whether it looks clear. Record support that was actually needed to get through the task.

Support is part of many people's ordinary experience. If someone usually books with a companion or uses communication assistance, agree how that will work in the session. Don't remove normal support to manufacture a test of independence. At the same time, distinguish that planned support from an extra hint supplied because your instructions or interface failed.

Avoid testing everything in one exhausting session. Choose a manageable set of questions, allow breaks and arrange another session if needed. The number of tasks completed isn't a measure of the participant's value. Finding one serious obstacle early can be a useful result, even when it means you stop the planned sequence and investigate the problem.

Prepare a session brief the team can follow

Write a short brief for each round. You can reuse the structure below, replacing the example details with your own. Keep participant contact details in the restricted recruitment record, rather than adding them to the copy shared with everyone observing. The facilitator needs the agreed support arrangements; a supplier investigating a ticket label usually doesn't.

For Canal Forum's booking round, the brief would say that the decision is whether the draft ticket offer and retrieval process are ready for launch. The participants are four prospective adult attendees recruited for the relevant ways of using the booking journey. Name the version of the draft event page, its connected booking steps and the test confirmation you'll use. The booking lead owns the round and can arrange changes before the on-sale decision.

The core task could read: "Imagine you want to attend the talks and practical workshop. Use this information to decide what you would book. Tell me when you're ready to continue." The facilitator then follows the agreed test purchase procedure and asks the participant to find the ticket they would present on arrival. Prepare those instructions in the format the participant needs. Reading them aloud is fine when agreed, but don't add the missing explanation you're trying to test.

Add the session's practical limits. Record its agreed duration and breaks, what can be recorded, who can observe and when to pause. Include a way to stop recording before private information appears. Name the person who can resolve a failed test connection or a problem with the payment arrangement. Rehearse these details with the team before participants spend their time on them.

The venue brief needs different material. It identifies the checked arrival directions, the proposed room plan and the activity being tried. It also identifies the venue contact who can stop the session if the route becomes unavailable. Record which furniture, signs and services will actually be present. If the workshop's final instructions aren't ready, list that as a separate task awaiting a later check.

Finish each brief with the decision date and the people who must review the findings. This makes the work useful to the production schedule. A booking lead can plan a change while a venue lead checks a room issue, and the producer can see whether either one threatens the planned launch. Don't leave that coordination until the participant sessions are finished.

Test booking with the tools people actually use

Ask participants to use their usual device and assistive technology where practical. Someone's screen reader, browser settings, magnification or keyboard setup may be carefully configured. Moving them onto an unfamiliar laptop can make the session about learning your equipment. Agree an alternative when their usual setup can't be used, and record that limitation.

The Service Manual's advice on running sessions with disabled people discusses using participants' own assistive technology, asking before helping and speaking directly to the person. Those are useful practical habits. Allow setup time, explain who's observing and check that the session itself works before starting the booking task.

Test the whole relevant journey. A clear event description doesn't help if ticket selection is confusing. A usable checkout doesn't help if the confirmation link is hard to identify or the access information disappears behind a login. Include the points where your website hands the buyer to a ticketing service, payment provider or email message, because that is still one purchase to the attendee.

With Loopyah's ticket checkout, buyers receive a confirmation email linking to their QR tickets. Include that actual confirmation-to-ticket step when checking your event's booking journey. The presence of the feature doesn't establish how your configured page and message work for a particular participant. Test what the buyer receives, including the information your own team added.

Agree a safe way to test payment with the relevant provider. Don't ask participants to expose card details on a recording, spend their own money unexpectedly or create real bookings that nobody will reconcile. Use an approved test arrangement where available. If part of the production journey can't be tested that way, document what you checked separately and what still needs verification.

Include recovery where it matters. What happens if a required field is missed, a payment doesn't complete or somebody returns later to find their ticket? You don't need to deliberately trigger every possible error in one session. Pick the relevant questions with your specialist and provider, and keep a record of any live-service limits that prevented a realistic check.

Rehearse the venue as attendees will encounter it

Start the venue task where the attendee's instructions start. If your guide says to use a particular drop-off point, begin there rather than meeting everyone inside the main hall. Ask the person to follow the published directions, with their agreed support and a safe session plan. Observe where the information stops matching what is in front of them.

Use the proposed event arrangement, not just an empty room. Registration desks, barriers, furniture and sponsor displays can change a route that worked during the sales visit. If the full setup isn't ready, mark the differences clearly and schedule a further check. A plan on a laptop can't establish whether a cable cover, doorway or queue will work in the finished space.

Canal Forum first checks its proposed furniture arrangement during a planned venue visit. Later, the production team checks the final setup before public entry. If changes affect an issue that required participant input, it arranges suitable further evaluation. The final visit isn't a licence to improvise access arrangements five minutes before doors; major questions need resolving while changes are still feasible.

Pay attention to the purpose of the room. Can the person follow the presentation from the intended position, use the workshop materials and reach a break space without losing the information needed to return? Test relevant communication arrangements together with the actual activity. A caption screen can be switched on while its position still makes following a demonstration difficult.

The W3C's guidance on making events accessible addresses accessible rooms, materials, communication and participation. For your rehearsal, use the event's real programme to choose what needs checking. A seated talk, a practical workshop and a discussion with audience questions place different demands on participants and the production team.

Keep the session safe. Don't ask participants to attempt a hazardous surface, force a difficult transfer or demonstrate an unassessed evacuation method. Work with the venue and competent advisers on emergency arrangements. You can discuss how information and assistance will be provided without making someone prove that they can escape a building under simulated pressure.

Facilitate without explaining every problem away

Tell participants you're testing the arrangements. They can pause, ask questions or stop. Check the agreed communication and breaks again at the start, because requirements can change. Introduce observers and their roles. A room full of silent staff can feel intimidating when the participant expected a conversation with one organiser.

Use neutral prompts. Ask what someone expects to happen next or what they are looking for. If they pause, allow time before jumping in with the correct button or direction. You can ask about what happened without treating every hesitation as a failure. Some people need more processing time, and some tools speak information at a pace unfamiliar to the observer.

When you help, make a note of it. Perhaps you explain a ticket label, reveal where an access link is hidden or point towards an unsigned door. Helping the session continue is reasonable. It changes what the observation tells you, so don't later report the task as completed using only the public information.

At Canal Forum, imagine the admissions are labelled "Forum" and "Forum Plus", with the workshop inclusion explained elsewhere on the page. A participant selects the first option when they want the workshop too. The facilitator initially wants to say that the distinction is obvious once you read the description. Instead, they ask what the participant understood each label to mean and where they looked for confirmation. The team can then investigate the wording and structure rather than defending the intention behind them.

Don't turn the session into a debate about whether the participant should have managed. If there is uncertainty about a technical cause, record the conditions and ask a specialist to investigate. The person may offer useful suggestions, but they aren't obliged to design the fix. Respectful curiosity will tell you more than a running explanation of why the problem shouldn't occur.

Record what happened so somebody can fix it

Keep observations separate from your interpretation. Write that the participant couldn't identify which ticket included the workshop and chose the other option after rereading both labels. Don't write that they were careless or that the booking system is completely unusable. Both jump beyond what you observed and make the next discussion harder.

The Service Manual's guidance on taking research notes and recordings recommends recording observations rather than personal interpretations. Apply that discipline to a short issue record. Include the task, the relevant page or physical location, the version tested and what support was provided. Record only the personal information needed to understand the barrier.

For each issue, capture enough to reproduce or investigate it:

• What the participant was trying to do and which information they had.

• The device, support or relevant venue condition used in that session.

• What happened, including any extra help that allowed the task to continue.

• The consequence for booking, arrival or participation.

• Who will investigate, when a decision is needed and how the response will be checked.

Canal Forum's booking issue becomes a specific record about two admission labels in the tested draft. Its venue issue records that the proposed registration queue crossed the agreed route into the workshop room. Those descriptions allow different owners to act. Neither needs a broad statement about the participant's competence or an invented estimate of how many customers would be affected.

Record what you couldn't test too. A workshop's final materials may not exist yet. A supplier may have provided only a demonstration version. The route may have been checked without the expected queue. Put those limits next to the findings so the next person doesn't interpret a blank box as successful completion.

Prioritise by consequence, then agree the actual change

Review the findings with the people who can deliver changes. Ask which barriers prevent a purchase or participation, which force an unsuitable workaround and which make a task unnecessarily difficult. Consider safety, dignity and access as well as operational effects. A problem raised by one person can require urgent action; frequency in a small group is a poor reason to dismiss it.

Don't compress all findings into one average satisfaction score. A participant can like the programme while being unable to enter a room. Another can complete every booking task while finding the instructions frustrating. Keep the task and consequence visible so enthusiasm about the event doesn't obscure an exclusion.

For Canal Forum, the producer assigns the ticket wording to the booking owner and the queue arrangement to the venue lead. The proposed labels become "Talks only" and "Talks and practical workshop", with consistent descriptions wherever buyers choose. The venue lead proposes moving the registration queue away from the room route. Each owner checks the proposal and sets a date for testing it. The team also records an unanswered question about the workshop's final instructions. That item stays open until the actual materials are available.

Check that a proposed fix doesn't create another problem. Moving a queue might obstruct a different route or separate someone from the person supporting them. Shortening a ticket label might remove the distinction another buyer needs. Ask the relevant specialist and affected staff to review the change, then test the important task again rather than assuming a tidier plan is a successful result.

Some issues need supplier work or a different event arrangement. Record the decision and its consequences while there is still time to act. If a serious barrier remains unresolved, escalate it before launch or opening and decide what must change. A note in an access guide doesn't by itself make an unsuitable arrangement acceptable or settle your obligations to attendees.

Retest the fix in the conditions that matter

An owner saying "done" means the change has been made. You still need evidence about whether it solves the problem. Repeat the affected task with the revised information or setup, keeping a record of what changed. Ask for appropriate participant involvement when the question depends on how someone uses the arrangement.

Invite the original participant back where useful and agreed, with a separate payment and support arrangement. They may recognise whether the original difficulty has been addressed. For a findability or comprehension task, consider another relevant participant too, because someone who already knows the answer may navigate the revision differently. Choose the retest around the question rather than insisting on one universal method.

Canal Forum checks the revised workshop labels in the actual booking sequence. It then checks the changed registration arrangement with the proposed furniture and staffing. If the venue visit still lacks a realistic queue, the record says so and the team plans a further operational check. The wording change and room change have different evidence requirements even though both began in the same testing programme.

Use clear issue states. An issue can be awaiting investigation, have a change ready for testing, be verified under stated conditions or remain unresolved. Keep the untested work visible. Don't mark everything complete because the producer accepted a supplier's proposal or because the retest budget has run out.

Tell contributors what happened, within the agreed communication and privacy arrangements. A short explanation of the change and any outstanding limits respects their contribution and gives them a chance to clarify a misunderstanding. It doesn't ask them to approve your event or take responsibility for the final decision. The organiser still owns that decision.

For example, imagine Canal Forum's booking retest finds that the revised labels let the participant select the intended admission without an extra explanation. The record names the revised page and the setup used. That supports closing the specific label issue under those conditions. It doesn't close an unrelated payment error or establish that every ticket option works with every device.

At the venue retest, suppose the revised queue leaves the agreed room route clear in the tested arrangement. The team records that outcome, then checks the layout again after installation. The unfinished workshop instructions remain open. That is a plausible result of useful testing: some problems resolved, an important gap still requiring work and no reason to describe the whole event as approved.

Use the evidence to make the launch decision

Before ticket sales, review the tested booking version, unresolved problems and the information buyers will receive. Before opening, review the actual venue setup and outstanding delivery questions. These are separate decisions. A successful early test doesn't cover a later change to the room, ticket offer or programme.

Keep the final record practical. Name what was tested, by whom in broad relevant terms, under which conditions, which barriers were found and which fixes were verified. List the remaining gaps and the person responsible for each. Store identifiable participant information separately. The producer should be able to understand the position without watching hours of recordings.

Write public information from verified arrangements. Our guide to event accessibility information before arrival explains how to describe routes, facilities, support and limitations. Use what you learned to make those descriptions accurate. Don't turn a participant session into a public claim that disabled attendees have endorsed the event.

Brief the people delivering the revised arrangements. Door staff need the current entrance and escalation instructions. The workshop team needs the actual participation method and materials. Whoever answers access questions needs to know which fixes are complete and which matters still require a conversation. Correcting a plan while leaving yesterday's instructions with staff can recreate the same barrier.

For your next event, start with the unresolved questions and the changes since the last checked version. Reuse useful tasks and recruitment relationships with permission, but confirm that the venue, programme and booking journey still match the evidence. Before committing to the on-sale date, open the issue list with the producer and agree who will verify each remaining barrier, and when.