Dla odbiorców · Telekomunikacja

Dostępność dla operatorów komórkowych, dostawców internetu i komunikacji zunifikowanej — CVAA, EAA i wszystko pomiędzy.

Operatorzy telekomunikacyjni działają w ramach jednego z najbardziej szczegółowych reżimów dostępności w USA — Ustawy o dostępności komunikacji i wideo XXI wieku (CVAA) — a Europejski Akt o Dostępności wymienia wprost „elektroniczne usługi komunikacyjne" i „konsumencki sprzęt końcowy" w artykule 2. Portale operatorskie, rozliczenia, aplikacje mobilne i procesy świadczenia usług wchodzą w zakres tych przepisów. Poniżej przedstawiamy listę kontrolną 30 punktów dotyczącą WCAG 2.2 AA wraz ze specyficznymi dla CVAA uwagami, których zespoły operatorów rzeczywiście potrzebują.

Reżim dostępności w telekomunikacji w 2026 roku

Dwóch regulatorów, dwie ustawy, jedna powierzchnia operacyjna.

W Stanach Zjednoczonych Ustawa o dostępności komunikacji i wideo XXI wieku — CVAA, skodyfikowana w 47 U.S.C. § 617 — nakłada szczegółowe obowiązki w zakresie dostępności na zaawansowane usługi komunikacyjne (ACS): VoIP, wiadomości elektroniczne i interoperacyjne wideokonferencje. Obowiązki te są niezależne od ogólniejszego obowiązku wynikającego z ADA Title III, mającego zastosowanie do stron internetowych ogólnodostępnych obiektów usługowych. Zapoznaj się z naszym przewodnikiem po ADA Title III dotyczącym szerszych ram — CVAA to nałożona na nie warstwa specyficzna dla telekomunikacji.

Egzekwowanie przepisów o dostępności w telekomunikacji przez FCC nasiliło się po 2022 roku. Komisja wprowadziła przepisy dotyczące tekstu w czasie rzeczywistym (RTT) i przejścia ze starszego standardu TTY w sieciach IP; standardów jakości usługi Video Relay Service (VRS) i telefonicznej usługi napisowej (CTS); oraz ocen kompatybilności z aparatami słuchowymi (HAC) dla słuchawek. Biuro ds. egzekwowania prawa publikuje ugody wskazujące operatorów, którzy nie spełnili wymagań interoperacyjności RTT lub składania deklaracji dostępności — są one publiczne i czytane przez pełnomocników powodów.

W Unii Europejskiej Europejski Akt o Dostępności wiąże operatorów z dwóch stron. Artykuł 2(2)(b) wymienia „elektroniczne usługi komunikacyjne" — głos, SMS, wiadomości oparte na IP — jako wchodzące w zakres. Artykuł 2(2)(c) obejmuje „konsumencki sprzęt końcowy z interaktywną zdolnością obliczeniową" — słuchawki, routery, dekodery — co obejmuje dostarczany przez operatora CPE i aplikacje do jego konfiguracji. EN 301 549 jest standardem zgodności i odsyła do WCAG 2.2 AA w zakresie interfejsów webowych i mobilnych.

WCAG 2.2 AA samo w sobie nadal ma zastosowanie do każdej strony internetowej i aplikacji mobilnej skierowanej do klientów — portalu rozliczeniowego, sklepu, bazy wiedzy wsparcia, natywnych aplikacji na iOS i Android. CVAA i EAA nie zastępują WCAG; nakładają obowiązki specyficzne dla telekomunikacji na podstawowy poziom, który nadal musi być spełniony dla samej strony internetowej. Poniższa lista kontrolna jest zorganizowana wokół tego nakładania się: WCAG 2.2 AA w każdym punkcie, z uwagami dotyczącymi CVAA/EAA wskazanymi tam, gdzie mają zastosowanie.

Lista kontrolna 30 punktów WCAG 2.2 AA + CVAA dla operatorów telekomunikacyjnych

Sześć obszarów × pięć punktów kontrolnych. Wydrukuj, zaznacz, następnie przeprowadź audyt.

  1. 01 Zarządzanie kontem i usługami

  2. 02 Rozliczenia i płatności

  3. 03 Usługi komunikacyjne

  4. 04 Zamawianie sprzętu i urządzeń

  5. 05 Awarie i wsparcie

  6. 06 Funkcje sieciowe i limity

Uwagi dotyczące platform — główni dostawcy dla operatorów telekomunikacyjnych

Gdzie lista kontrolna naprawdę spotyka się z kodem — według dostawcy.

Amdocs / CSG (rozliczenia i zarządzanie klientami)

Portale samoobsługowe zbudowane na Amdocs CES i CSG Ascendon są dostarczane z rozsądnymi ustawieniami domyślnymi, ale z rozległymi modyfikacjami agencji. Powtarzające się błędy to ekran podsumowania rachunku (renderowany jako pozycjonowana siatka div zamiast semantycznej tabeli) i kreator zmiany planu (kroki bez znacznika aria-current, przez co użytkownicy czytników ekranu nie mogą ustalić, na którym kroku się znajdują). Oba można naprawić w warstwie personalizacji bez dotykania kodu dostawcy. Należy poprosić integratora systemów o raport zgodności VPAT/EN 301 549 dla konkretnego wdrożenia, a nie dla standardowego produktu.

Salesforce Communications Cloud / Oracle Communications (CRM)

Portale oparte na CRM dziedziczą podstawę Lightning lub Redwood, która jest zadowalająca. Problemy pojawiają się na powierzchni personalizacji — komponenty Lightning Web Components złożone bez regionu aria-live w podglądach koszyka i śledzeniu zamówień, niestandardowe strony Apex omijające zarządzanie fokusem platformy oraz motywy witryn społecznościowych nadpisujące wskaźnik fokusa. Należy przeprowadzać oddzielny audyt motywu portalu/społeczności niezależnie od platformy i traktować każdą kompilację „headless Salesforce" jako niestandardowy sklep React do celów audytu.

Cisco Webex · Microsoft Teams · Zoom Phone (platformy UC)

Platformy komunikacji zunifikowanej publikują własne VPAT i znacząco zainwestowały w napisy, przypinanie tłumaczy ASL i obsługę RTT — prawdziwą powierzchnią do audytu jest treść opakowująca. Aplikacje Webex/Teams/Zoom brandowane przez operatora opakowują SDK dostawcy we własną warstwę, a to właśnie tam pojawiają się problemy: osadzony zestaw wybierania numerów nieogłaszający zmian stanu połączenia, lista kontaktów renderowana jako siatka div, wskaźnik obecności przekazywany wyłącznie przez kolor. Należy polegać na deklaracji dostępności dostawcy dla podstawowego silnika, ale przeprowadzać audyt własnej warstwy opakowującej.

Twilio · Vonage · RingCentral (osobliwości interfejsu CPaaS)

Dostawcy CPaaS oferują pulpity nawigacyjne i komponenty osadzane o różnej jakości. Same pulpity (Twilio Console, Vonage Dashboard, RingCentral Admin) są generalnie dobre. Komponenty osadzane — widżety click-to-call, pokoje wideo, fragmenty okien czatu — to miejsca, gdzie operatorzy i integratorzy najczęściej zawodzą. Każdy osadzony JavaScript dostawcy należy traktować jak wstrzykiwanie DOM od strony trzeciej: musi być audytowany według tej samej listy kontrolnej co własny kod, ponieważ jest renderowany na stronie operatora, pod jego domeną i jego odpowiedzialnością.

Własne aplikacje operatora (natywne iOS + Android)

Natywne aplikacje mobilne to obszar, gdzie EAA jest najbardziej wymagający — artykuł 2(2)(c) obejmuje aplikacje konfigurujące konsumencki sprzęt końcowy, a organy regulacyjne państw członkowskich aktywnie audytują wiodące aplikacje operatorów. Powtarzające się błędy to przyciski z samą ikoną bez etykiety (brak contentDescription na Androidzie, brak accessibilityLabel na iOS), niestandardowe modale wewnątrz aplikacji nieprzechwytujące fokusa oraz karuzele wprowadzające nigdy nieogłaszające zmian slajdów. Zapoznaj się z naszym przewodnikiem po natywnych API dostępności na urządzeniach mobilnych — ze wzorcami specyficznymi dla poszczególnych platform — TalkBack, VoiceOver, Switch Control — które zespół QA musi testować na rzeczywistych urządzeniach, a nie tylko w symulatorze.

Cykl monitorowania i audytu

Jednorazowa korekta nie przetrwa harmonogramu wdrożeń operatora.

Zasoby operatorów zmieniają się nieustannie. Marketing uruchamia baner z nową taryfą w wtorek, zespół OSS/BSS dostarcza aktualizację systemu rozliczeniowego w czwartek, a natywne aplikacje na iOS/Android wydają nową wersję co dwa tygodnie. Jednorazowa korekta dostępności przetrwa mniej więcej do następnego wdrożenia — dlatego zespoły operatorów, które utrzymują właściwy poziom, robią to w trzech warstwach, a nie w jednej.

Po pierwsze, uruchom bezpłatny skaner WCAG 2.2 na portalu klienta, procesie rozliczeń i mapie awarii już teraz, aby ustalić punkt odniesienia. Po drugie, włącz ciągłe automatyczne monitorowanie przy każdym prebuildzie i każdym wdrożeniu produkcyjnym — to warstwa wychwytująca regresje, zanim dotrą do klienta (i zanim zrobi to kolejka skarg do FCC). Po trzecie, zamów audyt ręczny przeprowadzany przez testerów z niepełnosprawnościami co najmniej raz w roku i po każdej większej migracji platformy — wymiana systemu rozliczeniowego (Amdocs → CSG lub odwrotnie) to zdarzenie wysokiego ryzyka, które uzasadnia ręczny audyt przed uruchomieniem, a nie po nim.

Szczegółowe informacje na temat przejścia od monitorowania do audytu ręcznego zawiera nasz przewodnik dla nabywców rozwiązań monitorujących, obejmujący platformy obsługujące przepływ pracy od skanowania do kompleksowego audytu ręcznego — Qualibooth, axe Monitor, Siteimprove i Level Access. W kontekście telekomunikacji wybór należy oceniać według trzech kryteriów: integracja z CI/CD (większość potoków wdrożeniowych operatorów to Jenkins lub GitLab CI, a nie GitHub Actions); czy sieć testerów ręcznych platformy obejmuje użytkowników RTT i użytkowników posługujących się językiem migowym — nie wszystkie platformy tak mają; oraz czy platforma obsługuje audyt zarówno stron internetowych, jak i natywnych aplikacji mobilnych w jednym pulpicie, ponieważ portal i aplikacja nie mogą działać w osobnych cyklach.

Często zadawane pytania

Pytania, które zadają zespoły operatorów przed podjęciem działań.

Czym jest CVAA i jak ma się do ADA?

Ustawa o dostępności komunikacji i wideo XXI wieku (CVAA, 47 U.S.C. § 617) to federalna ustawa dotycząca telekomunikacji, egzekwowana przez FCC. Dotyczy zaawansowanych usług komunikacyjnych (ACS) — VoIP, wiadomości elektronicznych, interoperacyjnych wideokonferencji — oraz sprzętu używanego do ich obsługi. ADA to odrębna, szersza ustawa egzekwowana przez DOJ, obejmująca strony internetowe ogólnodostępnych obiektów usługowych jako takich. Operatorzy telekomunikacyjni podlegają obu: CVAA w zakresie samej usługi, ADA Title III w zakresie strony internetowej i sklepu skierowanego do klientów. Operator musi przejść specyficzne testy CVAA i spełniać WCAG 2.2 AA na swoich interfejsach webowych i mobilnych.

Czy mamy obowiązek obsługi tekstu w czasie rzeczywistym (RTT)?

Tak, w Stanach Zjednoczonych. Przepisy FCC wymagają od operatorów bezprzewodowych i producentów słuchawek obsługi RTT (47 CFR § 67) jako nowoczesnego zamiennika TTY. Sieci nie muszą już obsługiwać starszego standardu TTY, ale muszą obsługiwać RTT — a trasa RTT musi działać od końca do końca, w tym między operatorami i do centrum reagowania na potrzeby bezpieczeństwa publicznego (PSAP / 911). Jest to obowiązek dotyczący sieci i słuchawek, a nie strony internetowej, jednak portal klienta musi dokładnie ujawniać obsługę RTT dla każdego urządzenia i planu.

Czy EAA obejmuje moją aplikację mobilną operatora?

Niemal na pewno. Artykuł 2(2)(b) EAA wymienia „elektroniczne usługi komunikacyjne" jako wchodzące w zakres, a artykuł 2(2)(c) wymienia „konsumencki sprzęt końcowy z interaktywną zdolnością obliczeniową" — co Komisja Europejska zinterpretowała jako obejmujące aplikację skierowaną do klientów, która łączy się z tym sprzętem końcowym. Każdy operator sprzedający karty SIM, urządzenia lub VoIP w UE podlega przepisom, musi spełniać EN 301 549 (odsyłający do WCAG 2.2 AA w zakresie interfejsów webowych i mobilnych) i musi publikować deklarację dostępności zgodnie z artykułem 13.

Czy obsługa TTY jest nadal wymagana?

Nie — nie w sieciach IP. FCC zniosło obowiązek obsługi bezprzewodowego TTY po upowszechnieniu się RTT; operatorzy mogą teraz używać RTT zamiast TTY w sieciach opartych na IP. Obsługa TTY jest nadal oczekiwana w starszych łączach TDM, gdzie są one nadal eksploatowane, ale nowe wdrożenia (głos 5G, VoLTE, VoNR) muszą obsługiwać wyłącznie RTT. Treść portalu klienta, która nadal mówi „tylko TTY", powinna zostać zaktualizowana do „RTT (tekst w czasie rzeczywistym) — następca TTY" z krótkim wyjaśnieniem przejścia.

Jak sprawić, by mapa awarii była dostępna?

Wymagane są dwa elementy. Po pierwsze, sama mapa musi mieć niedekoracyjną rolę i tekstową alternatywę; czysty element SVG na canvasie bez aria-label nie spełnia kryterium WCAG 1.1.1. Po drugie — i ważniejsze — należy opublikować te same dane o awariach jako listę tekstową: kod pocztowy/region, status (rozwiązano / w trakcie badania / przywrócono), usługi objęte awarią, szacowany czas rozwiązania. Użytkownicy klawiatury, użytkownicy czytników ekranu i użytkownicy wolnych połączeń polegają na liście, a nie na mapie. Mapa jest uzupełnieniem; lista jest głównym źródłem informacji.

Czy tłumacze VRS są obowiązkiem dostępności operatora?

Tłumacze usługi Video Relay Service (VRS) są świadczeni przez certyfikowanych przez FCC dostawców VRS, a nie bezpośrednio przez operatorów — usługa jest finansowana z federalnego Funduszu Usług Przekaźnikowych (TRS). Obowiązkiem operatora jest zapewnienie, że jego sieć i urządzenia są interoperacyjne z VRS, że ujawnienia w portalu klienta wyjaśniają dostępność VRS, oraz że własne kanały wsparcia operatora oferują ścieżkę zgłoszenia tłumacza języka migowego dla głuchych klientów i klientów z niedosłuchem. Zapewnienie tłumaczy nie jest obowiązkiem operatora; dostępność ścieżki zgłoszenia i interoperacyjność — tak.

Jak często operator powinien przeprowadzać audyt swojego portalu klienta?

Automatyczne skanowanie powinno być uruchamiane przy każdym wdrożeniu — portale operatorów zmieniają się co tydzień, czasem codziennie, a nieaudytowany portal zacznie odbiegać od normy. Należy uzupełnić to kwartalnym automatycznym raportem dla całego zasobu (portal, rozliczenia, aplikacja, mapa awarii) i corocznym audytem ręcznym przeprowadzanym przez testerów z niepełnosprawnościami, w tym użytkowników RTT i użytkowników posługujących się językiem migowym. Po każdej większej przebudowie lub migracji platformy — a zwłaszcza po wymianie systemu rozliczeniowego (Amdocs, CSG) — należy przeprowadzić nowy audyt ręczny przed uruchomieniem, a nie po nim.

Trzy kolejne kroki

Wybierz ten, który odpowiada aktualnemu stanowi zespołu operatora.

  1. Uruchom bezpłatny skaner teraz

    Działający bezpłatny skaner WCAG 2.2 dla dowolnego publicznego URL — portalu klienta, strony rozliczeń, mapy awarii. Najlepszy punkt startowy, jeśli nie dysponujesz aktualnym punktem odniesienia dla publicznych powierzchni.

    Otwórz skaner →

  2. Zapoznaj się z przepisami kraj po kraju

    Nasz przewodnik po EAA i przewodnik po ADA Title III omawiają, czego każda ustawa wymaga od stron internetowych i aplikacji operatorów — oraz w jakich obszarach CVAA, EAA art. 2 i WCAG 2.2 nakładają się na siebie.

    Przeczytaj przewodnik po EAA →

  3. Zamów audyt ręczny

    Zapoznaj się z naszym przewodnikiem po zamawianiu audytu ręcznego przeprowadzanego przez testerów z niepełnosprawnościami — czego wymagać, jaki budżet zaplanować i które platformy dysponują rzeczywistą siecią testerów obejmującą użytkowników RTT i posługujących się językiem migowym, a nie tylko podzlecają to zadanie.

    Przeczytaj przewodnik →