Venue Access Check Skill
"Is it accessible?" is the wrong question — venues answer yes to it reflexively, and
the disabled visitor discovers the truth at the door: the "accessible" entrance that's
a phone-call-and-wait around the back, the "step-free" route with one step, the toilet
that's an accessible sign on a cupboard. This skill replaces the yes/no with the
specific questions that surface reality, tailored to your needs, and teaches you to
read the answers — because how a venue answers ("let me check and send a photo" vs
"yeah should be fine") tells you as much as what they say. It's for personal go/no-go
decisions, not a formal WCAG-style audit (that's [[accessibility-audit]]).
What This Skill Produces
- A tailored question list: the specific things to confirm for this venue and
your needs — entrance and route, thresholds and widths, the accessible toilet's
reality, seating, lighting/noise, hearing loops, level changes, parking/drop-off
- How to read the answers: the reassuring-but-empty replies vs the credible ones,
and the follow-ups that catch the "should be fine"
- The photo/evidence ask: how to get pictures or a measurement rather than a
promise (the single most reliable move)
- A go / adapt / avoid verdict with the reasoning, plus what to arrange in advance
if it's a "go with adaptations"
Required Inputs
Ask for (if not already provided):
- The venue and what for (a meal, a meeting, an overnight, an appointment, an event)
- The specific access needs (wheelchair/mobility aid and transfer ability, sensory
needs, fatigue, service animal, dietary-medical) — the questions flex to these
- How much is at stake / how reversible (a casual coffee vs a booked event you can't
redo)
- Any info the venue has already given
Framework
- Translate the need into specific, checkable questions. "Accessible?" becomes
"Is there a step at the main entrance, and if so is there a genuinely step-free
alternative that's staffed at all times?", "What's the clear width of the toilet
door?", "Is the accessible toilet used for storage?" (a real and common problem).
Specific questions can't be waved away with a reflexive yes.
- Ask for evidence, not assurance. The reliability upgrade: request a photo of the
entrance/route/bathroom, or a measurement. A venue that sends one is credible; a
venue that can't or won't is a flag. This one move prevents most bad surprises.
- Read the answer's shape. "Let me physically check and get back to you" and
specific numbers signal a venue that understands access. "Yeah it should be fine" and
"we've never had complaints" signal a venue that doesn't — and "should be fine" has
failed more disabled visitors than any other phrase. Teach the follow-up that tests it.
- Verdict with adaptations. Go (confirmed workable), adapt (workable with
pre-arrangement — reserve the accessible table, arrange the staffed entrance, bring
the ramp), or avoid (the barrier is real and unfixable). For "adapt," list exactly
what to arrange and confirm before arriving.
- Have the day-of fallback. Even confirmed access fails sometimes; note the quick
check on arrival and the backup (a nearby alternative, the "this isn't as described"
line) so a bad answer at the door isn't the end of the plan.
Output Format
## Questions for this venue (ask these — get specifics)
[Entrance/route · thresholds & widths · the accessible toilet's reality · seating ·
sensory · parking/drop-off — tailored to your needs]
## Get evidence
[The photo/measurement ask — the single most reliable move]
## Reading their answers
[Credible signals vs the empty "should be fine" · the follow-up that tests it]
## Verdict: GO / ADAPT / AVOID
[The reasoning · if ADAPT, exactly what to arrange and confirm first]
## Day-of fallback
[Quick arrival check · the backup if it's not as described]
Quality Checks
Anti-Patterns
Related
[[accessible-travel-planner]] for the whole trip; [[accessibility-audit]] for a formal
digital/UI standards audit; [[accommodation-request]] when the venue is your workplace;
[[report-a-hazard]] if a public venue's access is unlawfully absent.
1---2name: venue-access-check3description: Check whether a specific venue — a restaurant, office, event space, Airbnb, clinic — will actually work for your access needs, before you commit, with the exact questions to ask and the red flags in the answers. Use when someone says 'will this place work for my wheelchair', 'check if this venue is accessible', 'questions to ask a venue about access', or 'is this restaurant/office actually accessible'. Produces a tailored question list, how to read the answers, and a go/adapt/avoid verdict. For personal access decisions; not a formal accessibility audit.4---5
6# Venue Access Check Skill
7
8"Is it accessible?" is the wrong question — venues answer yes to it reflexively, and
9the disabled visitor discovers the truth at the door: the "accessible" entrance that's
10a phone-call-and-wait around the back, the "step-free" route with one step, the toilet
11that's an accessible sign on a cupboard. This skill replaces the yes/no with the
12specific questions that surface reality, tailored to *your* needs, and teaches you to
13read the answers — because *how* a venue answers ("let me check and send a photo" vs
14"yeah should be fine") tells you as much as what they say. It's for personal go/no-go
15decisions, not a formal WCAG-style audit (that's [[accessibility-audit]]).
16
17## What This Skill Produces
18
19- A **tailored question list**: the specific things to confirm for *this* venue and
20 *your* needs — entrance and route, thresholds and widths, the accessible toilet's
21 reality, seating, lighting/noise, hearing loops, level changes, parking/drop-off
22- **How to read the answers**: the reassuring-but-empty replies vs the credible ones,
23 and the follow-ups that catch the "should be fine"
24- The **photo/evidence ask**: how to get pictures or a measurement rather than a
25 promise (the single most reliable move)
26- A **go / adapt / avoid verdict** with the reasoning, plus what to arrange in advance
27 if it's a "go with adaptations"
28
29## Required Inputs
30
31Ask for (if not already provided):
32- The venue and what for (a meal, a meeting, an overnight, an appointment, an event)
33- The specific access needs (wheelchair/mobility aid and transfer ability, sensory
34 needs, fatigue, service animal, dietary-medical) — the questions flex to these
35- How much is at stake / how reversible (a casual coffee vs a booked event you can't
36 redo)
37- Any info the venue has already given
38
39## Framework
40
411. **Translate the need into specific, checkable questions.** "Accessible?" becomes
42 "Is there a step at the main entrance, and if so is there a genuinely step-free
43 alternative that's staffed at all times?", "What's the clear width of the toilet
44 door?", "Is the accessible toilet used for storage?" (a real and common problem).
45 Specific questions can't be waved away with a reflexive yes.
462. **Ask for evidence, not assurance.** The reliability upgrade: request a photo of the
47 entrance/route/bathroom, or a measurement. A venue that sends one is credible; a
48 venue that can't or won't is a flag. This one move prevents most bad surprises.
493. **Read the answer's shape.** "Let me physically check and get back to you" and
50 specific numbers signal a venue that understands access. "Yeah it should be fine" and
51 "we've never had complaints" signal a venue that doesn't — and "should be fine" has
52 failed more disabled visitors than any other phrase. Teach the follow-up that tests it.
534. **Verdict with adaptations.** Go (confirmed workable), adapt (workable with
54 pre-arrangement — reserve the accessible table, arrange the staffed entrance, bring
55 the ramp), or avoid (the barrier is real and unfixable). For "adapt," list exactly
56 what to arrange and confirm before arriving.
575. **Have the day-of fallback.** Even confirmed access fails sometimes; note the quick
58 check on arrival and the backup (a nearby alternative, the "this isn't as described"
59 line) so a bad answer at the door isn't the end of the plan.
60
61## Output Format
62
63```
64## Questions for this venue (ask these — get specifics)
65[Entrance/route · thresholds & widths · the accessible toilet's reality · seating ·
66sensory · parking/drop-off — tailored to your needs]
67
68## Get evidence
69[The photo/measurement ask — the single most reliable move]
70
71## Reading their answers
72[Credible signals vs the empty "should be fine" · the follow-up that tests it]
73
74## Verdict: GO / ADAPT / AVOID
75[The reasoning · if ADAPT, exactly what to arrange and confirm first]
76
77## Day-of fallback
78[Quick arrival check · the backup if it's not as described]
79```
80
81## Quality Checks
82
83- [ ] Questions are specific and checkable, tailored to the user's actual needs — never
84 a bare "is it accessible?"
85- [ ] The photo/measurement evidence ask is included
86- [ ] The user is taught to read the *shape* of the answer, not just its content
87- [ ] The verdict is committed (go/adapt/avoid) with what to pre-arrange for "adapt"
88- [ ] A day-of fallback exists for when confirmed access fails anyway
89
90## Anti-Patterns
91
92- [ ] Do not accept "accessible" or "should be fine" as an answer — the whole skill
93 exists to get past that
94- [ ] Do not confuse this with a formal audit — it's a personal go/no-go; route to
95 [[accessibility-audit]] for a WCAG/standards review
96- [ ] Do not assume one disability's needs — the questions flex to this person
97- [ ] Do not skip the evidence ask — a promise is not access
98- [ ] Do not leave the user without a fallback for the door-step surprise
99
100## Related
101
102[[accessible-travel-planner]] for the whole trip; [[accessibility-audit]] for a formal
103digital/UI standards audit; [[accommodation-request]] when the venue is your workplace;
104[[report-a-hazard]] if a public venue's access is unlawfully absent.
Mohit Aggarwal