Das Telekommunikations-Barrierefreiheitsregime 2026
Zwei Regulierungsbehörden, zwei Gesetze, eine Betriebsoberfläche.
In den Vereinigten Staaten erlegt der 21st Century Communications and Video Accessibility Act — der CVAA, kodifiziert in 47 U.S.C. § 617 — erweiterten Kommunikationsdiensten (ACS) spezifische Barrierefreiheitspflichten auf: VoIP, elektronische Nachrichten und interoperable Videokonferenzen. Diese Pflichten bestehen unabhängig von der allgemeineren ADA-Title-III-Pflicht, die für Websites öffentlich zugänglicher Einrichtungen gilt. Unser ADA-Title-III-Leitfaden beschreibt den übergeordneten Rahmen — der CVAA ist die telekommunikationsspezifische Ebene darüber.
Die FCC-Durchsetzung der Telekommunikationsbarrierefreiheit hat sich seit 2022 verschärft. Die Behörde hat Regeln zu Echtzeittext (RTT) und zur Migration weg vom veralteten TTY in IP-Netzen erlassen; zu Leistungsstandards für Video Relay Service (VRS) und Captioned Telephone Service (CTS); sowie zu Hörgerätkompatibilitätsbewertungen (HAC) für Handgeräte. Das Durchsetzungsbüro veröffentlicht Einvernehmensvereinbarungen, in denen Anbieter genannt werden, die bei der RTT-Interoperabilität oder der Einreichung von Barrierefreiheitserklärungen Mängel aufwiesen — diese sind öffentlich und werden von Klageanwälten gelesen.
In der Europäischen Union verpflichtet der European Accessibility Act Anbieter von zwei Seiten. Artikel 2(2)(b) nennt „elektronische Kommunikationsdienste" — Sprache, SMS, IP-basierte Nachrichten — als in den Anwendungsbereich fallend. Artikel 2(2)(c) umfasst „Verbraucherendgeräte mit interaktiver Computerfunktion" — Mobilgeräte, Router, Set-Top-Boxen — womit vom Anbieter gelieferte CPE und die zu deren Konfiguration genutzten Apps einbezogen werden. EN 301 549 ist der Konformitätsstandard und verweist für Web- und Mobiloberflächen auf WCAG 2.2 AA.
Und WCAG 2.2 AA selbst gilt weiterhin für jede kundenseitige Website und Mobile-App — Abrechnungsportal, Retail-Storefront, Support-Wissensdatenbank, native iOS- und Android-Apps. CVAA und EAA ersetzen WCAG nicht; sie legen telekommunikationsspezifische Pflichten auf eine Grundlage auf, die ohnehin zu erfüllen ist. Die folgende Checkliste ist um diese Überlagerung herum strukturiert: WCAG 2.2 AA in jeder Zeile, mit CVAA-/EAA-spezifischen Hinweisen dort, wo sie gelten.
30-Punkte-Checkliste WCAG 2.2 AA + CVAA für Telekommunikation
Sechs Bereiche × fünf Prüfpunkte. Ausdrucken, abhaken, auditieren.
-
01 Konto- & Serviceverwaltung
-
02 Abrechnung & Zahlungen
-
03 Kommunikationsdienste
-
04 Geräte- & Hardwarebestellung
-
05 Störungen & Support
-
06 Netzwerkfunktionen & Kontingente
Plattformhinweise — wichtige Telko-Anbieter
Wo die Checkliste im Code tatsächlich ansetzt — nach Anbieter-Stack.
Amdocs / CSG (Abrechnung & Kundenverwaltung)
Self-Care-Portale auf Basis von Amdocs CES und CSG Ascendon werden mit grundlegenden Standardeinstellungen ausgeliefert, erfahren jedoch umfangreiche Agenturanpassungen. Die wiederkehrenden Mängel sind die Rechnungsübersichtsseite (als positioniertes Div-Raster statt als semantische Tabelle gerendert) und der Plan-Wechsel-Assistent (Schritte ohne aria-current-Markierung, sodass Screenreader-Nutzer nicht erkennen, auf welchem Schritt sie sich befinden). Beides lässt sich in der Anpassungsschicht beheben, ohne Anbietercode anzufassen. Der Systemintegrator sollte einen VPAT-/EN-301-549-Konformitätsbericht für das konkrete Deployment liefern — nicht für das Standard-Produkt.
Salesforce Communications Cloud / Oracle Communications (CRM)
CRM-basierte Portale erben die zugrundeliegende Lightning- oder Redwood-Basis, die grundsätzlich brauchbar ist. Die Anpassungsschicht ist der Bereich, in dem Probleme entstehen — Lightning Web Components ohne aria-live-Region in Warenkorb- und Bestellverfolgungsansichten, benutzerdefinierte Apex-Seiten, die das Fokusmanagement der Plattform umgehen, und Community-Site-Themes, die den Fokusindikator überschreiben. Das Community-/Portal-Theme ist separat von der Plattform zu auditieren; jeder „Headless Salesforce"-Aufbau ist für Auditzwecke wie ein benutzerdefiniertes React-Storefront zu behandeln.
Cisco Webex · Microsoft Teams · Zoom Phone (UC-Plattformen)
Unified-Comms-Plattformen veröffentlichen eigene VPATs und haben erheblich in Untertitelung, ASL-Anheften und RTT-Unterstützung investiert — die tatsächlich zu auditierende Oberfläche ist das Einbettungselement. Anbieterbrandete Webex-/Teams-/Zoom-Apps umhüllen das Anbieter-SDK mit eigenem Chrome; und der Chrome ist der Ort, an dem Probleme auftreten: ein In-App-Wähler, der keine Gesprächsstatusänderungen meldet, eine Kontaktliste als Div-Raster, ein Präsenzindikator, der nur durch Farbe übermittelt wird. Die Barrierefreiheitserklärung des Anbieters deckt die zugrundeliegende Engine ab — der Wrapper ist separat zu auditieren.
Twilio · Vonage · RingCentral (CPaaS-UI-Besonderheiten)
CPaaS-Anbieter liefern Dashboards und einbettbare Komponenten unterschiedlicher Qualität. Die Dashboards selbst (Twilio Console, Vonage Dashboard, RingCentral Admin) sind generell solide. Die einbettbaren Elemente — Click-to-Call-Widgets, Video-Räume, Chat-Fenster-Snippets — sind der Bereich, in dem Anbieter und Integratoren am häufigsten scheitern. Jedes vom Anbieter bereitgestellte JS-Einbettungselement ist als DOM-Injektion eines Dritten zu behandeln: Es muss gegen dieselbe Checkliste auditiert werden wie der eigene Code, da es unter der eigenen Domain und der eigenen Haftung in die Seite gerendert wird.
Interne Anbieter-Apps (native iOS + Android)
Native Mobile ist der Bereich, in dem der EAA am schärfsten greift — Artikel 2(2)(c) umfasst die Apps zur Konfiguration von Verbraucherendgeräten, und die Regulierungsbehörden der Mitgliedstaaten auditieren aktiv die führenden Anbieter-Apps. Die wiederkehrenden Mängel sind unbeschriftete Icon-only-Buttons (kein contentDescription auf Android, kein accessibilityLabel auf iOS), benutzerdefinierte In-App-Modals ohne Fokus-Trapping und Onboarding-Karussells, die Folienwechsel nie ankündigen. Der Leitfaden zu nativen Mobile-Barrierefreiheits-APIs beschreibt die plattformspezifischen Muster — TalkBack, VoiceOver, Switch Control —, die das QA-Team auf echten Geräten, nicht nur im Simulator, testen muss.
Der Monitoring- + Audit-Zyklus
Eine einmalige Behebung überlebt keinen Anbieter-Release-Zug.
Anbieter-Estates ändern sich kontinuierlich. Das Marketing spielt dienstags einen Tarifbanner aus, das OSS/BSS-Team liefert donnerstags ein Abrechnungs-Engine-Update, und die nativen iOS/Android-Apps schneiden alle zwei Wochen ein Release. Eine einmalige Barrierefreiheitsbehebung hält ungefähr so lange wie das nächste Deployment — weshalb Telekommunikationsteams, die die Anforderungen dauerhaft einhalten, dies in drei Schichten tun, nicht in einer.
Zunächst empfiehlt sich, heute einen kostenlosen WCAG-2.2-Scanner gegen das Live-Kundenportal, den Abrechnungsprozess und die Störungskarte laufen zu lassen, um eine Ausgangsbasis zu ermitteln. Anschließend ist ein kontinuierliches automatisiertes Monitoring gegen jeden Preview-Build und jedes Produktions-Deployment einzurichten — das ist die Schicht, die Regressionen abfängt, bevor sie den Kunden erreichen (und bevor die FCC-Beschwerdewarteschlange es tut). Drittens ist mindestens jährlich und nach jeder größeren Replatformierung ein manuelles Audit durch Tester mit Behinderungen in Auftrag zu geben — ein Abrechnungssystemwechsel (Amdocs → CSG oder umgekehrt) ist das risikoreichste Ereignis und rechtfertigt ein manuelles Audit vor dem Launch, nicht danach.
Für den Übergang von Monitoring zum manuellen Audit im Besonderen behandelt unser Monitoring-Einkaufsleitfaden die Plattformen, die den Scan-to-Audit-Workflow Ende-zu-Ende abwickeln — Qualibooth, axe Monitor, Siteimprove und Level Access. Für Telekommunikationsunternehmen im Besonderen empfiehlt sich, die Wahl nach drei Kriterien zu gewichten: Integration mit dem CI/CD (die meisten Anbieter-Release-Züge laufen auf Jenkins oder GitLab CI, nicht auf GitHub Actions); ob das manuelle Auditor-Netzwerk der Plattform RTT-Nutzer und ASL-first-Nutzer einschließt — nicht alle tun das; und ob die Plattform sowohl Web- als auch Native-Mobile-Auditing unter einem Dashboard unterstützt, da Portal und App nicht auf getrennten Zyklen sein können.
FAQ
Die Fragen, die Anbieter-Teams stellen, bevor sie sich committen.
Was ist der CVAA, und wie verhält er sich zur ADA?
Der 21st Century Communications and Video Accessibility Act (CVAA, 47 U.S.C. § 617) ist ein telekommunikationsspezifisches Bundesgesetz, das von der FCC durchgesetzt wird. Er gilt für erweiterte Kommunikationsdienste (ACS) — VoIP, elektronische Nachrichten, interoperable Videokonferenzen — sowie für die zu ihrer Nutzung eingesetzten Geräte. Die ADA ist ein separates, weiteres Gesetz, das vom DOJ durchgesetzt wird und öffentlich zugängliche Websites allgemein abdeckt. Telekommunikationsanbieter unterliegen beiden: dem CVAA für den Dienst selbst, ADA Title III für die kundenseitige Website und das Ladengeschäft. Ein Anbieter muss die CVAA-spezifischen Tests bestehen UND WCAG 2.2 AA in seiner Web- und Mobil-Oberfläche erfüllen.
Sind wir verpflichtet, Echtzeittext (RTT) zu unterstützen?
Ja, in den USA. Die FCC-Regeln verpflichten Mobilfunkanbieter und Gerätehersteller zur Unterstützung von RTT (47 CFR § 67) als modernem Ersatz für TTY. Netze müssen das veraltete TTY nicht mehr unterstützen, aber sie müssen RTT unterstützen — und der RTT-Pfad muss Ende-zu-Ende funktionieren, einschließlich anbieterübergreifend und bis zur öffentlichen Sicherheitsleitstelle (PSAP / Notruf 911). Dies ist eine Netz- und Gerätepflicht, keine Website-Pflicht; das Kundenportal muss die RTT-Unterstützung je Gerät und Tarif jedoch korrekt ausweisen.
Deckt der EAA meine Mobilfunkanbieterappp ab?
Mit an Sicherheit grenzender Wahrscheinlichkeit. EAA Artikel 2(2)(b) nennt „elektronische Kommunikationsdienste" als in den Anwendungsbereich fallend, und Artikel 2(2)(c) nennt „Verbraucherendgeräte mit interaktiver Computerfunktion" — was die Europäische Kommission dahingehend ausgelegt hat, dass die kundenseitige Mobile-App, die mit diesem Endgerät verknüpft ist, abgedeckt ist. Jeder Anbieter, der SIM-Karten, Geräte oder VoIP in die EU verkauft, fällt in den Anwendungsbereich, muss EN 301 549 erfüllen (das für Web und Mobile auf WCAG 2.2 AA verweist) und muss gemäß Artikel 13 eine Erklärung zur Barrierefreiheit veröffentlichen.
Wie steht es um TTY-Unterstützung — ist sie noch erforderlich?
Nein, nicht in IP-Netzen. Die FCC hat die TTY-Anforderung für Mobilfunk eingestellt, sobald RTT realisierbar wurde; Anbieter können RTT nun anstelle von TTY in IP-basierten Netzen verwenden. TTY-Unterstützung wird in Legacy-TDM-Schaltkreisen, wo diese noch in Betrieb sind, weiterhin erwartet; neue Aufbauten (5G-Sprache, VoLTE, VoNR) müssen jedoch nur RTT unterstützen. Kundenportaltexte, die noch „nur TTY" angeben, sollten auf „RTT (Echtzeittext) — ersetzt TTY" mit einer kurzen Migrationserkärung aktualisiert werden.
Wie mache ich die Störungskarte barrierefrei?
Es gibt zwei unverzichtbare Bestandteile. Erstens muss die Karte selbst eine nicht-dekorative Rolle und eine Textalternative haben; reines SVG auf Canvas ohne aria-label erfüllt WCAG 1.1.1 nicht. Zweitens — und noch wichtiger — müssen dieselben Störungsdaten als Textliste veröffentlicht werden: Postleitzahl/Region, Status (behoben / wird untersucht / wiederhergestellt), betroffene Dienste, geschätzte Lösungszeit. Tastaturnutzer, Screenreader-Nutzer und Nutzer mit geringer Bandbreite sind auf die Liste angewiesen, nicht auf die Karte. Die Karte ist eine Erweiterung; die Liste ist die Informationsquelle.
Sind VRS-Dolmetscher Teil der Barrierefreiheitspflicht des Anbieters?
Video-Relay-Service-Dolmetscher (VRS) werden von FCC-zertifizierten VRS-Anbietern bereitgestellt, nicht direkt von Mobilfunkanbietern — der Dienst wird aus dem bundesstaatlichen Telecommunications Relay Services (TRS) Fund finanziert. Die Pflicht des Anbieters besteht darin, sicherzustellen, dass Netz und Geräte mit VRS interoperieren, dass die Angaben im Kundenportal die VRS-Verfügbarkeit erläutern und dass die eigenen Support-Kanäle des Anbieters einen Weg zur Anforderung eines Gebärdensprachdolmetschers für gehörlose Kunden und Kunden mit Hörverlust bieten. Die Beschaffung von Dolmetschern liegt nicht beim Anbieter; die Auffindbarkeit und Interoperabilität liegen es.
Wie häufig sollte ein Anbieter sein Kundenportal auditieren?
Automatisiertes Scanning sollte bei jedem Deployment ausgeführt werden — Anbieterportale ändern sich wöchentlich, manchmal täglich, und ein nicht überwachtes Portal driftet ab. Ergänzt wird dies durch einen vierteljährlichen automatisierten Bericht für das gesamte Angebot (Portal, Abrechnung, App, Störungskarte) und ein jährliches manuelles Audit durch Tester mit Behinderungen, einschließlich RTT-Nutzern und ASL-first-Nutzern. Nach jeder größeren Überarbeitung oder Replatformierung — und insbesondere nach einem Abrechnungssystemwechsel (Amdocs, CSG) — ist vor dem Launch ein erneutes manuelles Audit erforderlich, nicht danach.
Drei nächste Schritte
Den passenden für den aktuellen Stand des Anbieter-Teams wählen.
-
Jetzt den kostenlosen Scanner starten
Ein Live-kostenloser WCAG-2.2-Scanner gegen jede öffentliche URL — das Kundenportal, die Abrechnungsseite, die Störungskarte. Der beste Einstieg, wenn noch keine aktuelle Ausgangsbasis für die öffentlichen Oberflächen vorhanden ist.
-
Die Rechtsvorschriften im Vergleich lesen
Unser EAA-Leitfaden und ADA-Title-III-Leitfaden beschreiben, was jedes Gesetz von anbieterseitigen Websites und Apps verlangt — und wo sich CVAA, EAA Artikel 2 und WCAG 2.2 überschneiden.
-
Ein manuelles Audit beauftragen
Der Leitfaden zur Beauftragung eines manuellen Audits durch Tester mit Behinderungen erläutert, was zu fordern ist, wie das Budget zu kalkulieren ist und welche Plattformen ein echtes Tester-Netzwerk mit RTT- und ASL-first-Nutzern einschließen — im Unterschied zu jenen, die dies auslagern.