Тестване с екранни четци: NVDA и JAWS

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

Това ръководство преминава през това как се различават основните екранни четци, защо тестването само на един от тях никога не е достатъчно, какво точно да тествате, кои комбинации от четец и браузър да използвате и капаните, които хващат дори опитни екипи. Написано е за разработчици, QA инженери и специалисти по достъпност, които искат да тестват целенасочено, вместо да гадаят. Ако предпочитате да поверите работата на специалисти, които използват тези инструменти всеки ден, нашата услуга за оценка с екранни четци прави точно това.

Защо екранният четец не е инструмент за „четене на глас“

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

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

Как се различават NVDA, JAWS, VoiceOver и TalkBack

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

NVDA (Windows)

NVDA е безплатен четец с отворен код и най-широко използваният екранен четец в света. Той се съчетава най-естествено с Firefox и Chrome. NVDA обикновено следва отблизо семантиката на ARIA и HTML, което го прави отлична отправна точка: ако нещо е счупено в маркъпа ви, NVDA често го показва ясно. Той има два ключови режима — режим на разглеждане (за четене и структурна навигация) и режим на фокус (за писане във формуляри и работа с уиджети) — и чест източник на грешки са уиджетите, които не успяват да задействат правилното превключване на режима.

JAWS (Windows)

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

VoiceOver (macOS и iOS)

VoiceOver е вграден във всеки Mac, iPhone и iPad и се съчетава почти изключително със Safari. На macOS навигацията се извършва чрез ротора и комбинациите с клавиша VO; на iOS тя е изцяло базирана на жестове — плъзгане за придвижване, двойно докосване за активиране, ротор чрез завъртане на два пръста. VoiceOver обикновено е най-строгият от четирите по отношение на ARIA: той често мълчи, вместо да гадае, когато липсват имена или роли, така че контрола, която JAWS обявява, може изобщо да не каже нищо във VoiceOver. Настолният и мобилният VoiceOver също се различават един от друг, така че се броят като две отделни цели за тестване.

TalkBack (Android)

TalkBack е вграденият четец на Android, съчетан с Chrome. Подобно на VoiceOver за iOS той е базиран на жестове, но неговите жестове, поведение на фокуса и обработка на живите региони и персонализираните контроли се различават от тези на VoiceOver. Мобилните четци като цяло разкриват проблеми, които никога не се появяват на настолен компютър: цели за докосване, които не могат да бъдат достигнати чрез плъзгане, фокус, който скача неочаквано след преход между екрани, и съдържание, което е визуално налично, но напълно прескочено от линейния ред на жестовете.

Защо тестването с няколко четеца е от съществено значение

Тъй като тези четци се разминават в начина, по който интерпретират един и същ маркъп, тестването само с един четец създава фалшиво чувство за сигурност. Няколко конкретни модела се появяват отново и отново:

Персонализиран комбобокс, който JAWS обявява безупречно, може напълно да замлъкне във VoiceOver, защото VoiceOver отказва да изведе липсваща role или състояние aria-expanded.
Жив регион, който NVDA обявява учтиво веднъж, може да бъде обявен многократно или изобщо да не бъде обявен в друг четец в зависимост от това как aria-live и времето на вмъкване в DOM си взаимодействат.
Контрола с излишно или противоречиво име (видим етикет плюс aria-label плюс title) може да бъде обявена разумно от един четец и като объркваща поредица от дубликати от друг.
Редът на четене, който съответства на визуалния ред в една комбинация браузър/четец, може да се разминава в друга, когато CSS пренарежда съдържанието, но DOM — не.

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

Какво да тествате

Тестването е далеч по-ефективно, когато е структурирано. Това са измеренията, които имат значение, приблизително по ред на приоритет, и всяко се съотнася към конкретни критерии за успех на WCAG 2.2.

Обявявания: име, роля, стойност

За всеки интерактивен елемент потвърдете, че четецът обявява точно име (какво е), правилната роля (бутон, връзка, отметка, раздел) и където е приложимо — стойността или състоянието. Това е сърцето на WCAG 4.1.2 (Име, роля, стойност). Вслушвайте се конкретно за: мълчаливи контроли, контроли, обявявани само като „кликаемо“ или „група“, бутони с икони без достъпно име и имена, които се четат като сурови файлови пътища или имена на класове.

Роли и състояния

Състоянията трябва да се актуализират, докато потребителят взаимодейства. Разгъващ се елемент, който се разширява, трябва да премине от „свито“ към „разгънато“; отметка трябва да премине от „неотметнато“ към „отметнато“; бутон за сортиране трябва да обяви текущата си посока. Статичен маркъп, който никога не актуализира aria-expanded, aria-checked, aria-selected или aria-pressed, е един от най-честите дефекти и той се разкрива само когато работите с уиджета при пуснат четец.

Ред на фокуса и управление на фокуса

Преминете с табулатора през целия интерфейс. Фокусът трябва да се движи в логичен, предвидим ред (WCAG 2.4.3), трябва винаги да е видим и никога да не бъде уловен в капан, освен преднамерено вътре в модален прозорец. Трудните случаи са динамичните: когато се отвори диалог, фокусът трябва да се премести в него; когато се затвори, фокусът трябва да се върне към елемента, който го е отворил. Прескачането на това е най-честата причина един модален поток да е неизползваем.

Ред на четене и навигация

Освен фокуса, потребителите на екранни четци навигират по структура. Уверете се, че заглавията образуват логичен план (WCAG 1.3.1), че ориентирите (header, nav, main, footer) позволяват на потребителите да прескачат и че списъците и таблиците са маркирани така, че четецът да може да навигира и да ги преброи. Проверете дали последователността на четене съответства на визуалното намерение и че нищо важно не се обявява в погрешен ред.

Живи региони и динамични актуализации

Асинхронните промени — грешки при валидиране, „намерени са 3 резултата“, „запазване…“, известия тип toast — трябва да достигнат до потребителя, без да го затрупват. aria-live="polite" за неспешни актуализации, aria-live="assertive" само за наистина спешни и role="status" или role="alert" за обичайните случаи. Тествайте дали регионът съществува в DOM, преди съдържанието да се промени, дали актуализацията се обявява точно веднъж и дали не прекъсва потребителя по средата на изречение. Това подкрепя WCAG 4.1.3 (Съобщения за състояние).

Персонализирани ARIA уиджети

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

Конкретен пример: недостъпен спрямо достъпен превключвател

Разгледайте превключвател в настройките. Визуално оформена, но семантично празна версия:

<div class="toggle" onclick="setNotifications()">
  <span class="dot"></span> Notifications
</div>

За екранния четец това е в най-добрия случай парче статичен текст. Няма роля, така че не се обявява като контрола; няма състояние, така че потребителят не може да разбере дали известията са включени или изключени; и не е в реда на табулиране, така че потребител на клавиатура или екранен четец изобщо не може да го достигне или да работи с него. При тестване NVDA чете „Notifications“ и продължава; VoiceOver може да го пропусне напълно.

Достъпният еквивалент използва нативния елемент и излага състоянието:

<button type="button" aria-pressed="false" id="notif">
  Notifications
</button>

const btn = document.getElementById('notif');
btn.addEventListener('click', () => {
  const on = btn.getAttribute('aria-pressed') === 'true';
  btn.setAttribute('aria-pressed', String(!on));
});

Сега всеки четец обявява „Notifications, превключващ бутон, не е натиснат“, достъпен е чрез Tab, работи се с него чрез Enter или интервал и състоянието се сменя осезаемо при активиране. Поуката се обобщава: предпочитайте нативната семантика, а когато трябва да използвате ARIA, тествайте дали всеки четец действително зачита ролята и състоянието. Модели като този дефект с липсващо състояние са сред често срещаните проблеми с достъпността, които трябва да се избягват.

Препоръчителни комбинации от четец и браузър

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

NVDA + Firefox (Windows) — най-чистата отправна точка за откриване на проблеми с маркъпа
NVDA + Chrome (Windows) — най-честата комбинация с безплатен четец в практиката
JAWS + Chrome (Windows) — доминираща в корпоративни и държавни среди
VoiceOver + Safari (macOS) — единствената напълно поддържана настолна комбинация с VoiceOver
VoiceOver + Safari (iOS) — мобилна, базирана на жестове, отделна цел от настолната
TalkBack + Chrome (Android) — стандартната комбинация за Android

Комбинациите имат значение, защото четците са настроени за конкретни браузъри; VoiceOver с Chrome или JAWS с Firefox произвежда поведение, което не отразява как вашата аудитория действително изживява страницата. Където анализите ви показват определена аудитория — да речем, продукт от публичния сектор с интензивно използване на JAWS или потребителско приложение, ориентирано към мобилни устройства — претеглете матрицата съответно. Нашата услуга за оценка с екранни четци настройва тази матрица към анализите на всеки клиент, вместо да тества фиксиран списък.

Често срещани капани

Дори внимателните екипи се спъват в едни и същи неща. Внимавайте за тези:

Тестване с отворени очи. Ако виждате екрана, подсъзнателно ще компенсирате това, което четецът не ви казва. Изключете монитора или поне погледнете встрани и навигирайте само на слух.
Тестване само на един четец. Разгледано по-горе — това е най-големият източник на фалшива увереност.
Прескачане на режима за формуляри/фокус. В NVDA и JAWS персонализираните уиджети често изискват потребителят да е в правилния режим. Ако тествате само в режим на разглеждане, ще пропуснете взаимодействия, които се чупят в режим на фокус.
Прекомерна употреба на aria-label. Добавянето на ARIA етикети навсякъде може да замени видимия текст, да десинхронизира достъпното име с показваното и да обърка потребителите на гласово управление. Предпочитайте нативно етикетиране; посягайте към ARIA само когато HTML не може да изрази връзката.
Допускане, че APG гарантира успех. ARIA Authoring Practices описват предвиденото поведение, а не това, което прави всеки четец. Винаги проверявайте спрямо реални четци.
Доверяване на наслагващи уиджети. Наслагващите и „AI достъпност“ уиджети, които твърдят, че поправят достъпа с екранни четци по време на изпълнение, не осигуряват надеждно изживяване и често влошават навигацията за самите хора, на които твърдят, че помагат. Няма заместител на достъпния маркъп, потвърден чрез реално тестване. Одитирайте действителния DOM и обявяванията, а не маркетинга на наслагването.
Третиране на мобилните устройства като второстепенни. VoiceOver за iOS и TalkBack за Android разкриват собствени проблеми с жестове, фокус и живи региони, които настолното тестване никога не показва.

Защо тестването от хора с увреждания добавя стойност

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

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

Къде се вписва тестването с екранни четци във вашата програма

Тестването с екранни четци е една дисциплина в рамките на по-широка практика. То се съчетава естествено с тестване само с клавиатура и с адаптивните уеб инструменти, на които разчитат вашите потребители, и произвежда вида доказателства, които подкрепят правните задължения по EAA, ADA и Section 508. Находките също захранват директно документацията: нашият екип превежда резултатите четец по четец в VPAT отчети и в приоритизираните планове за отстраняване, които предоставяме чрез консултиране по достъпност. Ако изграждате дългосрочна програма, а не еднократна проверка, именно тази интеграция предпазва достъпността от влошаване.

Заключение

Екранните четци не са взаимозаменяеми, а чист автоматизиран отчет не е използваем продукт. NVDA, JAWS, VoiceOver и TalkBack интерпретират маркъпа ви по различен начин, съчетават се с различни браузъри и разкриват различни дефекти — така че тестването в реалните комбинации, които използва вашата аудитория, е единственият начин да сте уверени. Структурирайте тестването си около обявяванията, ролите и състоянията, фокуса, реда на четене, живите региони и персонализираните уиджети; предпочитайте нативната семантика пред ARIA кръпките; пренебрегвайте наслаганията; и където е възможно, оставете хората, които използват тези инструменти всеки ден, да ви кажат какво реално работи.

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

Често задавани въпроси

Колко екранни четеца наистина трябва да тествам?

Като минимум тествайте NVDA, JAWS и VoiceOver на настолен компютър, плюс VoiceOver на iOS и TalkBack на Android, ако предлагате мобилно изживяване. Тестването на по-малко оставя слепи петна, защото четците се разминават в начина, по който обработват ARIA и динамичното съдържание.

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

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

Премахват ли наслагващите или „AI достъпност“ уиджетите нуждата от тестване?

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

Кои критерии на WCAG покрива тестването с екранни четци?

То директно подкрепя 1.3.1 (Информация и взаимоотношения), 2.4.3 (Ред на фокуса), 4.1.2 (Име, роля, стойност) и 4.1.3 (Съобщения за състояние), наред с други. Всяка находка от структурирана оценка може да бъде съотнесена към съответния критерий за успех на WCAG 2.2.