Синтез на реч срещу екранни четци

Вашето съдържание има глас

Технологията за синтез на реч (TTS) преобразува писмена информация в аудио. Тя помага на хора със слепота, зрителни увреждания, дислексия и ADHD да възприемат съдържание по начин, който им подхожда. TTS се използва широко и в училищата, от изучаващите езици и от професионалисти, които правят корекции на слух, а не с очи.

Тъй като и TTS, и екранните четци произвеждат синтетичен глас, хората често приемат, че са едно и също нещо — или че добавянето на бутон „прочети на глас“ към даден уебсайт го прави достъпен за незрящи потребители. Това допускане е погрешно и действието според него може да ви остави със сайт, който звучи достъпно, но е невъзможен за реално използване от много хора. Тази статия обяснява как работи всяка технология, кой разчита на нея, къде наистина минава границата между тях и какво е нужно, за да се разработва правилно за екранни четци. Ако запомните само едно нещо, нека е това: джаджата за четене на глас е функция за удобство, а не функция за достъпност.

Как работи TTS?

TTS обработва текста в три големи етапа:

Анализ на текста — определяне на тон, граматика и структура, разгръщане на числа и символи („5 $“ става „пет долара“) и сегментиране на изреченията.
Лингвистична обработка — изчисляване на произношение, ударение и акцент, често с помощта на речник за произношение плюс правила за непознати думи.
Аудиосинтез — генериране на реч от математически гласови модели, все по-често с помощта на невронни мрежи, които звучат далеч по-естествено от по-старите конкатенативни двигатели.

Съвременните системи предлагат персонализиране на гласа като скорост, височина, гласова персона и избор на език. Ключовият момент е какво приема TTS като вход: блок текст, който някой вече е избрал, поставил или посочил. TTS по същество е технология за извеждане на съдържание. Тя изговаря това, което ѝ е дадено. Не изследва интерфейс и няма понятие за бутони, полета на форми или структура на страницата.

Какви са ограниченията на технологията TTS?

TTS е наистина полезна, но не е съвършена, а ограниченията ѝ са от значение за предстоящото сравнение:

Пропуски в произношението — може да произнесе погрешно необичайни думи, собствени имена, медицински или правни термини и съкращения.
Неравномерна езикова поддръжка — много инструменти се справят добре с основните езици, но се затрудняват с по-рядко срещаните езици и регионалните диалекти.
Тон и нюанс — TTS се затруднява със сарказъм, хумор и идиоматични изрази, така че съдържанието може да бъде предадено с грешен тон.
Без модел на взаимодействие — и това е най-същественото: TTS чете; не ви позволява да правите нищо. Не можете да попълните форма за плащане, да затворите модален прозорец или да се придвижвате между елементи на меню само с TTS.

Точно това последно ограничение е мястото, където започва объркването с екранните четци.

Каква е разликата между технологията за синтез на реч и тази за екранен четец?

Тук възниква често срещаното недоразумение. Синтезът на реч чете текст на глас — това е основната му функция. Екранният четец прави много повече: позволява на потребителите да навигират и да управляват цял компютър или мобилно устройство със слух и клавиатура (или жестове с докосване).

Екранните четци обявяват етикетите на интерфейса, полетата на формите, бутоните и връзките; четат алтернативния текст на изображенията, за да разберат потребителите визуалното съдържание; и излагат състоянието на компонентите — дали едно поле за отметка е отметнато, дали едно меню е разгънато, дали един раздел е избран или дали се е появила грешка. Те превръщат визуален, управляван с мишка интерфейс в линеен, чуваем и управляем такъв.

Бърз начин да усетите разликата: TTS отговаря на въпроса „какво пише в този абзац?“ Екранният четец отговаря на „къде съм, какво мога да правя тук и какво току-що се случи?“ Първото е свързано с възприемане на съдържание. Второто — с управление на софтуер.

Как потребителят на екранен четец всъщност се придвижва из страница

Зрящите потребители обхождат страница за секунди. Потребителят на екранен четец изгражда мисловен модел последователно и разчита на структурата, за да се придвижва ефективно. На практика те:

Прескачат между заглавията, за да разберат структурата на страницата (затова правилната йерархия на заглавията е толкова важна).
Извикват списък с всички връзки или всички полета на формите, за да навигират по ориентири, вместо да четат отгоре надолу.
Използват ориентировъчните области (банер, навигация, основно съдържание, долен колонтитул), за да прескочат направо до съдържанието, което искат.
Преминават през интерактивните елементи с клавиша Tab и очакват фокусът да попадне на видимо и логично място.
Се вслушват в живи известия, когато нещо се промени без пълно презареждане на страницата.

Нищо от това не работи, освен ако подлежащата маркировка не описва страницата честно. Функцията „прочети на глас“ не предоставя нито едно от тези навигационни удобства — тя просто разказва какъвто и да е текст на екрана, във визуален ред, без начин да се управляват контролите.

Кой какво използва и защо има значение

TTS се използва от широка аудитория, често ситуативно: хора с дислексия, ADHD или слабо зрение; хора, които вършат няколко неща наведнъж; изучаващи езици; и всеки, който просто предпочита да слуша. Повечето от тези потребители все още виждат екрана и могат да използват мишка.

Потребителите на екранни четци включват хора, които са незрящи или с тежки зрителни увреждания, както и някои хора с когнитивни или двигателни увреждания, които разчитат на технологията, за да могат изобщо да използват устройство. За тях тя не е слой на предпочитание върху използваем интерфейс — тя е интерфейсът. Най-разпространените инструменти са NVDA и JAWS на Windows, VoiceOver на устройства на Apple и TalkBack на Android. Всеки от тях интерпретира една и съща уеб страница малко по-различно, което е една от причините тестването с всички тях да има значение.

Защо джаджите за четене на глас не заместват достъпността

Все повече уебсайтове прикачват бутон „слушай тази страница“ или джаджа от трета страна, която осветява и изговаря текст. Тези инструменти могат да помогнат на някои читатели и няма нищо лошо да се предлага такъв като удобство. Проблемът е да се третира като заместител на истинската поддръжка за екранни четци. Не е, по няколко конкретни причини.

Те само четат; не управляват. Джаджата за четене на глас ще разкаже таблицата ви с цени, но не може да позволи на незрящ потребител да избере план, да отвори количката, да въведе данни за плащане и да завърши покупката. Реалните задачи изискват управляеми контроли, а не разказване.
Не могат да изложат състояние или роли. Дали един бутон е натиснат, дали едно поле е задължително, дали един раздел е свит или дали току-що се е появило съобщение за грешка — нищо от това не се предава чрез четене на видимия текст. Екранните четци разчитат на роли, имена и състояния в маркировката, за да го обявят.
Потребителите на екранни четци вече имат инструмент. Незрящите потребители носят свой собствен екранен четец, фино настроен според техните предпочитания и мускулна памет. Джаджа на ниво страница се конкурира с него, понякога му пречи и не прави нищо, за да поправи дефектната маркировка, на която екранният им четец засича.
Маскират проблемите, вместо да ги поправят. Ако едно поле на форма няма етикет, джаджата ще го пропусне точно както би направил екранен четец — но сега липсващият етикет е скрит зад функция, която изглежда полезна. Подлежащият дефект остава.

Същата логика важи, дори по-силно, за така наречените наслагвания за достъпност (overlays) — скриптове, които обещават мигновено съответствие чрез наслагване на автоматизирани поправки и лента с инструменти върху съществуващ сайт. Те не поправят подлежащия код, често влизат в конфликт със собствената помощна технология на потребителите и не могат да осигурят истинско съответствие. Надеждният път е да се поправи източникът. За по-пълно обяснение защо повърхностните поправки не са достатъчни, вижте нашето ръководство за истинската цифрова достъпност.

Конкретен пример: касата, която „говори“

Представете си онлайн магазин, който е добавил джаджа за четене на глас и е убеден, че сайтът вече е достъпен. Незряща клиентка пристига със собствен работещ екранен четец. Описанието на продукта се чете добре — тази част е просто текст. Но контролът „Добави в количката“ е стилизиран div с обработчик на щракване вместо истински бутон, така че екранният четец никога не го обявява като бутон и клавиатурата не може да го достигне. Селекторът за количество актуализира обща сума без жива област, така че промяната е безшумна. Полето за промокод има текст-заместител, но няма свързан етикет, така че се обявява само като „редактиране на текст“. Формата за доставка показва визуално червена грешка, но грешката не е свързана с полето и изобщо не се обявява. Джаджата за четене на глас весело разказва видимия текст и не променя нищо от това. Клиентката може да чуе маркетинговото съдържание, но не може да завърши покупка. Тази пропаст — между чуването на съдържание и управлението на продукт — е цялата разлика между функция за удобство и достъпност.

Какво всъщност изисква разработването за екранни четци

Поддръжката на екранни четци не е свързана с добавянето на функция — тя е свързана с изграждането на страниците ви така, че смисълът, структурата и поведението да са достъпни за софтуера, а не само за човешкото око. Основните съставки:

Семантичен, структуриран HTML

Използвайте истински заглавия (h1–h6) в логичен ред, нативни бутони и връзки за правилните цели, списъци за списъци и ориентировъчни елементи за областите на страницата. Семантичният HTML носи информация за достъпност безплатно; стена от общи контейнери не носи никаква.

Текстови алтернативи за нетекстово съдържание

Всяко смислено изображение се нуждае от точен алтернативен текст, а декоративните изображения трябва да бъдат маркирани така, че да бъдат пропускани. Иконите, които действат като бутони, се нуждаят от достъпни имена. Диаграмите и инфографиките се нуждаят от текстов еквивалент, който предава същата информация.

Достъпни имена, роли и състояния

Полетата на формите се нуждаят от програмно свързани етикети. Персонализираните компоненти — раздели, акордеони, комбинирани полета, модални прозорци — се нуждаят от правилните роли и състояния, за да обяви екранният четец какви са те и как се държат. Където нативният HTML не е достатъчен, ARIA запълва празнината, но трябва да се използва прецизно; неправилният ARIA е по-лош от никакъв.

Управляемост с клавиатура и управление на фокуса

Всичко, което работи с мишка, трябва да работи с клавиатура, редът на фокуса трябва да е логичен, индикаторът за фокус трябва да е видим, а динамичните промени (отваряне на диалог, разкриване на грешка) трябва да преместват или обявяват фокуса по подходящ начин. Поддръжката на клавиатура и поддръжката на екранни четци са дълбоко преплетени.

Обявяване на динамични промени

Когато съдържанието се актуализира без презареждане на страницата — съобщение за валидиране на форма, брояч на количка, състояние на зареждане — използвайте живи области, за да каже екранният четец на потребителя, че нещо се е случило. Безшумните актуализации са невидими за хората, които не могат да виждат екрана.

Всички тези очаквания са кодифицирани в критериите за успех на WCAG 2.2, които формират техническия гръбнак на European Accessibility Act и на ADA, прилаган към уеб. Ако искате практическите подробности, нашето ръководство за тестване с екранни четци преминава стъпка по стъпка през това как да проверите всяко от тези поведения с реални инструменти.

Защо „на мен ми се чете добре“ е подвеждащо

Зрящ разработчик може да включи функция за четене на глас, да чуе чисти изречения и да заключи, че страницата е достъпна. Капанът е, че четенето на глас възпроизвежда видимия ред на четене и видимия текст, които и двата вече имат смисъл за човек, който гледа екрана. То не казва нищо за това дали персонализирано падащо меню обявява опциите си, дали фокусът е задържан вътре в отворен диалог, дали бутон само с икона има име или дали редът на табулиране съответства на визуалното оформление. Точно това са нещата, които се чупят за потребителите на екранни четци, и точно това са нещата, които демонстрация на четене на глас не може да разкрие. Единственият начин да се разбере е да се тества така, както го правят реалните потребители.

Как да тествате и за двете — и защо само автоматизацията не е достатъчна

Не можете да потвърдите, че една страница работи за потребителите на екранни четци, като слушате бутон за четене на глас. Потвърждавате го, като проверявате структурата, имената, ролите, състоянията, работата с клавиатура и реалното изживяване с екранен четец в множество инструменти и платформи.

Един надежден процес съчетава три слоя:

Автоматизирано сканиране, за да се уловят масовите, машинно откриваеми проблеми — липсващ алтернативен текст, празни етикети, счупени ARIA препратки, неуспехи в контраста. Нашият софтуер за сканиране на достъпността и безплатно сканиране на достъпността са бърз начин да установите къде се намирате.
Ръчно експертно тестване, за да се оцени всичко, което автоматизацията не може да прецени: дали едно име е смислено, дали редът на фокуса има смисъл, дали персонализирана джаджа е наистина управляема. Обосновката зад този слой е разгледана в нашето ръководство за ръчни одити на достъпността.
Тестване с реална помощна технология и реални потребители. Нищо не замества управлението на страницата с NVDA, JAWS, VoiceOver и TalkBack — и в идеалния случай наблюдаването на хора, които използват тези инструменти всеки ден. Нашите одити от хора с увреждания внасят точно тази изживяна експертиза.

Автоматизираните инструменти обикновено откриват само част от критериите за успех на WCAG 2.2; останалото изисква човешка преценка. Да се третира преминато автоматизирано сканиране като доказателство за достъпност е същата категория грешка като да се третира джаджа за четене на глас като поддръжка за екранни четци.

Къде се вписва QualiBooth

QualiBooth тества вашия уебсайт спрямо случаите на употреба както на TTS, така и на екранни четци, така че съдържанието ви да е достъпно за потребители, разчитащи на която и да е от двете технологии — и така че хората, които зависят от екранен четец, не само да чуват съдържанието ви, но и реално да управляват продукта ви. Нашият комплект инструменти за достъпност и платформата Agora съчетават сканиране със структуриран ръчен преглед, а нашият екип за консултации по достъпност ви помага да отстраните това, което тестовете разкриват, и да се приведете в съответствие с изискванията на WCAG 2.2, EAA и ADA.

Изводът е прост. Да дадете глас на съдържанието си е приятен щрих. Да направите съдържанието си навигируемо, управляемо и правилно обявявано пред екранен четец е достъпност — и само едно от тези неща удовлетворява закона и хората, които той защитава.