Phone accessibility
Accessible phone controls for keyboard and screen-reader users
Accessible phone control lets a person operate the call. Test the controls, status information, and input method together in the phone system they will use.
By Tenacity Updated
Separate operating a call from understanding its content
Some telephone barriers concern what a caller says. Others concern finding the right button, identifying a ringing line, reading call status, or completing a transfer. A caption display addresses spoken content; it does not necessarily make the phone’s controls accessible. Begin by listing which actions the user needs to perform and which are currently difficult.
Accessaphone is Tenacity’s accessible phone-control product for users with vision or mobility access needs. Cisco’s partner directory describes it separately from captioning and typed telephone products. That distinction helps an evaluator select the right demonstration and avoid buying a solution for a different barrier.
Evaluate the user’s actual input and display setup
Bring the phone-system version, computer operating system, screen reader and version, keyboard or alternative input method, headset, and required call controls to the compatibility review. Identify any drivers or phone-system interfaces the proposed installation needs. Obtain confirmation for that combination rather than extrapolating from an old installation guide.
Include the organization’s existing accessibility features in the comparison. A built-in phone or softphone feature may already perform part of the job. Focus the trial on the remaining gap and on whether the additional software works with the user’s normal settings, magnification, and work applications.
Walk through the call from start to finish
| Task | What the user should assess |
|---|---|
| Incoming call | Notice the call, identify relevant caller/line information, and answer using the preferred input method. |
| Outgoing call | Find or enter a number, start the call, and understand connection status. |
| During a call | Locate the active call, change the required controls, and know the current state. |
| Hold or transfer | Perform the needed steps, identify the destination, and confirm the result without losing context. |
| End and return to work | End the correct call and move back to the work application with predictable focus. |
These are evaluation tasks, not a promise that every call feature is supported in every configuration. Mark the functions the job actually requires, then have the supplier demonstrate those functions in the proposed environment.
With a screen reader, listen for meaningful labels, changes in call state, and a predictable navigation order. With a keyboard or alternative input device, look for visible focus, reachable controls, and a way to complete the task without relying on a pointer. Let the user set the pace and describe where the interaction becomes confusing or tiring.
Review the evidence and support path
Ask for the current installation guide and any applicable accessibility conformance report. Check that they describe the product and release being proposed. An older document can explain a historical setup without establishing support for a newer operating system or phone-system release.
Tenacity’s Accessaphone product page includes a product demonstration. Use it to understand the approach, then request a hands-on evaluation for the user’s own configuration.
Finish with a concise record of successful tasks, remaining limitations, the tested setup, and who provides support. Make sure the user can reach that support channel accessibly. If they also need speech captions or typed responses, document those as additional requirements and evaluate the corresponding products alongside phone control.
A test-drive request that names the phone system, assistive technology, and two or three important work tasks gives the evaluation a practical starting point.