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

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

Владеенето, за нашите цели, е точката, в която можете да подадете на колега развален компонент, да вземете клавиатурата му и да възпроизведете грешката с работещ екранен четец — без да гледате екрана, без да се позовавате на справочна карта и без да направите съобщението по-лошо, отколкото би било при реална употреба. Запознатостта е точката, в която сте чули екранен четец. Разликата между двете е приблизително тридесет до тридесет и пет часа целенасочена практика.

На пазара има три екранни четеца, които имат значение за настолна уеб работа: NVDA на Windows, VoiceOver на macOS и iOS, и JAWS на Windows. Всеки от тях има достатъчно голяма потребителска база, че пренебрегването му би било истински залог, и всеки от тях съобщава една и съща маркировка малко по различен начин. Свободно владеещ разработчик може да управлява поне два от тях.

Нашата препоръка, след като сме наблюдавали десетки разработчици да преминат прага, е недвусмислена: започнете с NVDA на Windows и VoiceOver на macOS. И двата са безплатни. И двата са предварително инсталирани (VoiceOver) или се инсталират за под пет минути (NVDA). И двата се използват от достатъчно реални потребители — NVDA държи прибл. 65% от пазарния дял на екранни четци за Windows според най-новото проучване на WebAIM, а VoiceOver доминира на мобилни устройства и държи значителен дял от macOS — че наученото се пренася незабавно към грешки, за които можете да доставите поправка. JAWS е третият инструмент, а не първият, въпреки че все още е екранният четец с най-голямата корпоративна инсталирана база. По три причини.

Трите причини да пропуснете JAWS в началото са педагогически, а не политически. Първо, JAWS и NVDA споделят един мисловен модел — режим на разглеждане спрямо режим на фокус в Windows, същия команден префикс с клавиша Insert, същия виртуален буфер — така че щом можете да управлявате NVDA, деветдесет процента от командите на JAWS, които наистина ви трябват, са на едно справочно търсене разстояние. Второ, JAWS е натрупал десетилетия „умно“ извеждане: той се опитва да поправи лошата маркировка, преди потребителят да я чуе, което означава, че грешка, която JAWS прикрива, пак ще се достави до потребителите на NVDA. Умишлено консервативното поведение на NVDA го прави по-добрия еталонен четец, когато се опитвате да научите какво е счупено. Трето, лицензионното триене на JAWS — активирането, четиридесетминутният пробен режим, който досажда при всяко рестартиране — е данък върху ученето, който не е нужно да плащате, докато не сте достатъчно уверени да го изразходвате.

VoiceOver се комбинира с NVDA, вместо да се конкурира с него, защото двата четеца представляват двата доминиращи модела на взаимодействие. NVDA (и JAWS) използват модела „PC курсор“: виртуален буфер, който подрежда страницата като линеен документ, и отделен фокус, който следва реда на табулиране. VoiceOver използва единен VoiceOver курсор, който живее върху фокуса, навигиран чрез ротора и чрез клавишите VO+стрелка. Разработчик, който владее само един модел, ще пише код, който се съобщава добре в неговия четец и зле в другия. Усвояването на двата едновременно е единственият надежден начин да усетите разликата.

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

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

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

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

Моделът за трета седмица е форми. Изградете частна тестова страница с осем или десет контрола: задължително текстово поле с вградена грешка, избор на дата, многократен избор, потребителски стилизиран чекбокс, деактивиран бутон, който се активира, превключвател „покажи паролата“, поле за телефонен номер с избор на код на държава и бутон за изпращане, който задейства резюме на валидиране от страна на сървъра. Мониторът изключен, навигирайте през нея пет пъти — първо с NVDA в режим на разглеждане, после NVDA в режим на фокус, после NVDA отново с увеличена настройка за подробни съобщения (Insert+Z, повече за това в раздел пет), после VoiceOver с ротора, после VoiceOver без ротора. Същата форма ще звучи различно пет пъти. Ето как се усеща владеенето отвътре: да забелязваш, че същата маркировка разказва пет различни истории, и да можеш да предвидиш предварително коя ще се възпроизведе.

Четвъртата седмица е навигация. Вземете реален, сложен сайт — портал с документация, работно табло, страница с категория за електронна търговия — и опитайте да намерите конкретна информация, използвайки само преки пътища на екранния четец. Използвайте H, за да прескачате заглавия. Използвайте D (NVDA) или VO+U, после „Ориентири“ (VoiceOver), за да прескачате ориентири. Използвайте 1 до 6, за да прескочите до определено ниво на заглавие. До края на четвъртата седмица навигационните преки пътища следва да са рефлекси, а не избори, така както табулирането и shift-tab вече са.

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

Два допълнителни навика ще спестят повече време от който и да е отделен пряк път. Първо, оставете прегледа на речта на NVDA закачен на втори монитор (или в ъгъл на единствения ви монитор), докато разработвате. Дословният дневник на всяко съобщение е за работата с екранни четци това, което конзолата на инструментите за разработка е за JavaScript: разликата между предположение и знание. Второ, научете се да четете дървото за достъпност в инструментите за разработка на браузъра си — панела Accessibility на Chrome, Accessibility Inspector на Firefox, раздела Audit на Safari. Четецът съобщава това, което съдържа дървото за достъпност, а не това, което съдържа DOM, и двете се разминават достатъчно често, че не можете да дебъгвате живи региони, ARIA или shadow DOM, без да четете дървото директно.

Объркване, което да отбележим още сега, защото изяжда часове през втората и третата седмица: режимът на четене спрямо режима на фокус не е същата ос като „страницата е интерактивна“ спрямо „страницата е документ“. NVDA превключва в режим на фокус автоматично, когато фокусът попадне върху контрол с role=“application”, или върху contenteditable, или върху определени потребителски джаджи, които четецът евристично класифицира като интерактивни — независимо дали страницата е предимно статична. Обратно, богато интерактивно еднстраничнo приложение, чийто коренен елемент е ориентир main и чиито джаджи са добре маркирани нативни бутони, ще остане в режим на разглеждане през почти цялата сесия на потребителя. Режимът е свойство на фокусирания елемент, а не свойство на страницата.

Числата по-долу произлизат от неформално проследяване на около осемдесет разработчици — фронтенд инженери, ръководители на QA, специалисти по достъпност в обучение — в продължение на три години корпоративни обучения и индивидуално менторство. Те не са научно изследване. Достатъчно добри са, за да се планира спрямо тях. Две допускания: целенасочена практика (мониторът изключен, реални задачи, а не „оставих NVDA да работи на фона, докато кодирах“) и фиксирана комбинация от четци (NVDA на Windows и VoiceOver на macOS).

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

Последен показател, за да зададем честно очакванията: разработчиците, които стигат до плато, по наш опит стигат до него между десетия и двадесетия час. Причината почти винаги е една и съща — спират да изключват монитора. Казват си, че вече са „достатъчно добри“, за да тестват с включен екран, с екранен четец, работещ на фона, и с визуално потвърждение на разположение всеки път, когато аудиото е нееднозначно. Не са. Шестнадесетте часа между „полезен“ и „удобство“ изискват изключен монитор, защото това е отрязъкът, в който съобщенията на четеца стават информация, а не шум. Без този натиск мозъкът се връща към зрението и гласът на четеца избледнява до фон. Ако установите, че забавяте темпото, почти винаги е заради монитора.

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

Пътят през него е този по-горе: NVDA и VoiceOver, три сесии през първата седмица с изключен монитор, форми и режими през седмици две до четири, преки пътища в режим за разработчици веднага щом преките пътища в потребителски режим станат рефлекси, общо четиридесет часа, преди да можете да ви се повери сериозна проверка преди издаване. Нищо от това не е новаторско. Работата, която индустрията не е свършила, е да го третира като работа — да планира часовете, да ги защитава от други ангажименти, да приема, че първите десет от тези часове ще изглеждат безполезни, докато изведнъж не станат полезни.

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