Electronic Communications Services and the EAA: What Telecoms Must Fix Beyond Emergency Calls
Most EAA coverage of telecoms stops at the emergency call. Real-time text to 112, total conversation, the equivalence duty - it's the most dramatic obligation, so it's the one that gets written up. But the European Accessibility Act does not name "emergency communications" as the in-scope category. It names electronic communications services[1]: the voice calls, SMS, and IP-based messaging a telecom sells every day, to every customer, for money.
That's a much bigger compliance surface than most operators have mapped. And 2026 is the year regulators started checking.
The scope nobody finishes reading
The EAA has applied since 28 June 2025, and electronic communications services sit in Annex I alongside e-commerce, banking, and transport. The obligation isn't limited to the network layer - it extends across the customer journey: how a person signs a contract, how they're billed, how they get help when something breaks, and how they communicate once the service is live.
Two enforcement bodies are worth naming directly. The Dutch Authority for Consumers and Markets (ACM) is actively supervising e-commerce and electronic communications services accessibility, and German regulators have confirmed audits are underway with more planned through the year. Neither is treating 2026 as a grace period - both describe this as the first full year of supervised enforcement.
What "beyond emergency calls" actually covers
Accessible contracts and billing. Terms of service, tariff information, and invoices are documents a deaf, blind, or cognitively disabled customer has the same legal right to understand as anyone else. If billing is only available as an unstructured PDF or a portal that fails basic screen-reader testing, the contract itself is inaccessible - not just the marketing site around it.
Real-time text and total conversation as everyday features, not emergency-only ones. RTT and total conversation get discussed almost exclusively in the context of the 112 duty. But the EAA's logic is broader: a deaf or speech-impaired customer needs equivalent means of ordinary communication - customer support calls, account changes, complaints - not just a lifeline reserved for emergencies. An operator that built RTT support only into its emergency-calling stack has built a narrower system than the law asks for.
Accessible customer support and complaints channels. Voice-only support lines with no text alternative, IVR trees that can't be navigated by keyboard-equivalent input, chat widgets that trap screen-reader focus - these are common failure points precisely because support tooling is bought from vendors and rarely audited for accessibility before rollout.
SIM and eSIM activation, and self-service portals. Activation flows, usage dashboards, and account-management portals are web or app products subject to the same EN 301 549 baseline as any other digital service: WCAG 2.1 AA today, with EN 301 549 v4.1.1 - expected to publish in 2026 and fold in WCAG 2.2 - likely to become the reference standard once it clears the EU Official Journal. Keyboard operability, screen-reader compatibility, and sufficient color contrast are not optional extras on a "just a portal" - they're the same legal floor that applies to the rest of the site.
Relay services and equivalent access. Where a hearing or speech-impaired customer cannot use standard voice calling, the operator needs a functionally equivalent path - text relay, video relay, or another mechanism that doesn't require the customer to route every interaction through a third party informally.
Why this keeps getting missed
Telecom accessibility programmes tend to organize around the two things everyone already knows are required: the 112 duty and WCAG-compliant marketing pages. Everything in between - billing systems, IVR, activation flows, complaint handling - is often owned by different teams, built on different vendor platforms, and never brought into the same accessibility review.
That gap is exactly where auditors are starting to look, because it's the gap between "we did the well-known thing" and "we did the whole thing."
A compliance checklist for operators and MVNOs
- Map every customer-facing communications channel - voice, SMS, IP messaging, chat, IVR - against the EAA's electronic communications services scope, not just the emergency-calling stack.
- Test contract, tariff, and billing documents for accessibility, not just the pages that link to them.
- Confirm RTT and total conversation are available as standing customer-support options, not features wired only into 112 dialing.
- Audit third-party support tooling (chat widgets, IVR platforms, ticketing portals) for keyboard operability and screen-reader compatibility - vendor accessibility claims are not a substitute for your own testing.
- Run self-service portals (activation, account management, usage dashboards) against EN 301 549 / WCAG 2.1 AA, and track the incoming v4.1.1 revision toward WCAG 2.2.
- Establish a relay or equivalent-access path for customers who cannot use standard voice calling for routine interactions, not only emergencies.
- Document all of the above - the EAA's enforcement pattern in 2026 is audit-led, and undocumented compliance is functionally identical to no compliance when a regulator asks.
The emergency-call duty will keep getting the attention, because it's dramatic and deadline-driven. But an ACM or German-regulator audit doesn't stop at 112. It asks whether the whole service - the one the customer pays for every month - is one they can actually use.
Related reading

Your Design System Is Your Accessibility Infrastructure: An Operating Model for 2026
95.9% of the web still fails WCAG. The bottleneck isn't detection - it's organisational capacity to act. A design system is the only place where one accessibility decision propagates everywhere.

Cookie Banner Accessibility: Why Your Vendor's Conformance Claim Doesn't Protect You
Your site may pass an audit and still block every keyboard user at the front door. The consent banner, chat widget, and payment iframe are someone else's code - but your legal liability.

Transport Accessibility Under the EAA: A Journey-Stage Compliance Guide for Operators and Travel-Tech Vendors
A practitioner's guide to EAA transport accessibility: what's in scope by mode and journey stage, the WCAG 2.2 failure modes that block passengers, and a prioritised remediation order for operators and travel-tech vendors.