Build keyboard-accessible call controls with the IllyVoIP SDK

Your custom IllyVoIP SDK dialer needs usable controls when someone cannot use a mouse or hear a ringtone. Build on native HTML buttons, clear labels and the SDK’s observed call state. Accessibility belongs to your application UI as well as its telephony connection.

Start with the official IllyVoIP Webphone SDK 1.4.2 bundle and one managed phone owner. Your backend must authorize the signed-in user’s SIP identity and issue the short-lived browser token. The examples extend your application; they do not change the hosted Portal phone.

1. Use native controls and explicit labels

<section aria-labelledby="phone-heading">
  <h2 id="phone-heading">Phone</h2>
  <button type="button" id="answer">Answer call</button>
  <button type="button" id="mute" aria-pressed="false">Mute microphone</button>
  <button type="button" id="end">End call</button>
  <p id="phone-status" role="status" aria-live="polite"></p>
</section>

Bind these elements to the selected call in your existing owner. Native buttons provide normal keyboard activation. Keep visible focus styles, adequate contrast and a logical tab order. An icon alone needs an accessible name; do not rely on green or red color to communicate the action.

2. Show only actions appropriate to the actual call

1. Enable Answer only for the intended incoming call.
2. Keep End tied to the captured call object or ID.
3. Update the mute pressed state from confirmed SDK state after the operation.
4. Disable competing submissions while an action is pending, then reconcile success or failure.

If a call ends while a button action is pending, reread the actual call state instead of applying a stale response to the next call. Do not optimistically announce “Muted” before the SDK action succeeds. A rejected action needs visible feedback as well as any spoken announcement.

3. Announce meaningful changes

Write short status updates into the live region: an incoming call is available, a call connected, an action failed or the call ended. Avoid announcing every timer tick or statistics sample. Show the same information visibly for people who do not use a screen reader.

Treat caller names and numbers as untrusted text. Do not inject them as HTML into an announcement. Respect privacy when the computer’s speakers can be heard by others; unnecessary customer details do not belong in repeated alerts.

4. Manage focus deliberately

1. Keep the user’s current work stable when an incoming call first appears.
2. Make the call controls reachable in a predictable location.
3. If you use a modal answer dialog, implement its focus and dismissal behavior consistently.
4. After a call or dialog closes, return focus to a sensible surviving control.

Do not add a global Enter or Space handler that can accidentally answer while the user types in a CRM field. Prefer explicit, discoverable shortcuts only when they do not conflict with browser or assistive-technology commands. A shortcut must not bypass the selected-call and authorization checks.

5. Test with the keyboard first

Use Tab and Shift+Tab to reach each control, then Enter and Space to activate buttons. Test incoming, connecting, active, held, failed and ended states using a mocked SDK. Check that pending actions cannot be submitted repeatedly and focus does not disappear into a removed element.

Then review with a screen reader and the target browser. Confirm names, toggle state and status messages are understandable without looking at the screen. Automated DOM checks help identify missing labels but do not establish a complete accessibility review. Finally arrange an authorized call to check the controls alongside real audio and microphone permissions.

Related guides

• Add browser calling with the Webphone SDK
• Add mute, hold, resume and keypad controls to an IllyVoIP browser phone
• Manage the IllyVoIP WebRTC Phone SDK lifecycle in React

Reference

Current instructions and technical reference: W3C: button interaction pattern, W3C: accessible status messages.

Reviewed 13 October 2026 against the current IllyVoIP controls, implementation and applicable references. Available options depend on account permissions and service state.