UK AI Accessibility: Assistive Technology That Fails Safely

AI can draft captions, describe an image, simplify a first version of text or help a person control a device. It cannot guarantee that content is accessible, translate every British Sign Language conversation accurately or navigate an unfamiliar building with centimetre-level certainty.

A missing medicine instruction, invented obstacle, wrong speaker or mistranslated consent question can remove access or cause harm. The goal is useful assistance with visible uncertainty, user control and a dependable route when the model fails.

This guide is current to 31 July 2026. The Equality Act 2010 applies in England, Scotland and Wales; Northern Ireland has separate disability-discrimination law. Public-sector digital accessibility rules have their own scope, while sector rules may add duties in health, education, transport, employment or communications. Confirm the service and jurisdiction; this is not legal advice.

Accessibility is a duty and an outcome

The government’s service-provider guidance explains that the Equality Act requires anticipatory reasonable adjustments: changes to practices, physical features, auxiliary aids and services where disabled people would otherwise face substantial disadvantage. A provider cannot discharge that duty by offering an AI feature that some people cannot use.

Northern Ireland is different. The Equality Commission for Northern Ireland explains protection against disability discrimination, including failures to make reasonable adjustments, under NI law. Products operating nationally need a jurisdiction map, not one generic “Equality Act compliant” flag.

Public-sector websites and apps in scope must also follow the accessibility regulations. Current GOV.UK guidance points to WCAG 2.2 AA and an accessibility statement. WCAG is a minimum technical framework, not proof that a specific assistive task works.

The W3C’s WCAG 2.2 Recommendation itself notes that even highest-level conformance cannot address every need. Test standards and real tasks with disabled people; do not use an automated scan or model-generated alt text as a compliance certificate.

Define the assistance and the fallback

For each feature, state who uses it, for what task, in what environment, with which input and latency, and what happens when confidence is low. Define prohibited contexts, such as using automated captions alone for a legal caution or replacing emergency signage with an experimental route.

Keep the fallback genuinely equivalent. “Call us” is not an alternative for a Deaf user if the line has no text relay or BSL route. A paper form is not equivalent if it cannot be obtained privately or on time.

Co-design before collecting training data

Disabled people are not one evaluation segment. Needs vary across sensory, physical, speech, cognitive, learning, neurological and fluctuating conditions, and many people use combinations of assistive technologies.

Pay participants for discovery, prototype and release testing. Include users who rely on screen readers, magnification, keyboard, switch, voice input, captions, hearing devices, BSL, easy read, augmentative and alternative communication, and personal assistance where relevant. Let participants choose access arrangements and avoid demanding medical proof that is unnecessary for research.

Co-design the failure experience:

• how confidence is conveyed without adding cognitive load;
• how to repeat, slow, correct or dismiss an output;
• how to reach a person;
• what information is safe to retain;
• which errors are merely annoying and which are dangerous; and
• whether the feature should work offline.

Do not average away blockers. Report task completion, time, errors, abandonment and support needed by access method and relevant context. A feature that helps most participants but prevents one supported screen reader from submitting a form is not ready for that advertised scope.

Maintain an accessibility decision log showing user evidence, trade-offs, unresolved exclusions, owner and review date. Avoid presenting disabled participants as endorsing a product beyond the features they tested.

Make captions and descriptions correctable

Caption performance changes with microphone, room acoustics, overlapping speech, vocabulary, accent, code-switching and speaker position. Overall word error rate can hide meaning-changing errors in names, numbers, negatives and clinical or legal terms.

Test those critical tokens separately. Show whether captions are automated; let users identify speakers, view the previous line and report a correction. For prerecorded public content, edit captions before publication and provide an accessible transcript when appropriate. Preserve human communication support where required.

Image descriptions need purpose. “A chart” is inadequate for someone trying to understand a result, while a long visual inventory may obstruct a button. The model should receive surrounding context and a bounded instruction, but the content owner must review informative images. Decorative images should remain ignored by assistive technology rather than receiving generated prose.

Never invent race, gender, emotion, disability or intent from appearance. Do not describe sensitive personal detail unless necessary for the user’s stated task. Let the user request more or less detail and reach the original source.

Treat BSL as language, not gesture substitution

The British Sign Language Act 2022 legally recognises BSL in England, Scotland and Wales, not Northern Ireland where equality law is devolved. The government’s fourth BSL report covers May 2025 to April 2026 and reports work to promote and facilitate BSL in public communications.

Recognition does not mean a camera can provide seamless two-way translation. BSL uses handshape, movement, location, facial expression, body movement, spatial reference and discourse context. Signers vary, and occlusion, framing, lighting and regional or personal language all affect input. Spoken or written English and BSL have different grammar.

Use AI for bounded support co-designed with Deaf BSL users: searchable approved phrases, draft timing, production assistance, interpreter preparation or low-risk practice. For public information, use qualified translation and review by BSL users. In health, legal, safeguarding, emergency or employment decisions, preserve an appropriate qualified interpreter or agreed communication support.

Label machine output and provide rapid repair. A wrong BSL output must not become the user’s consent, refusal or official statement without confirmation.

Do not overclaim indoor navigation

Indoor positioning can combine Bluetooth beacons, Wi-Fi, inertial sensors, visual landmarks and a mapped venue. Accuracy changes with phone, body position, crowding, moved furniture, signal reflections, camera access and map age. A location estimate is not proof that the next metre is obstacle-free.

Build an accessible route graph with surveyed entrances, lifts, ramps, widths, gradients, tactile features, accessible toilets, quiet areas, help points and temporary closures. Give every fact an owner and last-check time. Separate static accessibility information from live status and model inference.

Route instructions should expose uncertainty and allow confirmation at landmarks. Never direct a user into a road, platform edge, stairs or restricted area because the shortest-path model chose it. Integrate emergency procedures approved for the venue, but do not promise that consumer positioning works during an evacuation.

Evaluate complete journeys with intended mobility aids and assistance, at busy and quiet times. Measure safe arrival, wrong turns, interventions, unavailable lifts, battery and network loss, and hazardous instructions—not centimetres from a survey marker alone.

Protect disability, voice and image data

Assistive services may process speech, faces, gaze, gait, location, communication content and inferred health or disability information. Collect only what the current task requires. Define lawful basis, any special-category condition, processor, storage, training use, retention and deletion. Offer an alternative when camera or cloud processing is unnecessary.

The ICO’s current special-category guidance explains that facial, voice, gait and gaze data can become special-category biometric data when technically processed to uniquely identify someone. Do not create a reusable identity template merely to caption or navigate.

Complete a DPIA where processing is likely high risk, especially for systematic monitoring, biometrics, vulnerable people, data matching or decisions affecting access. Separate consent or choices for:

• performing the immediate assistive task;
• saving a personalised profile;
• sharing with a carer, employer or service;
• product analytics; and
• model improvement.

Refusing training must not remove necessary access. Encrypt data, minimise logs, restrict support access and test deletion across vendors and backups. For the broader framework, see AI and UK data-privacy compliance.

Secure the feature and preserve independence

An assistive tool can become a high-value attack path: microphone streams, camera feeds, communication histories, device controls and venue maps. Threat-model malicious audio or signs, prompt injection in documents, poisoned maps, account takeover, unsafe commands and compromised model updates.

Follow the NCSC’s secure AI development guidance: secure design, development, deployment, operation, logging, update management and incident response. Restrict commands to an allowlist with confirmation for consequential actions. Keep payments, locks, mobility devices and emergency controls behind independent safety protections.

Design graceful degradation. Download essential language packs or venue facts where appropriate, show offline status, retain native accessibility APIs and never trap the user behind a model error. Updates must not change keyboard order, labels, speech commands or personalised settings without regression testing.

For conversational escalation patterns, see AI customer-service and chatbot operations. An accessibility route must reach trained support without forcing the user to repeat information unnecessarily.

A measurable 90-day pilot

Days 1–30: select one task and user group; map GB or NI duties and sector risks; recruit paid disabled co-designers; define intended use, prohibited contexts, fallback, data flows, threat model and current non-AI baseline.

Days 31–60: test offline across access technologies and real conditions. Include noise, accents, low light, occlusion, poor network, moved obstacles, unknown signs, sensitive text, adversarial input, device loss and vendor outage. Fix the fallback before adding users.

Days 61–90: release to an opt-in cohort with direct support. Review harmful errors immediately, all corrections weekly and task evidence by access method. Publish known limitations in accessible formats.

Release only when:

• every critical journey works with the agreed keyboard, screen-reader, switch and zoom combinations;
• task-success floors pass for every declared user and environment slice;
• zero high-stakes caption, BSL or navigation output is treated as verified without required confirmation;
• hazardous instruction and meaning-changing error thresholds meet the pre-agreed limit;
• confidence, correction, human support and equivalent fallback are accessible;
• BSL content for public or high-impact use receives the defined qualified review;
• consent, access, deletion and vendor-training controls are demonstrated;
• loss of network, model or sensor leaves a safe, usable route;
• all critical security and native accessibility regressions are closed; and
• disabled pilot participants confirm that unresolved limitations are described accurately.

Pause after a harmful instruction, inaccessible update, false consent, privacy disclosure, material group disparity or missing fallback. Revalidate after model, device, map, language, workflow, vendor or accessibility-platform changes.

The practical verdict

AI can extend access when it supports a person’s chosen way of reading, communicating, navigating or controlling technology. It undermines access when an unreliable feature replaces a dependable adjustment.

Co-design the task, measure real use and build the failure route first. The best assistive AI is not the one that appears magical; it is the one users can understand, correct, refuse and safely live without when it stops working.