An in-app agent is an accessibility feature, narrowly

Vendors describing an assistant as an accessibility feature usually mean it in the vaguest possible way, and disability advocates are right to be tired of it. So here is the narrow version, which is defensible, and then the boundaries of it, which matter more.

The claim, stated narrowly#

An in-app agent is one additional input path. It is not an accessibility strategy, it does not substitute for your screens working with a screen reader, and building one does not discharge any obligation you already had.

What is different about it is the layer it operates at. Every other input method is a way of driving your interface. An agent is a way of completing the task without driving it.

Who this is for, with real numbers#

The World Health Organization’s disability fact sheet, dated 7 March 2023, states that “an estimated 1.3 billion people experience significant disability. This represents 16% of the world’s population, or 1 in 6 of us.”

The figure people usually reach for instead is a claim that Apple says one in seven. It is not on Apple’s accessibility pages, so we are not repeating it.

For mobile specifically, WebAIM’s tenth Screen Reader User Survey, fielded in December 2023 and January 2024 with 1,539 valid responses, found that “91.3% of respondents report using a screen reader on a mobile device”. For this audience the phone is the primary computer, and the screen reader running on it is the primary interface.

That survey also names what gets in the way, and the top item is instructive: “CAPTCHA remains the most (by a notable margin) problematic item indicated by respondents.” Second is interactive elements like menus, tabs and dialogs not behaving as expected. Third is links or buttons that do not make sense.

Where mobile interfaces fail people today#

WebAIM’s other project, the WebAIM Million, automatically tested one million home pages in February 2026 and found that “95.9% of home pages had detected WCAG 2 failures”, at an average of 56.1 errors per page. Six categories account for most of it, and WebAIM note that “these most common errors have been the same for the last 7 years”.

Those are web numbers, and this post is about native apps, so the percentages do not transfer. What transfers is the shape of the problem. Every item on that list is a property that was supposed to be set per instance, by whoever built the page, and was not. Contrast, alt text, a label on a control.

This is the accessibility case for a fixed widget catalogue that has nothing to do with security. When an agent’s answer is drawn from twelve components your team built, contrast is tested once per component and then holds for every answer. When it is drawn from markup generated at request time, each of those properties is a fresh promise made by something that never read your accessibility review.

The criterion that changes the biometric argument#

Biometric confirmation is normally argued as a security measure with an accessibility cost. Under WCAG 2.2 the sign flips.

Success criterion 3.3.8, Accessible Authentication (Minimum), at Level AA, states that “a cognitive function test (such as remembering a password or solving a puzzle) is not required for any step in an authentication process” unless that step offers one of four exceptions: Alternative, Mechanism, Object Recognition, or Personal Content. A cognitive function test is defined as “a task that requires the user to remember, manipulate, or transcribe information”, with memorisation and transcription named explicitly.

Re-entering a password is memorisation. Typing a code from a text message is transcription. Both are cognitive function tests that then need an exception. A glance or a fingerprint is neither, and the understanding document names biometrics directly among the qualifying approaches.

So an agent that confirms a payment with a biometric prompt is doing better by this criterion than the same app’s ordinary checkout doing step-up authentication with an emailed code. Which actions actually deserve that prompt is a separate question, and the answer is fewer than you think.

Target size, focus and what a catalogue can guarantee#

WCAG 2.2’s success criterion 2.5.8 requires that pointer targets be “at least 24 by 24 CSS pixels”, with five named exceptions including spacing and inline targets.

Android’s guidance is more demanding and worth following. Google’s accessibility help documentation advises “making sure these elements have a width and height of at least 48dp”, and explains why in physical terms: “a touch target of 48x48dp results in a physical size of about 9mm, regardless of screen size. The recommended target size for touchscreen objects is 7-10mm.” Note the wording is advisory, unlike WCAG’s normative minimum.

Either way, it is a number you satisfy once per component. Twelve components, checked once, and every answer the agent ever gives inherits the result.

That list of suggested phrases is worth dwelling on, because it is the part teams leave out. An alternative input path only helps people who know it exists and know what it accepts. Voice interfaces without visible affordances ask the user to guess the vocabulary, which is its own cognitive load.

What an agent does not fix#

It does not fix your screens. A user who cannot navigate your transfer flow with a screen reader still cannot navigate it, and they will need to, because the agent will hand off to it.

It does not work for everyone who cannot use touch. Speech input assumes speech, which excludes people with certain speech disabilities and anyone in a context where speaking is not possible. Text input to the same agent covers some of that, which is a reason to build both rather than to build voice alone.

It is not universally available, and the platforms are candid about this in a way vendors often are not. Apple’s own documentation for Voice Control states that “Voice Control isn’t available in all countries or regions” and that “Voice Control uses the Siri speech recognition engine for U.S. English only”. If a platform feature that ships with the operating system carries that limitation, an assistant built on a speech vendor carries at least as much, and users outside the supported languages get nothing. Our own production deployment answers in Modern Standard Arabic as well as English, which is a real capability, and it is still a list of languages rather than all of them.

And it introduces a new failure mode: an agent that misunderstands has wasted a turn for someone for whom turns are expensive. Reliability is an accessibility property, and it is the one least often counted as such. A sighted user who gets a wrong answer glances at the screen and corrects in a second. A screen reader user listens to the whole wrong answer first, then corrects, then listens again. The cost of a miss is not symmetric across your users, which means a model that is right nine times out of ten is a materially different product depending on who is holding the phone.

There is a design consequence. Every widget the agent can draw needs to be readable aloud as a unit, which is a constraint on the catalogue itself rather than on the model. A chart is a good example: it is the most useful widget for a sighted user and close to the least useful read aloud, so it needs a text summary attached at the component level, once, rather than improvised per answer.

Testing with the tools people actually use#

Turn on VoiceOver and complete a task end to end with it, including the confirm step. Do the same with TalkBack, which Android’s accessibility principles describe as announcing “content through a synthesized voice” and performing actions “in response to user gestures”. Do the same with Switch Access, described there as highlighting interactive elements and letting someone control the device “using only one or two buttons”, because a linear scan exposes focus-order bugs nothing else finds.

Then do the part most teams skip: test the agent’s own output under a screen reader. Each widget kind needs a reading order and a label that makes sense read aloud, and a stat card that announces a number with no context is a failure that no automated check will catch.

Finally, test with the suggestion list hidden, to see whether anyone can discover what to say. And test a misunderstanding, because how an agent recovers matters more for someone who cannot easily fall back to tapping. Conversation design for the recovery path is the same skill whether or not accessibility is the reason you care. The broader case for building this way, and the curb-cut argument behind it, goes further than the narrow claim this post is willing to make.

Common questions#

Is a voice assistant an accessibility feature?#

It is an additional input path, which helps some people with some tasks. It is not an accessibility strategy and it does not substitute for your screens working with a screen reader, switch access and keyboard navigation. Claiming more than that is the thing disability advocates object to.

Does WCAG require voice input?#

No. WCAG 2.2 sets requirements about how interfaces behave rather than which input methods must exist. Its relevance here is that specific criteria, particularly 3.3.8 on accessible authentication and 2.5.8 on target size, are easier to satisfy when an agent’s output comes from a fixed set of components.

What is accessible authentication under WCAG 2.2?#

Success criterion 3.3.8 says a cognitive function test, meaning a task requiring the user to remember, manipulate or transcribe information, must not be required in authentication unless one of four exceptions applies. Biometrics fall under the Object Recognition exception, which makes a Face ID or fingerprint confirmation the accessible option rather than the burdensome one.

How do you test an in-app agent for accessibility?#

Complete a real task with VoiceOver, TalkBack and Switch Access, including the confirmation step. Then read the agent’s own widget output under a screen reader, checking that each widget kind has a sensible reading order and a label that works aloud. Then check that a first-time user can discover what to say.

Sources#

• World Health Organization, Disability and health, fact sheet dated 7 March 2023.
• WebAIM, Screen Reader User Survey #10, fielded December 2023 to January 2024, 1,539 valid responses.
• WebAIM, The WebAIM Million, February 2026 edition, one million home pages tested automatically.
• W3C, Understanding Success Criterion 3.3.8: Accessible Authentication (Minimum), WCAG 2.2.
• W3C, Understanding Success Criterion 2.5.8: Target Size (Minimum), WCAG 2.2.
• Google, Touch target size, Android Accessibility Help. Advisory guidance.
• Apple, Use Voice Control on your iPhone, iPad, or iPod touch.
• Android Developers, Accessibility principles. Page last updated 21 July 2026.