Voice access should be a choice—with clear controls

An extra route, not a compulsory route

A learner may prefer to speak a question while walking, type it in a shared room, use a keyboard with assistive technology, or choose a different method when they are tired. A voice feature can offer another route into a task. It should not require the learner to announce private questions aloud, accept an inaccurate transcript, or abandon a familiar input method.

This matters because accessibility is not a single mode that can be switched on for everyone. The same person may need different interaction options in different circumstances. Instead of asking only 'does this app have voice?', ask what the person can choose, understand, correct, and stop. Those questions are useful for a purchasing conversation, a classroom trial, or an ordinary personal download.

What the standards help us notice

W3C's WCAG 2.2 guidance describes support for different input mechanisms and situations where users switch between them. Keyboard accessibility remains important; voice should not become the only way to complete an otherwise accessible task. W3C also cautions that its recommendations do not cover every individual need. A checklist is a starting point, not proof that a particular person will find a product usable.

The U.S. Department of Education's 2024 assistive-technology guidance notes that a learner's reluctance to use a tool can have different causes and should be understood rather than ignored. In an IDEA context, relevant decisions belong to the appropriate team. More broadly, the practical lesson for a product trial is to listen to the person, not assume that a feature label predicts their experience.

A five-question demonstration

First, ask how recording starts and stops. Try the interface without activating the microphone: is the control clearly named and reachable? Once recording begins, can the person tell that it is active? Can they cancel without submitting anything? Demonstrate with invented text, not a learner's private account or a real classroom conversation.

Second, check alternatives. Can the same task be completed by typing and by keyboard navigation? Can a user move from a spoken draft to typed editing without losing their work? Third, deliberately introduce a harmless transcription error. See whether the person can review and correct the text before it affects a message, assignment, or other consequential action.

Fourth, follow the information. Ask the provider what audio and transcript data are sent, where processing occurs, who can access it, how long it is retained, and what deletion means. Do not infer 'nothing is stored' from a clean screen or a reassuring icon. Fifth, test the failure: denied microphone permission, an interrupted connection, background noise, and an unsupported language. An intelligible fallback matters as much as a successful demonstration.

Keep privacy language precise

Not every voice feature identifies a speaker, and not every recording is a voiceprint. Conversely, a recording can still contain personal or sensitive information without being used for identification. The FTC's COPPA FAQ includes audio containing a child's voice within its discussion of personal information. Whether COPPA applies and which requirements follow depend on the service and circumstances; this is not a legal assessment of any particular deployment.

For an institutional evaluation, obtain the relevant written provider answers and have the authorized privacy and IT reviewers assess them. Record what is verified, what is promised in a contract, and what remains unanswered. Avoid the shortcut of advertising an entire product as legally compliant on the strength of one permission dialog.

Evaluate control, not novelty

A small trial can use a fictional task such as organizing a three-item study list. Invite participants to choose their input method, change it, correct a mistake, and cancel. Record the obstacles they describe, the steps that required help, and the changes they would request. Do not turn a small convenience test into a claim about learning outcomes or a diagnosis of the user.

We use this checklist as an editorial and product-evaluation principle for SASHA, not as a declaration that every control has passed on every device. Ask for a demonstration of the release you will actually use. The most useful voice feature is not necessarily the most dramatic one. It is the one that adds a workable option while leaving the learner in control of the task.