Niemal każdy program dostępności, który poddajemy audytowi, podaje tę samą liczbę: dziewięćdziesiąt kilka procent frontendowych programistów twierdzi, że „testuje z czytnikiem ekranu“. Poproszeni o demonstrację, wykonują zwykle te same trzy czynności — włączają czytnik, przechodzą przez stronę tabulatorem, wyłączają czytnik. To nie jest testowanie. To odhaczenie pozycji na liście.

Przyczyna tego zjawiska jest strukturalna, nie wynika z lenistwa. Czytnik ekranu nie jest narzędziem, które można podjąć tak jak nowy linter. To inny model interakcji z własnym stanem modalnym, własną gramatyką skrótów i zbiorem konwencji, które nabierają sensu dopiero po kilku godzinach realnej pracy. Dopóki nie przekroczy się tego progu, narzędzie mówi nam niemal nic — co gorsza, mówi rzeczy nieprawdziwe, bo komunikaty, które słyszymy, zależą od trybu czytnika, drzewa dostępności przeglądarki i warstwy IME platformy w sposób nieoczywisty z zewnątrz.

Biegłość, na potrzeby tego artykułu, to punkt, w którym można wziąć klawiaturę od kolegi, mając zepsuty komponent, i odtworzyć błąd przy działającym czytniku ekranu — bez patrzenia na ekran, bez ściągawki i bez pogarszania komunikatów ponad to, co użytkownik rzeczywiście słyszy. Znajomość to punkt, w którym słyszało się czytnik ekranu. Dystans między nimi to mniej więcej trzydzieści do trzydziestu pięciu godzin celowych ćwiczeń.

Na rynku istnieją trzy czytniki ekranu istotne dla pracy z webem na desktopie: NVDA na Windows, VoiceOver na macOS i iOS oraz JAWS na Windows. Każdy ma wystarczająco dużą bazę użytkowników, by jego ignorowanie było realnym zakładem, i każdy ogłasza te same znaczniki nieco inaczej. Biegły programista potrafi obsługiwać co najmniej dwa z nich.

Nasza rekomendacja, po obserwowaniu dziesiątek programistów przekraczających próg biegłości, jest jednoznaczna: zacznij od NVDA na Windows i VoiceOver na macOS. Oba są bezpłatne. Oba są zainstalowane z wyprzedzeniem (VoiceOver) lub można je zainstalować w mniej niż pięć minut (NVDA). Oba są używane przez wystarczającą liczbę rzeczywistych użytkowników — NVDA ma ok. 65% udziału w rynku czytników ekranu na Windows w najnowszym badaniu WebAIM, VoiceOver dominuje na urządzeniach mobilnych i znacząco też na macOS — że to, czego się nauczysz, przekłada się bezpośrednio na błędy, na które możesz wydać poprawkę. JAWS to trzecie narzędzie, a nie pierwsze — mimo że nadal ma największą bazę instalacji enterprise. Trzy powody.

Trzy powody pominięcia JAWS na początku są pedagogiczne, nie polityczne. Po pierwsze, JAWS i NVDA dzielą model mentalny — tryb przeglądania i tryb fokusa na Windows, ten sam prefiks poleceń oparty na Insert, ten sam wirtualny bufor — więc gdy już potrafi się obsługiwać NVDA, dziewięćdziesiąt procent faktycznie potrzebnych poleceń JAWS to kwestia jednego spojrzenia do glosariusza. Po drugie, JAWS zgromadził dekady „inteligentnej“ inferencji: stara się naprawiać złe znaczniki, zanim użytkownik je usłyszy, co oznacza, że błąd, który JAWS zamaskuje, nadal dotrze do użytkowników NVDA. Celowo konserwatywne zachowanie NVDA czyni z niego lepszy czytnik referencyjny, gdy szuka się błędów. Po trzecie, tarcie licencyjne JAWS — aktywacja, czterdziestominutowy tryb próbny przypominający o sobie przy każdym restarcie — to podatek od nauki, którego nie warto płacić, dopóki nie osiągnie się wystarczającej pewności siebie.

VoiceOver uzupełnia NVDA, a nie z nim konkuruje, ponieważ oba czytniki reprezentują dwa dominujące modele interakcji. NVDA (i JAWS) używają modelu „PC cursor“: wirtualny bufor układający stronę jako liniowy dokument oraz oddzielny fokus podążający za kolejnością tabulacji. VoiceOver używa pojedynczego kursora VoiceOver znajdującego się nad fokusem, nawigowanego rotorem i klawiszami VO+strzałka. Programista biegły tylko w jednym modelu napisze kod, który dobrze brzmi w jego czytniku, a źle w drugim. Nauka obu jednocześnie jest jedynym niezawodnym sposobem na poczucie tej różnicy.

Program pierwszego tygodnia ma jedną zasadę: wyłącz monitor. Nie przyciemniony, nie zminimalizowany, nie „zamknę oczy“ — fizycznie wyłączony lub zasłonięty kawałkiem kartonu, jeśli to jedyny ekran w pokoju. Celem jest usunięcie możliwości oszukiwania. Instynkt widzącego programisty, gdy czytnik ekranu mówi coś niezrozumiałego, to rzucić okiem na ekran i wizualnie rozwiązać niejednoznaczność. Ten instynkt jest jedyną największą przyczyną tego, że „testowałem z czytnikiem ekranu“ nie wykrywa prawdziwych błędów.

Zaplanuj trzy sesje po około dziewięćdziesiąt minut w pierwszym tygodniu, z co najmniej jednym dniem przerwy między sesjami, aby pamięć mięśniowa miała czas się utrwalić. Każda sesja ma jedno zadanie. Pierwsza buduje podstawową gramatykę poleceń. Druga wymusza prawdziwą interakcję. Trzecia testuje retencję pod niewielką presją.

Drugi do czwartego tygodnia ćwiczeń powinien łącznie dać około dwudziestu godzin pracy — dwie sesje po dziewięćdziesiąt minut tygodniowo i trochę przypadkowego używania przy codziennych zadaniach. Celem tego etapu jest zinternalizowanie dwóch rzeczy, które najbardziej dezorientują nowych użytkowników czytników ekranu: rozróżnienia między trybem przeglądania i trybem fokusa oraz różnicy między tym, co widzi rotor, a tym, co widzi kolejność tabulacji.

Najczęstszym momentem dezorientacji w drugim tygodniu jest sytuacja, gdy programista naciska klawisz strzałki w NVDA, oczekując przesunięcia wirtualnego buforu, a zamiast tego słyszy rozwijającą się listę opcji aktywnej listy wyboru. To tryb przeglądania przełączający się automatycznie w tryb fokusa, bo fokus trafił na element, który NVDA klasyfikuje jako widżet „aplikacji“. Nowi programiści odbierają to jako błąd czytnika. Tak nie jest — to czytnik robiący dokładnie to, czego wymaga specyfikacja. Po usłyszeniu tego dziesięć lub piętnaście razy przestaje się być zaskoczonym; do tamtego momentu należy planować na zaskoczenie mniej więcej co drugą sesję.

Wzorzec trzeciego tygodnia to formularze. Należy zbudować prywatną stronę testową z ośmioma lub dziesięcioma kontrolkami: wymagane pole tekstowe z błędem inline, selektor daty, wielokrotny wybór, ostylowany checkbox, wyłączony przycisk który staje się aktywny, przełącznik „pokaż hasło“, pole numeru telefonu z selektorem kodu kraju i przycisk submit uruchamiający podsumowanie walidacji po stronie serwera. Monitor wyłączony, przejść przez formularz pięć razy — najpierw NVDA w trybie przeglądania, potem NVDA w trybie fokusa, potem NVDA z ustawieniem szczegółowości komunikatów maksymalnie podwyższonym (Insert+Z, więcej o tym w sekcji piątej), potem VoiceOver z rotorem, potem VoiceOver bez rotora. Ten sam formularz będzie brzmiał inaczej pięć razy. Tak biegłość wygląda od środka: dostrzeganie, że te same znaczniki opowiadają pięć różnych historii, i umiejętność przewidzenia z góry, która z nich zostanie odtworzona.

Czwarty tydzień to nawigacja. Weź prawdziwą, złożoną stronę — portal dokumentacji, firmowy dashboard, stronę kategorii w sklepie — i spróbuj znaleźć konkretną informację, używając wyłącznie skrótów czytnika ekranu. Użyj H do skakania po nagłówkach. Użyj D (NVDA) lub VO+U, a następnie „Punkty orientacyjne“ (VoiceOver), by skakać po landmarkach. Użyj klawiszy 1–6, by przejść do nagłówka określonego poziomu. Do końca czwartego tygodnia skróty nawigacyjne powinny być odruchami, a nie decyzjami — podobnie jak już jest z Tab i Shift+Tab.

Gdy polecenia trybu użytkownika stają się odruchami, kolejny krok to przejście do powierzchni każdego czytnika przeznaczonych dla deweloperów. To tryby i skróty zakopane w podręcznikach — częściowo dlatego, że są skierowane do programistów, częściowo dlatego, że są wystarczająco hałaśliwe, by codzienny użytkownik nie chciał ich włączonych. Trzy warto znać od razu.

Dwa dalsze nawyki zaoszczędzą więcej czasu niż jakikolwiek pojedynczy skrót. Po pierwsze, trzymaj podgląd mowy NVDA przypięty na drugim monitorze (lub w rogu jedynego monitora) podczas programowania. Dosłowny log każdego komunikatu jest dla pracy z czytnikami ekranu tym, czym konsola narzędzi deweloperskich jest dla JavaScriptu: różnicą między zgadywaniem a wiedzą. Po drugie, naucz się czytać drzewo dostępności w narzędziach deweloperskich przeglądarki — panel Dostępność w Chrome, Inspektor dostępności w Firefoksie, karta Audit w Safari. Czytnik ogłasza to, co zawiera drzewo dostępności, a nie to, co zawiera DOM, a te dwie rzeczy rozchodzą się wystarczająco często, by debugowanie live regions, ARIA czy shadow DOM bez bezpośredniego odczytu drzewa było niemożliwe.

Jedna kwestia do zasygnalizowania już teraz, bo pochłania wiele czasu w tygodniach drugim i trzecim: tryb czytania a tryb fokusa to nie ta sama oś co „strona jest interaktywna“ a „strona jest dokumentem“. NVDA przełącza się automatycznie w tryb fokusa, gdy fokus trafia na kontrolkę z role=“application”, na contenteditable lub na pewne własne widżety, które czytnik heurystycznie klasyfikuje jako interaktywne — niezależnie od tego, czy strona jest głównie statyczna. Odwrotnie, bogato interaktywna aplikacja jednostronicowa, której główny element to landmark main, a widżety to dobrze oznaczone natywne przyciski, przez większość sesji użytkownika pozostanie w trybie przeglądania. Tryb jest właściwością aktywnego elementu, nie właściwością strony.

Poniższe liczby pochodzą z nieformalnego śledzenia około osiemdziesięciu programistów — frontend engineerów, liderów QA, specjalistów ds. dostępności w szkoleniu — przez trzy lata warsztatów korporacyjnych i mentoringu indywidualnego. To nie jest badanie naukowe. Jest wystarczająco dobre, by planować na jego podstawie. Dwa założenia: celowe ćwiczenia (monitor wyłączony, prawdziwe zadania, nie „zostawiłem NVDA w tle podczas kodowania“) i stała para czytników (NVDA na Windows i VoiceOver na macOS).

„Półbiegłość“ to realistyczny cel dla większości widzących programistów i — w praktyce — wszystko, czego potrzeba, by być dobrym współtwórcą dostępnego produktu. Prawdziwa biegłość — poziom, na którym można by wiarygodnie zastąpić codziennego użytkownika czytnika ekranu podczas przeglądu użyteczności — to około sto pięćdziesiąt godzin i rok przypadkowych ćwiczeń, a większość pracujących programistów jej nie potrzebuje. Celem jest półbiegłość; należy zaplanować czterdzieści godzin i zaakceptować, że wszystko powyżej tego wynika z wykonywania codziennej pracy przy działającym czytniku i gotowości do zwalniania.

Jeszcze jeden wskaźnik, by uczciwie ustawić oczekiwania: programiści, którzy utkną w miejscu, zatrzymują się — według naszych obserwacji — między dziesiątą a dwudziestą godziną. Przyczyną jest niemal zawsze to samo — przestają wyłączać monitor. Mówią sobie, że są już „wystarczająco dobrzy“, by testować z monitorem włączonym, czytnikiem działającym w tle i wizualnym potwierdzeniem dostępnym zawsze, gdy audio jest niejednoznaczne. Nie są. Szesnaście godzin między „użytecznym“ a „komfortowym“ wymaga wyłączonego monitora, bo to etap, na którym komunikaty czytnika stają się informacją, a nie szumem. Bez tej presji mózg wraca do wzroku, a głos czytnika zaciera się w tle. Jeśli zwalnia się tempo, niemal zawsze chodzi o monitor.

Powodem, dla którego „testuj z czytnikiem ekranu“ przynosi tak słabe wyniki w całej branży, nie jest to, że narzędzie jest trudne do nauczenia — czterdzieści godzin to naprawdę niewiele czasu — lecz to, że nauka jest niewygodna w specyficzny sposób. Wyłączenie monitora sprawia, że widzący programista czuje się niekompetentny w sposób niecodzienny w naszym zawodzie. Jesteśmy przyzwyczajeni do bycia ludźmi, którzy rozwiązują problemy; czytnik ekranu sprawia, że przez kilka godzin z rzędu jesteśmy znowu początkującymi. Ta niewygoda — a nie skróty klawiszowe — jest prawdziwą przeszkodą.

Ścieżka przez nią jest taka, jak opisano powyżej: NVDA i VoiceOver, trzy sesje w pierwszym tygodniu z wyłączonym monitorem, formularze i tryby w tygodniach od drugiego do czwartego, skróty trybu deweloperskiego gdy tylko skróty trybu użytkownika staną się odruchami, łącznie czterdzieści godzin zanim będzie można powierzyć poważny przegląd przed wydaniem. Żaden z tych kroków nie jest odkrywczy. Praca, której branża nie wykonała, to traktowanie tego jako pracy — planowanie godzin, obrona ich przed innymi zobowiązaniami, akceptacja, że pierwsze dziesięć z tych godzin będzie czuć się bezużytecznie, aż nagle nie będzie.

Jeśli dostarcza się frontendowe oprogramowanie, wersja ciebie po drugiej stronie tych czterdziestu godzin jest znacznie lepszym inżynierem niż ta, która zaczęła — w sposób widoczny nie tylko w pracy nad dostępnością, ale też w rozumieniu kolejności fokusa, progresywnego rozszerzania i tego, co przeglądarka naprawdę robi pod maską. Czytnik ekranu to najtańsza lekcja z systemów rozproszonych dostępna dla każdego piszącego dla internetu. Ceną jest wyłączony monitor i kilka weekendów.