Voice AI Accessibility: The Equality Act Duty You Owe

A vendor demo is a controlled performance. The caller speaks in full, clear sentences. They never stammer, never ask the agent to slow down, never hand the call to a Relay UK operator halfway through, never lose the thread and need the last question repeated. They are, in other words, nobody's grandmother, nobody with a stammer, nobody who is Deaf, nobody calling in their third language while holding a crying child. The demo caller is the median caller — and the median caller is the one customer your voice agent was always going to handle.

The callers who decide whether your deployment is lawful are the ones at the edges. In Great Britain, a service provider that deploys a voice agent which cannot accommodate a disabled caller is not merely delivering poor customer experience. It may be in breach of the Equality Act 2010 — and the part of that Act most teams have never read is the part that bites first: the duty to make reasonable adjustments is anticipatory. You are required to design for disabled callers in advance of them calling, not to wait for one to fail and then apologise.

This is the compliance obligation that almost no voice AI procurement process tests for. Teams run security review, data-protection review, and an FCA or ICO governance pass — and ship an agent that quietly excludes a slice of every caller base. This guide is the one that closes that gap: what the anticipatory duty actually requires, the seven design layers that satisfy it, how it bites differently by sector, and the audit trail that proves you met it.

This guide is shipped by the team behind Dilr Voice — enterprise voice AI built with the human route, pacing, and adjustment logic accessibility demands. Or see DATS, our five-stage AI methodology for placing voice agents inside regulated operations.

The 88% who deploy, the 6% who design for everyone

The macro numbers explain why this slips through. According to McKinsey's State of AI 2025, 88% of enterprises now use AI and 71% use generative AI weekly — but only 33% have it in production and just 6% capture material EBIT impact. BCG's Widening AI Value Gap (Sep 2025) found AI leaders earn 2.5× more EBIT than peers. The gap between adoption and value is, in regulated customer operations, partly an inclusion gap: an agent that works for the median caller and fails the edge is an agent that generates complaints, escalations, and remediation cost that erase the efficiency it was bought for.

There is also a "why now". From 28 June 2025, the European Accessibility Act (Directive (EU) 2019/882) became applicable across the EU. Among its nine in-scope categories are telephony services and related equipment, banking services, and e-commerce — which means a voice agent fielding calls for an EU-facing bank, telco, or online retailer is now operating inside an explicit accessibility regime, not a discretionary one. Combine that with the EU AI Act's Article 50 transparency duty — which requires callers be told they are speaking to an AI — and the obligation compounds: the disclosure itself must be delivered in a form a disabled caller can actually receive. Accessibility is no longer a UX nicety you get to fund later. In two of your largest markets it is now codified.

Accessibility is not vulnerability — and the difference is legal

Before the framework, one distinction that decides whether you target the right risk at all. Accessibility and vulnerability are routinely collapsed into one box in deployment documents. They are different obligations, with different triggers and different tests.

• Accessibility is grounded in the Equality Act 2010 and turns on a protected characteristic — disability. The trigger is structural: the caller is a disabled person, whether or not they are in any difficulty today. The test is the anticipatory reasonable-adjustments duty — did you design the service so a disabled person could use it as close to equally as possible?
• Vulnerability is grounded principally in FCA Consumer Duty (in financial services) and turns on a circumstance — a customer who, because of their situation, is at heightened risk of harm. The trigger is dynamic and may be temporary: bereavement, a health shock, financial distress. The test is a good-outcomes duty: did you recognise the vulnerability and respond?

The two overlap — a Deaf customer in financial distress is both — but they are not interchangeable, and the controls differ. Vulnerability detection is a runtime discipline: the agent listens for distress and confusion cues and escalates. Accessibility is a design-time discipline: the routes exist before anyone calls. This post is about the design-time duty. (Vulnerability detection and the Consumer Duty response are their own deployment problem, with their own escalation thresholds.) Conflating them is how teams build a clever distress-detector and still ship an agent a Deaf caller cannot use.

The legal spine, stated precisely

Compliance copy that gets the law slightly wrong is worse than none — so here it is exactly, for Great Britain:

• The Equality Act 2010 governs England, Scotland and Wales. Northern Ireland is not covered by it; disability discrimination there runs on the older Disability Discrimination Act 1995. If you serve NI callers, the duty exists — under a different statute. Say "Great Britain", not "UK-wide".
• A business serving the public is a service provider under the Act, and owes the reasonable-adjustments duty (sections 20 and 29, and Schedule 2). Crucially, for service providers this duty is anticipatory: you must take reasonable steps to anticipate the needs of disabled people in advance. You do not get to wait until a particular disabled caller is defeated by your agent and then react. A voice deployment with no built-in adjustment route is, on its face, a service designed without anticipating the people it will exclude.
• The duty has limbs that map cleanly onto voice: changing a provision, criterion or practice (e.g. an aggressive 3-second timeout that cuts off slower speakers) and providing an auxiliary aid or service (e.g. an accessible alternative channel). The standard is "reasonable", judged against size, resources, and the cost and practicability of the step — but "we didn't think about it" is never reasonable.
• Public bodies carry an extra weight: the Public Sector Equality Duty (section 149) requires them to have due regard to advancing equality of opportunity and eliminating discrimination. An NHS trust or a council deploying a voice agent must be able to show it considered disabled service users in the design — which is why public-sector voice AI deployments need the audit trail more than anyone.
• Enforcement runs two ways: the Equality and Human Rights Commission (EHRC) can act on systemic failures, and an individual can bring a services-discrimination claim in the county court. A pattern of excluded callers is the kind of systemic signal that draws attention.
• One caution on hype: the British Sign Language Act 2022 is real but narrow — it is a promotion and reporting duty on the UK government, not a service-provision mandate on private firms. Don't cite it as the reason your bank must support BSL; the reasonable-adjustments duty already does that work. And WCAG is a web accessibility standard. It is excellent design guidance and worth borrowing from, but it does not legally bind a voice channel — don't let a vendor wave a WCAG badge as if it discharged a telephony duty it never covered.

This is practitioner guidance, not legal advice. Equality law is fact-sensitive and the reasonableness standard is contextual — take advice on your specific deployment, caller base, and jurisdictions before go-live.

The seven-layer accessible voice AI stack

Accessibility in voice AI is not one feature. It is a stack of design decisions, each of which a disabled caller can fall through. Earlier layers gate later ones — there is no point tuning pacing (layer 04) if the caller could never get an input mode that works (layer 01). The three that teams skip most often are 01 (input modes), 03 (the human route), and 07 (the audit trail) — and those are exactly the three a claim or an EHRC enquiry will probe.

Layer 01 — Input modes: clear speech is an assumption, not a fact

Speech recognition tuned on clean, fluent audio is the single most common way a voice agent excludes disabled callers. A person who stammers, who has dysarthria after a stroke, who has a strong regional or non-native accent, or who is using a synthetic voice will be misheard, asked to repeat, and — if the agent is impatient — cut off. The fix is partly model quality and partly design: keep a DTMF keypad fallback alive for every critical step, never make voice the only way to proceed, and design the flow to survive a Relay UK call, where a relay assistant or text-relay device sits between caller and agent and the cadence is unusual. An agent that treats a relayed turn as a failed turn locks out Deaf and speech-impaired callers entirely. This is also where the multilingual design overlaps with accessibility — the same patience and confirmation logic that serves a non-native speaker on a multilingual voice deployment serves a caller with a speech difference.

Layer 03 — The human route is a legal right, not a containment leak

There is a tension at the heart of every voice AI business case: the metric the vendor sells on is containment — the share of calls fully handled without a human. Pushed too hard, containment becomes a wall. An accessible deployment treats the route to a human as a reasonable adjustment that must always be reachable, and resists the temptation to hide it to protect the containment number. The design question is not "can we deflect this caller?" but "is the human route discoverable and usable by someone who needs it?" That makes the human-handover pattern an accessibility control, not just an operational one — and it means you should read containment-rate benchmarks as a ceiling with an asterisk: the last few points of containment are often bought by making it harder for the callers least able to fight through.

Layer 04 — Pacing: the timeout that excludes

The interruption-and-timeout logic that governs conversational flow is, for a disabled caller, an accessibility setting in disguise. A caller with a cognitive impairment, a stammer, or simply the slower cadence of age needs more time to formulate a response, and needs the agent not to barge over them. An agent tuned for snappy, median-speed turns will repeatedly cut these callers off — which is precisely the kind of provision, criterion or practice the Equality Act expects you to adjust. The technical lever is the same one that governs conversation quality generally: how the system handles barge-in and interruptions. Set generous response windows, let callers take their time, and make "say that again" a first-class, always-available command.

Layer 05 — Disclosure the caller can actually receive

The EU AI Act's Article 50 requires that a person interacting with an AI system be informed they are doing so. For an accessible deployment, that disclosure cannot be a fast, jargon-laden sentence rattled off before the caller has settled. It must be clear, paced, and — where a caller needs it — repeatable. The Article 50 disclosure obligation and the EC's draft Article 50 guidelines set the what; accessibility sets the how it lands. The same principle applies to any consent you capture on the call: consent given by a caller who could not understand the disclosure is not meaningful consent.

Layer 07 — Evidence, because anticipatory duties are proven, not asserted

The anticipatory duty has a quiet implication most teams miss: because you must design adjustments in advance, you must be able to show that you did. When a complaint or an EHRC enquiry lands, "our agent is accessible" is worth nothing without a record. Log, per call where relevant, which adjustment was offered and whether it was honoured: was a human route requested and provided, was an alternative channel offered, was the disclosure repeated. This belongs in the same governance plumbing as the rest of your AI evidence — the auditability and explainability layer and the AI tool inventory that ICO, FCA and the EU AI Act all expect. Build the adjustments log as columns on the records you already keep, not a separate spreadsheet nobody maintains.

How the duty bites by sector

The reasonable-adjustments duty is universal, but the specific access obligation — and the regulator most likely to ask about it — changes by sector. The table below maps where the duty bites hardest and the deployment pattern that carries the detail.

Two of these deserve a flag. In healthcare and public services, the duty is heavier — the PSED requires due regard in the design, and the NHS Accessible Information Standard specifically requires that patients' communication needs are identified, recorded, and met. A voice agent that cannot honour a recorded communication need is not just inaccessible; it undercuts a standard the trust is already bound to. And in recruitment, an under-appreciated edge: a voice agent that screens candidates can discriminate against disabled applicants if it cannot accommodate a stammer or a relay call — turning an efficiency tool into a discrimination-claim surface. The pattern holds across every regulated-industry voice deployment: the duty is constant, the artefact that proves it differs.

How to make a voice deployment accessible before go-live

Accessibility is cheapest when it is designed in and most expensive when it is retrofitted after a complaint. Treat these as gating steps in the build, not a post-launch backlog. Run them in order — each depends on the one before.

Step 01 — Map your caller access profile. Before tuning a single prompt, characterise who actually calls you. What share are older callers, non-native speakers, likely to use Relay UK, likely to have a cognitive or speech difference? You will not get exact numbers — but a service that has never asked the question cannot claim it anticipated the answer. This profile is the evidence base for every "reasonable" judgement that follows, and it belongs in your pilot-to-scale program design from the first cohort.

Step 02 — Build the reasonable-adjustment routes. Stand up the three non-negotiables: multiple input modes (voice + DTMF), an always-reachable human route, and at least one equivalent alternative channel. These are layers 01, 03 and 06 of the stack. Wire them before you optimise anything, because they are the routes a disabled caller falls back to when the happy path fails. Make them a written requirement, too — accessibility belongs in the vendor evaluation buyers actually run and codified in the MSA your legal team signs, not left as an implicit hope.

Step 03 — Tune for pace and comprehension. Set response windows generously, make repetition and "slow down" first-class commands, write prompts in plain language, and confirm understanding on anything consequential. Resist the pressure to compress the call for cost-per-call at the expense of the callers who need the extra seconds.

Step 04 — Make disclosure and consent accessible. Deliver the Article 50 AI disclosure clearly and repeatably, and ensure any consent capture is understandable to a caller who is not a native speaker, not fast, and not familiar with your jargon. Accessible disclosure is a layer-05 control and a transparency control at once.

Step 05 — Test with disabled users, then log the evidence. Synthetic test calls will not surface what a real Deaf caller using Relay UK, or a caller who stammers, experiences. Include disabled users — lived experience, not personas — in pre-launch testing, and capture the findings. Then turn on the adjustments audit trail (layer 07) so that, from the first production call, you are accumulating proof. This is also a change-management discipline: the team has to believe the human route and the slower pace are features, not leaks.

What to measure

Accessibility that is never measured regresses the moment someone optimises the containment number. Track a small, honest set of access metrics alongside your standing programme KPIs:

• Human-route honour rate — of callers who asked for a person, what share reached one, and how fast.
• Relay / assisted-call completion rate — do calls routed through Relay UK complete at a rate comparable to direct calls, or do they fail disproportionately?
• Timeout / cut-off rate on slow-paced calls — a rising rate here is your agent excluding the callers who need the most time.
• Adjustment-request and complaint rate — requests for a different channel or format, and any access-related complaints, are leading indicators.
• Alternative-channel offer rate — what share of callers who hit a wall were offered an equivalent route rather than dropped.
• Audit completeness — the share of relevant calls where the adjustment offered and honoured was actually logged. An anticipatory duty you cannot evidence is a duty you cannot defend.

These belong in the same governance review as the rest of the programme — accessibility is a standing line in the enterprise voice AI governance framework, and a failure to honour a human route on a vulnerable call is exactly the kind of event your incident runbook should treat as serious, not cosmetic.

Building the procurement case for an accessible deployment? See Dilr Voice live (free, $20 credits), pressure-test a vendor with the accessibility questions a CFO's diligence should include, or read about our approach to placing AI inside regulated operations.

Frequently asked questions

Is accessibility the same thing as customer vulnerability?

No — and conflating them creates risk. Accessibility is grounded in the Equality Act 2010 and turns on disability, a protected characteristic; its test is the anticipatory reasonable-adjustments duty, a design-time obligation. Vulnerability (principally an FCA Consumer Duty concern) turns on a customer's circumstances, may be temporary, and is detected at runtime. A caller can be both, but the controls differ: vulnerability needs distress-and-confusion detection; accessibility needs routes that exist before anyone calls.

Does the Equality Act actually apply to an AI voice agent?

Yes. A business serving the public is a service provider under the Act and owes the reasonable-adjustments duty (s.20, s.29). For service providers that duty is anticipatory — you must design for disabled people's needs in advance, regardless of the channel. A voice agent is simply the channel through which the service is delivered; deploying one does not suspend the duty, and "the AI couldn't handle it" is not a defence. Note the Act covers Great Britain; Northern Ireland runs on the Disability Discrimination Act 1995.

Is "press 0 to speak to a human" enough to discharge the duty?

It is necessary but not sufficient. A human route only counts as a reasonable adjustment if it is discoverable and usable by the caller who needs it — clearly offered, reachable early, and not buried behind a wall of deflection designed to protect the containment metric. If a disabled caller has to fight through several rounds of an agent that keeps mishearing them before any human option surfaces, the route exists on paper but fails in practice.

Does the European Accessibility Act apply to our voice deployment?

If you provide services to consumers in the EU in one of its in-scope categories, very likely. The EAA became applicable on 28 June 2025 and covers nine categories including telephony services and related equipment, banking services, and e-commerce. A voice agent fielding calls for an EU-facing telco, bank, or online retailer sits inside that regime. It runs in parallel with — not instead of — the GB Equality Act for your British callers, so a multi-market deployment must satisfy both.

Can a voice agent serve a Deaf caller or a Relay UK call at all?

Yes, if it is designed for it. The agent must tolerate the unusual cadence of a relay-assisted call without treating relayed turns as failures, keep a DTMF keypad path alive, and — critically — offer an equivalent alternative channel (textphone, web, or callback) that delivers the same service rather than a degraded one. What the duty does not permit is an agent that simply breaks when the call does not sound like the demo.

Written by the Dilr.ai engineering team — practitioners who ship enterprise voice AI in regulated operations. This guide is practitioner insight, not legal advice; take advice on your specific obligations. Follow us on LinkedIn for shipping notes, or subscribe via the RSS feed.