Is It Accessible

Is it accessible?

Whether a place actually works for a disabled person is almost never on its website. Where accessibility data exists at all it is one flattened claim — "wheelchair accessible: yes" — that hides the detail deciding the trip: how many steps at the door, whether the accessible toilet is up a flight of stairs, whether the lift is working today, whether staff will write things down.

So people ring round venues before every outing. That phone work is unpaid, repetitive, and falls on the person with the least energy to spare. This skill does the ringing and brings back an answer you can act on.

What it is not: an inspection, an audit, or a legal determination. It records what staff said on the phone. Staff answer in good faith about buildings they did not design, and they are sometimes wrong. Treat the result as a much better starting point than a website, not as a guarantee.

When to use this skill

• Someone is planning a visit and needs to know whether a specific venue works for their specific needs.
• Someone has a shortlist of three or four venues and wants them ranked.
• A published accessibility claim needs checking against what staff say.

When not to use it

• To audit a venue for compliance, or to build a case against one. This asks questions; it does not assess anyone against a standard.
• To call a venue repeatedly. One call per venue per enquiry. A business rung three times by the same tool is a nuisance, and the answers will not improve.
• To call domestic or personal numbers. This is for businesses and public venues.
• Without the person's explicit go-ahead for this specific call.

Before you start

You need three things.

A profile. The needs that matter to this person, each marked must-have or nice-to-have. Copy assets/example-profile.json and edit it. Run node scripts/check_access.mjs --list-needs to see all 30 need ids and the question each one asks. Maximum 12 needs per profile — a call that runs past a dozen questions outlasts the patience of whoever picked up, and the later answers get terse and unreliable.

A phone number in E.164 format, starting with + and the country code: +15555550123. Country codes are never inferred from an area code or a place name. A number without a + is rejected, because guessing wrong means calling a stranger.

Explicit intent. Confirm with the person that they want this specific call placed to this specific venue. A profile on disk is not consent to dial.

For real calls you also need the CALL-E SDK and a key:

npm install @call-e/calle
export CALLE_API_KEY="…"    # dashboard.heycall-e.com/account/api-keys

Dry runs need neither — everything except --real runs on Node alone, with no dependencies installed. Never accept a key pasted into a chat, never print one, and never write one into a file.

Safety boundaries

Dry run is the default. Every invocation is a dry run against recorded answers unless --real is passed. A dry run opens no socket, spends no credit, and rings nobody. IIA_FORCE_DRY_RUN=1 overrides --real entirely, so a shared or demo environment can guarantee nothing dials out however the command is written.

Real calls are confirmed twice. The --real flag, then an interactive prompt showing the venues, the questions and the credit cost. --yes skips the prompt for scripted use — only pass it when the person has already agreed to this exact call. Without a TTY and without --yes, the script refuses rather than assuming.

Phone numbers are masked everywhere but the dial. Output shows +1555555****. Full numbers appear only in the request to CALL-E. Free text coming back from a call — summaries, notes, quotes — is scrubbed of any run of eight or more digits before it is printed or stored, because people read numbers aloud on the phone.

Nothing about the caller is disclosed. The call says only that a customer is planning a visit. Never the person's name, number, condition, or why they are asking. If the venue asks, that boundary holds.

The call is a question, never a demand. No obligation is implied and no law is cited. If the venue is busy, the call offers to ring back and lets them go. If they do not know an answer, that is recorded as unknown — a third push gets a made-up answer, which is worse than none.

No recurring schedules. One invocation, one round of calls. If someone wants repeat checks, create them explicitly and tell the person how to stop them.

To cancel: interrupt the process. In dry run nothing has happened. If a real call is already in flight, interrupting stops the wait but not the call — CALL-E finishes it. The call id is printed as soon as CALL-E accepts it, before the wait starts; rebuild the report from it later with --call call_… --profile alex.json rather than starting a new call.

Workflow

1. Establish the need and get explicit intent

Ask what the person needs, in their words. Map it onto need ids from --list-needs. Mark as must-have only what genuinely decides whether the visit can happen — everything else is nice-to-have, because a failed must-have sinks a venue outright.

Confirm the venue and the number with them before going further.

2. Write the profile

{
  "id": "alex",
  "label": "Wheelchair user, visiting with a companion",
  "needs": [
    { "id": "step-free-entry", "severity": "must-have" },
    { "id": "accessible-toilet", "severity": "must-have" },
    { "id": "step-free-to-table", "severity": "must-have", "note": "my chair is about 70cm wide" },
    { "id": "accessible-parking", "severity": "nice-to-have" }
  ],
  "language": "English",
  "notes": "Visiting on a weekday afternoon."
}

note is folded into the question so the venue is asked about the actual chair, not a generic one. notes gives the call context it can use if asked.

3. Dry run first — always

node scripts/check_access.mjs \
  --profile alex.json \
  --venue "Sample Cafe" \
  --phone +15555550123

This confirms the profile parses, the number is valid E.164, and the report renders — with nothing dialled. Do this every time before a real call. Vary --fixture to see how the awkward cases render: accessible, not-accessible, unsure, unevidenced-claim, hedged-claim, no-structured-result, voicemail, not-placed, not-placed-no-attempt.

4. Place the real call

CALLE_API_KEY=… node scripts/check_access.mjs \
  --profile alex.json \
  --venue "Sample Cafe" \
  --phone +15555550123 \
  --real

Confirm at the prompt. The script prints Call call_… accepted the moment CALL-E takes it, then waits. A call can take an hour or two, and the wait gives up after ten minutes unless you say otherwise (--wait 120); if it does, or if you stop it, nothing is lost — run

node scripts/check_access.mjs --call call_… --profile alex.json

to rebuild the report from the finished call. One GET, no dial, no credit, no prompt. Pass the profile the call was placed with: the report is built from the profile you hand it, so a different one shows unknown for needs the venue was never asked.

A single call task carries all recipients, so a shortlist is one batch:

CALLE_API_KEY=… node scripts/check_access.mjs \
  --profile alex.json \
  --venue "Cafe A" --phone +15555550123 \
  --venue "Cafe B" --phone +15555550142 \
  --real

5. Read the result honestly

Check the run status and verdict before reporting anything. A call that failed, went to voicemail, or was cut off can still carry a partially filled summary — verdict: "unverified" with an unverifiedReason means nothing was established, and saying otherwise is worse than saying nothing.

When a call fails, say which side failed. callFailure on the report is no-answer (the phone rang, nobody picked up), not-placed (the call never reached a phone) or unclassified (it is not possible to tell). Only the first is about the venue. Reporting "they did not answer" for a call the provider never placed tells someone a venue ignored them when a venue was never rung — and unlike a wrong verdict, nothing later in the conversation corrects it. Repeat unverifiedReason as it stands rather than summarising it into "they did not respond".

Report each finding with its quote. The quote is the evidence; without it there is only an assertion. Rank a low-confidence positive below a high-confidence negative — "they said yes but seemed to be guessing" is weaker than "they said no and were certain".

Always include the not-an-audit caveat when presenting results.