EN 301 549 6.3 / 6.4 -- Caller ID and Alternatives to Voice

For reference only -- not part of a11ybot's automated checks.

What It Is

EN 301 549 v3.2.1 clause 6.3 Caller ID requires that where ICT provides caller identification or similar telecommunications functions, that identification is available in text form and is programmatically determinable, unless the function is closed[1]. Two conditions, both mandatory: a sighted user must be able to read the caller's identifier as text (not only hear it, not only see an avatar), and an assistive technology must be able to query it through the platform accessibility API. Clause 6.4 Alternatives to voice-based services applies where ICT offers real-time voice alongside voicemail, auto-attendant, or IVR: the system must provide a path to the same information and tasks that does not depend on hearing or speaking[1]. "Closed" in 6.3 means the hardware has no mechanism for assistive technology to connect at all -- a single-purpose intercom with a sealed firmware stack. A softphone, contact-centre client, or mobile dialer is not closed, and the exemption does not apply.

Why It Matters

The failure mode for 6.3 is a dialer that renders the caller's name into a bitmap, or draws it on a canvas, or announces it through TTS without exposing the string to the accessibility tree. A blind user running a screen reader hears silence on the incoming-call screen because the name node has no accessible name and no text content the platform can scrape. The failure mode for 6.4 is a voicemail product that stores audio recordings and offers no transcript, no visual voicemail feed, and no text relay path: a deaf user receives a notification that a message exists and has no mechanism to read it. Both failures are structural -- the product treats voice as the canonical channel and every other modality as a post-hoc accommodation that never gets built.

How It Relates to WCAG

WCAG 2.2 covers non-text content (1.1.1), name, role, value (4.1.2), and status messages (4.1.3), but none of those criteria require a telephony product to expose call state, caller identity, or a non-voice path to voicemail. EN 301 549 clause 6 is the layer that makes those requirements explicit for two-way voice communication ICT[1]. A dialer that passes every WCAG check on its settings screens can still fail 6.3 on its active-call screen and 6.4 on its voicemail inbox.

Practical Implications

  • Render caller identification as real text nodes in the accessibility tree, not as images or canvas draws. Use the platform's native labelling APIs (contentDescription on Android, accessibilityLabel on iOS, UIA_NamePropertyId on Windows) so screen readers can read the string without OCR.
  • Expose call state changes (ringing, connected, on hold, ended) as accessible name or live-region updates on the call screen so assistive technology announces them when they change.
  • For voicemail: deliver a visual voicemail feed with transcripts, and surface each message as a selectable item with duration, sender, and transcript text. Audio-only voicemail with no transcript does not satisfy 6.4.
  • For auto-attendant and IVR: provide a parallel path that does not require DTMF-plus-listening -- a web form, an SMS menu, or a text-relay-compatible entry point. The voice menu cannot be the only way through the system.
  • Test with the actual assistive technology on the target platform. Visual inspection of the call screen will not catch an accessibility-tree gap; only TalkBack, VoiceOver, or Narrator reading the live call UI will.

Related Clauses

Sources

  • ETSI EN 301 549 v3.2.1, clauses 6.3 and 6.4[1]