Adaptacyjne narzędzia webowe

Narzędzia interakcji

Dla osób, które przy poruszaniu się po internecie polegają na adaptacyjnych narzędziach webowych, sposób, w jaki treść jest budowana i prezentowana, jest wszystkim. Nawet najbardziej zaawansowana technologia wspomagająca na świecie nie potrafi odczytać, ogłosić ani obsłużyć treści, która nie istnieje w dostępnej formie. Przycisk, który w rzeczywistości jest ostylowanym <div>, obraz bez alternatywy tekstowej czy niestandardowa lista rozwijana bez obsługi klawiatury są po prostu niewidoczne — albo, co gorsza, stanowią ślepą uliczkę — dla osób, które każdego dnia polegają na tych narzędziach.

QualiBooth pomaga zrozumieć dwie rzeczy naraz: jak narzędzia użytkownika faktycznie interpretują Twoją treść oraz jakiej treści lub struktury brakuje, co jest uszkodzone lub niejednoznaczne. To właśnie ta kombinacja odróżnia witrynę, która technicznie się ładuje, od takiej, która naprawdę działa dla wszystkich.

Ten przewodnik omawia główne kategorie technologii wspomagających i adaptacyjnych, sposób, w jaki każda z nich oczekuje zachowania witryny, oraz praktyczne kroki, które możesz podjąć, aby budować wraz z tymi narzędziami, a nie przeciwko nim. Wytycza również wyraźną granicę między prawdziwą technologią wspomagającą a nakładkami dostępności — ponieważ te dwie rzeczy są często mylone, a to pomylenie ma realne konsekwencje dla realnych użytkowników.

Co tak naprawdę oznaczają „adaptacyjne narzędzia webowe”

Adaptacyjne narzędzia webowe — częściej nazywane technologią wspomagającą (AT) — to oprogramowanie i sprzęt, które zmieniają sposób, w jaki osoba postrzega interfejs cyfrowy lub go obsługuje. Nie są dodatkami do Twojej witryny; są własnym środowiskiem użytkownika, skonfigurowanym pod jego potrzeby i często używanym godzinami dziennie na tysiącach stron.

Główne kategorie obejmują:

Czytniki ekranu, które przekształcają treść na ekranie w syntetyzowaną mowę lub odświeżany alfabet Braille’a.
Powiększenie ekranu, które powiększa i przelewa część lub całość ekranu.
Urządzenia przełącznikowe (switch access) dla osób, które nie mogą korzystać ze standardowej klawiatury lub myszy.
Sterowanie głosem, które obsługuje interfejs w całości za pomocą komend głosowych.
Wbudowane funkcje przeglądarki i systemu operacyjnego, takie jak tryby wysokiego kontrastu, ograniczenie ruchu i narzędzia do czytania.
Pomoce do czytania i rozumienia, które upraszczają, czytają na głos lub restrukturyzują tekst.

Każda z nich opiera się na tym samym fundamencie: dobrze ustrukturyzowanej, semantycznej, obsługiwalnej klawiaturą stronie zgodnej z ustalonymi standardami. Gdy budujesz zgodnie z WCAG 2.2, tworzysz umowę, od której zależy każde z tych narzędzi.

Czytniki ekranu: struktura jest interfejsem

Czytniki ekranu to najlepiej znana technologia wspomagająca i dla wielu zespołów najtrudniejsza do zaprojektowania — właśnie dlatego, że widoczny układ wizualny niemal nic nie mówi o tym, co czytnik ekranu ogłasza.

Najczęściej używane czytniki ekranu to NVDA i JAWS w systemie Windows, VoiceOver w macOS i iOS oraz TalkBack w systemie Android. Nie „widzą” one Twojej strony; budują model z drzewa dostępności, które wywodzi się z semantyki Twojego HTML i wszelkiego ARIA, które na nim umieścisz.

Czego czytniki ekranu od Ciebie potrzebują

Prawdziwe elementy semantyczne. Używaj <button>, <a>, <nav>, <main>, <h1>–<h6> i <table> zgodnie z ich przeznaczeniem. Nagłówek musi być nagłówkiem, aby użytkownicy mogli przeskakiwać między sekcjami; link musi być linkiem, aby pojawił się na liście linków.
Sensowne alternatywy tekstowe. Każdy informacyjny obraz potrzebuje atrybutu alt, który opisuje jego cel. Obrazy dekoracyjne powinny mieć pusty alt="", aby były pomijane, a nie ogłaszane jako szum.
Programowe etykiety dla kontrolek. Pola formularzy potrzebują powiązanych elementów <label>; przyciski z samą ikoną potrzebują dostępnej nazwy poprzez aria-label lub tekst ukryty wizualnie.
Logiczna hierarchia nagłówków. Nagłówki to główny sposób, w jaki użytkownicy czytników ekranu przeglądają stronę. Pomijanie poziomów lub używanie nagłówków wyłącznie ze względu na rozmiar wizualny psuje tę nawigację.
Poprawne ARIA — i tylko wtedy, gdy potrzeba. ARIA może komunikować stany (rozwinięty, zaznaczony, wyłączony) oraz role niestandardowych widżetów, ale złe ARIA jest gorsze niż żadne. Pierwsza zasada ARIA brzmi: używaj natywnego HTML, gdziekolwiek to możliwe.

Częstym punktem nieporozumień jest różnica między czytnikiem ekranu a zwykłą syntezą mowy. Narzędzie do czytania czyta tekst na głos; czytnik ekranu udostępnia i obsługuje cały interfejs, w tym kontrolki, stany i nawigację. Omawiamy to rozróżnienie szczegółowo w synteza mowy a czytniki ekranu.

Ponieważ narzędzia automatyczne wychwytują tylko ułamek problemów z czytnikami ekranu, jedynym wiarygodnym sposobem, aby dowiedzieć się, jak brzmi Twoja witryna, jest testowanie jej tak, jak robią to użytkownicy. Nasz przewodnik po testowaniu z czytnikiem ekranu opisuje praktyczny proces, a dedykowana ocena z czytnikiem ekranu poddaje temu procesowi Twoje najważniejsze ścieżki użytkownika z udziałem doświadczonych testerów.

Powiększenie ekranu: projektuj dla widoku po przybliżeniu

Osoby słabowidzące często powiększają ekran od 200% do 800% lub więcej, widząc jednocześnie tylko niewielki wycinek strony. Niektórzy używają lupy systemu operacyjnego; inni polegają na powiększeniu przeglądarki lub specjalistycznym oprogramowaniu.

Przy wysokim powiększeniu decyzje dotyczące układu, o których nigdy nie myślisz, stają się krytyczne:

Przelewanie treści (reflow). Treść musi przelewać się do jednej kolumny przy 400% powiększeniu (kryterium sukcesu 1.4.10 WCAG 2.2), aby użytkownicy nie musieli przewijać w dwóch kierunkach, by przeczytać zdanie.
Bliskość powiązanych elementów. Jeśli komunikat o błędzie pojawia się daleko od pola, które opisuje, użytkownik korzystający z powiększenia może nigdy nie zobaczyć ich w tym samym oknie widoku. Trzymaj etykiety, pola wejściowe i informacje zwrotne razem.
Widoczny fokus. Wyraźny, kontrastowy wskaźnik fokusu pozwala użytkownikowi z powiększeniem odnaleźć, gdzie się znajduje, po przeskoczeniu widoku.
Brak utraty treści lub funkcji. Nic nie powinno zostać przycięte, nałożone ani uczynione nieoperacyjnym, gdy tekst jest powiększony do 200% (kryterium sukcesu 1.4.4).

Powiększenie nagradza czyste, responsywne układy, a karze projekty oparte na stałych pikselach oraz treści zależne od najechania kursorem.

Dostęp przełącznikowy i obsługa klawiaturą

Urządzenia przełącznikowe (switch) pozwalają obsługiwać komputer za pomocą jednego lub dwóch prostych sygnałów wejściowych — przycisku, urządzenia typu sip-and-puff lub ruchu głowy — zwykle przez skanowanie elementów interaktywnych po kolei. Dostęp przełącznikowy jest zbudowany na obsłudze klawiatury: jeśli Twoja witryna działa w pełni z klawiatury, prawie na pewno działa też z przełącznikami.

To sprawia, że pełna obsługa klawiaturą jest jedną z najbardziej opłacalnych rzeczy, które możesz zrobić dobrze:

Wszystko osiągalne. Każdy element interaktywny musi być możliwy do skupienia fokusem i obsłużenia bez myszy — linki, przyciski, kontrolki formularzy, menu, okna modalne, karuzele i widżety niestandardowe na równi.
Widoczna, logiczna kolejność fokusu. Fokus powinien przemieszczać się po stronie w kolejności zgodnej z układem wizualnym i kolejnością czytania, a element z fokusem musi być zawsze wyraźnie wskazany.
Brak pułapek klawiaturowych. Użytkownicy muszą mieć możliwość przeniesienia fokusu poza dowolny komponent, w tym osadzone media i okna dialogowe.
Linki pomijające. Link „przejdź do treści głównej” pozwala pomijać powtarzającą się nawigację zamiast przeglądać ją na każdej stronie.

Jeśli klient wypełnia formularz, czy może przejść klawiszem Tab przez każde pole, otworzyć listę rozwijaną, wybrać produkt i wysłać — wszystko bez dotykania myszy? Czy autouzupełnianie przeglądarki będzie współpracować z Twoim kodem? To pytania, na które użytkownicy przełączników i klawiatury odpowiadają o Twojej witrynie, niezależnie od tego, czy je zadasz.

Sterowanie głosem: nazwy i widoczne etykiety mają znaczenie

Narzędzia sterowania głosem, takie jak Dragon, Voice Control i Voice Access, pozwalają użytkownikom wypowiadać komendy w rodzaju „kliknij Wyślij” lub „przewiń w dół”. Aby te komendy działały, widoczna etykieta kontrolki musi odpowiadać jej dostępnej nazwie. To podstawa kryterium sukcesu 2.5.3 WCAG 2.2, Etykieta w nazwie.

Praktyczne wskazówki:

Dostępna nazwa powinna zawierać widoczny tekst. Jeśli przycisk głosi „Wyślij wiadomość”, nie nadawaj mu aria-label „Wyślij formularz” — użytkownik, który powie „kliknij Wyślij wiadomość”, zostanie zignorowany.
Unikaj kontrolek z samą ikoną bez tekstu lub nadaj im dostępną nazwę odpowiadającą prawdopodobnej komendzie głosowej.
Utrzymuj klikalne cele na tyle duże, aby można je było niezawodnie wybrać, co spełnia również kryterium rozmiaru celu w WCAG 2.2.

Funkcje dostępności przeglądarki i systemu operacyjnego

Nie wszystkie narzędzia adaptacyjne to osobne produkty. Nowoczesne przeglądarki i systemy operacyjne mają potężne wbudowane funkcje, które użytkownicy włączają na poziomie całego systemu, a Twoja witryna powinna je automatycznie respektować:

Ograniczenie ruchu. Honoruj zapytanie medialne prefers-reduced-motion, aby wyłączyć lub złagodzić animacje dla użytkowników, u których ruch wywołuje mdłości lub rozprasza.
Tryb ciemny i wysoki kontrast. Obsługuj prefers-color-scheme oraz Windows High Contrast / Forced Colors, aby Twój interfejs pozostawał czytelny, bez walki z ustawieniami użytkownika.
Zmiana rozmiaru tekstu i powiększenie. Używaj jednostek względnych, aby skalowanie tekstu w przeglądarce działało, zamiast blokować rozmiary w pikselach.
Tryby czytania i narzędzia do czytania. Widoki do czytania w przeglądarce oraz narzędzia takie jak Immersive Reader sprowadzają stronę do jej zasadniczej treści — co działa znacznie lepiej, gdy Twój HTML jest semantyczny i wolny od bałaganu.

Te funkcje nic nie kosztują użytkownika i bardzo niewiele Ciebie, a jednak dramatycznie poprawiają komfort szerokiej grupy odbiorców, w tym osób bez zdiagnozowanych niepełnosprawności.

Narzędzia do czytania i rozumienia

Narzędzia do czytania służą osobom z dysleksją, ADHD, niepełnosprawnościami poznawczymi lub ograniczoną umiejętnością czytania w języku strony. Należą do nich lektory syntezy mowy, linijki do czytania, podświetlanie słów, narzędzia do streszczania i tłumaczenia.

Aby dobrze z nimi współpracować:

Pisz prostym, dobrze zorganizowanym językiem z opisowymi nagłówkami i krótkimi akapitami.
Oznacz stronę tak, aby treść główna była łatwa do zidentyfikowania, a kolejność czytania była poprawna.
Unikaj przekazywania znaczenia wyłącznie kolorem, układem lub obrazami — zapewnij odpowiednik tekstowy.
Upewnij się, że język jest zadeklarowany (atrybut lang), aby czytanie i tłumaczenie używały właściwej wymowy i reguł.

Dobra struktura treści pomaga wszystkim narzędziom z tego artykułu naraz, ponieważ wszystkie czerpią z tego samego podstawowego kodu.

Prawdziwa technologia wspomagająca a nakładki dostępności

To rozróżnienie ma największe znaczenie i to tutaj wiele organizacji popełnia błąd.

Prawdziwa technologia wspomagająca — czytniki ekranu, lupy, dostęp przełącznikowy, sterowanie głosem — działa na urządzeniu użytkownika, pod jego kontrolą, i obsługuje Twoją witrynę poprzez jej semantykę i obsługę klawiatury. Użytkownik spędził lata na jej konfigurowaniu. Twoim zadaniem jest po prostu zbudowanie strony, którą te narzędzia potrafią zrozumieć.

Nakładki dostępności to skrypty firm trzecich, które dodajesz do własnej witryny, a które obiecują automatycznie „uczynić ją dostępną”, zwykle za pomocą pływającego widżetu. Nie są substytutem technologii wspomagającej ani rozwiązaniem dla niedostępnej witryny. Oto dlaczego:

Nie potrafią naprawić kodu źródłowego. Nakładki znajdują się na wierzchu strony; nie potrafią niezawodnie wymyślić brakującego tekstu alternatywnego, naprawić uszkodzonych struktur nagłówków ani sprawić, by <div> zachowywał się jak prawdziwy przycisk w każdym czytniku ekranu.
Często wchodzą w konflikt z prawdziwą AT. Wielu użytkowników czytników ekranu zgłasza, że nakładki zakłócają działanie narzędzi, na których już polegają, czasem czyniąc witryny trudniejszymi w użyciu, a nie łatwiejszymi.
Tworzą fałszywe poczucie zgodności. Zainstalowanie widżetu nie spełnia WCAG 2.2, EAA ani ADA. Pozwy złożono przeciwko witrynom korzystającym z nakładek właśnie dlatego, że bariery u podstaw pozostały.
Nie odzwierciedlają rzeczywistego doświadczenia. Dostępność ostatecznie oceniają osoby, które na co dzień korzystają z AT — dlatego przeprowadzamy audyty wykonywane przez osoby z niepełnosprawnościami, zamiast polegać na zapewnieniach skryptu.

Wiarygodna droga to naprawienie dostępności w kodzie i zweryfikowanie jej zarówno testami automatycznymi, jak i z udziałem ludzi. Wyjaśniamy tę filozofię szerzej w co oznacza prawdziwa dostępność cyfrowa.

Praktyczny proces budowania z narzędziami adaptacyjnymi

Budowanie dla technologii wspomagających nie jest jednorazowym projektem; to proces, który wpisuje się w sposób, w jaki już dostarczasz oprogramowanie. Zrównoważone podejście zwykle łączy cztery rzeczy:

Skanowanie automatyczne, wcześnie i często. Narzędzia takie jak oprogramowanie do skanowania dostępności wychwytują dużą liczbę problemów na poziomie kodu — brakujące etykiety, błędy kontrastu, uszkodzone ARIA — zanim trafią one na produkcję. Kontrole automatyczne są szybkie i powtarzalne, ale obejmują tylko część obrazu.
Testy ręczne i z technologią wspomagającą. Problemy najbardziej dotykające realnych użytkowników — mylna kolejność fokusu, niejasne komunikaty, nieużywalne widżety niestandardowe — wymagają człowieka. Nasz przewodnik po ręcznych audytach dostępności opisuje, jak uzupełnia to automatyzację.
Osadzenie dostępności w zespole. Traktowanie dostępności jako ciągłej dyscypliny, wspartej przez doskonalenie procesu dostępności, zapobiega powolnemu regresowi, który następuje, gdy poprawki są jednorazowe.
Właściwe narzędzia dla Twojego stosu. Zestaw narzędzi dostępności QualiBooth łączy skanowanie, monitorowanie i raportowanie, a Agora oraz nasza community edition oferują punkty wyjścia dla zespołów na różnych etapach dojrzałości.

Jeśli terminologia z tego artykułu jest dla Ciebie nowa, słownik dostępności będzie przydatnym towarzyszem podczas wdrażania tych praktyk.

Gdzie wpisuje się QualiBooth

QualiBooth identyfikuje problemy na Twojej istniejącej witrynie, a także potrafi skanować strony, zanim wejdą na żywo, dzięki czemu klienci korzystający z dowolnego narzędzia adaptacyjnego otrzymują płynne doświadczenie, które zwiększa użyteczność i lojalność wobec marki. Łączymy automatyczne wykrywanie z oceną doświadczonych testerów oraz osób z niepełnosprawnościami, a następnie pomagamy Twojemu zespołowi przekuć ustalenia w trwałe poprawki — nigdy w nakładkę, która maskuje problem.

Cel jest prosty: witryna, która działa wraz z narzędziami, którym Twoi użytkownicy już ufają, na ich warunkach, za każdym razem, gdy ją odwiedzają.

Gotów zobaczyć, jak Twoja witryna radzi sobie z prawdziwą technologią wspomagającą? Uruchom bezpłatne skanowanie dostępności, aby wychwycić szybkie usprawnienia, poproś o demo, aby zobaczyć QualiBooth w działaniu, lub porozmawiaj z naszym zespołem o dopasowanym projekcie doradztwa w zakresie dostępności.