Co jest przedmiotem pozwów: Przewodnik po wzorcach interfejsu użytkownika leżących u podstaw 6 666 skarg dotyczących dostępności

Nagłówek to pierwszy interaktywny element na każdej stronie, a przycisk „hamburger” jest często pierwszą rzeczą, do której dociera użytkownik korzystający z klawiatury. Gdy przycisk ten jest wyświetlany jako <div> jeśli element zawiera obraz tła CSS, nie ma nazwy ułatwiającej dostęp lub rozwijając menu blokuje fokus albo nie informuje o swoim stanie (otwarte/zamknięte), cała strona staje się strukturalnie niedostępna przy obsłudze za pomocą klawiatury, zanim użytkownik dotrze do jakiejkolwiek rzeczywistej treści.

Link pomijający jest tym samym problemem. Działający "Skip to main content" Link ten wymaga zaledwie pięciu linijek kodu, ale stanowi jednocześnie najskuteczniejszy wskaźnik pozwalający sprawdzić, czy zespół programistów w ogóle uwzględnił kwestię dostępności w swojej liście kontrolnej. W zgłoszeniach często pojawiają się obie te kwestie w tym samym akapicie, ponieważ brakujący lub niedziałający link do pominięcia jest swego rodzaju „kanarkiem” – jeśli zespół nie wdrożył linku do pominięcia, to prawie na pewno nie wdrożył też stanów aria-expanded.

Przedstaw wywołanie menu jako rzeczywiste <button> z etykietą tekstową widoczną lub dostępną wyłącznie dla czytnika ekranu oraz zarządzanym aria-expanded atrybut. Podaj "Skip to main content" link, który staje się widoczny po najechaniu kursorem i prowadzi do strony <main> punkt orientacyjny. Upewnij się, że po otwarciu menu fokus przechodzi do niego, a po zamknięciu wraca do elementu wyzwalającego oraz że Esc zamyka menu.

W większości dużych witryn funkcja wyszukiwania jest zaimplementowana jako niestandardowy komponent — pole tekstowe z wygaszeniem, które wysyła żądanie przy każdym naciśnięciu klawisza i wyświetla pływającą listę sugestii wewnątrz elementu o pozycji absolutnej <div>. Samo pole tekstowe zazwyczaj działa bez zarzutu. Lista sugestii prawie nigdy nie działa poprawnie. Jest ona renderowana poza kontekstem DOM pola tekstowego i nie ma role="listbox", nie aria-activedescendant… i brak komunikatu o aktywnej strefie, gdy pojawiają się wyniki. Użytkownik czytnika ekranu wpisuje tekst, nie słyszy nic, naciska klawisz Enter i otrzymuje stronę z wynikami, o której nie wiedział, że tam czeka.

Ten sam wzorzec architektoniczny powtarza się zarówno w panelach filtrów wyszukiwania fasetowego, jak i na samej liście wyników: elementy, na które można przenieść fokus klawiatury, są widoczne, ale nigdy nie są odczytywane. Skargi dotyczące wyszukiwania rzadko dotyczą samego pola wyszukiwania; dotyczą one wszystkiego, co pojawia się po wpisaniu tekstu przez użytkownika.

Należy zastosować standardowy wzorzec Combobox zgodny z WAI-ARIA: role="combobox" na wejściu z aria-expanded, aria-controlsoraz aria-activedescendant podłączony do role="listbox" sugestii. Dodajcie elegancki obszar interaktywny, który wyświetla liczbę wyników. Upewnijcie się, że do listy sugestii można dotrzeć za pomocą klawisza strzałki w dół, a nie tylko myszką.

Siatka PLP skupia kilka antywzorców na jednym ekranie. Każdy element siatki to zazwyczaj klikalna karta zawierająca trzy lub cztery interaktywne elementy podrzędne — link do obrazu, link do tytułu, próbki kolorów, przycisk szybkiego dodawania — otoczone kolejnym linkiem do strony produktu. Skutkiem tego są zagnieżdżone elementy interaktywne (błąd HTML), zbędny tekst linków („Link do obrazu Hero Dash Three” powtarzający się cztery razy) oraz próbki kolorów zbudowane z <div> elementy z procedurami obsługi kliknięcia, ale bez roli i nazwy.

Pasek boczny filtru wprowadza drugą kategorię błędów. Filtry są zazwyczaj listami pól wyboru, ale tworzone są przy użyciu niestandardowych elementów div i span, stylizowanych tak, by wyglądały jak pola wyboru, przy czym rzeczywiste <input> ukryty poza ekranem. Gdy ten ukryty element wejściowy traci swoje powiązanie — na skutek reguły CSS, procedury obsługi zdarzeń JavaScript, która ignoruje naciśnięcia klawisza spacji, lub braku for atrybut na widocznej etykiecie — filtr można obsługiwać wyłącznie za pomocą myszy.

Używaj jednego linku na produkt z opisem, a nie trzech linków na produkt. Wyświetlaj próbki w rzeczywistym wyglądzie <button> elementy wewnątrz role="radiogroup". Twórz filtry według rzeczywistych <input type="checkbox"> elementy powiązane z <label> tagi; należy stylizować pola wprowadzania danych w sposób widoczny, zamiast je ukrywać. O zmianach w filtrze należy informować za pomocą uprzejmego komunikatu wyświetlanego na bieżąco.

Na stronie szczegółów produktu użytkownik czytnika ekranu musi dokonać kilku konkretnych wyborów w odpowiedniej kolejności: wybrać kolor, wybrać rozmiar, określić ilość, a następnie dodać do koszyka. Każdy z tych wyborów jest w nowoczesnym e-commerce zrealizowany jako niestandardowy widget — zazwyczaj w postaci poziomego rzędu <button>w kształcie <div>Jeśli chodzi o rozmiary, kolorowe kafelki zbudowane z elementów div stylizowanych za pomocą CSS oraz suwak numeryczny złożony z dwóch przycisków z ikonami po obu stronach pola wprowadzania danych. Przyciski zwiększania i zmniejszania są zazwyczaj dostarczane bez nazwy ułatwiającej dostęp; w zgłoszeniach opisuje się je jako ogłoszono jako „button, button” bez żadnej wzmianki o tym, czym się zajmują.

Przewodniki po rozmiarach i tabele rozmiarów to osobny problem: prawie zawsze znajdują się one pod linkiem „Tabela rozmiarów”, który otwiera okno modalne, a sam link często nie ma opisu, okno modalne często nie ma widocznego tytułu, a tabela w środku często nie ma nagłówków wierszy ani kolumn.

Należy stosować prawdziwe elementy formularza. Próbki kolorów i selektory rozmiarów powinny być role="radiogroup" z role="radio" przyciski (lub rzeczywiste pola wyboru stylizowane tak, by były niewidoczne), z których każdy powinien mieć nazwę dostępności, np. „Rozmiar: Średni”. Suwak ilości powinien być oznaczonym polem liczbowym z parą przycisków zwiększania i zmniejszania, których nazwy dostępności zawierają opis działania oraz aktualną ilość. Cały blok wyboru należy umieścić w elemencie `fieldset` z podpisem.

Funkcja „Dodaj do koszyka” to najczęściej testowany etap w każdym lejku e-commerce i jeden z tych, które najczęściej nie działają poprawnie dla użytkowników technologii wspomagających. Schemat jest prosty: użytkownik klika przycisk, na ekranie pojawia się na dwie lub trzy sekundy małe okienko potwierdzenia lub wysuwana szuflada koszyka, a ikona koszyka aktualizuje liczbę produktów w nagłówku. Użytkownicy widzący widzą wszystkie trzy sygnały. Użytkownicy czytników ekranu zazwyczaj nie otrzymują żadnego. Okienko pojawia się poza obszarem aktywnym, wysuwana szuflada pojawia się bez zarządzania fokusem, a zmiana liczby produktów w koszyku jest przekazywana jako zwykła mutacja DOM, której żaden czytnik ekranu nie ogłosi.

W rezultacie powstaje przycisk, który z punktu widzenia użytkownika nie działa. Naciskają go, nie słyszą żadnego dźwięku, zakładają, że coś poszło nie tak, i naciskają go ponownie. W niektórych zgłoszeniach klienci opisują, że naciskali przycisk pięć lub sześć razy, zanim zorientowali się, że do koszyka po cichu trafiło pięć lub sześć produktów.

Otocz obszar „cart-status” tagiem aria-live="polite" i aktualizować jego treść przy każdym pomyślnym dodaniu produktu. Jeśli projekt wykorzystuje okienko potwierdzenia, należy przenieść fokus na to okienko po jego otwarciu i przywrócić fokus do pierwotnego przycisku po jego zamknięciu. Należy zaktualizować znacznik liczby produktów w koszyku, dodając komunikat przeznaczony wyłącznie dla czytników ekranu, np. „Dodano 1 produkt. Łącznie w koszyku: 3 produkty”.

Elementy sterujące składające się wyłącznie z ikon zawodzą w przewidywalny sposób: widoczna treść to plik SVG lub znak z czcionki ikonowej, treść dostępna jest pusta, a komunikat czytnika ekranu sprowadza się do strukturalnej roli elementu bez nazwy. Ikona koszyka jest w końcu ogłaszana jako „link” lub „zwinięta”; dymek czatu jako „przycisk”; rząd ikon społecznościowych w stopce jako „link, link, link, link, link”. Użytkownik nie ma możliwości dowiedzieć się, do czego służą.

Ikony koszyka ulegają awariom częściej niż inne ikony z przyczyn technicznych: w wielu implementacjach liczba produktów w koszyku jest renderowana w ramach nazwy dostępowej ikony (np. w pliku SVG ikona zawiera cyfrę „0”), a czytnik ekranu wychwytuje jedynie tę cyfrę. Zgłaszane skargi dotyczą sytuacji, w których ikona koszyka jest odczytywana jako „3, link” lub „0, link”, bez żadnej wskazówki, że „3” odnosi się do liczby produktów w koszyku.

Każdy element sterujący zawierający wyłącznie ikonę musi mieć nazwę dostępności. Dodaj aria-label na przycisku lub umieścić w nim niewidoczną etykietę tekstową: "Shopping cart, 3 items". Należy unikać umieszczania cyfr liczbowych w nazwie dostępności ikony bez odpowiedniego kontekstu. W przypadku ikon dekoracyjnych umieszczonych obok widocznego tekstu należy używać aria-hidden="true" kliknij ikonę i niech tekst pełni rolę etykiety.

Strona kasy wiąże się z większym ryzykiem naruszenia przepisów na każdy piksel niż jakakolwiek inna strona w witrynie sklepu internetowego, a występowanie błędów jest bardzo częste. Lista rozwijana z adresami wyświetlana jako element niestandardowy <div> elementy, które ignorują klawisz spacji. Oznaczenia pól obowiązkowych wyświetlane są wyłącznie jako czerwona gwiazdka, bez aria-required ani żadnego powiązania programowego. Komunikaty o błędach wyświetlane są na czerwono poniżej pola, bez aria-describedby powiązanie pola z błędem oraz brak komunikatu o obszarze aktywnym w przypadku niepowodzenia walidacji. Użytkownik wypełnia formularz, klika „Kontynuuj”, zostaje po cichu przekierowany z powrotem i nie ma możliwości dowiedzieć się, które pola nie przeszły walidacji ani dlaczego.

W setkach zgłoszeń powtarzają się te same uwagi: brak komunikatów o błędach, niejasne komunikaty o błędach, brak możliwości wprowadzenia danych rozliczeniowych. Nie są to pojedyncze usterki. Stanowią one standardowe zachowanie większości komponentów kasowych w systemach e-commerce, które zostały wdrożone bez uwzględnienia kwestii dostępności.

Używaj prawdziwych <label> elementy powiązane z wejściami poprzez for/id. Pola obowiązkowe należy oznaczyć symbolem aria-required="true" i zaznaczaj wymagania za pomocą widocznego tekstu, a nie tylko kolorem. W przypadku niepowodzenia walidacji wyświetl komunikat o błędzie wewnątrz pola aria-describedby cel, podaj pole, w którym wystąpił błąd aria-invalid="true"oraz przenieść fokus klawiatury na pierwsze nieprawidłowe pole. W górnej części formularza należy umieścić obszar podsumowujący błędy wraz z linkami do poszczególnych pól, w których wystąpiły błędy.

Blok płatności jest nietypowy, ponieważ często jest wyświetlany za pomocą osadzonej ramki iframe dostawcy zewnętrznego — Stripe Elements, Braintree Hosted Fields czy wtyczki Adyen. Wewnątrz ramki iframe formularz dostawcy usług płatniczych jest zazwyczaj dobrze oznaczony. Jednak w momencie, gdy strona tworzy własny moduł do wprowadzania danych karty lub otacza osadzone pola niestandardowym układem, który zastępuje etykiety wizualnymi symbolami zastępczymi, cztery pola — numer, data ważności, kod CVV, kod pocztowy — stają się dla czytnika ekranu rzędem pustych pól.

Pole CVV jest najczęściej błędnie oznaczane, ponieważ projektanci często zastępują jego etykietę ikoną znaku zapytania, która otwiera podpowiedź wyjaśniającą, czym jest kod CVV. Podpowiedź nie jest etykietą; pole nadal wymaga nazwy programowej. Gdy jej brakuje, czytnik ekranu odczytuje cały blok płatności jako „edytuj, edytuj, edytuj, edytuj”, a transakcja zostaje przerwana.

Jeśli korzystasz z integracji z polami hostowanymi przez podmiot zewnętrzny, postępuj zgodnie z wytycznymi dostawcy dotyczącymi dostępności — większość z nich udostępnia udokumentowaną metodę oznaczania pól spoza ramki iframe. Jeśli tworzysz niestandardowy moduł do wprowadzania danych, każde pole wprowadzania danych musi mieć rzeczywisty <label> element z widoczną etykietą tekstową oraz autocomplete="cc-number" / cc-exp" / cc-csc" atrybuty, dzięki czemu menedżery haseł i technologie wspomagające mogą rozpoznawać pola według ich przeznaczenia.

Na stronie koszyka powtarza się ten sam błąd, co w przypadku suwaka ilościowego na stronie produktu, ale stawka jest wyższa: użytkownik korzystający z czytnika ekranu, który nie może obsługiwać suwaka, nie jest w stanie sfinalizować zamówienia. Przycisk „Usuń” sam w sobie stanowi antywzorzec — zazwyczaj jest to mała ikona „×” obok każdej pozycji, często bez widocznego tekstu, bez aria-label… i brak komunikatu po usunięciu wiersza. Użytkownik naciska przycisk, który, jak ma nadzieję, służy do usuwania, wiersz znika, a czytnik ekranu milczy. Nie ma możliwości potwierdzenia, że operacja się powiodła.

W kilku zgłoszeniach opisano podobny błąd: suma w koszyku aktualizuje się dynamicznie w miarę zmiany ilości lub usuwania produktów, jednak nowa suma jest wyświetlana jako zwykły tekst DOM poza obszarem aktualizacji na żywo, przez co użytkownik nie ma pojęcia, jaka kwota zostanie mu naliczona.

Każda pozycja powinna zawierać przycisk usunięcia z etykietą (np. "Remove Blue T-Shirt, size M, from cart"). Elementy do zmiany wartości ilości powinny podawać swoją aktualną wartość w ramach nazwy dostępnej dla osób niepełnosprawnych lub poprzez powiązane aktualizacje obszaru aktywności. Suma częściowa koszyka powinna znajdować się wewnątrz elementu aria-live="polite" region, więc zmiany są ogłaszane. Potwierdź usunięcia za pomocą funkcji cofania.

Jest to największa kategoria w zbiorze danych, ponieważ wykrycie tego problemu wiąże się z najniższymi kosztami, a jego zignorowanie – z najwyższymi. Czytnik ekranu przechodzi przez drzewo DOM, napotyka element <input>i odczytuje jego nazwę dostępową — którą oblicza na podstawie następujących elementów, w kolejności: aria-labelledby, aria-label, powiązany <label for>, title atrybut lub symbol zastępczy. Jeśli żadnego z nich nie ma, czytnik ekranu odczytuje jedynie rolę: „pole edycji” lub „edycja, puste”. To sformułowanie, niemal dosłownie, powtarza się w setkach zgłoszeń.

Powód, dla którego jest to tak powszechne, ma charakter strukturalny. Nowoczesne systemy projektowania często wyświetlają tekst zastępczy wewnątrz pola wprowadzania danych jako namiastkę widocznej etykiety, a programiści zakładają, że to właśnie ten tekst zastępczy pełni funkcję etykiety. Tak jednak nie jest. Tekst zastępczy znika, gdy użytkownik zacznie pisać, nie pozostawiając żadnej nazwy programowej, co sprawia, że pole staje się bezużyteczne dla każdego, kto trafi do niego w dalszej części procesu lub powróci do niego po wystąpieniu błędu.

Każdy element sterujący otrzymuje widoczną etykietę, przypisaną programowo. <label for="email">Email</label><input id="email" type="email"> jest wzorcem standardowym. Symbole zastępcze stanowią jedynie dodatkowe wskazówki, a nie pełnoprawne zamienniki. W przypadku elementów sterujących, w których widoczna etykieta jest rzeczywiście niepożądana (pola wyszukiwania, przyciski z ikonami), należy używać aria-label z tekstem opisowym — nigdy z powtórzonym symbolem zastępczym.

Wyrażenie „niezgłoszone lub bez fokusu” pojawia się dosłownie w ponad 400 zgłoszeniach i jest jednym z najczęściej powtarzających się zdań w całym zbiorze danych. Opisuje ono konkretny rodzaj błędu: na stronie pojawia się okno modalne lub okno dialogowe (często automatycznie — rejestracja do newslettera, weryfikacja wieku, potwierdzenie lokalizacji), widoczna treść ulega zmianie, ale czytnik ekranu nie otrzymuje żadnego sygnału, że coś się zmieniło. Fokus pozostaje na stronie bazowej. Użytkownik kontynuuje poruszanie się za pomocą klawisza Tab po tym, co znajdowało się pod okienkiem modalnym, zupełnie nieświadomy, że pojawiło się blokujące okno dialogowe.

To klasyczny przykład okienka modalnego, które zawodzi pod każdym względem: brak role="dialog", nie aria-modal="true", brak programowej zmiany punktu skupienia podczas otwarcia, brak pułapki skupienia podczas otwarcia, brak zamknięcia po naciśnięciu klawisza Esc, brak wyświetlania tytułu. Ponieważ wszystkie te błędy występują łącznie, naprawienie tylko jednego z nich nie przyniesie żadnej poprawy.

Należy stosować sprawdzony wzorzec okna dialogowego (punktem odniesienia jest specyfikacja WAI-ARIA Authoring Practices). Po otwarciu: należy przenieść fokus na pierwszy element w oknie dialogowym, który może przyjąć fokus, ustawić aria-modal="true" oraz role="dialog", nadaj oknu dialogowemu nazwę aria-labelledby wskazując na jego nagłówek. Gdy okno jest otwarte: utrzymuj fokus w oknie dialogowym. Po zamknięciu: przywróć fokus do elementu, który spowodował jego wyświetlenie. Obsługuj klawisz Esc. Jeśli okno modalne przerywa przebieg działania (np. automatyczne odtwarzanie po załadowaniu strony), zapewnij użytkownikowi jeden mechanizm umożliwiający jego trwałe zamknięcie.

Wskaźniki fokusu są zazwyczaj celowo wyłączane przez programistę lub projektanta, który uznał domyślne obramowanie przeglądarki za element zakłócający wygląd i napisał *:focus { outline: none; } do globalnego arkusza stylów. Strona wygląda teraz bardziej przejrzyście dla widzącego użytkownika korzystającego z myszki. Dla widzącego użytkownika korzystającego z klawiatury — w tym dla większości osób z wadami wzroku, osób z niepełnosprawnością ruchową oraz użytkowników poruszających się po stronie bez myszki — strona staje się niemożliwa do użycia. Użytkownik może naciskać klawisz Tab, ale nie widzi, w którym miejscu się znajduje.

Jest to jeden z nielicznych rodzajów błędów, które można dostrzec bez użycia jakichkolwiek technologii wspomagających. Specjalista ds. kontroli jakości, który przejdzie po stronie głównej za pomocą klawisza Tab, nie korzystając z żadnych dodatkowych narzędzi, zauważy ten błąd w mniej niż minutę. Fakt, że zespoły ds. dostępności konsekwentnie wykrywają go na stronach, które stały się przedmiotem sporów sądowych, podczas gdy pomijały go wewnętrzne kontrole, stanowi jeden z najbardziej wiarygodnych sygnałów w zbiorze danych wskazujących, że strona ta w ogóle nie przeszła testów z użyciem klawiatury.

Nigdy nie wyłączaj wszystkiego na raz :focus kontury bez wypełnienia. Należy zastosować styl wyróżniający — zazwyczaj kontur o grubości 2–3 pikseli, zapewniający odpowiedni kontrast zarówno względem samego elementu, jak i jego tła — przy użyciu :focus-visible tak więc wskaźnik pojawia się podczas nawigacji za pomocą klawiatury, ale nie przy kliknięciach myszą. Sprawdź to w przypadku każdego interaktywnego elementu, w tym niestandardowych widżetów, linków wewnątrz kart oraz elementów z tabindex.

Logo jest najczęściej wyświetlanym obrazem na stronie internetowej i jednym z tych, które najczęściej nie działają. Zazwyczaj znajduje się ono w linku przekierowującym z powrotem na stronę główną, ale obraz jest dostarczany bez alt, nie aria-label w linku, bez otaczającego go tekstu. Czytnik ekranu odczytuje jedynie „link”, bez żadnej informacji o tym, dokąd prowadzi. Pomnóż to przez liczbę wszystkich stron w witrynie.

Szersza kategoria — obrazy bez tekstu alternatywnego — obejmuje grafiki banerowe, zdjęcia produktów, ilustracje w sekcji głównej, ikony serwisów społecznościowych oraz ogromny zbiór materiałów graficznych wykorzystywanych w marketingu, które zazwyczaj zawiera typowa strona sklepu internetowego. W skargach dotyczących tej kategorii często podaje się konkretne nazwy plików graficznych, co wskazuje, że biegły powoda przeprowadził automatyczną kontrolę, w wyniku której sporządzono listę wszystkich obrazów, których alt brakowało tego atrybutu lub był on pusty, podczas gdy powinien zawierać opis.

Logo powinno zawierać tekst alternatywny opisujący nazwę firmy, a jeśli logo prowadzi do jakiejś strony, również jej adres — alt="Acme Co. — homepage". Obrazy dekoracyjne otrzymują pusty atrybut alt (alt=""), co celowo uniemożliwia ich wykrycie przez technologie wspomagające. Obrazy informacyjne powinny mieć opisowy tekst alternatywny. Należy unikać automatycznego generowania tekstu alternatywnego na podstawie nazw plików lub opisów tworzonych przez sztuczną inteligencję bez weryfikacji przez człowieka; w rejestrach skarg wielokrotnie pojawiają się przypadki, w których narzędzia nakładkowe opisywały logo firmy jako „niebiesko-żółty znak”.

Czytniki ekranu udostępniają widok „listy linków”, z którego często korzystają doświadczeni użytkownicy, aby w kilka sekund przejrzeć stronę. Widok ten pokazuje wyłącznie tekst linku, oddzielony od otaczającego go akapitu. Strona, na której każdy fragment zapowiedzi wpisu kończy się tagiem „Czytaj dalej” wyświetla się w tym widoku jako piętnaście identycznych wpisów. Strona z pięcioma pustymi linkami — <a href="..."></a>, co często zdarza się, gdy ikony znajdują się w elementach otaczających linki bez tekstu zastępczego — powoduje wyświetlenie pięciu pustych znaków.

Rozwiązanie tego problemu jest powszechnie znane, podobnie jak sama usterka, dlatego ten schemat wciąż pojawia się w zgłoszeniach — jego powtarzalność wskazuje na proces tworzenia oprogramowania, w którym brakuje automatycznego narzędzia do sprawdzania poprawności tekstu linków oraz ręcznej weryfikacji pod kątem zgodności z czytnikami ekranu.

Każdy link musi mieć nazwę ułatwiającą dostęp, opisującą miejsce docelowe lub działanie. Zastąp ogólne sformułowania opisowymi — „Czytaj dalej” staje się „Dowiedz się więcej o wynikach finansowych za III kwartał”. W przypadku linków zawierających wyłącznie ikony należy dodać tekst niewidoczny dla użytkownika lub element aria-label. Przeprowadź automatyczną kontrolę (axe, Lighthouse itp.) pod kątem pustych <a> elementy podczas CI.

W zgłoszeniach dotyczących filmów wideo pojawiają się dwa typowe przypadki. Pierwszy jest oczywisty: film marketingowy, prezentacja produktu lub film instruktażowy jest udostępniany bez napisów, transkrypcji ani żadnej alternatywy tekstowej — w związku z czym osoby niesłyszące lub niedosłyszące nie mają dostępu do tych treści. Drugi jest bardziej subtelny: filmik, który odtwarza się automatycznie po załadowaniu strony, co zakłóca działanie czytnika ekranu i narusza wymagania dotyczące kontroli pauzy/zatrzymania przewidziane w standardzie WCAG 2.2 poziom AA (zgodnie z SC 2.2.2 Pauza, zatrzymanie, ukrycie dla treści ruchomych oraz SC 1.4.2 dla wszelkich treści audio).

W niektórych skargach zawartych w tym zbiorze danych stwierdza się, że „brak napisów na filmach zamieszczonych na stronie internetowej stanowi naruszenie ustawy ADA”, co przedstawia się jako wniosek prawny. To, czy takie ujęcie ma rację bytu, zależy od jurysdykcji i okoliczności; bardziej istotne jest jednak to, że filmy te konsekwentnie nie spełniają wymogów standardu WCAG 2.2 AA, który większość sądów i ugód traktuje jako decydujący punkt odniesienia w zakresie zgodności.

Należy zapewnić zsynchronizowane napisy do wszystkich nagranych wcześniej filmów zawierających dźwięk. Należy również udostępnić transkrypcję tekstową; transkrypcje są przydatne dla użytkowników korzystających z urządzeń z wyciszonym dźwiękiem, w środowiskach o niskiej przepustowości oraz do celów indeksowania. Należy unikać automatycznego odtwarzania; jeśli automatyczne odtwarzanie jest konieczne ze względów projektowych, należy zapewnić przycisk pauzy/zatrzymania, który można natychmiast uruchomić za pomocą klawiatury. W przypadku treści zawierających wyłącznie obraz (bez dźwięku) należy zapewnić audiodeskrypcję lub alternatywę tekstową.

Logowanie stanowi punkt kontrolny całego procesu uwierzytelniania. Gdy formularz zawodzi, wszystkie kolejne strony stają się niedostępne, a użytkownicy często postrzegają tę kaskadę jako jedną przeszkodę. Wzorzec ten jest taki sam jak w przypadku błędu E·01 związanego z etykietowaniem formularza, często w połączeniu z trzema konkretnymi podbłędami: przełącznikiem „Pokaż hasło” zaimplementowanym jako przycisk zawierający wyłącznie ikonę, bez nazwy i bez komunikatu o zmianie stanu, CAPTCHA, która całkowicie uniemożliwia korzystanie z czytnika ekranu, oraz błędy wbudowane („nieprawidłowe dane uwierzytelniające”), które są wyświetlane na ekranie, ale nie są odczytywane.

Pole wyboru „Zapamiętaj mnie” to kolejny powtarzający się błąd drugorzędny: wyświetlane jako stylizowany <div>, przy czym rzeczywista <input> Ponieważ pole wyboru jest ukryte poza ekranem, można je obsługiwać za pomocą myszy, ale nie za pomocą klawiatury ani czytnika ekranu. Użytkownik nie ma możliwości włączenia trybu trwałej sesji.

Używaj prawdziwych <input>, <label>oraz <button> elementy. Spraw, by przełącznik „pokaż/ukryj hasło” stał się prawdziwym przyciskiem z nazwą ułatwiającą dostęp, która zmienia się wraz ze stanem ("Show password" / "Hide password") oraz ogłosić tę zmianę za pomocą aria-pressed. Zapewnij alternatywę dla CAPTCHA opartych na obrazkach (CAPTCHA dźwiękowa lub — najlepiej — zastąp CAPTCHA uwierzytelnianiem opartym na ocenie ryzyka lub wersjami hCaptcha dostosowanymi do potrzeb osób niepełnosprawnych).

Czytniki ekranu udostępniają zawartość strony w trzech trybach nawigacji: według nagłówków, według punktów orientacyjnych i według linków. Strona, która nie zawiera <h1>, bez <main>, <nav>oraz <footer> zabytki, a bez lang="en" atrybut w <html> element ten pozbawił użytkowników wszystkich trzech trybów nawigacji jednocześnie. Użytkownicy nie mają możliwości przeglądania treści, nie mogą przejść bezpośrednio do wybranej sekcji, a czytnik ekranu nie może załadować odpowiedniego modułu wymowy.

Jest to niezwykle poważna usterka: brak jednego punktu orientacyjnego powoduje lawinę problemów w dalszej części strony, ponieważ wszystkie strategie nawigacji czytników ekranu, które się na nim opierają, przestają działać. Zgłoszenia tej kategorii zazwyczaj wymieniają jednocześnie cztery lub pięć konkretnych problemów strukturalnych, co stanowi dowód na brak semantycznej podstawy w witrynie.

Każda strona otrzymuje dokładnie jedną <h1>, z podtytułami (<h2>, <h3>) uporządkowane logicznie. Otocz regiony elementami orientacyjnymi HTML5: <header>, <nav>, <main>, <aside>, <footer>. Ustaw lang w katalogu głównym <html> element. Sprawdź poprawność za pomocą narzędzia do sprawdzania konturu lub uruchom document.querySelectorAll('h1').length === 1 jako test sprawdzający w CI.

Większość testów zapewnienia dostępności przeprowadza się w przeglądarkach stacjonarnych przy użyciu programów NVDA lub JAWS. Mobilne technologie wspomagające — VoiceOver w systemie iOS czy TalkBack w systemie Android — wyświetlają ten sam model DOM w inny sposób, co często wiąże się z występowaniem innych błędów. W zgłoszeniach wielokrotnie pojawia się skrót „mobile SRU” (użytkownik mobilnego czytnika ekranu) w celu wskazania błędów charakterystycznych dla widoku mobilnego: menu hamburgerowe, które działa z NVDA na komputerze stacjonarnym, ale nie reaguje w VoiceOver, przycisk Apple Pay, który jest dostępny na laptopie, ale nie na stronie przeznaczonej dla iPhone'a, komunikaty o błędach wyświetlane na komputerze stacjonarnym, ale nie na urządzeniu mobilnym.

Z danych wynika, że pozwani, których strony działają bez zarzutu na komputerach stacjonarnych, nadal są pozywani z powodu problemów związanych z wersjami mobilnymi. Zgodność z wersjami mobilnymi stanowi osobny kryterium pozytywnego wyniku audytu.

Należy przeprowadzić testy przy użyciu funkcji VoiceOver w przeglądarce Safari na iOS oraz TalkBack w przeglądarce Chrome na Androidzie, przynajmniej w odniesieniu do tych samych scenariuszy, które obejmuje kontrola jakości na komputerach stacjonarnych. Należy zwrócić szczególną uwagę na interakcje oparte na gestach, natywne przyciski płatności oraz komunikaty dotyczące pól formularza po uzyskaniu przez nie fokusu. Jeśli istnieje aplikacja natywna, należy poddać ją tej samej kontroli — zgłoszenia często dotyczą zarówno strony internetowej, jak i aplikacji w ramach tej samej sprawy.

Nakładka ułatwiająca dostępność jest jedyną pozycją w tym katalogu, w której problem nie leży w ogóle po stronie samej witryny — wynika on z warstwy, która miała ten problem rozwiązać. Skargi z tej kategorii wskazują na dwie odrębne szkody. Po pierwsze, nakładki w rzeczywistości nie eliminują istniejących barier, więc użytkownik napotyka te same wadliwe okna modalne, błędnie oznaczone formularze i niekomunikowane błędy, niezależnie od tego, czy nakładka jest aktywna. Drugi jest bardziej konkretny: nakładki czasami wprowadzają nowe błędy poprzez wstawianie nieprawidłowych etykiet, niewłaściwe stosowanie ról ARIA lub zakłócanie konfiguracji technologii wspomagających użytkownika.

Warto zwrócić uwagę na jedną rzecz: w skargach z lat 2024 i 2025 coraz częściej wymienia się z nazwy dostawców nakładek. W dwóch konkretnych fragmentach skarg jednoznacznie wskazano firmy UserWay i AccessiBe, a ostatnie działania Federalnej Komisji Handlu (FTC) stworzyły wyraźne ryzyko, że samo dodanie nakładki może stanowić dowód na brak rzeczywistych działań naprawczych — a nie argument obrony w postępowaniu sądowym.

Traktuj nakładki jako sygnał ostrzegawczy, a nie jako rozwiązanie. Jeśli obecnie korzystasz z nakładki, opracuj plan rzeczywistych działań naprawczych, który zajmie się samym kodem źródłowym, a nie tylko zamaskuje problem. Sprawdzonym podejściem jest połączenie następujących elementów: zautomatyzowanego skanera zintegrowanego z procesem ciągłej integracji (CI), ręcznej weryfikacji zgodności z wytycznymi WCAG 2.2 poziom AA, ręcznych testów z wykorzystaniem co najmniej jednego czytnika ekranu i nawigacji wyłącznie za pomocą klawiatury oraz ciągłej kontroli jakości dostępności w ramach procesu projektowania i tworzenia oprogramowania.