Режимът за достъпност в телекомуникациите през 2026 г.
Два регулатора, два закона, една оперативна повърхност.
В Съединените щати Законът за достъпност на комуникациите и видеото на 21-ви век — CVAA, кодифициран в 47 U.S.C. § 617 — налага конкретни задължения за достъпност на усъвършенстваните комуникационни услуги (ACS): VoIP, електронни съобщения и оперативно съвместими видеоконферентни връзки. Тези задължения са независими от по-общото задължение по ADA Title III, приложимо за уебсайтовете на заведения за обществено ползване. Вижте нашето ръководство за ADA Title III за по-широката рамка — CVAA е специфичното за телекомуникациите наслояване върху него.
Правоприлагането от страна на FCC в областта на достъпността в телекомуникациите се засили след 2022 г. Комисията въведе правила за текст в реално време (RTT) и прехода от наследения TTY в IP мрежи; за производителността на услугата за видеоретранслиране (VRS) и телефонната услуга с субтитри (CTS); и за рейтингите за съвместимост с слухови апарати (HAC) за слушалки. Бюрото по правоприлагане публикува споразумения за съгласие, назоваващи оператори, неизпълнили изискванията за оперативна съвместимост на RTT или подаване на декларации за достъпност — те са публични и се четат от адвокати на ищци.
В Европейския съюз Европейският акт за достъпност обвързва операторите от две посоки. Член 2(2)(б) назовава "електронните комуникационни услуги" — глас, SMS, IP-базирани съобщения — като попадащи в обхвата. Член 2(2)(в) обхваща "потребителско крайно оборудване с интерактивна изчислителна способност" — слушалки, рутери, декодери — което включва доставяното от оператора CPE и приложенията за конфигурирането му. EN 301 549 е стандартът за съответствие и препраща към WCAG 2.2 AA за уеб и мобилните повърхности.
А WCAG 2.2 AA сам по себе си все още се прилага за всеки клиентски уебсайт и мобилно приложение — портал за фактуриране, търговски магазин, база знания за поддръжка, нативни приложения за iOS и Android. CVAA и EAA не заместват WCAG; те наслагват специфични за телекомуникациите задължения върху базовото ниво, което все още трябва да бъде изпълнено за самия уебсайт. Контролният списък по-долу е структуриран около това наслагване: WCAG 2.2 AA на всеки ред, с бележки за CVAA/EAA, посочени там, където се прилагат.
Контролен списък от 30 точки WCAG 2.2 AA + CVAA за телекоми
Шест повърхности × пет проверки. Отпечатайте го, отбележете го, след това го одитирайте.
-
01 Управление на акаунт и услуги
-
02 Фактуриране и плащания
-
03 Комуникационни услуги
-
04 Поръчка на оборудване и устройства
-
05 Прекъсвания и поддръжка
-
06 Мрежови функции и квоти
Бележки за платформата — основни доставчици за телекоми
Където контролният списък реално се среща с кода, по доставчик.
Amdocs / CSG (фактуриране и управление на клиенти)
Порталите за самообслужване, изградени на Amdocs CES и CSG Ascendon, се доставят с работещи настройки по подразбиране, но с тежка персонализация от агенции. Повтарящите се неуспехи са екранът с обобщение на сметката (рендиран като позиционирана div мрежа вместо семантична таблица) и съветникът за смяна на план (стъпки без маркер aria-current, поради което потребителите на екранни четци не могат да разберат на коя стъпка се намират). И двете са поправими в слоя за персонализация, без да се докосва кодът на доставчика. Поискайте от системния интегратор VPAT/EN 301 549 доклад за съответствие за вашето конкретно внедряване, а не за стандартния продукт.
Salesforce Communications Cloud / Oracle Communications (CRM)
Порталите, базирани на CRM, наследяват основата Lightning или Redwood, която е приемлива. Повърхността за персонализация е там, където нещата се разпадат — Lightning Web Components, съставени без aria-live регион в прегледите на количката и проследяването на поръчки, персонализирани Apex страници, заобикалящи управлението на фокуса на платформата, и теми за общностни сайтове, отменящи индикатора за фокус. Одитирайте темата на общността/портала отделно от платформата и третирайте всяко "headless Salesforce" изграждане като персонализиран React магазин за целите на одита.
Cisco Webex · Microsoft Teams · Zoom Phone (UC платформи)
Платформите за унифицирани комуникации публикуват свои собствени VPAT и са инвестирали значително в субтитри, закачане на ASL и поддръжка на RTT — повърхността, която реално трябва да се одитира, е вграденото съдържание. Брандираните от оператора приложения Webex/Teams/Zoom обвиват SDK на доставчика с вашата собствена обвивка, и обвивката е мястото, където се появяват проблемите: вграден набор за набиране, не обявяващ промените в статуса на разговора, списък с контакти, рендиран като div мрежа, индикатор за присъствие, предаван само чрез цвят. Разчитайте на декларацията за достъпност на доставчика за основния двигател, но одитирайте вашата обвивка.
Twilio · Vonage · RingCentral (CPaaS UI особености)
Доставчиците на CPaaS предлагат табла за управление и вградими компоненти с различно качество. Самите табла за управление (Twilio Console, Vonage Dashboard, RingCentral Admin) са като цяло добри. Вградимите компоненти — джаджи за кликване и обаждане, видео стаи, фрагменти за прозорец за чат — са там, където операторите и интеграторите най-често се провалят. Третирайте всяко вградено JS от доставчик като инжектиране на DOM от трета страна: то трябва да бъде одитирано спрямо същия контролен списък като вашия собствен код, тъй като се рендира на вашата страница под вашия домейн и вашата отговорност.
Вградени операторски приложения (нативни iOS + Android)
Нативният мобилен е там, където ухапването на EAA е най-острото — Член 2(2)(в) обхваща приложенията, конфигуриращи потребителско крайно оборудване, а регулаторите на държавите членки активно одитират водещите операторски приложения. Повтарящите се неуспехи са бутони само с икони без надпис (без contentDescription на Android, без accessibilityLabel на iOS), персонализирани модали в приложението, не улавящи фокуса, и въвеждащи карусели, никога не обявяващи смените на слайдовете. Вижте нашето ръководство за нативни API за достъпност на мобилни устройства за специфичните за платформата модели — TalkBack, VoiceOver, Switch Control — които QA екипът трябва да тества на реални устройства, а не само в симулатора.
Цикълът за мониторинг + одит
Еднократна корекция не оцелява в пускателния влак на оператора.
Операторските активи се променят непрекъснато. Маркетингът пуска тарифен банер в вторник, екипът по OSS/BSS доставя актуализация на системата за фактуриране в четвъртък, а нативните приложения за iOS/Android пускат версия на всеки две седмици. Еднократна корекция за достъпност трае приблизително толкова, колкото следващото разгръщане — затова операторските екипи, които удържат линията, го правят в три слоя, а не в един.
Първо, стартирайте безплатен скенер за WCAG 2.2 срещу вашия клиентски портал, процес на фактуриране и карта на прекъсванията днес, за да установите базово ниво. Второ, включете непрекъснат автоматизиран мониторинг срещу всяко предварително изграждане и всяко производствено разгръщане — това е слоят, който улавя регресиите преди да достигнат клиента (и преди опашката за жалби на FCC да го направи). Трето, поръчайте ръчен одит от тестери с увреждания поне веднъж годишно и след всяко основно преминаване към нова платформа — замяната на система за фактуриране (Amdocs → CSG, или обратното) е събитието с най-висок риск и оправдава ръчен одит преди пускане в експлоатация, а не след него.
За прехода от мониторинг към ръчен одит конкретно, нашето ръководство за купувачи на мониторинг обхваща платформите, обработващи работния процес от сканиране до одит от край до край — Qualibooth, axe Monitor, Siteimprove и Level Access. Специфично за телекомите, претегляйте избора си по три критерия: интеграция с CI/CD (повечето операторски пускателни влакове са Jenkins или GitLab CI, а не GitHub Actions); дали тестерската мрежа за ръчен одит на платформата включва потребители на RTT и потребители с приоритет на жестовия език — не всички го правят; и дали платформата поддържа одит както на уеб, така и на нативно мобилно под едно табло, тъй като порталът и приложението ви не могат да бъдат на отделни цикли.
Често задавани въпроси
Въпросите, които операторските екипи задават преди да се ангажират.
Какво е CVAA и как е свързан с ADA?
Законът за достъпност на комуникациите и видеото на 21-ви век (CVAA, 47 U.S.C. § 617) е федерален закон, специфичен за телекомуникациите, прилаган от FCC. Той се прилага за усъвършенствани комуникационни услуги (ACS) — VoIP, електронни съобщения, оперативно съвместими видеоконферентни връзки — и за оборудването, използвано за достъп до тях. ADA е отделен, по-широк закон, прилаган от DOJ, покриващ уебсайтовете на заведения за обществено ползване като цяло. Телекомуникационните оператори са предмет и на двата: CVAA за самата услуга, ADA Title III за уебсайта и магазина, насочени към клиенти. Операторът трябва да премине специфичните тестове за CVAA И да отговаря на WCAG 2.2 AA на своя уеб и мобилен интерфейс.
Задължени ли сме да поддържаме текст в реално време (RTT)?
Да, в САЩ. Правилата на FCC изискват от безжичните оператори и производителите на слушалки да поддържат RTT (47 CFR § 67) като съвременна замяна на TTY. Мрежите вече не трябва да поддържат наследения TTY, но трябва да поддържат RTT — и RTT маршрутът трябва да работи от край до край, включително между оператори и до центъра за отговор на обществената безопасност (PSAP / 911). Това е задължение на мрежата и слушалките, а не на уебсайта, но клиентският ви портал трябва точно да разкрива поддръжката на RTT за всяко устройство и план.
Обхваща ли EAA приложението ми за мобилен оператор?
Почти сигурно. Член 2(2)(б) от EAA назовава "електронните комуникационни услуги" като попадащи в обхвата, а Член 2(2)(в) назовава "потребителско крайно оборудване с интерактивна изчислителна способност" — което Европейската комисия е тълкувала като обхващащо приложението, насочено към клиентите, което се сдвоява с това крайно оборудване. Всеки оператор, продаващ SIM карти, устройства или VoIP в ЕС, попада в обхвата, трябва да отговаря на EN 301 549 (който препраща към WCAG 2.2 AA за уеб и мобилни устройства) и трябва да публикува декларация за достъпност съгласно Член 13.
А поддръжката на TTY — все още ли се изисква?
Не, не в IP мрежи. FCC прекрати изискването за безжичен TTY след като RTT стана приложим, и операторите вече могат да използват RTT вместо TTY в IP-базирани мрежи. Поддръжката на TTY все още се очаква в наследените TDM вериги, където те остават в експлоатация, но новите изграждания (5G глас, VoLTE, VoNR) трябва само да поддържат RTT. Текстът на клиентския портал, в който все още се казва "само TTY", трябва да бъде актуализиран до "RTT (текст в реално време) — замества TTY" с кратко обяснение за прехода.
Как да направя картата на прекъсванията достъпна?
Два задължителни компонента. Първо, самата карта трябва да има недекоративна роля и текстова алтернатива; чист SVG върху canvas без aria-label не отговаря на WCAG 1.1.1. Второ — и по-важно — трябва да публикувате същите данни за прекъсванията като текстов списък: пощенски код/регион, статус (решен / в процес на проучване / възстановен), засегнати услуги, очаквано време за разрешаване. Потребителите на клавиатура, потребителите на екранни четци и потребителите с нискоскоростна връзка разчитат на списъка, а не на картата. Картата е допълнение; списъкът е основният източник на истина.
Преводачите на VRS ли са задължение за достъпност на оператора?
Преводачите на Video Relay Service (VRS) се предоставят от FCC-сертифицирани доставчици на VRS, а не директно от операторите — и услугата се финансира от федералния Фонд за телекомуникационни ретранслационни услуги (TRS). Задължението на оператора е да гарантира, че неговата мрежа и устройства оперативно съвместими с VRS, че разкриванията в клиентския портал обясняват наличността на VRS, и че собствените канали за поддръжка на оператора предлагат маршрут за заявка на преводач на жестов език за глухи клиенти и клиенти с увреден слух. Намирането на преводачи не е задължение на оператора; достъпността за намиране и оперативната съвместимост са.
Колко често трябва операторът да одитира клиентския си портал?
Автоматизираното сканиране трябва да се изпълнява при всяко разгръщане — операторските портали се променят седмично, понякога ежедневно, и немаркиран портал ще се отклони. Съчетайте това с тримесечен автоматизиран доклад за цялото имущество (портал, фактуриране, приложение, карта на прекъсванията) и ежегоден ръчен одит от тестери с увреждания, включително потребители на RTT и потребители с приоритет на жестовия език. След всяко основно преработване или преминаване към нова платформа — и особено след замяна на система за фактуриране (Amdocs, CSG) — трябва да се извърши нов ръчен одит преди пускане в експлоатация, а не след него.
Три следващи стъпки
Изберете тази, която съответства на текущото положение на вашия операторски екип.
-
Стартирайте безплатния скенер сега
Жив безплатен скенер за WCAG 2.2 срещу всеки публичен URL — вашия клиентски портал, страницата за фактуриране, картата на прекъсванията. Най-доброто начало, ако нямате текущо базово ниво за публичните повърхности.
-
Прочетете нормативната уредба страна по страна
Нашето ръководство за EAA и ръководство за ADA Title III обхващат какво изисква всеки закон от уебсайтовете и приложенията, насочени към операторите — и където CVAA, EAA Член 2 и WCAG 2.2 се застъпват.
-
Поръчайте ръчен одит
Прочетете нашето ръководство за поръчване на ръчен одит от тестери с увреждания — какво да поискате, какъв бюджет да заделите и кои платформи включват реална тестерска мрежа с потребители на RTT и такива с приоритет на жестовия език, за разлика от тези, които го възлагат на подизпълнители.