Quick answer: The European Accessibility Act (EAA) has applied to covered products and services since June 2025, and WCAG 2.2 plus EN 301 549 give it teeth for the messaging and voice journeys you procure. What to look for in a platform is not a certificate the vendor hands you, but per-channel controls that keep every journey usable when rich media or speech recognition fails: a complete plain-text fallback behind every rich card, a keypad equivalent for every speech menu, real-time text (RTT/TTY-TDD) on live calls, and an opt-out path that works from a keyboard and a keypad alike. This guide maps the regulation to the four WCAG principles, walks the five channels buyers deploy most (web chat widget, IVR, RCS, WhatsApp, AI voice agents), compares how each one degrades, and closes with the pre-launch checklist to run before any journey goes live.
The regulatory backdrop: EAA, WCAG 2.2, EN 301 549
Three texts stack here. The EAA is the directive: it sets accessibility requirements for covered products and services sold in the EU, and member-state law made it enforceable from June 2025. EN 301 549 is the European standard that says what accessibility requires of information and communication technology, and WCAG 2.2 is the technical baseline it incorporates for web and interactive surfaces.
Read together, they change what a procurement review asks of a communications platform. The question is no longer "do you have an accessibility statement?" but "show me, channel by channel, how a customer who cannot see the image, cannot speak to the menu, or cannot use a pointer completes the same journey."
Two things follow for buyers:
- Map your own obligations. Whether the EAA covers your service, and which parts of WCAG 2.2 or EN 301 549 apply to your audience, is a determination your organization makes, with counsel, per market. A platform vendor cannot make it for you, and a vendor badge does not substitute for it.
- Buy controls, not certificates. What a platform can give you is tenant-owned controls you configure per journey: plain-text fallbacks, DTMF equivalents for speech menus, RTT on live calls, quiet hours in the called party's timezone, and a recognized opt-out keyword set. The finished journey (your copy, your layout, your timing, your testing) remains yours. That division of responsibility is the honest posture to look for in any vendor, including Devotel Orbit, and it is the posture our accessibility documentation states explicitly.
The four WCAG principles, applied to messaging
WCAG 2.2 organizes accessibility under four principles. Applied to business messaging and voice, each one translates into concrete channel behavior:
- Perceivable. Every image that carries information in an RCS card needs alt text that says what a sighted reader would learn from it, and every rich message needs a plain-text equivalent for devices that cannot render it. Essential information never lives only in an image, a color, or an audio clip.
- Operable. Chat controls and unsubscribe actions must work from a keyboard, and every speech input in a voice menu needs a keypad equivalent. Some callers cannot speak, are in a loud environment, or use a relay service; speech recognition must never be the only path.
- Understandable. Replies in plain language, the next action stated first, predictable prompts, and a visible way to reach a human. A caller stuck in a loop with an agent that cannot help must see the exit.
- Robust. The preferred channel failing must not remove the only path to completion. Test the fallback as deliberately as the primary: the SMS behind the RCS card, the keypad behind the speech menu, the keyboard-only pass through the widget.
Channel by channel
Web chat widget
The widget is the surface where WCAG 2.2 applies most directly, because it is web content. The controls that matter: a keyboard focus order that matches the visual order with a visible focus indicator, buttons named by action ("Send", "Close conversation") rather than by icon, incoming messages announced through a polite live region instead of an interrupting assertive one, and contrast that never signals outbound versus inbound by color alone. The practical test is a keyboard-only pass followed by a current screen reader, on mobile and desktop.
IVR and voice menus
Voice menus fail accessibility in predictable ways, and the fixes are all authoring discipline plus one platform control. State the action before the digit ("For billing, press 1", not "Press 1 for billing") so a caller who missed the digit does not have to replay the whole prompt. Reserve a digit to repeat the menu, and do not hang up after a single timeout. Offer a keypad equivalent for every speech input, and tell callers up front when a human handoff is available, carrying context across the handoff so they never repeat themselves. The IVR and contact-center surfaces are where these menus get built, and the IVR product pages describe the menu tooling; the accessibility outcome still depends on how you author the prompts.
RCS rich cards
RCS is the channel where rich media and accessibility most often collide. Carousels, images, and suggestion chips render beautifully on capable devices, and not at all on others. Three authoring rules carry the accessibility load: write alt text for every image that carries information (say what the image shows, not "image"), keep card actions labeled with real destinations ("View order", "Track package") so screen readers announce a purpose instead of a bare "Button", and never embed essential text in an image. The alt text is yours to author; what the platform owes you is the transport when the card cannot render, covered below.
WhatsApp traffic runs on approved templates, which is an accessibility feature in disguise: structured, plain-language bodies with predictable shape. The discipline is to keep the body readable at a general reading level, lead with the next action, and carry any link as real text the recipient can hear announced and tap. When a media attachment fails or a device strips it, the text body must still state the facts and the next step on its own.
AI voice agents
An AI voice agent is an IVR a caller talks to, so it inherits every IVR rule and adds two of its own. Replies must stay in plain language with the next action in the first sentence, and the agent must match the recipient's language: a fallback to a language the caller does not read makes the journey inaccessible in practice. Keep the shape of answers predictable so assistive-technology users learn it, and always say when a human handoff exists and how to reach it.
Shipped controls to wire into your journeys
The controls below are the tenant-owned building blocks Devotel Orbit ships; how you combine them into an accessible journey is the work this guide's checklist closes with.
Real-time text on live calls (RTT / TTY-TDD)
Real-time text is the modern successor to the TTY/TDD channel: a deaf or hard-of-hearing caller exchanges typed text on a live call, character by character, alongside or instead of the audio. On Orbit it ships as RFC 4103 (T.140) real-time text carried on the same voice leg, and the guide covers the contact-center rollout end to end:
- Arm it per call, deliberately. RTT is off until something opts in: the agent flips the Real-time text (TTY) toggle in the softphone footer, an IVR or queue step patches the call's RTT config before an agent picks up, or the agent's first typed line auto-arms the channel. Per-call opt-in is the point; a contact center treats RTT as a conversation-level flag, not a blanket setting.
- Both directions, live. The caller's text arrives over an SSE stream as it is typed; the agent's outgoing frames carry
final: falsewhile typing andtrueon Enter, so each side sees the other mid-thought. - A bounded, replayable record. Frames are capped at a 2,000-character ceiling per frame, persisted per leg, and interleaved by call-relative timestamp into the post-call transcript, exportable through the same WebVTT/SRT/JSON path as every other transcript source. QA can replay exactly what the caller and agent exchanged.
The accessibility commitment for deaf and hard-of-hearing callers sits with each contact center; Orbit is the text-relay surface, not the mandate. The two rollout postures the guide names are arm-it-on-demand (the default: the channel opens when a caller is flagged as a text-relay user) and arm-it-up-front (a flagged accessibility lane opens the channel before the call lands on an agent).
RCS fallback transport and authored alt text
Split the RCS accessibility story cleanly in two. The alt text and the plain-text equivalent are content you author, per the practices above and in the accessibility documentation. The transport when a card cannot render is what the platform ships: RCS falls back to SMS through an org-level cross-channel fallback chain, and the fallback must carry the same facts and the same next action, not a truncated teaser. Two details matter for an accessibility review: the chain re-runs opt-out and do-not-contact screening when it lands on SMS, so a contact who opted out of SMS is suppressed rather than re-contacted by the fallback; and rich link actions require a plain HTTPS fallback_url, so a recipient whose device cannot open the deep link still reaches a working page. Configure the fallback once at the organization and every RCS send inherits it.
Keypad equivalents, quiet hours, predictable opt-out
Three smaller controls round out the set. Speech-based IVR gets a DTMF equivalent per menu decision, so the keypad is never a degraded afterthought. Quiet hours are configured in the called party's timezone rather than the sender's clock, because contacting someone in the middle of their night is an operability failure, not just a regulatory one. And opt-out stays reachable with assistive technology: a keyboard-operable unsubscribe action labeled in words, a recognized keyword set for SMS opt-out rather than invented words recipients will not guess, and a one-step confirmation in the same channel the person subscribed.
How each channel degrades when rich media or speech fails
The honest comparison for an accessibility review is not feature-versus-feature but failure-versus-failure: when the rich or spoken path breaks, what does the recipient still have?
| Channel | Most likely failure | Graceful path that must remain |
|---|---|---|
| Web chat widget | Widget blocked, or screen-reader-only navigation | Keyboard-only operation with visible focus; a phone or SMS alternative published beside the widget |
| IVR / voice menu | Speech recognition misses the caller | DTMF keypad equivalent for every menu decision; repeat-the-menu digit; human handoff with context |
| RCS rich card | Device or carrier cannot render rich media | Org-level fallback to SMS carrying the same facts and next action, with opt-out re-screening |
| Media stripped or attachment fails | Plain-text template body that states the facts and next step on its own | |
| AI voice agent | The model mishears or loops | Plain-language replies with next action first, visible handoff to a human, context carried across |
A channel whose failure mode removes the only path to completion is an accessibility defect, whatever its success mode looks like.
The pre-launch accessibility checklist
Run this before any messaging or voice journey ships, and re-run it on every major template or flow change:
- Focus order. Walk the chat widget and any landing page with keyboard only; focus order matches visual order and never traps.
- Contrast and color. Message bubbles and input text meet your minimum contrast ratio; state is never signaled by color alone.
- Live regions. Incoming chat messages announce politely; nothing interrupting fires assertively.
- Equivalents. Every image in a rich card has meaningful alt text; every rich message has a complete plain-text fallback; every speech menu has a DTMF equivalent; every deep link has a working
fallback_url. - Fallback paths. Send the journey on a device and carrier that falls back to SMS and confirm the fallback carries the same facts and the same next action.
- Voice input, both ways. Run the IVR with speech and with DTMF; confirm the repeat-menu digit works and a single timeout never ends the call.
- RTT drill. Arm real-time text on a live test call from the softphone and from the IVR path; exchange text both directions and replay the transcript afterward.
- Screen reader pass. Run chat and widget paths with a current screen reader on mobile and desktop; buttons announce actions, not icons.
- Opt-out. Opt out by keyboard and by keyword; the confirmation arrives in one step, in the same channel.
- Quiet hours. Preview a scheduled send against the recipient's timezone before the campaign approves it.
Orbit's role, and your responsibility
Devotel Orbit provides the tenant-owned controls this guide names: plain-text fallbacks, the RCS-to-SMS fallback chain, DTMF equivalents for speech menus, real-time text on live calls, quiet hours in the recipient's timezone, language detection for AI replies, and the recognized opt-out keyword set. What Orbit does not do is certify your finished journeys as accessible, and no vendor can. Your copy, layout, timing, focus order, and assistive-technology behavior are yours to build and to test, and whether the EAA, WCAG 2.2, EN 301 549, or another local requirement applies to your organization is a determination for your team with your counsel.
That division is the point of buying a platform with real controls: the regulation asks you to demonstrate accessible journeys, and the right platform hands you the levers, the fallback transports, and the transcript evidence, while you own the experience those levers produce. If you are mapping the EAA against your contact center today, the contact-center software overview, the IVR pages, and our trust and compliance resources are the right next stops, and the two docs pages this guide cites (accessibility in business messaging and real-time text on live voice calls) carry the configuration-level detail your launch review will need.