Jak korzystać z tego przewodnika

Ten tekst można czytać od początku, ale nie trzeba. Osoba, która chce zrozumieć, dlaczego nie potrafi obsłużyć formularza, może przejść do rozdziałów o klawiaturze, etykietach i błędach. Redaktor przygotowujący nagranie znajdzie osobną część o napisach, transkrypcji i audiodeskrypcji. Projektant aplikacji może rozpocząć od rozdziałów o wielkości przycisków, przeciąganiu i logowaniu. Osoba zamawiająca stronę powinna przeczytać także końcowe części dotyczące całych procesów i odbioru prac.

Przy każdym kryterium podano jego numer oraz poziom. Numer jest jak adres w dużym podręczniku. Dzięki niemu użytkownik, programista i osoba zamawiająca usługę mogą rozmawiać o tym samym wymaganiu. Nie trzeba znać tych numerów na pamięć. W codziennym zgłoszeniu ważniejsze jest jasne wyjaśnienie, co się stało, w którym miejscu i dlaczego nie można ukończyć zadania.

Przewodnik zawiera wszystkie 86 kryteriów sukcesu WCAG 2.2 oraz osobne wyjaśnienie historycznego kryterium 4.1.1, które usunięto z tej wersji. Brak numeru 4.1.1 wśród obowiązujących kryteriów nie jest przeoczeniem. Dodatkowe scenariusze pokazują, jak wymagania łączą się ze sobą podczas jednej czynności. W praktyce użytkownik nie korzysta przecież z osobnego kontrastu, osobnej klawiatury i osobnego komunikatu. Korzysta z usługi, która powinna działać jako całość.

Słowo „sprawdź” w tym tekście oznacza prostą próbę pozwalającą zauważyć problem. Nie każda taka próba stanowi pełny test zgodności. Jeżeli po powiększeniu strony widać wszystkie elementy, to dobry znak, ale jeszcze nie dowód, że wszystkie wymagania dostępności są spełnione. Jeżeli na jednej stronie czytnik odczytuje przyciski poprawnie, nie wynika z tego, że tak samo działa logowanie, koszyk i potwierdzenie płatności.

Czytelnik nie musi instalować wszystkich technologii asystujących ani symulować każdej niepełnosprawności. Własny test klawiaturą pozwala wykryć część barier, ale osoba, która dopiero poznaje czytnik ekranu, nie odtwarza doświadczenia jego wieloletniego użytkownika. Warto łączyć podstawowe sprawdzenia, ocenę specjalistyczną oraz udział osób o różnych potrzebach. Każda z tych perspektyw ujawnia inne problemy.

Co właściwie oznacza dostępność

Wyobraźmy sobie bibliotekę internetową. Można znaleźć książkę, przeczytać opis i nacisnąć przycisk wypożyczenia. Jednak potwierdzenie odbioru przychodzi wyłącznie jako obraz, a instrukcja jego wykorzystania jest nagraniem bez napisów. Pierwsza część usługi wygląda na dostępną, ale nie każdy może ukończyć zadanie. Dostępność należy więc rozumieć przez możliwość uzyskania potrzebnego rezultatu, a nie przez liczbę udogodnień widocznych na stronie.

Dla jednej osoby problemem jest tekst zlewający się z tłem. Dla innej przycisk, do którego nie można dotrzeć klawiaturą. Jeszcze ktoś inny potrafi przeczytać każde słowo, ale nie rozumie, czy naciśnięcie „Kontynuuj” jedynie otworzy kolejny ekran, czy zawrze umowę. Te trudności mają różne przyczyny i potrzebują różnych rozwiązań. Jeden przełącznik kontrastu nie rozwiązuje ich wszystkich.

Dostępność wspiera samodzielność. Osoba niewidoma nie powinna podawać znajomemu hasła tylko dlatego, że przycisk logowania nie ma nazwy. Osoba głucha nie powinna prosić sąsiada o wykonanie obowiązkowego telefonu, gdy może bez problemu porozumiewać się tekstowo. Osoba z ograniczeniami ruchowymi nie powinna rezygnować z zakupu dlatego, że w ostatnim kroku trzeba przeciągnąć mały element na drugi koniec ekranu.

Pomoc drugiego człowieka bywa potrzebna i wartościowa. Problem pojawia się wtedy, gdy system narzuca ją mimo możliwości samodzielnego działania. Wsparcie powinno poszerzać wybór, a nie odbierać prywatność. To ważne szczególnie przy danych o zdrowiu, pieniądzach, sprawach rodzinnych, ocenach szkolnych i korespondencji z urzędem. Użytkownik powinien móc zdecydować, komu i w jakim zakresie ujawni informacje.

Nie każda potrzeba jest stała. Po operacji dłoni ktoś przez kilka tygodni korzysta tylko z klawiatury. W silnym słońcu trudniej odczytać słaby kontrast. W pociągu nie można swobodnie odtwarzać dźwięku. W stresie trudniej zrozumieć złożone instrukcje. Takie sytuacje pomagają dostrzec wartość dostępności, ale nie powinny przesłaniać doświadczeń osób, dla których dana bariera występuje codziennie i decyduje o uczestnictwie w życiu społecznym.

Cztery pytania, które porządkują WCAG

WCAG to wytyczne dotyczące dostępności treści internetowych. Można je uporządkować wokół czterech pytań. Czy potrafię odebrać informację? Czy potrafię obsłużyć stronę? Czy rozumiem treść oraz skutki działania? Czy strona współpracuje z narzędziami, których używam? Oficjalne zasady nazywają się postrzegalność, funkcjonalność, zrozumiałość i solidność, nazywana również kompatybilnością. Źródło: W3C, WCAG 2.2.

Pierwsze pytanie dotyczy odbioru. Zdjęcie wejścia do budynku może wymagać opisu. Nagranie wypowiedzi może wymagać napisów. Treść powinna pozostać czytelna po powiększeniu. Drugie pytanie dotyczy działania. Trzeba móc nacisnąć przycisk, zamknąć okno, zmienić termin i poprawić dane bez jednej narzuconej metody obsługi. Trzecie obejmuje zarówno słowa, jak i przewidywalność. Czwarte przypomina, że strona musi przekazywać programom informacje o swoich elementach.

Przykład prostego formularza pokazuje wszystkie zasady jednocześnie. Etykieta „Adres e-mail” powinna być widoczna i odpowiednio powiązana z polem. Do pola trzeba dotrzeć klawiaturą. Instrukcja powinna wyjaśniać, do czego adres zostanie wykorzystany. Po wysłaniu informacja o powodzeniu powinna dotrzeć również do czytnika ekranu. Poprawienie tylko wyglądu formularza nie zapewnia pozostałych elementów.

W praktyce warto zadawać te pytania na spotkaniu projektowym, zanim powstanie kod. Czy osoba niesłysząca dowie się o błędzie? Czy ktoś używający jednej ręki wybierze datę? Czy użytkownik wie, co stanie się po zamknięciu okna? Czy program odczyta zmianę stanu przełącznika? Takie pytania pozwalają projektować rozwiązania, zamiast dopisywać poprawki dopiero po skardze.

Poziomy A, AA i AAA bez nieporozumień

Poziomy oznaczają zestawy wymagań. Zgodność na poziomie AA obejmuje także poziom A. Zgodność AAA obejmuje wymagania niższych poziomów. Nie jest to system punktowy, w którym dobry wynik kontrastu równoważy niedostępny formularz. Jeżeli wymagane kryterium nie jest spełnione, nie można zastąpić go innym udogodnieniem i uznać sprawy za załatwioną. Zasady zgodności obejmują również całe strony i kompletne procesy. Źródło: W3C, Understanding Conformance.

Poziom A nie oznacza mało ważnych spraw. Znajdują się tam wymagania, bez których niektórzy użytkownicy w ogóle nie skorzystają ze strony. Poziom AAA również nie oznacza luksusu pozbawionego znaczenia. Niektóre jego rozwiązania mogą być kluczowe dla określonej grupy odbiorców. Nie należy jednak przedstawiać każdego kryterium AAA jako powszechnego obowiązku prawnego ani obiecywać pełnej zgodności AAA bez sprawdzenia całego zakresu.

Wyobraźmy sobie poradnię, której pacjenci często potrzebują dodatkowych wyjaśnień. Zespół może świadomie wdrożyć pomoc kontekstową i szczególnie prostą wersję informacji, nawet jeżeli umowa przewiduje poziom AA. To rozsądna decyzja wynikająca z potrzeb odbiorców. Z drugiej strony deklaracja „spełniamy AAA” wymaga czegoś więcej niż kilku bardzo dobrych rozwiązań. Trzeba odróżnić stosowanie wybranych kryteriów od zgodności na określonym poziomie.

Pomocne jest prowadzenie dwóch list. Pierwsza obejmuje wymagania, które trzeba spełnić w danym projekcie. Druga zawiera dodatkowe usprawnienia wynikające z badań z użytkownikami. Osoba zgłaszająca problem nie musi wiedzieć, na której liście powinien się znaleźć. To zadanie zespołu. Ważne, aby uwagi spoza formalnego zakresu nie trafiały automatycznie do kosza. Brak odpowiedniego numeru WCAG nie sprawia, że trudność przestaje istnieć.

Standard, technika i prawo to różne rzeczy

Kryterium opisuje rezultat, który należy osiągnąć. Technika pokazuje jeden ze sposobów dojścia do tego rezultatu. W3C publikuje wyjaśnienia Understanding i materiały techniczne, które pomagają interpretować wymagania. Nie są one jednak dodatkowym zbiorem obowiązkowych kryteriów. Możliwe bywają inne rozwiązania, jeśli rzeczywiście prowadzą do zgodności i działają z technologiami asystującymi. Źródło: W3C, About Understanding Documents.

Prawo określa natomiast, kto ma określone obowiązki, w jakim zakresie i według jakiej podstawy. Nie wystarczy powiedzieć, że pojawiła się nowsza wersja WCAG, aby automatycznie uznać ją za treść każdego obowiązku ustawowego. W umowach również trzeba wskazywać wersję, poziom i zakres. Ten przewodnik objaśnia WCAG 2.2; nie zastępuje analizy właściwej ustawy, normy ani konkretnej umowy.

Dla użytkownika ma to prostą konsekwencję. W zgłoszeniu można opisać barierę i wskazać odpowiadające jej kryterium, ale nie należy zakładać, że każde naruszenie kryterium AAA daje identyczną podstawę żądania wobec każdej firmy. Dla zamawiającego wniosek jest inny: sformułowanie „strona ma być zgodna z WCAG” jest zbyt mało precyzyjne. Trzeba wskazać, co obejmuje zamówienie oraz jak zostanie sprawdzone.

Także norma dotycząca dostępności technologii informacyjnych może obejmować zagadnienia szersze niż sama treść strony. Nie należy traktować wyniku skanera WCAG jako automatycznego dowodu spełnienia wszystkich wymagań dotyczących produktu lub usługi. Przedmiotem oceny może być dokumentacja, pomoc, oprogramowanie, komunikacja i inne elementy. Szczegółowe obowiązki trzeba ustalić oddzielnie, korzystając z aktualnych źródeł właściwych dla danego przypadku.

Jak czytać przykłady i nie zamienić ich w stereotypy

W przykładach występują osoby niewidome, słabowidzące, głuche, słabosłyszące, osoby z ograniczeniami ruchowymi oraz osoby z trudnościami poznawczymi. Nie oznacza to, że wszyscy członkowie danej grupy korzystają z identycznych ustawień. Jedna osoba słabowidząca wybierze powiększenie, druga wysoki kontrast, trzecia czytnik ekranu, a czwarta połączy kilka metod. Dobre rozwiązanie pozostawia przestrzeń na taki wybór.

Nie należy też utożsamiać trudności z mową z trudnościami w rozumieniu. Osoba korzystająca z komunikatora może doskonale rozumieć skomplikowaną umowę. Osoba płynnie mówiąca może natomiast potrzebować prostszego wyjaśnienia procedury. Projektant nie powinien wymagać diagnozy, aby udostępnić czytelne instrukcje lub dodatkowy czas. Ustawienia dostępności powinny wspierać wykonanie zadania, a nie wymuszać publiczne ujawnienie stanu zdrowia.

Przykłady są punktem wyjścia do myślenia, a nie listą wszystkich możliwych użytkowników. Gdy czytamy o formularzu rejestracji, możemy odnieść tę samą zasadę do zapisów na zajęcia, wniosku o dokument i zgłoszenia awarii. Warto jednak zachować ostrożność przy przenoszeniu szczegółów. Inne ryzyko wiąże się z omyłkowym zapisaniem ustawienia, a inne z zatwierdzeniem przelewu. Dostępność nie usuwa potrzeby rozważnego projektowania skutków działania.

Co zapisać, gdy napotkasz barierę

Przydatne zgłoszenie opisuje zadanie: „Chcę wybrać termin wizyty”. Następnie wskazuje miejsce: „Kalendarz na drugim ekranie rejestracji”. Potem opisuje działanie: „Poruszam się klawiszem Tab”. Na końcu wyjaśnia rezultat: „Mogę dotrzeć do zmiany miesiąca, ale nie do żadnego dnia”. Takie informacje często pomagają bardziej niż samo zdanie „strona nie spełnia WCAG”. Można dopisać nazwę przeglądarki i używanej technologii, jeżeli są znane.

Nie trzeba ujawniać diagnozy ani przesyłać prawdziwych dokumentów, żeby pokazać niedostępny przycisk. W zrzucie ekranu warto zasłonić dane osobowe. Przy opisie formularza można wykorzystać fikcyjne dane w środowisku testowym, jeśli jest dostępne. Nie należy wysyłać prawdziwego wniosku tylko po to, aby sprawdzić, co stanie się po naciśnięciu przycisku. Testowanie powinno uwzględniać skutki czynności.

Zespół przyjmujący zgłoszenie powinien odpowiedzieć zrozumiale. Użytkownik potrzebuje wiedzieć, czy problem został potwierdzony, jaki jest sposób wykonania pilnej czynności i kiedy można oczekiwać poprawki. Odpowiedź zawierająca wyłącznie techniczny numer błędu nie rozwiązuje jego sytuacji. Jednocześnie nie warto obiecywać terminu bez uzgodnienia z osobą odpowiedzialną za zmianę. Rzetelna informacja jest częścią dostępnej obsługi.

Postrzegalność: Informacja dostępna różnymi drogami

Pierwsza grupa wymagań dotyczy tego, czy informacja dociera do człowieka. Nie chodzi wyłącznie o widzenie i słyszenie. Ważna jest także możliwość zmiany sposobu prezentacji: powiększenia liter, odczytania struktury dokumentu, zwiększenia odstępów lub zastąpienia obrazu tekstem. Informacja powinna przetrwać te zmiany. Jeśli po powiększeniu znika cena, a po odczytaniu tabeli nie wiadomo, czego dotyczą liczby, treść przestaje spełniać swoją funkcję.

Kryterium 1.1.1 — Treść nietekstowa. Poziom A

Zdjęcia, wykresy i inne elementy nietekstowe potrzebują odpowiednika odpowiadającego ich funkcji. Przycisk graficzny powinien mieć nazwę działania. Dekoracja powinna być pomijana przez technologie asystujące. Specjalne zasady dotyczą między innymi testów zmysłów, mediów oraz CAPTCHA. Samo wpisanie czegokolwiek w opis obrazu nie wystarcza. Objaśnienie W3C: 1.1.1.

Prosty przykład: na stronie poradni umieszczono fotografię wejścia, aby pacjent wiedział, gdzie skręcić. Opis „Budynek” niewiele pomaga. Lepsza informacja brzmi: „Wejście do poradni od ulicy Lipowej, po prawej stronie apteki”. Jeżeli zdjęcie pokazuje także podjazd, warto opisać jego położenie, o ile jest istotne dla celu fotografii. Opis powinien wynikać z tego, co wiadomo, a nie z domysłów autora.

Drugi przykład dotyczy sklepu z ubraniami. Zdjęcie swetra pokazuje wzór, którego nie opisano obok. Osoba niewidoma potrzebuje informacji o tym wzorze, aby dokonać wyboru. Jednak ikona koszyka powinna nazywać działanie „Dodaj do koszyka”, a nie przedstawiać wygląd drucianego kosza. To samo rozróżnienie działa na stronie urzędu: symbol drukarki może znaczyć „Drukuj dokument”, choć jego kształt nie jest ważny dla zadania.

Jak sprawdzić? Przeczytaj teksty alternatywne w kontekście strony. Zapytaj, czy pozwalają zrozumieć te same informacje i wykonać tę samą czynność. Przy wykresie może być potrzebny krótki opis oraz dłuższe wyjaśnienie lub tabela danych. Nie upychaj całego raportu w jednym opisie. Jeśli grafika powtarza tekst obok i niczego nie wnosi, nie każ użytkownikowi słuchać tej samej informacji drugi raz.

Kryterium 1.2.1 — Nagrania zawierające tylko dźwięk albo tylko obraz. Poziom A

Dla nagranego materiału zawierającego wyłącznie dźwięk potrzebna jest tekstowa alternatywa. Dla nagrania samego obrazu należy zapewnić odpowiednik tekstowy albo ścieżkę dźwiękową przekazującą równoważną informację. Wyjątek dotyczy materiału będącego wyraźnie oznaczoną alternatywą istniejącego tekstu. Objaśnienie W3C: 1.2.1.

Wyobraźmy sobie bibliotekę publikującą rozmowę o zapisach na warsztaty. Osoba niesłysząca otwiera stronę i widzi jedynie odtwarzacz. Obok powinien znaleźć się tekst rozmowy, obejmujący także istotne informacje wypowiedziane poza głównym wywiadem. Jeśli prowadzący dopowiada termin zgłoszeń na końcu, ta informacja również powinna trafić do transkrypcji. Krótkie streszczenie „Rozmowa o warsztatach” nie zastępuje treści.

Drugi przykład to niemy film pokazujący zmianę filtra w urządzeniu. Kolejne kroki można opisać tekstowo: otwórz pokrywę, wyjmij zużyty element, włóż nowy zgodnie z oznaczeniem. Opis musi jednak obejmować istotne szczegóły, takie jak kierunek montażu. Osoba niewidoma nie dowie się o nich z samego komunikatu „Film przedstawia wymianę filtra”. Alternatywa powinna przekazywać instrukcję, a nie tylko identyfikować materiał.

Podczas sprawdzania warto porównać nagranie z tekstem fragment po fragmencie. Czy zachowano nazwy, liczby i kolejność? Czy zaznaczono zmianę rozmówcy tam, gdzie ma to znaczenie? Czy tekst znajduje się blisko odtwarzacza i można do niego dotrzeć klawiaturą? Osobną sprawą jest dostępność samego odtwarzacza. Dobra transkrypcja nie naprawia przycisku, którego nie można obsłużyć, ale daje użytkownikowi ważną alternatywną drogę poznania treści.

Kryterium 1.2.2 — Napisy do nagrań. Poziom A

Nagrany materiał z obrazem i dźwiękiem powinien mieć zsynchronizowane napisy obejmujące mowę oraz istotne dźwięki. Wyjątek dotyczy materiału będącego wyraźnie oznaczoną alternatywą tekstu. Napisy nie są tym samym co transkrypcja umieszczona pod filmem. Powinny pozwalać śledzić wydarzenia w czasie odtwarzania. Objaśnienie W3C: 1.2.2.

W filmie o bezpiecznej ewakuacji osoba prowadząca przestaje mówić, a w tle rozlega się alarm. Jeśli napisy obejmują tylko wypowiedzi, osoba głucha nie pozna ważnego sygnału. Potrzebna jest informacja o alarmie. W wywiadzie prowadzonym poza kadrem może być także potrzebne oznaczenie rozmówcy. Czytelnik powinien wiedzieć, kto odpowiada, zwłaszcza gdy wypowiedzi dwóch osób przedstawiają różne stanowiska.

Automatyczne napisy mogą pomóc w przygotowaniu materiału, ale wymagają kontroli. W naszym przykładzie system rozpoznaje „nie składaj wniosku” jako „składaj wniosek”. Jedno pominięte słowo odwraca znaczenie instrukcji. Podobne ryzyko dotyczy dat, kwot i nazw miejscowości. Redaktor powinien odsłuchać całość, sprawdzić podział napisów i upewnić się, że nie zasłaniają ważnych informacji na ekranie.

Praktyczna próba jest prosta: wycisz film i obejrzyj go od początku. Czy rozumiesz, co się dzieje? Czy wiadomo, kiedy ktoś mówi ironicznie lub kiedy istotny dźwięk zmienia sens sceny? Nie każda muzyka potrzebuje rozbudowanego opisu, ale znaczących sygnałów nie można ignorować. Dodatkowo sprawdź, czy napisy można włączyć klawiaturą. Dla użytkownika trudność w odnalezieniu przełącznika może być równie dotkliwa jak brak napisów.

Kryterium 1.2.3 — Audiodeskrypcja albo alternatywa dla nagrania. Poziom A

Dla nagranego materiału audiowizualnego należy zapewnić audiodeskrypcję albo pełną alternatywę tekstową obejmującą istotną treść obrazu i dźwięku. Na tym poziomie istnieje wybór między tymi rozwiązaniami, z wyjątkiem opisanym dla mediów będących alternatywą tekstu. Na poziomie AA trzeba uwzględnić również kryterium 1.2.5. Objaśnienie W3C: 1.2.3.

Film instruktażowy pokazuje, jak złożyć wniosek w portalu. Prowadzący mówi „Teraz klikamy tutaj”, a wskaźnik wskazuje ikonę bez nazwy. Osoba niewidoma słyszy wypowiedź, ale nie poznaje działania. W alternatywie należy napisać, który przycisk wybrać i jaki ekran się pojawi. Audiodeskrypcja może przekazać te informacje podczas odtwarzania. Sam zapis wypowiedzi prowadzącego nadal pozostawi lukę.

Druga sytuacja to film przedstawiający dostępne wejście do muzeum. Kamera pokazuje boczną bramę, przycisk przywołania i windę. Muzyka w tle nie przekazuje żadnej z tych informacji. Tekst powinien opisać trasę i ważne punkty orientacyjne. Warto przy tym oddzielić obserwację od oceny: „Przycisk znajduje się po lewej stronie drzwi” jest konkretniejsze niż „Wejście jest wygodne”. Nie należy obiecywać dostępności, której nie sprawdzono.

Jak skontrolować materiał? Posłuchaj samego dźwięku i zapisz, czego nie da się zrozumieć bez obrazu. Następnie porównaj te braki z alternatywą. Czy opisano napisy pojawiające się tylko na ekranie? Czy uwzględniono istotne działania bez dialogu? Czy zachowano kolejność instrukcji? Taka próba pomaga autorowi, ale przy bardziej złożonych materiałach warto zaprosić użytkownika audiodeskrypcji do oceny zrozumiałości gotowej wersji.

Kryterium 1.2.4 — Napisy na żywo. Poziom AA

Transmisja audiowizualna na żywo wymaga napisów do dźwięku. Chodzi o możliwość śledzenia wydarzenia w czasie jego trwania. Późniejsze opublikowanie transkrypcji jest przydatne, ale nie zastępuje udziału na żywo. Objaśnienie W3C: 1.2.4.

Urząd prowadzi spotkanie internetowe o zmianie organizacji ruchu. Mieszkańcy mogą zadawać pytania tylko podczas transmisji. Osoba głucha potrzebuje napisów w tym samym czasie, aby poznać wyjaśnienia i zareagować przed zakończeniem dyskusji. Jeśli otrzyma tekst następnego dnia, dowie się o decyzjach, lecz utraci możliwość udziału. Widać tu różnicę między dostępem do archiwum a dostępem do wydarzenia.

Organizator powinien wcześniej ustalić, jak powstaną napisy, kto będzie kontrolował ich jakość oraz jak uczestnik je uruchomi. W scenariuszu szkolenia prowadzący otrzymuje listę nazw własnych i trudnych terminów, którą można przekazać osobie przygotowującej napisy. Mówiący nie powinni stale wchodzić sobie w słowo. Dobra organizacja spotkania poprawia także zrozumiałość dla osób słyszących i pomaga później przygotować poprawne nagranie.

Próba techniczna powinna objąć rzeczywisty widok uczestnika. Czy napisy nie zasłaniają slajdów? Czy można je odczytać na telefonie? Czy po udostępnieniu ekranu nadal są dostępne? Czy nazwy przycisków pozwalają odnaleźć funkcję? Jeżeli napisy automatyczne mylą istotne słowa, samo istnienie funkcji nie zapewnia równoważnego przekazu. Potrzebny jest sposób reagowania na błędy. Po zakończeniu wydarzenia nagranie należy ocenić także według wymagań odnoszących się do materiałów nagranych.

Kryterium 1.2.5 — Audiodeskrypcja nagrań. Poziom AA

Istotne informacje wizualne w nagranym materiale audiowizualnym powinny być dostępne w audiodeskrypcji. Jeśli wszystkie ważne informacje obrazu są już przekazane w głównej ścieżce dźwiękowej, dodatkowy opis może nie być potrzebny. Sama transkrypcja nie zastępuje tego wymagania na poziomie AA. Objaśnienie W3C: 1.2.5.

W filmie o nowej aplikacji prowadzący mówi nazwę każdej funkcji i opisuje rezultat jej użycia. Taki sposób przygotowania materiału może ograniczyć potrzebę osobnej ścieżki. Jeśli jednak na końcu pojawia się tylko plansza z terminem zgłoszeń, trzeba przekazać tę informację również dźwiękiem. Najłatwiej zadbać o to podczas pisania scenariusza, zanim film zostanie nagrany i zmontowany.

W innym przykładzie materiał pokazuje ćwiczenie obsługi urządzenia. Osoba prowadząca mówi „Tak jest dobrze”, porównując dwa sposoby ułożenia części. Bez opisu obrazu wypowiedź nie ma wystarczającej treści. Audiodeskrypcja powinna wskazać różnicę, na przykład położenie oznaczenia względem pokrywy. Nie musi opisywać koloru ściany, jeżeli ten kolor nie ma związku z instrukcją. Ważna jest selekcja informacji odpowiadająca celowi filmu.

Przy sprawdzaniu warto zapytać, czy odbiorca może wykonać zadanie po wysłuchaniu materiału. Dobrze brzmiący opis może być niewystarczający, jeśli pomija moment istotnej zmiany. Należy również sprawdzić, jak odnaleźć wersję z audiodeskrypcją i czy jej odtwarzacz działa z klawiaturą. Link opisany jedynie jako „Wersja druga” utrudnia wybór. Czytelna nazwa „Film z audiodeskrypcją” wyjaśnia przeznaczenie bez konieczności zgadywania.

Kryterium 1.2.6 — Język migowy w nagraniach. Poziom AAA

Nagrana treść dźwiękowa w materiale audiowizualnym powinna mieć tłumaczenie na język migowy. Napisy i język migowy odpowiadają na częściowo różne potrzeby. Nie wolno zakładać, że każda osoba głucha odbiera polski tekst pisany równie łatwo albo że każda posługuje się językiem migowym. Objaśnienie W3C: 1.2.6.

W naszym przykładzie instytucja publikuje film wyjaśniający procedurę uzyskania wsparcia. Wersja z tłumaczeniem na polski język migowy pozwala części odbiorców lepiej zrozumieć warunki i kolejne kroki. Tłumacz musi być widoczny w rozmiarze umożliwiającym obserwowanie dłoni, twarzy i ruchu ciała. Małe okienko umieszczone pod dużymi napisami może sprawić, że formalnie dodany przekaz będzie trudny do wykorzystania.

Organizator powinien przygotować tłumacza do terminologii oraz udostępnić mu treść przed nagraniem. Jeśli film dotyczy umowy, nie wystarczy improwizować znaczenia specjalistycznych pojęć. Warto także ocenić kontrast stroju i tła oraz sprawdzić, czy montaż nie ucina gestów. To elementy jakości przekazu, które mają bezpośrednie znaczenie dla odbiorcy, choć osoba nieznająca języka migowego może ich nie zauważyć.

Praktyczny test wymaga udziału osób korzystających z danego języka migowego. Autor słyszący może sprawdzić rozmiar okna, ale nie potwierdzi samodzielnie poprawności tłumaczenia, jeśli nie zna języka. Należy unikać określania krótkiego filmu promocyjnego jako pełnego tłumaczenia długiej instrukcji. Użytkownik powinien otrzymać informacje potrzebne do tej samej sprawy. Warto zachować również napisy, ponieważ odbiorcy mają różne preferencje i mogą korzystać z kilku form przekazu.

Kryterium 1.2.7 — Rozszerzona audiodeskrypcja. Poziom AAA

Gdy przerwy w głównym dźwięku są zbyt krótkie, aby opisać ważne informacje wizualne, potrzebna jest rozszerzona audiodeskrypcja. Może ona zatrzymywać film, przekazywać opis i następnie wznawiać odtwarzanie. Wymaganie dotyczy sytuacji, w których zwykły opis nie mieści niezbędnej treści. Objaśnienie W3C: 1.2.7.

Wyobraźmy sobie film szkoleniowy pokazujący schemat urządzenia, podczas gdy prowadzący mówi bez przerwy. Próba wciśnięcia opisu pomiędzy słowa sprawiłaby, że odbiorca usłyszałby dwa przekazy jednocześnie. W rozszerzonej wersji film zatrzymuje się przy schemacie, a opis wyjaśnia położenie trzech części. Następnie materiał wraca do wypowiedzi. Użytkownik może spokojnie zbudować obraz sytuacji i zrozumieć dalszą instrukcję.

Drugim przykładem jest prezentacja mapy ewakuacyjnej. Nazwy pomieszczeń, kierunki i punkty orientacyjne wymagają czasu. Opis ograniczony do zdania „Na ekranie mapa” nie przekazuje informacji potrzebnych do orientacji. Rozszerzenie pozwala oddzielić wyjaśnienie układu od kolejnych wydarzeń. Ważne jest jednak zachowanie zrozumiałej kolejności, aby odbiorca wiedział, kiedy opis dotyczy zatrzymanego kadru, a kiedy akcja już trwa dalej.

Jak sprawdzić? Najpierw ustal, których informacji nie można pominąć bez utraty sensu. Następnie oceń, czy mieszczą się w naturalnych przerwach. Jeśli nie, nie przyspieszaj opisu do tempa uniemożliwiającego zrozumienie. Sprawdź także sterowanie rozszerzoną wersją. Użytkownik powinien móc zatrzymać odtwarzanie i wrócić do fragmentu. W materiałach edukacyjnych dobra kontrola tempa bywa równie ważna jak sam fakt dodania opisu.

Kryterium 1.2.8 — Pełna alternatywa dla nagrań. Poziom AAA

Nagrany materiał audiowizualny oraz nagranie samego obrazu powinny mieć pełną alternatywę dla mediów zależnych od czasu. Taki tekst przedstawia istotne dźwięki, wypowiedzi, działania i informacje wizualne w odpowiedniej kolejności. Może też wskazywać możliwości interakcji. Objaśnienie W3C: 1.2.8.

Osoba głuchoniewidoma korzystająca z monitora brajlowskiego może potrzebować tekstu, a nie ścieżki dźwiękowej czy napisów zmieniających się w tempie filmu. Pełna alternatywa pozwala poznawać treść we własnym tempie. W naszym przykładzie film pokazuje przebieg zebrania: wypowiedzi, wyniki głosowania wyświetlane na planszy i moment przerwania obrad. Wszystkie te elementy mają znaczenie dla zrozumienia wydarzenia.

Tekst nie powinien być mechanicznym zlepkiem napisów i opisów. Warto oznaczać rozmówców, porządkować wydarzenia i stosować nagłówki. Jeśli pada stwierdzenie „ten wariant”, należy wyjaśnić, do którego wariantu odnosi się gest. Czytelnik nie powinien otwierać filmu, aby rozszyfrować sens transkrypcji. W instrukcji cyfrowej alternatywa może przyjąć postać kolejnych kroków z opisem oczekiwanego rezultatu.

Sprawdzenie polega na przejściu całego materiału i porównaniu go z tekstem. Czy opisano także treści prezentowane jedynie na ekranie? Czy nie pominięto ważnego dźwięku? Czy kolejność informacji pozwala odtworzyć tok wydarzeń? Przy długim nagraniu przydatne są nagłówki i odsyłacze do części. To dobra praktyka organizacyjna: samo udostępnienie kilkudziesięciu stron jednolitego tekstu może przenieść barierę z odbioru filmu na odnalezienie potrzebnego fragmentu.

Kryterium 1.2.9 — Alternatywa dla dźwięku na żywo. Poziom AAA

Treść przekazywana wyłącznie dźwiękiem na żywo powinna mieć alternatywę przekazującą równoważną informację. Może to być bieżący zapis tekstowy, a w odpowiednich przypadkach udostępniony wcześniej tekst, jeżeli rzeczywiście odpowiada temu, co jest nadawane. Objaśnienie W3C: 1.2.9.

Przykład dotyczy internetowej relacji radiowej z konsultacji społecznych. Uczestnik niesłyszący chce poznać pytania mieszkańców oraz odpowiedzi prowadzącego. Udostępniony wcześniej porządek spotkania nie wystarcza, ponieważ nie zawiera spontanicznych wypowiedzi. Potrzebny jest tekstowy przekaz wydarzenia. Jeżeli nadawany jest wcześniej przygotowany komunikat odczytywany bez zmian, równoważny tekst może pełnić inną rolę niż przy swobodnej rozmowie.

W praktyce należy wyraźnie wskazać miejsce dostępu do alternatywy. Link nie powinien być ukryty na innej podstronie ani opisywany jedynie jako „Dodatkowe materiały”. Osoba otwierająca odtwarzacz powinna wiedzieć, że dostępny jest zapis tekstowy. Gdy występuje opóźnienie, organizator powinien uwzględnić je w przebiegu interakcji, na przykład nie zamykać pytań natychmiast po wypowiedzi, zanim tekst dotrze do odbiorców.

Próba przed wydarzeniem powinna objąć pełny łańcuch: mikrofon, przekaz do osoby sporządzającej tekst, publikację i odczyt po stronie uczestnika. Dobrze działający dokument roboczy nie pomaga, jeśli użytkownik nie może go otworzyć. Trzeba też pamiętać o jakości nazw własnych, numerów i poleceń. W komunikacji dotyczącej bezpieczeństwa lub terminów nawet niewielki błąd może zmienić znaczenie informacji. Po wydarzeniu warto udostępnić uporządkowaną wersję archiwalną jako dodatkową pomoc.

Kryterium 1.3.1 — Informacje i relacje. Poziom A

Struktura i związki widoczne na stronie powinny być dostępne także programowo albo opisane tekstem. Nagłówek, lista, tabela i etykieta nie mogą opierać swojego znaczenia wyłącznie na wyglądzie. Technologie asystujące potrzebują informacji o tym, czym jest element i z czym się łączy. Objaśnienie W3C: 1.3.1.

Na stronie poradni duży pogrubiony tekst wygląda jak nagłówek „Przygotowanie do wizyty”. Jeśli w kodzie jest zwykłym akapitem, osoba korzystająca z listy nagłówków może go nie znaleźć. Redaktor powinien zastosować prawdziwy styl nagłówka, a nie tylko zwiększyć rozmiar czcionki. Podobnie wypunktowanie tworzone ręcznie przez wpisywanie myślników może nie przekazać struktury tak dobrze jak prawdziwa lista.

Tabela opłat pokazuje w pierwszej kolumnie nazwę usługi, a w kolejnych ceny. Osoba widząca śledzi wiersz wzrokiem. Czytnik powinien móc powiązać liczbę z odpowiednim nagłówkiem. Jeżeli tabela jest jedynie obrazem albo układem pustych pól, relacje stają się niejasne. W formularzu grupę „Sposób kontaktu” warto połączyć z opcjami „E-mail” i „Telefon”, aby użytkownik wiedział, na jakie pytanie odpowiada.

Jak sprawdzić? Przejrzyj listę nagłówków w narzędziu wspomagającym, odczytaj tabelę komórka po komórce i sprawdź etykiety pól. Nie oceniaj wyłącznie estetyki. Jednocześnie sama obecność znacznika nagłówka nie gwarantuje sensownej struktury. Nagłówek „Inne” nad kilkoma niezwiązanymi sekcjami może być mało użyteczny. Dobra struktura powinna odzwierciedlać znaczenie treści i pomagać szybko przejść do potrzebnej informacji.

Kryterium 1.3.2 — Znacząca kolejność. Poziom A

Jeżeli kolejność treści wpływa na jej znaczenie, powinna być możliwa do prawidłowego ustalenia programowo. Wygląd strony może zmieniać się na telefonie lub po powiększeniu, ale sens nie powinien się rozpadać. Objaśnienie W3C: 1.3.2.

Przykład: instrukcja składa się z czterech kroków rozłożonych w dwóch kolumnach. Wzrokowo czyta się ją od lewej do prawej, ale czytnik otrzymuje najpierw kroki pierwszy i trzeci, a następnie drugi i czwarty. Użytkownik może wysłać dokument przed dodaniem załącznika. Problem nie wynika ze zbyt małej liczby wskazówek, lecz z nieprawidłowej kolejności przekazu.

Inna sytuacja występuje przy kartach produktów. Nazwa jednego produktu pojawia się przed ceną drugiego, bo elementy rozmieszczono niezależnie za pomocą stylów. Osoba słuchająca strony przypisuje kwotę do niewłaściwego przedmiotu. W poprawnej wersji każda karta tworzy spójną całość: nazwa, opis, cena i przycisk. Można zmieniać jej wygląd, zachowując sensowną kolejność odczytu.

Proste sprawdzenie polega na odczytaniu treści liniowo, bez polegania na rozmieszczeniu na ekranie. Czy wiadomo, do czego odnosi się „poniżej”, „następnie” i „ta kwota”? Nie każda różnica kolejności jest błędem; czasem kilka układów zachowuje ten sam sens. Trzeba ocenić znaczenie, a nie wymuszać jeden wzór wizualny. Warto szczególnie sprawdzić formularze, instrukcje, wielokolumnowe artykuły i dokumenty przekształcane do innych formatów, ponieważ właśnie tam kolejność bywa niezamierzenie zmieniana.

Kryterium 1.3.3 — Instrukcje niezależne od samych cech zmysłowych. Poziom A

Instrukcje nie powinny opierać się wyłącznie na kształcie, kolorze, położeniu, orientacji lub dźwięku. Można używać takich wskazówek, ale trzeba dodać sposób rozpoznania dostępny także inną drogą. Objaśnienie W3C: 1.3.3.

Polecenie „Naciśnij zielony przycisk po prawej” może być niezrozumiałe dla osoby niewidomej i kogoś, kto nie rozróżnia kolorów. Na telefonie ten sam przycisk może znaleźć się niżej. Lepiej napisać „Wybierz przycisk Zapisz”. Kolor i położenie można pozostawić jako dodatkową pomoc, ale nazwa pozwala odnaleźć element niezależnie od układu.

W drugim przykładzie kurs internetowy mówi „Po usłyszeniu krótkiego sygnału przejdź dalej”. Osoba niesłysząca nie otrzyma sygnału. Należy zapewnić również komunikat tekstowy lub inne dostępne wskazanie. Nie wystarczy dodać ogólnego zdania na początku kursu, że „czasem pojawią się dźwięki”. Informacja powinna być dostępna w chwili, gdy użytkownik musi podjąć działanie.

Sprawdzając instrukcje, wyszukaj słowa odnoszące się do koloru, kierunku i kształtu. Zapytaj, czy osoba bez tej wskazówki nadal zidentyfikuje element. Dotyczy to także komunikatów pomocy udzielanej przez konsultanta. Zdanie „Kliknij kółko” może być niejasne, jeśli na stronie jest kilka okrągłych ikon. Nazwanie funkcji ułatwia rozmowę obu stronom. Przy projektowaniu szkolenia warto stosować nazwy zgodne z rzeczywistymi etykietami przycisków, aby uczestnik nie musiał tłumaczyć opisu na interfejs.

Kryterium 1.3.4 — Orientacja ekranu. Poziom AA

Treść nie powinna być ograniczona do jednej orientacji ekranu, chyba że określona orientacja jest istotna dla jej działania. Strona powinna zasadniczo działać zarówno pionowo, jak i poziomo. Objaśnienie W3C: 1.3.4.

Osoba korzystająca z wózka ma telefon zamocowany w uchwycie. Nie może łatwo obrócić urządzenia. Jeśli formularz rejestracji wymusza poziomą orientację, użytkownik zostaje zatrzymany przed pierwszym polem. Projektant powinien zadbać o układ dostosowujący się do dostępnej przestrzeni. Sam komunikat „Obróć telefon” nie rozwiązuje sytuacji kogoś, kto fizycznie nie może tego zrobić.

Inny użytkownik trzyma tablet poziomo, ponieważ wtedy wygodniej obsługuje go jedną ręką. Po otwarciu dokumentu aplikacja wymusza pion. Tekst może być czytelny w obu układach, ale interfejs nie pozwala wybrać. W takim przypadku ograniczenie nie wynika z natury treści. Przykłady wymagające określonej orientacji należy rozpatrywać indywidualnie; nie wystarczy powołać się na preferencję projektanta lub estetykę ekranu.

Test jest prosty: otwórz usługę w obu orientacjach i wykonaj to samo zadanie. Sprawdź nie tylko stronę główną, lecz także okna dialogowe, podpisy, wybór daty i potwierdzenie. Zwróć uwagę, czy zmiana orientacji nie usuwa wpisanych danych. Użytkownik nie powinien tracić pracy dlatego, że urządzenie się obróciło. Nawet gdy konkretna treść wymaga jednego układu, warto wyjaśnić powód i zadbać o dostępność pozostałej części usługi.

Kryterium 1.3.5 — Określenie przeznaczenia pól. Poziom AA

Pola zbierające określone informacje o użytkowniku powinny mieć programowo rozpoznawalny cel, jeśli technologia obsługuje taką identyfikację, a cel znajduje się w katalogu WCAG. Dotyczy to na przykład imienia, adresu i danych kontaktowych. Widoczna etykieta pozostaje potrzebna. Objaśnienie W3C: 1.3.5.

Osoba z ograniczoną sprawnością rąk wypełnia adres dostawy. Prawidłowe oznaczenie pól pozwala przeglądarce uzupełnić je zapisanymi danymi. Zamiast kilkudziesięciu naciśnięć wystarcza wybór odpowiedniego zestawu. Dla osoby z trudnościami pamięciowymi zmniejsza to również konieczność przypominania sobie, jak zapisano nazwę ulicy czy numer telefonu. Użytkownik powinien móc sprawdzić i poprawić wynik.

Jeżeli pole „Kod pocztowy” jest oznaczone jako numer telefonu, automatyczne uzupełnianie może wprowadzić błąd. Dlatego nie chodzi o dodanie dowolnego atrybutu, lecz o właściwe określenie celu. W formularzu dotyczącym kilku osób trzeba uważnie rozróżnić dane użytkownika i dane innej osoby. Automatyczne wstawienie własnego adresu do pola adresata może być kłopotliwe, nawet jeśli wizualnie formularz wygląda poprawnie.

Jak sprawdzić? Oprócz przeglądu kodu wykonaj próbę z zapisanym profilem testowym. Czy dane trafiają do właściwych pól? Czy etykiety nadal są widoczne po uzupełnieniu? Czy można zmienić jedną wartość bez kasowania pozostałych? Nie należy mylić tego kryterium z obowiązkiem automatycznego wypełniania każdego pola na świecie. Zakres dotyczy określonych celów informacji, a poprawne wdrożenie powinno pomagać użytkownikowi, nie odbierać mu kontroli nad wysyłanymi danymi.

Kryterium 1.3.6 — Określenie przeznaczenia elementów. Poziom AAA

Cel elementów interfejsu, ikon i regionów strony powinien dać się określić programowo w treści tworzonej w językach znaczników. Pomaga to narzędziom dostosowującym prezentację do potrzeb użytkownika. Jest to szersze zagadnienie niż samo nazwanie pól dotyczących danych osobowych. Objaśnienie W3C: 1.3.6.

Wyobraźmy sobie użytkownika, który rozpoznaje stały symbol pomocy łatwiej niż różne ozdobne ikony. Jeśli cel elementu jest prawidłowo opisany, narzędzia wspomagające mogą lepiej przedstawić jego znaczenie. Podobnie rozpoznawalne regiony głównej treści, nawigacji i wyszukiwania pozwalają uporządkować stronę. Nie chodzi o narzucenie wszystkim jednego wyglądu, lecz o przekazanie znaczenia, na którym można oprzeć dostosowanie.

W portalu edukacyjnym przycisk prowadzący do pomocy raz ma kształt koła ratunkowego, raz dymka, a raz postaci nauczyciela. Osoba z trudnościami poznawczymi musi za każdym razem odgadywać symbol. Spójna prezentacja pomaga, ale ważne jest również to, co interfejs przekazuje programom. Dekoracyjny obrazek bez określonej funkcji nie staje się zrozumiałą kontrolką tylko dlatego, że projektant uważa go za oczywisty.

Sprawdzanie tego kryterium zwykle wymaga wiedzy technicznej i oceny dostępnych mechanizmów semantycznych. Użytkownik może natomiast wskazać objaw: „Nie rozpoznaję, które elementy służą do pomocy”. W projekcie warto ustalić stałe nazwy i przeznaczenia elementów jeszcze przed wyborem ikon. Nie należy obiecywać automatycznej personalizacji, której użyte technologie faktycznie nie zapewniają. Opis programowy powinien być sprawdzony w rzeczywistym środowisku, a nie istnieć wyłącznie w dokumentacji projektu.

Kryterium 1.4.1 — Użycie koloru. Poziom A

Kolor nie może być jedynym wizualnym sposobem przekazania informacji, wskazania działania lub odróżnienia elementów. Można stosować kolory, ale znaczenie powinno wynikać również z tekstu, kształtu, wzoru albo innego dostępnego sygnału. Objaśnienie W3C: 1.4.1.

Formularz zaznacza błędne pola na czerwono. Osoba nierozróżniająca części barw może nie zauważyć różnicy, a osoba niewidoma w ogóle nie odbierze obramowania. Obok pola powinien pojawić się tekst, na przykład „Wpisz numer mieszkania albo zaznacz, że go nie ma”. Sam czerwony kolor nie wyjaśnia także, jaki błąd popełniono. Rozwiązanie może więc jednocześnie poprawić dostępność i zmniejszyć liczbę ponownych prób.

W kalendarzu wolne terminy są zielone, a zajęte czerwone. Lepszy układ zawiera również napisy lub rozpoznawalne oznaczenia z wyjaśnieniem. W wykresie linie można odróżnić nie tylko barwą, ale też rodzajem kreski i podpisem. Nie należy zakładać, że każda osoba zna znaczenie przyjętej palety. Dla jednego odbiorcy niebieski oznacza informację, dla innego jest tylko kolorem bez dodatkowej treści.

Sprawdź stronę po usunięciu koloru lub wyobraź sobie wydruk w odcieniach szarości. Czy nadal wiadomo, które pole jest błędne i która seria na wykresie przedstawia daną wartość? Taka próba nie zastępuje wszystkich testów, ale szybko ujawnia zależność od barwy. Pamiętaj również o linkach w akapicie. Użytkownik powinien móc je rozpoznać bez konieczności przesuwania kursora po każdym słowie i sprawdzania, czy przypadkiem jest odsyłaczem.

Kryterium 1.4.2 — Kontrola dźwięku. Poziom A

Jeżeli dźwięk uruchamia się automatycznie i trwa dłużej niż trzy sekundy, trzeba zapewnić możliwość jego zatrzymania lub wstrzymania albo niezależnej regulacji głośności. Wyłączenie całego dźwięku komputera nie jest równoważne, gdy użytkownik potrzebuje słyszeć czytnik ekranu. Objaśnienie W3C: 1.4.2.

Osoba niewidoma otwiera stronę hotelu. Natychmiast zaczyna grać muzyka, która zagłusza nazwy elementów odczytywane przez program. Użytkownik nie może odnaleźć przycisku wyciszenia, ponieważ nie słyszy nawigacji. Najprostsze rozwiązanie projektowe to pozostawienie decyzji o odtwarzaniu użytkownikowi. Jeśli automatyczny dźwięk jest używany, kontrola powinna być łatwa do znalezienia i obsługi.

Dźwięk może także utrudniać koncentrację osobom z nadwrażliwością sensoryczną. W naszym przykładzie portal edukacyjny odtwarza komentarz powitalny na każdej podstronie. Nawet krótki komunikat, powtarzany wielokrotnie, staje się uciążliwy. Warto zapamiętać wybór użytkownika i nie traktować każdego przejścia jako zgody na ponowne odtwarzanie. To dobra praktyka wykraczająca poza samo sprawdzenie długości pojedynczego dźwięku.

Podczas testu otwórz stronę w nowej sesji i sprawdź zachowanie bez wcześniejszych ustawień. Czy dźwięk pojawia się sam? Czy można go zatrzymać klawiaturą? Czy kontrolka ma zrozumiałą nazwę? Czy regulacja nie wycisza równocześnie technologii asystującej? Warto wykonać próbę z włączonym czytnikiem, ponieważ konflikt dwóch źródeł mowy bywa trudny do przewidzenia na podstawie samego wyglądu strony. Dobrą zasadą redakcyjną pozostaje pytanie, czy automatyczny dźwięk jest w ogóle potrzebny.

Kryterium 1.4.3 — Minimalny kontrast tekstu. Poziom AA

Tekst i obrazy tekstu powinny zasadniczo osiągać kontrast co najmniej 4,5:1, a duży tekst co najmniej 3:1. Duży tekst oznacza w tym kontekście co najmniej 18 punktów albo 14 punktów przy pogrubieniu. Istnieją wyjątki, między innymi dla logotypów, dekoracji i nieaktywnych elementów. Objaśnienie W3C: 1.4.3.

Osoba słabowidząca otwiera formularz, w którym instrukcja ma jasnoszary kolor na białym tle. Widzi ramkę pola, ale nie potrafi przeczytać wymaganego formatu daty. Zwiększenie rozmiaru liter może pomóc, jednak nie usuwa problemu z kontrastem. Projektant powinien dobrać kolory tak, aby instrukcja była czytelna od początku, a nie wymagała odkrycia ukrytego trybu dostępności.

Inny przykład to biały napis na fotografii. Na ciemnej części zdjęcia jest czytelny, ale na jasnym niebie znika. Pomiar jednego punktu nie wystarczy. Trzeba uwzględnić tło, na którym rzeczywiście znajdują się litery. Można użyć jednolitego podkładu lub umieścić tekst obok obrazu. Dla użytkownika liczy się czytelność całego komunikatu, zwłaszcza daty, ceny i ostrzeżenia.

Kontrast warto mierzyć narzędziem, a nie oceniać wyłącznie na oko. Sprawdź tekst zwykły, linki, komunikaty błędów i tekst w przyciskach. Upewnij się, że wybrany wariant kolorystyczny zachowuje wymagane wartości. Wyjątek dla nieaktywnej kontrolki nie powinien być pretekstem do projektowania nieczytelnych instrukcji. Użytkownik nadal potrzebuje rozumieć, dlaczego przycisk jest nieaktywny i co zrobić, aby stał się dostępny. To szersza kwestia użyteczności, którą warto rozwiązać razem z kontrastem.

Kryterium 1.4.4 — Powiększanie tekstu. Poziom AA

Tekst powinien dać się powiększyć do 200 procent bez utraty treści i funkcji, bez konieczności używania technologii asystującej. Kryterium przewiduje wyjątki dla napisów w mediach i obrazów tekstu. Objaśnienie W3C: 1.4.4.

Osoba starsza powiększa stronę sklepu. Nazwy produktów rosną, ale cena mieści się w ramce o stałej wysokości i zostaje ucięta. Użytkownik widzi „129”, nie widząc dalszej części kwoty lub oznaczenia promocji. Poprawny projekt pozwala elementowi zwiększyć wysokość albo zmienić układ. Powiększenie powinno ułatwiać czytanie, a nie tworzyć nową zagadkę.

W formularzu zgłoszenia napis na przycisku po powiększeniu zmienia się z „Zapisz szkic” w samo „Zapisz”. Może to zmienić rozumienie skutku działania. Dlatego trzeba sprawdzać nie tylko akapity, ale także etykiety, przyciski, menu i komunikaty. Szczególną uwagę wymagają okna dialogowe oraz elementy umieszczone blisko krawędzi ekranu. Często właśnie tam pojawia się obcinanie treści.

Praktyczna próba polega na ustawieniu dwukrotnego powiększenia i przejściu typowego zadania. Czy można odczytać wszystkie informacje? Czy pola nie nakładają się na siebie? Czy przycisk zamknięcia pozostaje osiągalny? Nie należy uznawać możliwości powiększenia za sukces, jeśli potem użytkownik musi zgadywać znaczenie uciętych słów. Warto również sprawdzić własne ustawienia rozmiaru tekstu na urządzeniu mobilnym. To dodatkowa perspektywa, ponieważ nie wszyscy korzystają z powiększania całej strony w przeglądarce.

Kryterium 1.4.5 — Tekst zamiast obrazu tekstu. Poziom AA

Jeżeli użyta technologia pozwala uzyskać zamierzony wygląd tekstem, należy używać tekstu zamiast jego obrazu. Wyjątki dotyczą sytuacji, gdy obraz można dostosować do potrzeb użytkownika albo określona prezentacja jest istotna, na przykład w logotypie. Objaśnienie W3C: 1.4.5.

Instytucja publikuje plakat z godzinami przyjęć jako jedyną informację na stronie. Osoba słabowidząca powiększa obraz, ale litery stają się rozmyte. Osoba korzystająca z czytnika nie otrzymuje danych, jeśli nie dodano odpowiedniej alternatywy. Najlepiej umieścić godziny także jako zwykły tekst strony. Wtedy można zmienić wielkość, skopiować nazwę i odnaleźć informację wyszukiwaniem.

W sklepie internetowym cena promocyjna jest częścią banera. Redaktor zmienia grafikę, lecz zapomina o tekście alternatywnym, który pokazuje starą kwotę. Umieszczenie ceny jako tekstu ułatwia aktualizację i ogranicza ryzyko dwóch sprzecznych wersji. Dostępność często poprawia więc również zarządzanie treścią. Nie trzeba rezygnować z atrakcyjnego wyglądu, aby zachować tekstową postać informacji.

Sprawdź, czy da się zaznaczyć i skopiować ważne słowa. To wskazówka, choć nie pełny test. Zapytaj, czy użytkownik może zmienić rozmiar i kolory bez pogorszenia czytelności. Nie każda fotografia zawierająca napis jest zakazanym obrazem tekstu; znaczenie ma funkcja i kontekst. Zdjęcie historycznego szyldu może dokumentować obiekt. Jednak plan wizyt, regulamin i informacja o cenie nie powinny być zamykane w obrazie wyłącznie dlatego, że łatwiej wkleić gotowy plakat.

Kryterium 1.4.6 — Podwyższony kontrast tekstu. Poziom AAA

Podwyższony poziom wymaga zasadniczo kontrastu tekstu co najmniej 7:1, a dużego tekstu co najmniej 4,5:1. Wyjątki są podobne do tych dotyczących minimalnego kontrastu. Wyższy kontrast może pomóc użytkownikom, dla których minimum pozostaje niewystarczające. Objaśnienie W3C: 1.4.6.

Wyobraźmy sobie portal z instrukcjami obsługi sprzętu, z którego korzysta wiele osób słabowidzących. Zespół wybiera ciemny tekst na jasnym, jednolitym tle i wyraźne odsyłacze. Nie czeka, aż użytkownik odnajdzie przełącznik specjalnego trybu. Taki domyślny wygląd może poprawić wygodę czytania wielu osobom, szczególnie przy dłuższych akapitach. Nie oznacza jednak, że wszystkim odpowiada identyczna paleta.

Dla części osób bardzo jasne tło jest męczące. Warto pozostawić możliwość dostosowania kolorów i respektować ustawienia użytkownika. Celem nie jest zmuszanie wszystkich do czarno-białego interfejsu. Podwyższony kontrast opisuje mierzalną relację barw, a indywidualne preferencje mogą wymagać dodatkowych rozwiązań. Projekt powinien zachować czytelność również wtedy, gdy użytkownik wybiera dostępny wariant ciemny.

Sprawdzając stronę, zmierz kontrast w różnych stanach: zwykłym, po wskazaniu i podczas obsługi klawiaturą. Upewnij się, że zmiana motywu nie pozostawia jasnych napisów na jasnym tle albo ciemnych ikon na ciemnym przycisku. Jeżeli zespół wdraża wybrane wymagania AAA, powinien opisywać je precyzyjnie. Sam podwyższony kontrast nie uzasadnia deklaracji zgodności całego serwisu na poziomie AAA. Jest konkretnym usprawnieniem, które należy połączyć z pozostałymi potrzebami odbiorców.

Kryterium 1.4.7 — Cichy podkład dźwiękowy albo jego brak. Poziom AAA

W nagraniach zawierających tylko dźwięk, z mową na pierwszym planie, tło powinno nie występować, dać się wyłączyć albo być zasadniczo co najmniej 20 decybeli cichsze od mowy. Standard przewiduje szczegółowe wyjątki, w tym krótkie dźwięki i określone rodzaje treści. Objaśnienie W3C: 1.4.7.

Osoba słabosłysząca słucha instrukcji składania dokumentów. Pod głosem lektora gra muzyka, która dla autora wydaje się przyjemna, ale utrudnia rozpoznawanie słów. Zwiększenie głośności podnosi zarówno mowę, jak i muzykę. Najprostszym rozwiązaniem jest wersja bez podkładu. Nie trzeba wykorzystywać każdej dostępnej warstwy dźwiękowej, jeśli celem materiału jest przekazanie instrukcji.

W innym przykładzie nagranie powstało w pomieszczeniu z wentylatorem. Stały szum pogarsza zrozumiałość, zwłaszcza w słuchawkach. Warto poprawić warunki nagrania, zamiast liczyć wyłącznie na późniejsze usuwanie zakłóceń. Dobre nagranie głosu pomaga także automatycznemu przygotowaniu transkrypcji, choć jej poprawność nadal wymaga kontroli. Dostępność zaczyna się więc już przy wyborze miejsca i mikrofonu.

Sprawdzenie powinno obejmować odsłuch na zwykłym urządzeniu, nie tylko na studyjnych głośnikach. Pomiar różnicy poziomów wymaga odpowiednich narzędzi; wrażenie autora nie jest wystarczającym dowodem. Zapytaj również, czy użytkownik może wybrać ścieżkę bez muzyki i czy funkcja jest jasno opisana. W materiałach informacyjnych warto rozważyć, czy podkład wnosi jakąkolwiek niezbędną treść. Jeśli nie, jego usunięcie bywa najtańszym i najskuteczniejszym usprawnieniem.

Kryterium 1.4.8 — Prezentacja bloków tekstu. Poziom AAA

Użytkownik powinien mieć mechanizm pozwalający uzyskać określone cechy prezentacji bloków tekstu: wybór kolorów, ograniczoną długość wiersza, brak obustronnego justowania, odpowiednie odstępy oraz powiększenie bez konieczności poziomego przewijania podczas czytania wiersza. Standard podaje konkretne parametry, między innymi do 80 znaków w wierszu, oraz do 40 znaków dla tekstów w językach chińskim, japońskim i koreańskim. Objaśnienie W3C: 1.4.8.

Osoba z trudnościami w śledzeniu tekstu czyta długi regulamin na szerokim monitorze. Wiersz rozciąga się przez cały ekran, a po jego końcu trudno odnaleźć początek następnego. Ograniczenie szerokości kolumny i zwiększenie odstępów może znacznie ułatwić lekturę. Nie trzeba dzielić każdego zdania na osobną stronę. Chodzi o spokojną, przewidywalną prezentację i możliwość dostosowania.

Obustronne justowanie tworzy czasem duże przerwy między wyrazami. Dla części osób wygląda to estetycznie, lecz inni tracą rytm czytania. W portalu edukacyjnym można zastosować wyrównanie do jednej strony oraz czytelne akapity. Użytkownik powinien móc zwiększyć tekst bez konieczności przesuwania całej strony w lewo i prawo po każdym wierszu. Taki ruch jest szczególnie męczący przy ograniczonej sprawności dłoni.

Przy ocenie trzeba sprawdzić mechanizm dostosowania, nie tylko domyślny wygląd. Wymagane parametry odstępów obejmują między innymi interlinię co najmniej półtora w obrębie akapitu oraz odstęp pomiędzy akapitami co najmniej półtora raza większy od odstępu między wierszami. Nie należy mylić tego kryterium z 1.4.12, które dotyczy odporności strony na zmianę odstępów przez użytkownika. Oba zagadnienia łączy cel: czytelnik ma móc dostosować tekst bez utraty informacji.

Kryterium 1.4.9 — Obrazy tekstu tylko w szczególnych sytuacjach. Poziom AAA

Na tym poziomie obrazy tekstu są dopuszczalne zasadniczo wtedy, gdy mają charakter czysto dekoracyjny albo określona postać tekstu jest istotna dla przekazywanej informacji. Logotypy należą do szczególnych przypadków. Zakres jest surowszy niż w kryterium 1.4.5. Objaśnienie W3C: 1.4.9.

Przykład dotyczy elektronicznej gazetki szkoły. Wszystkie artykuły zapisano jako obrazy stron przygotowanych do druku. Uczeń nie może dostosować czcionki, a tekst nie dopasowuje się do małego ekranu. Lepsza wersja zawiera artykuły jako treść strony, z obrazami pełniącymi funkcję ilustracji. Materiał do druku może pozostać dodatkiem, ale nie powinien być jedynym sposobem poznania informacji.

W galerii sztuki fotografia kaligrafii przedstawia wygląd dzieła. Zastąpienie jej zwykłą czcionką usunęłoby ważną część przekazu. To inna sytuacja niż zapisanie godziny otwarcia w ozdobnym banerze. Nadal trzeba pomyśleć o odpowiedniku informacji dla osoby niewidomej, ale nie każda obecność liter na obrazie oznacza ten sam problem. Istotne jest, po co obraz został użyty.

Sprawdź materiały promocyjne, zaproszenia i instrukcje. Redaktorzy często wklejają je jako gotowe grafiki, ponieważ tak otrzymali plik. Warto wprowadzić prostą zasadę obiegu treści: wraz z plakatem należy przekazać tekst źródłowy. Dzięki temu osoba publikująca nie musi przepisywać danych i rzadziej popełnia błędy. To usprawnienie organizacyjne może mieć większy wpływ niż późniejsze poprawianie pojedynczych obrazów. Użytkownik otrzymuje wtedy treść możliwą do odczytu, wyszukania i dostosowania.

Kryterium 1.4.10 — Dopasowanie treści do szerokości. Poziom AA

Treść powinna dać się przedstawić bez utraty informacji i funkcji oraz bez przewijania w dwóch kierunkach przy szerokości odpowiadającej 320 pikselom CSS dla treści przewijanej pionowo. Dla treści przewijanej poziomo stosuje się odpowiedni próg wysokości 256 pikseli CSS. Wyjątki obejmują części wymagające układu dwuwymiarowego. Objaśnienie W3C: 1.4.10.

Osoba słabowidząca powiększa stronę na komputerze do 400 procent. Jeśli akapit zachowuje szerokość dużego monitora, trzeba przesuwać go w obie strony po każdym wierszu. Lepszy układ zawija tekst i umieszcza elementy jeden pod drugim. Użytkownik może wtedy czytać w naturalnej kolejności. Nie chodzi o to, aby cała treść zmieściła się naraz na ekranie, lecz aby dało się ją wygodnie przechodzić.

Tabela porównująca wiele wartości może rzeczywiście potrzebować dwóch wymiarów. Nie oznacza to jednak, że cała strona z tabelą jest zwolniona z dopasowania. Nagłówek, opis i przyciski mogą nadal zawijać się prawidłowo, a sama tabela przewijać w osobnym obszarze. Podobnie mapa potrzebuje przestrzeni, lecz instrukcja korzystania z mapy nie powinna być ucięta.

Próba powinna objąć nie tylko artykuł, ale też banery, menu i elementy przyklejone do krawędzi ekranu. Czasami tekst dopasowuje się dobrze, lecz okno zgód zajmuje całą wysokość i blokuje dostęp. Sprawdź, czy można dotrzeć do przycisków oraz czy żadna informacja nie znika. Zwróć uwagę na długie adresy, nazwy plików i komunikaty błędów. To często one ujawniają sztywne szerokości, których nie widać przy krótkim tekście testowym.

Kryterium 1.4.11 — Kontrast elementów nietekstowych. Poziom AA

Wizualne informacje potrzebne do rozpoznania elementów interfejsu i ich stanów oraz istotne części grafik wymagają zasadniczo kontrastu co najmniej 3:1 względem sąsiadujących kolorów. Istnieją wyjątki, między innymi dotyczące nieaktywnych elementów i niezmodyfikowanych kontrolek przeglądarki. Objaśnienie W3C: 1.4.11.

Pole formularza ma białe tło i niemal niewidoczną jasną ramkę. Osoba słabowidząca czyta etykietę, ale nie potrafi rozpoznać, gdzie znajduje się obszar wpisywania. Wyraźniejsza granica może rozwiązać problem. Nie zawsze konieczna jest ramka; ważne, aby sposób przedstawienia pozwalał rozpoznać kontrolkę. Projektant powinien oceniać funkcję wizualnej informacji, a nie mechanicznie obrysowywać wszystko.

W przełączniku „Powiadomienia” różnica między włączeniem a wyłączeniem jest widoczna tylko jako bardzo subtelna zmiana odcienia. Użytkownik nie wie, jaki stan wybrał. Warto połączyć wyraźną prezentację z tekstem lub pozycją wskaźnika, a stan przekazać również programowo. Wykres z jasnymi liniami na białym tle może podobnie ukrywać dane mimo obecności poprawnej legendy.

Sprawdź elementy w różnych stanach: zaznaczone, rozwinięte, aktywne i z błędem. Nie ograniczaj pomiaru do ekranu początkowego. Upewnij się, że istotne fragmenty grafiki są rozpoznawalne. Dekoracyjne cienie nie muszą spełniać tych samych wymagań co linia pokazująca wynik. Trzeba ustalić, co jest potrzebne do zrozumienia. Warto też pamiętać, że poprawny kontrast nie zastępuje tekstowej alternatywy wykresu ani nazwy przycisku dla czytnika ekranu.

Kryterium 1.4.12 — Odstępy w tekście. Poziom AA

Strona nie powinna tracić treści ani funkcji po zastosowaniu określonych odstępów: interlinii 1,5 wielkości czcionki, odstępu po akapicie dwukrotnej wielkości czcionki, odstępu między literami 0,12 i między wyrazami 0,16 wielkości czcionki. Chodzi o odporność na zmianę, a nie obowiązek ustawienia tych wartości domyślnie. Objaśnienie W3C: 1.4.12.

Użytkownik zwiększa odstępy, ponieważ łatwiej śledzi wtedy tekst. W karcie produktu opis wychodzi poza ramkę i nachodzi na przycisk. Część zdania zostaje ukryta. Poprawny układ pozwala karcie zwiększyć wysokość. Treść powinna mieć pierwszeństwo przed utrzymaniem idealnie równych prostokątów. W przeciwnym razie indywidualne dostosowanie staje się karą zamiast pomocą.

W formularzu dłuższa etykieta po zwiększeniu odstępów przechodzi do drugiego wiersza. Jeśli projekt przewidział tylko jedną linię, nazwa pola może zostać ucięta. To szczególnie niebezpieczne, gdy znika słowo „opcjonalnie” lub fragment odróżniający adres zamieszkania od adresu korespondencyjnego. Warto sprawdzać rzeczywiste polskie nazwy, które bywają dłuższe niż krótkie przykłady użyte podczas projektowania.

Do testu można użyć narzędzia zmieniającego wskazane parametry. Następnie trzeba przejść formularze, menu i okna. Sam fakt, że tekst wygląda inaczej, nie oznacza błędu. Błędem jest utrata informacji albo możliwości działania. Nie należy blokować ustawień użytkownika po to, aby zachować pierwotny wygląd. Rozwiązaniem jest elastyczny układ. Szczególną uwagę warto poświęcić przyciskom, zakładkom i komunikatom, ponieważ mają mniej miejsca niż zwykłe akapity.

Kryterium 1.4.13 — Treść pojawiająca się po wskazaniu. Poziom AA

Dodatkowa treść wyświetlana po najechaniu wskaźnikiem lub uzyskaniu fokusu powinna spełniać warunki dotyczące możliwości zamknięcia, najechania na nią i odpowiedniej trwałości. Standard przewiduje szczegółowe wyjątki. Użytkownik powinien móc przeczytać podpowiedź bez walki z jej znikaniem. Objaśnienie W3C: 1.4.13.

Osoba słabowidząca najeżdża na ikonę informacji. Pojawia się dymek z wyjaśnieniem opłaty. Gdy przesuwa wskaźnik, aby przyjrzeć się tekstowi w powiększeniu, dymek natychmiast znika. Poprawna podpowiedź pozwala przenieść wskaźnik na jej obszar. Jeżeli zasłania inną treść, użytkownik powinien mieć sposób jej zamknięcia bez przymusowego przesuwania wskaźnika lub fokusu, z uwzględnieniem warunków kryterium.

W drugim przykładzie menu rozwija się po przejściu klawiaturą na nazwę działu. Użytkownik zaczyna czytać opcje, ale lista zamyka się po krótkim czasie. Nie powinien ścigać się z interfejsem. Dodatkowa treść powinna pozostawać dostępna tak długo, jak wymagają tego warunki standardu, a jej zniknięcie powinno wynikać z przewidywalnego działania, zmiany ważności informacji lub usunięcia wskazania.

Testuj osobno mysz i klawiaturę. Czy podpowiedź pojawia się również po uzyskaniu fokusu? Czy można ją przeczytać w powiększeniu? Czy klawisz zamknięcia działa bez utraty miejsca? Nie umieszczaj niezbędnej instrukcji wyłącznie w dymku, jeśli prostsze jest pokazanie jej bezpośrednio przy polu. Widoczny tekst często lepiej służy osobom z trudnościami pamięciowymi i użytkownikom ekranów dotykowych, dla których klasyczne najechanie wskaźnikiem nie jest naturalną czynnością.

Funkcjonalność: Możliwość wykonania działania

Informacja może być czytelna, a usługa nadal niedostępna. Użytkownik widzi termin wizyty, lecz nie może go zaznaczyć. Słyszy nazwę okna, lecz nie potrafi go zamknąć. Rozumie formularz, ale czas kończy się przed wpisaniem danych. Ta część przewodnika dotyczy możliwości działania różnymi sposobami i we własnym tempie. Szczególnie ważne jest sprawdzanie całych czynności, ponieważ pojedynczy działający przycisk nie dowodzi dostępności procesu.

Kryterium 2.1.1 — Obsługa klawiaturą. Poziom A

Funkcje powinny być dostępne przez interfejs klawiatury bez wymagania określonego tempa naciskania klawiszy. Wyjątek dotyczy funkcji, których istota zależy od przebiegu ruchu, a nie tylko punktów końcowych. Nie obejmuje to dowolnej funkcji tylko dlatego, że zaprojektowano ją do obsługi myszą. Objaśnienie W3C: 2.1.1.

Osoba z ograniczeniami ruchowymi korzysta z klawiatury i chce wybrać datę. Może wejść do kalendarza, ale dni reagują wyłącznie na kliknięcie. Rozwiązaniem może być prawidłowo obsługiwany kalendarz oraz możliwość wpisania daty. Użytkownik powinien otrzymać jasny format i możliwość poprawienia błędu. Sama obecność pola nie pomaga, jeśli po wpisaniu daty system nadal wymaga kliknięcia niedostępnego dnia.

W sklepie lista produktów działa z klawiaturą, lecz przycisk zmiany liczby sztuk jest pomijany. Klient może kupić jedną sztukę, ale nie dwie. To realna utrata funkcji. Podobnie możliwość otwarcia menu nie wystarcza, gdy nie można przejść do jego pozycji. Trzeba sprawdzać wybór, rozwijanie, zamykanie i potwierdzanie, a nie tylko obecność widocznego zaznaczenia.

Odłóż mysz i wykonaj typowe zadanie klawiszami Tab, Shift i Tab, Enter, spacją oraz strzałkami tam, gdzie pasują do kontrolki. Nie oczekuj, że każda funkcja będzie działać wyłącznie Tabem. Złożone elementy mają własne wzorce obsługi. Zapisuj miejsca, w których działanie staje się niemożliwe. Nie używaj prawdziwych płatności do eksperymentu; sprawdzenia końcowych skutków należy organizować w odpowiednim środowisku testowym.

Kryterium 2.1.2 — Brak pułapki klawiaturowej. Poziom A

Jeżeli można wejść do elementu klawiaturą, trzeba móc z niego wyjść również klawiaturą. Gdy wyjście wymaga nietypowej kombinacji, użytkownik powinien otrzymać informację o sposobie jej użycia. Objaśnienie W3C: 2.1.2.

Użytkownik otwiera mapę osadzoną w portalu. Tab przenosi go pomiędzy przyciskami mapy, lecz nigdy do dalszej części strony. Nie może przejść do formularza zgłoszenia. To pułapka. Podobny problem występuje w niektórych odtwarzaczach i edytorach. Osoba używająca myszy może go nie zauważyć, ponieważ po prostu klika poza elementem.

W oknie dialogowym celowe utrzymanie fokusu wewnątrz może być prawidłowe, jeśli użytkownik może zamknąć okno albo zakończyć działanie. To odróżnia kontrolowane zachowanie od pułapki. Przykład: okno wyboru terminu pozwala przechodzić pomiędzy dniami, a przycisk „Anuluj” zamyka je i przywraca miejsce. Użytkownik nie zostaje uwięziony, ponieważ istnieje dostępna droga wyjścia.

Test wymaga sprawdzenia wejścia i wyjścia w obu kierunkach. Otwórz okno, przejdź jego kontrolki, użyj dostępnego zamknięcia i sprawdź, gdzie wraca fokus. Nie uznawaj odświeżenia strony za normalne rozwiązanie. Odświeżenie może usunąć dane i przerwać pracę. Jeśli element wymaga specjalnego klawisza, instrukcja powinna być dostępna przed utknięciem. Warto także sprawdzić komponenty pochodzące od zewnętrznych dostawców, ponieważ użytkownik odbiera je jako część jednej usługi.

Kryterium 2.1.3 — Pełna obsługa klawiaturą bez wyjątku. Poziom AAA

To kryterium wymaga obsługi wszystkich funkcji przez interfejs klawiatury bez wyjątku dotyczącego funkcji zależnych od przebiegu ruchu. Jest szersze od 2.1.1. Nie należy twierdzić, że spełnienie podstawowego wymagania automatycznie oznacza spełnienie tego poziomu. Objaśnienie W3C: 2.1.3.

Wyobraźmy sobie internetowe narzędzie do tworzenia prostych schematów. Użytkownik może dodawać węzły, łączyć je i zmieniać położenie za pomocą poleceń klawiaturowych. Nie musi przeciągać obiektów myszą. Dla osoby korzystającej z alternatywnego urządzenia wejścia oznacza to możliwość samodzielnego przygotowania tej samej pracy co inni uczestnicy kursu.

W narzędziu rysunkowym zapewnienie takiej równoważności może być trudniejsze. Nie wystarczy dopisać przycisku „Gotowe”, jeśli samą treść nadal można stworzyć tylko swobodnym ruchem wskaźnika. Projekt powinien jasno określić, które funkcje rzeczywiście udostępnia klawiaturą. Jeżeli nie spełnia wymagań AAA, nie należy ukrywać tego za ogólną deklaracją „przyjazny dla wszystkich”. Uczciwa informacja pomaga użytkownikowi wybrać narzędzie.

Przy sprawdzaniu sporządź listę funkcji, a nie tylko listę ekranów. Dodawanie, usuwanie, skalowanie, przesuwanie i zatwierdzanie to odrębne działania. Sprawdź, czy rezultat uzyskany klawiaturą jest równoważny. Nie każ użytkownikowi wykonywać setek niepotrzebnych kroków tam, gdzie można zaprojektować prostą komendę. Formalna możliwość działania i praktyczna wygoda nie są identyczne. Badanie z osobami używającymi klawiatury pomaga ocenić oba te aspekty i ustalić, które funkcje wymagają przeprojektowania.

Kryterium 2.1.4 — Skróty z pojedynczych znaków. Poziom A

Skróty wykorzystujące wyłącznie znaki, takie jak litery lub cyfry, powinny dać się wyłączyć, zmienić na kombinację z klawiszem nieznakowym albo działać tylko wtedy, gdy odpowiedni element ma fokus. Chroni to przed przypadkowym uruchamianiem funkcji. Objaśnienie W3C: 2.1.4.

Osoba korzystająca z dyktowania wypowiada zdanie, a system zamienia część słów na pojedyncze znaki. Portal interpretuje literę „d” jako polecenie usunięcia wiadomości. Użytkownik nie chciał usuwać treści; próbował ją napisać. Skrót działający globalnie może też kolidować z metodą nawigacji lub zostać uruchomiony przez niezamierzone naciśnięcie.

W aplikacji pocztowej można pozostawić skróty dla osób, które je lubią, ale dodać ustawienie ich wyłączenia. Innym rozwiązaniem jest wymaganie kombinacji z klawiszem modyfikującym, zgodnie z warunkami kryterium. Jeżeli skrót dotyczy odtwarzacza, może działać tylko podczas aktywnej obsługi tego komponentu. Ważne, aby użytkownik nie uruchamiał niewidocznych funkcji podczas pracy w innym miejscu.

Sprawdź ustawienia oraz rzeczywiste zachowanie. Czy wyłączenie skrótów obejmuje wszystkie znaki, czy tylko część? Czy po odświeżeniu wybór pozostaje zachowany? Czy informacja o skrótach jest dostępna dla użytkownika? Nie należy usuwać przydatnych funkcji bez potrzeby. Celem jest możliwość kontroli i uniknięcie konfliktów. Dobrym testem jest także próba dyktowania dłuższego tekstu oraz sprawdzenie, czy podczas tego działania aplikacja nie zmienia nieoczekiwanie widoku, nie usuwa elementów ani nie wysyła wiadomości.

Kryterium 2.2.1 — Możliwość dostosowania czasu. Poziom A

Dla limitów czasu ustalanych przez treść trzeba zasadniczo zapewnić wyłączenie, odpowiednio szeroką regulację albo możliwość przedłużenia po ostrzeżeniu. Standard podaje konkretne warunki: między innymi co najmniej 20 sekund na reakcję przy przedłużaniu i możliwość powtórzenia go co najmniej dziesięć razy. Przy regulacji zakres powinien sięgać co najmniej dziesięciokrotności ustawienia domyślnego. Wyjątki obejmują zdarzenia na żywo, czas istotny dla czynności oraz limity przekraczające 20 godzin. Objaśnienie W3C: 2.2.1.

Osoba wpisująca dane jednym palcem wypełnia wniosek. Po kilku minutach system bez ostrzeżenia usuwa formularz. Użytkownik zaczyna od początku, chociaż zna odpowiedzi i nie popełnił błędu. Lepszy system informuje o końcu sesji i daje dostępny sposób przedłużenia czasu, jeśli takie rozwiązanie odpowiada wymaganiom i charakterowi usługi. Ostrzeżenie musi być zauważalne także dla czytnika ekranu.

Nie każdy limit jest dowolny. Aukcja na żywo lub czynność, w której czas jest istotny, może wymagać innej oceny. Nie należy jednak nazywać każdego krótkiego czasu „wymogiem bezpieczeństwa” bez analizy. W wielu formularzach można rozdzielić wygaśnięcie uwierzytelnienia od zachowania bezpiecznego szkicu. Dzięki temu ponowne logowanie nie musi oznaczać utraty całej pracy.

Podczas testu sprawdź rzeczywisty moment ostrzeżenia, jego odczyt i możliwość reakcji klawiaturą. Czy przedłużenie działa? Czy po jego użyciu wraca się do właściwego pola? Czy limit nie obejmuje także okna pomocy, które użytkownik musi przeczytać? W dokumentacji warto zapisać przyjęty wariant spełnienia kryterium oraz uzasadnienie ewentualnego wyjątku. Sam komunikat „Masz mało czasu” nie zapewnia możliwości dostosowania tempa.

Kryterium 2.2.2 — Wstrzymywanie, zatrzymywanie i ukrywanie. Poziom A

Ruchome, migające lub przewijane informacje uruchamiane automatycznie, trwające ponad pięć sekund i pokazywane równolegle z inną treścią wymagają możliwości wstrzymania, zatrzymania albo ukrycia, chyba że są istotne. Dla automatycznie aktualizowanych informacji standard przewiduje kontrolę bez tego samego progu pięciu sekund. Objaśnienie W3C: 2.2.2.

Osoba z trudnościami koncentracji próbuje przeczytać zasady zapisów, ale obok stale zmienia się karuzela zdjęć. Każdy ruch odciąga uwagę. Przycisk zatrzymania pozwala skupić się na tekście. Nie powinien być ukryty do chwili najechania myszą, jeśli użytkownik korzysta z klawiatury. Zatrzymanie powinno trwać wystarczająco długo, aby spokojnie zapoznać się z informacją.

W drugim przykładzie lista wyników aktualizuje się co kilka sekund. Użytkownik czytnika zaczyna czytać pozycję, która nagle przesuwa się lub znika. Możliwość wstrzymania aktualizacji albo kontrolowania częstotliwości pomaga zachować orientację. Trzeba przy tym jasno informować, czy widoczne dane są aktualne. Dostępność nie wymaga ukrywania faktu, że użytkownik ogląda zatrzymany widok.

Sprawdź, co dzieje się po otwarciu strony bez żadnego działania. Czy coś porusza się stale? Czy użytkownik może to zatrzymać i wrócić do lektury? Czy po przejściu do kolejnego elementu animacja nie zaczyna się znowu? Nie należy uznawać ruchu za istotny wyłącznie dlatego, że zwiększa atrakcyjność reklamy. W wielu serwisach statyczna prezentacja jest prostsza, bardziej czytelna i mniej obciążająca niż automatycznie zmieniający się blok.

Kryterium 2.2.3 — Brak ograniczeń czasowych. Poziom AAA

Czas nie powinien być istotnym elementem czynności, z wyjątkami dotyczącymi nieinteraktywnych mediów zależnych od czasu oraz zdarzeń na żywo. To wymaganie idzie dalej niż możliwość przedłużenia limitu. Objaśnienie W3C: 2.2.3.

Platforma szkoleniowa oferuje ćwiczenie utrwalające wiedzę o obsłudze portalu. Uczestnik z trudnościami czytania potrzebuje więcej czasu na pytanie. Jeśli celem jest zrozumienie procedury, a nie pomiar szybkości, licznik może być zbędny. Usunięcie go pozwala skupić się na treści. Użytkownik nie musi wielokrotnie prosić o przedłużenie ani ujawniać swojej trudności prowadzącemu.

Inny przykład dotyczy przygotowania listy zakupów. Aplikacja zamyka edycję po dziesięciu minutach, choć nic nie uzasadnia takiego ograniczenia funkcjonalnego. Użytkownik korzystający z komunikatora wraca do zadania po rozmowie i traci możliwość spokojnego zakończenia. Projekt może umożliwić zapis szkicu oraz kontynuowanie pracy bez sztucznego wyścigu. Ochronę konta należy zaprojektować oddzielnie, z uwzględnieniem bezpieczeństwa danych.

Przy ocenie trzeba ustalić, czy limit jest częścią samej czynności, czy jedynie decyzją autora aplikacji. Nie wystarczy wydłużyć go trochę i ogłosić braku ograniczeń. Należy także sprawdzić ukryte liczniki, na przykład czas na przeczytanie komunikatu, wybranie opcji lub odpowiedź w ćwiczeniu. W praktyce dobrze pytać użytkowników, kiedy potrzebują przerw. Część osób wykonuje zadania etapami z powodu zmęczenia, bólu lub konieczności skorzystania z pomocy, a nie z braku zainteresowania.

Kryterium 2.2.4 — Kontrola przerw w pracy. Poziom AAA

Użytkownik powinien móc odłożyć lub wyłączyć przerwania, z wyjątkiem sytuacji awaryjnych. Chodzi o komunikaty i działania, które odrywają od bieżącego zadania. Objaśnienie W3C: 2.2.4.

Osoba z trudnościami uwagi wypełnia długi formularz. Co chwilę pojawia się zaproszenie do ankiety, reklama dodatkowej usługi albo automatyczny czat. Po każdym przerwaniu użytkownik musi przypomnieć sobie, co robił. Możliwość wyłączenia takich komunikatów pozwala ukończyć zadanie bez ciągłego odzyskiwania koncentracji. Nie jest to kwestia wygody wyłącznie dla bardzo wymagających odbiorców.

W systemie edukacyjnym powiadomienie o nowej wiadomości może poczekać do zakończenia odpowiedzi. Informacja o realnym zagrożeniu wymaga innego traktowania. Trzeba rozróżnić ważność komunikatu od interesu marketingowego. Promocja kończąca się za godzinę nie staje się sytuacją awaryjną tylko dlatego, że firma chce zwiększyć sprzedaż. Warto przyjąć jasne zasady priorytetu powiadomień.

Sprawdź ustawienia przerw i wykonaj zadanie z włączonymi typowymi powiadomieniami. Czy okno odbiera fokus? Czy można je odłożyć? Czy po zamknięciu wraca się w to samo miejsce? Użytkownik powinien wiedzieć, gdzie później odnajdzie odłożoną informację. W przeciwnym razie może obawiać się zamknięcia komunikatu i przerwać własne zadanie. Dobry projekt daje wybór bez karania za odroczenie. Warto również ograniczyć liczbę komunikatów, zanim powstanie skomplikowany panel ich ustawień.

Kryterium 2.2.5 — Ponowne uwierzytelnienie bez utraty pracy. Poziom AAA

Po wygaśnięciu sesji i ponownym uwierzytelnieniu użytkownik powinien móc kontynuować czynność bez utraty danych. Kryterium nie oznacza obowiązku pozostawienia konta bez ochrony. Objaśnienie W3C: 2.2.5.

Osoba przygotowuje opis sprawy w portalu pomocy. Pisze wolno, ponieważ korzysta ze sterowania alternatywnego. W tym czasie sesja wygasa. Po zalogowaniu użytkownik powinien odzyskać wpisany tekst i miejsce pracy. Konieczność ponownego wpisania kilku stron może oznaczać rezygnację z uzyskania pomocy. Strata jest większa niż kilka dodatkowych kliknięć.

Rozwiązanie wymaga przemyślenia bezpieczeństwa. Nie należy przechowywać wrażliwego szkicu w miejscu dostępnym dla kolejnej osoby korzystającej ze wspólnego komputera. Można zastosować bezpieczny zapis powiązany z kontem i przywracanie po ponownym potwierdzeniu tożsamości. Użytkownik powinien otrzymać jasną informację, co zostało zachowane. Sama obietnica „Twoje dane są bezpieczne” nie wyjaśnia, czy formularz można kontynuować.

Testuj sytuację z realistyczną ilością danych. Poczekaj na wygaśnięcie w środowisku testowym, zaloguj się ponownie i porównaj treść. Sprawdź załączniki, wybrane opcje i etap procesu, nie tylko pierwsze pole. Zwróć uwagę, czy system przypadkiem nie wysłał formularza podczas przywracania. Odzyskanie szkicu powinno pozostawić decyzję o wysłaniu użytkownikowi. Warto również zapewnić czytelny komunikat, że sesja została odnowiona i można dalej pracować.

Kryterium 2.2.6 — Informacja o bezczynności. Poziom AAA

Użytkownik powinien zostać ostrzeżony o czasie bezczynności, który może doprowadzić do utraty danych, chyba że dane są zachowywane przez ponad 20 godzin bezczynności. To wymaganie informacyjne nie zastępuje innych zasad dotyczących czasu. Objaśnienie W3C: 2.2.6.

Osoba rozpoczyna formularz wymagający numerów z kilku dokumentów. Musi odejść od komputera, aby je odnaleźć. Jeśli system usuwa dane po określonym czasie, powinna wiedzieć o tym wcześniej. Informacja na początku pozwala przygotować dokumenty lub zaplanować pracę. Ostrzeżenie dopiero po utracie treści nie daje możliwości podjęcia świadomej decyzji.

Dobry komunikat wyjaśnia, co oznacza bezczynność. Czy samo czytanie instrukcji jest traktowane jako brak aktywności? Czy zapis szkicu przerywa licznik? W naszym przykładzie użytkownik czyta długie objaśnienia w osobnym oknie, a formularz w tle wygasa. Autor usługi powinien uwzględnić takie naturalne zachowanie, zamiast zakładać ciągłe naciskanie klawiszy. Nie każdy moment bez wpisywania danych oznacza porzucenie zadania.

Sprawdź, gdzie pojawia się informacja i czy jest zrozumiała bez wiedzy technicznej. „Sesja ma TTL 900” nie jest dobrym komunikatem dla przeciętnego odbiorcy. Lepiej wyjaśnić czas i skutek zwykłymi słowami. Zweryfikuj również zgodność komunikatu z rzeczywistym zachowaniem systemu. Jeśli zmieniono konfigurację, tekst pomocy musi zostać zaktualizowany. Dobrze jest połączyć ostrzeżenie z możliwością bezpiecznego zapisania pracy, choć samo to kryterium koncentruje się na informacji o ryzyku utraty danych.

Kryterium 2.3.1 — Ograniczenie błysków. Poziom A

Treść nie może zawierać więcej niż trzech błysków w ciągu sekundy, chyba że mieści się poniżej określonych progów błysków ogólnych i czerwonych. Ocena progów wymaga odpowiednich parametrów i narzędzi. Nie należy sprawdzać potencjalnie niebezpiecznej treści poprzez narażanie wrażliwej osoby. Objaśnienie W3C: 2.3.1.

Strona wydarzenia używa szybko migającego banera, aby zwrócić uwagę na sprzedaż biletów. Dla części użytkowników efekt może stanowić zagrożenie, a dla innych być bardzo męczący. Najbezpieczniejsza decyzja projektowa to rezygnacja z takiego sposobu przyciągania uwagi. Ważny termin można wyróżnić nagłówkiem, kontrastem i czytelnym komunikatem bez gwałtownych zmian światła.

Podobne ryzyko może pojawić się w filmie lub animacji osadzonej przez zewnętrzny podmiot. Fakt, że materiał pochodzi z innej platformy, nie sprawia, że znika z doświadczenia użytkownika. Zespół publikujący powinien ocenić zawartość przed umieszczeniem jej w serwisie. Ostrzeżenie napisane nad filmem nie jest automatycznym zastępstwem spełnienia wymagania dotyczącego błysków.

W testach korzystaj z analizy materiału i właściwych narzędzi. Nie zapraszaj osoby z nadwrażliwością na błyski do „sprawdzenia, czy jej przeszkadza”. To nie jest właściwa metoda oceny. Warto także przyjąć zasadę redakcyjną eliminującą zbędne miganie już na etapie zamówienia grafiki. Dzięki temu nie trzeba później analizować każdego efektu granicznego. Dostępność obejmuje ochronę użytkownika przed szkodliwą prezentacją, a nie tylko możliwość odczytania tekstu.

Kryterium 2.3.2 — Nie więcej niż trzy błyski. Poziom AAA

Na poziomie AAA treść nie powinna błyskać więcej niż trzy razy w ciągu sekundy. Nie stosuje się tu tej samej możliwości oparcia oceny na progach co w kryterium 2.3.1. Objaśnienie W3C: 2.3.2.

Wyobraźmy sobie platformę szkoleniową, która po poprawnej odpowiedzi pokazuje gwałtowną animację gratulacyjną. Uczestnik może zrozumieć wynik z prostego tekstu „Odpowiedź poprawna”. Efekt nie jest konieczny do osiągnięcia celu edukacyjnego. Usunięcie błysków nie zubaża informacji, a pozwala uniknąć ryzyka związanego z agresywną prezentacją. Warto pamiętać o tym również przy grach edukacyjnych.

W drugim przykładzie reklamodawca dostarcza mały migający obraz. Zespół może uznać, że mały rozmiar rozwiązuje wszystkie problemy. Przy wymaganiu AAA trzeba jednak zastosować właściwą, surowszą zasadę, a nie dowolnie przenosić wyjątki z niższego poziomu. W dokumentacji projektu dobrze zapisać, że materiały dostarczane przez partnerów również podlegają przyjętym wymaganiom jakościowym.

Sprawdzenie powinno objąć animacje pojawiające się po działaniu, a nie tylko stronę w stanie początkowym. Efekt może uruchomić się po wysłaniu formularza, zdobyciu punktów albo otwarciu okna. Warto prowadzić listę takich stanów. Nie należy odtwarzać potencjalnie niebezpiecznych sekwencji wielokrotnie na potrzeby zwykłej oceny wzrokowej. Lepiej usunąć zbędny efekt lub zastosować właściwą analizę. Projektowanie spokojnego interfejsu jest często prostsze niż późniejsze dowodzenie, że skomplikowana animacja pozostaje w dopuszczalnych granicach.

Kryterium 2.3.3 — Animacje wywołane działaniem. Poziom AAA

Animacje ruchowe uruchamiane przez interakcję powinny dać się wyłączyć, chyba że są istotne dla funkcji lub informacji. Dotyczy to między innymi efektów przesuwania, powiększania i ruchu podczas przewijania. Objaśnienie W3C: 2.3.3.

Użytkownik przewija stronę, a tło porusza się z inną prędkością niż tekst. Dla projektanta jest to atrakcyjny efekt, lecz dla osoby z wrażliwością na ruch może wywoływać silny dyskomfort. Strona powinna umożliwić ograniczenie animacji, na przykład respektując odpowiednie ustawienie systemu. Treść nadal może być estetyczna i czytelna bez ruchomej scenografii.

W sklepie każda karta produktu gwałtownie powiększa się po wskazaniu. Osoba szukająca ceny dostaje serię niepotrzebnych ruchów. Można zastosować spokojną zmianę obramowania lub koloru, o ile zachowuje ona odpowiednią czytelność. Jeśli animacja pokazuje rzeczywiście ważną zmianę, warto zastanowić się, jak przekazać tę samą informację w wariancie ograniczonego ruchu. Samo wyłączenie efektu nie powinno usuwać informacji o wyniku działania.

Testuj interfejs z włączonym systemowym ograniczeniem animacji oraz sprawdź dostępne ustawienia strony. Czy zmiana obejmuje wszystkie efekty, czy tylko tło? Czy po otwarciu okna nadal pojawia się duży ruch? Użytkownik nie powinien najpierw przejść przez serię animacji, aby dotrzeć do ich wyłączenia. Dobrze jest uwzględnić preferencję od pierwszego wyświetlenia. Warto także pamiętać, że nie każda animacja jest błyskiem; ograniczenie błysków i ograniczenie ruchu to powiązane, ale odrębne zagadnienia.

Kryterium 2.4.1 — Pomijanie powtarzających się bloków. Poziom A

Użytkownik powinien mieć możliwość pominięcia bloków treści powtarzających się na wielu stronach. Pozwala to dotrzeć do głównej informacji bez każdorazowego przechodzenia przez rozbudowane menu. Objaśnienie W3C: 2.4.1.

Osoba niewidoma przegląda dziesięć ogłoszeń urzędu. Przed każdym znajduje się identyczne menu z kilkudziesięcioma linkami. Bez mechanizmu pomijania musi stale przechodzić przez ten sam zestaw. Link „Przejdź do treści” pozwala rozpocząć lekturę od właściwego miejsca. Ważne, aby nie tylko przesuwał obraz, lecz rzeczywiście pozwalał kontynuować obsługę w obszarze treści.

Podobną korzyść odnosi osoba obsługująca stronę pojedynczym przełącznikiem. Każde przejście może wymagać czasu i wysiłku. Ograniczenie liczby zbędnych kroków ma dla niej większe znaczenie niż dla osoby szybko poruszającej myszą. Prawidłowe regiony strony i nagłówki również pomagają w orientacji, ale należy sprawdzić, czy przyjęty mechanizm działa w przewidzianych sposobach korzystania.

Rozpocznij test od początku strony i naciśnij Tab. Jeśli istnieje link pomijający, powinien być dostępny i widoczny po uzyskaniu fokusu. Uruchom go, a następnie przejdź do następnego elementu. Czy znajdujesz się już w treści, czy nadal w menu? Sprawdź kilka typów podstron. Częsty błąd polega na tym, że link prowadzi do identyfikatora, którego nie ma w jednym z szablonów. Nazwa obiecuje pomoc, ale działanie niczego nie zmienia.

Kryterium 2.4.2 — Tytuł strony. Poziom A

Każda strona powinna mieć tytuł opisujący jej temat albo cel. Tytuł dokumentu widoczny na karcie przeglądarki jest czymś innym niż duży nagłówek w treści, choć oba mogą być podobne. Objaśnienie W3C: 2.4.2.

Użytkownik otworzył kilka kart z dokumentami. Wszystkie nazywają się „Portal”. Nie wiadomo, gdzie jest formularz, gdzie instrukcja, a gdzie potwierdzenie wysłania. Tytuł „Potwierdzenie złożenia wniosku — Portal mieszkańca” pozwala rozpoznać kartę bez otwierania każdej po kolei. Jest szczególnie przydatny osobom korzystającym z czytnika ekranu oraz osobom mającym trudność z zapamiętaniem układu wielu okien.

W aplikacji, która zmienia ekran bez pełnego przeładowania, tytuł również powinien odzwierciedlać aktualną treść. Jeśli użytkownik przeszedł od wyszukiwania do szczegółów wizyty, pozostawienie tytułu „Wyszukiwarka” może wprowadzać w błąd. Dobry tytuł pomaga także wrócić do strony z historii przeglądarki. Nie powinien jednak ujawniać zbędnych danych wrażliwych na pasku kart, szczególnie na współdzielonym ekranie.

Sprawdź tytuły kolejnych etapów procesu. Czy odróżniają się od siebie? Czy po błędzie nadal opisują właściwe zadanie? Czy nie zawierają wewnętrznych nazw technicznych, takich jak numer szablonu? W praktyce warto zaczynać od informacji najważniejszej dla użytkownika, a nazwę serwisu umieszczać dalej. Dzięki temu przy wielu otwartych kartach początek tytułu szybciej wskazuje potrzebną stronę. Nie trzeba tworzyć długiego zdania, aby tytuł był wystarczająco konkretny.

Kryterium 2.4.3 — Kolejność fokusu. Poziom A

Jeśli kolejność nawigacji wpływa na znaczenie lub obsługę, elementy powinny otrzymywać fokus w kolejności zachowującej sens i możliwość działania. Fokus to miejsce, do którego w danej chwili odnoszą się polecenia klawiatury. Objaśnienie W3C: 2.4.3.

Formularz prosi kolejno o imię, nazwisko i adres. Po wpisaniu imienia Tab przenosi jednak do przycisku wysłania, potem do stopki, a dopiero później do nazwiska. Osoba korzystająca z klawiatury traci orientację. Poprawna kolejność powinna wynikać z logicznej struktury, a nie z przypadkowych ustawień dodawanych osobno do każdego pola.

Po otwarciu okna wyboru terminu użytkownik powinien móc obsłużyć jego zawartość. Jeśli fokus pozostaje w tle, może uruchomić funkcję niewidoczną pod oknem. Po zamknięciu warto przywrócić miejsce, z którego okno otwarto, lub inne logiczne miejsce wynikające z zakończonej czynności. Na przykład po usunięciu elementu nie da się wrócić do przycisku, który już nie istnieje; trzeba wybrać sensowny punkt dalszej pracy.

Testuj zarówno przechodzenie do przodu, jak i powrót. Otwieraj rozwijane sekcje i sprawdzaj, gdzie trafiają nowo dodane pola. Nie każda kolejność musi odpowiadać dokładnie układowi od lewej do prawej, ale powinna zachowywać sens. Warto obserwować rzeczywisty przebieg zadania, ponieważ sam przegląd kodu może nie ujawnić zmian wywoływanych przez skrypty. Szczególnie sprawdzaj komunikaty błędów, okna modalne i dynamicznie dodawane wiersze formularza.

Kryterium 2.4.4 — Cel linku wynikający z kontekstu. Poziom A

Cel linku powinien być możliwy do ustalenia na podstawie jego tekstu albo tekstu wraz z programowo określonym kontekstem. Istnieje wyjątek dla sytuacji, gdy cel byłby niejednoznaczny dla wszystkich użytkowników. Objaśnienie W3C: 2.4.4.

Na stronie znajdują się trzy dokumenty, a obok każdego link „Pobierz”. Jeśli powiązanie z nazwą dokumentu jest czytelne również programowo, kontekst może wyjaśniać cel. Jednak najprostsze rozwiązanie to nazwy „Pobierz formularz zgłoszenia” i „Pobierz instrukcję”. Użytkownik szybciej podejmuje decyzję i rzadziej otwiera niewłaściwy plik. Warto dodać rodzaj pliku, gdy pomaga to przewidzieć dalsze działanie.

Problem pojawia się, gdy link „Tutaj” jest wizualnie blisko opisu, ale w strukturze strony nie ma z nim odpowiedniego związku. Osoba korzystająca z technologii asystującej może usłyszeć samo „Tutaj”. Równie niejasny bywa adres techniczny zawierający przypadkowe znaki. Użytkownik nie powinien analizować długiego ciągu, aby dowiedzieć się, czy otworzy regulamin, mapę czy formularz.

Sprawdź odsyłacze w ich rzeczywistym kontekście. Czy wiadomo, dokąd prowadzą i czego dotyczą? Nie należy sztucznie wydłużać każdej nazwy, jeśli krótki tekst jest jasny. „Kontakt” w głównym menu zwykle dobrze opisuje cel. Z kolei kilka identycznych linków „Więcej” wymaga uważnej oceny powiązań. Warto także zachować spójność nazw: odsyłacz zapowiadający instrukcję nie powinien prowadzić od razu do formularza bez wyjaśnienia tej zmiany.

Kryterium 2.4.5 — Więcej niż jeden sposób odnalezienia strony. Poziom AA

W obrębie zestawu stron należy zapewnić więcej niż jeden sposób odnalezienia konkretnej strony, z wyjątkiem stron będących wynikiem lub etapem procesu. Może to być na przykład menu i wyszukiwarka albo spis treści i mapa serwisu. Objaśnienie W3C: 2.4.5.

Osoba z trudnościami poznawczymi nie wie, czy informacja o zmianie adresu znajduje się w dziale „Sprawy mieszkańców”, „Ewidencja” czy „Dokumenty”. Wyszukiwarka pozwala wpisać własne słowa. Inna osoba woli przejrzeć uporządkowane działy. Dwie drogi nie oznaczają zbędnego powielenia. Odpowiadają na różne sposoby orientowania się w informacjach.

W małym serwisie rozbudowana wyszukiwarka może być niepotrzebna, jeśli istnieją inne skuteczne sposoby dotarcia do treści. Ważna jest rzeczywista możliwość znalezienia strony. Samo pole wyszukiwania, które nie zwraca aktualnych wyników, nie jest pełnowartościową pomocą. Podobnie mapa serwisu z nieaktualnymi linkami może zwiększyć frustrację zamiast ją zmniejszyć.

Sprawdź kilka ważnych informacji, rozpoczynając raz od menu, a raz od drugiej drogi. Czy obie prowadzą do właściwego miejsca? Czy nazwy działów są zrozumiałe dla odbiorców, a nie wyłącznie dla pracowników organizacji? Nie trzeba zapewniać bezpośredniego wejścia do poufnego potwierdzenia konkretnej transakcji, które stanowi wynik procesu. Trzeba natomiast ułatwić znalezienie ogólnej instrukcji i punktu rozpoczęcia usługi. Warto badać słowa używane przez użytkowników, ponieważ często różnią się od urzędowej lub branżowej terminologii.

Kryterium 2.4.6 — Opisowe nagłówki i etykiety. Poziom AA

Nagłówki i etykiety powinny opisywać temat albo cel. Samo zastosowanie właściwego znacznika nie wystarcza, jeśli nazwa niczego nie wyjaśnia. Objaśnienie W3C: 2.4.6.

Długi artykuł ma nagłówki „Informacje”, „Dalsze informacje” i „Pozostałe informacje”. Osoba przeglądająca listę nagłówków nadal nie wie, gdzie znaleźć termin, koszty i potrzebne dokumenty. Lepsze nazwy to „Kiedy złożyć wniosek”, „Ile zapłacisz” i „Jakie dokumenty przygotować”. Czytelnik może przejść bezpośrednio do własnego pytania, zamiast odsłuchiwać całość.

W formularzu pole nazwano „Numer”. Może chodzić o numer telefonu, sprawy, mieszkania lub dokumentu. Precyzyjna etykieta zmniejsza liczbę błędów. Jeśli obok znajdują się dwa pola dotyczące adresów, trzeba wyraźnie odróżnić ich przeznaczenie. Osoba słuchająca pojedynczego pola nie zawsze ma w pamięci cały układ wizualny. Nazwa powinna pomagać także wtedy, gdy odbiorca wraca do formularza po przerwie.

Sprawdź nagłówki jako samodzielną listę. Czy dają obraz zawartości? Następnie przeczytaj etykiety bez zgadywania na podstawie przykładowych danych. Tekst wpisany jako podpowiedź wewnątrz pola nie powinien być jedyną informacją, jeśli znika podczas pisania. Warto testować nazwy z osobami spoza zespołu. Pracownik może wiedzieć, co oznacza „Identyfikator jednostki”, lecz użytkownik spotykający usługę pierwszy raz potrzebuje bardziej konkretnego wyjaśnienia. Dobry nagłówek oszczędza czas wszystkim, a nie tylko użytkownikom czytników.

Kryterium 2.4.7 — Widoczny fokus. Poziom AA

Każdy interfejs obsługiwany klawiaturą powinien mieć tryb działania, w którym wskaźnik fokusu jest widoczny. Osoba widząca, która nie korzysta z myszy, musi wiedzieć, jaki element uruchomi kolejnym klawiszem. Objaśnienie W3C: 2.4.7.

Użytkownik naciska Tab na stronie zakupowej. W tle fokus przechodzi między przyciskami, ale wizualnie nic się nie zmienia. Naciśnięcie Enter staje się zgadywaniem. Projektant usunął obramowanie, ponieważ nie pasowało do wyglądu strony, i nie zastąpił go innym wskaźnikiem. Wyraźne zaznaczenie pozwala bezpiecznie rozpoznać bieżące miejsce.

Fokus nie jest tym samym co zaznaczenie opcji. W grupie przycisków jeden może oznaczać aktualnie wybrany wariant, a inny mieć fokus podczas przeglądania. Jeśli oba stany wyglądają identycznie, użytkownik może pomylić wybór z miejscem nawigacji. Warto zaprojektować je tak, aby znaczenie było czytelne. Dotyczy to zakładek, kalendarzy, ocen i list wyboru.

Test jest prosty: przejdź klawiaturą całą stronę i obserwuj każdy element. Sprawdź jasne i ciemne tła, przyciski na zdjęciach oraz menu rozwijane. Czy zaznaczenie nie znika w którymś stanie? Czy pozostaje widoczne po powiększeniu? Nie należy uznawać samego przesunięcia strony za wystarczający wskaźnik. Użytkownik potrzebuje wiedzieć, który konkretnie element jest aktywny. Dalsze kryteria 2.4.11–2.4.13 rozwijają problem zasłaniania i wyglądu fokusu, ale podstawowa widoczność pozostaje osobnym wymaganiem.

Kryterium 2.4.8 — Informacja o położeniu w serwisie. Poziom AAA

Użytkownik powinien mieć dostęp do informacji o swoim miejscu w zestawie stron. Pomagają w tym między innymi ścieżki nawigacyjne, oznaczenie bieżącego działu i czytelna struktura. Objaśnienie W3C: 2.4.8.

Osoba trafia z wyszukiwarki na szczegółową instrukcję. Nie wie, do jakiej usługi należy ani gdzie znaleźć informacje ogólne. Ścieżka „Strona główna — Usługi — Zmiana adresu — Dokumenty” pokazuje miejsce i umożliwia powrót wyżej. Dla osoby z trudnościami orientacji jest to odpowiednik drogowskazu. Nie musi pamiętać, jak dotarła na stronę.

W dużym portalu edukacyjnym podobną funkcję pełni wskazanie kursu, modułu i lekcji. Uczeń może wrócić do spisu materiałów bez wielokrotnego używania przycisku wstecz. Warto jednak nie mylić miejsca w strukturze z historią odwiedzonych stron. Ścieżka powinna przedstawiać zrozumiałe powiązania, a nie przypadkową drogę konkretnego użytkownika przez serwis.

Sprawdź stronę otwartą bezpośrednio z zewnętrznego linku. Czy wiadomo, gdzie się znajduje? Czy oznaczenie bieżącego miejsca jest dostępne również programowo? Czy nazwy w ścieżce odpowiadają tytułom stron? Nie należy tworzyć kilkunastopoziomowej struktury tylko po to, aby pokazać rozbudowaną nawigację. Celem jest orientacja. W małym serwisie proste wskazanie działu może być bardziej użyteczne niż skomplikowany pasek. Warto sprawdzić, czy ścieżka nadal jest czytelna na telefonie i po zwiększeniu rozmiaru tekstu.

Kryterium 2.4.9 — Cel linku z samej nazwy. Poziom AAA

Cel każdego linku powinien być możliwy do ustalenia na podstawie samego tekstu linku, z przewidzianym wyjątkiem niejednoznaczności dla wszystkich użytkowników. Jest to surowsze wymaganie niż możliwość skorzystania z kontekstu na poziomie A. Objaśnienie W3C: 2.4.9.

Osoba korzystająca z czytnika otwiera listę wszystkich odsyłaczy. Słyszy „Więcej, więcej, więcej”. Nie wie, który dotyczy godzin przyjęć, a który opłat. Nazwy „Godziny przyjęć poradni” oraz „Opłaty za dokumenty” rozwiązują problem. Dobrze opisany link pomaga również osobie, która szybko przegląda tekst wzrokiem i zatrzymuje się na wyróżnionych odsyłaczach.

W newsletterze organizacji kilka linków „Przeczytaj” prowadzi do różnych poradników. Redaktor może zastąpić je tytułami materiałów. Nie musi dopisywać długiej instrukcji do każdego odsyłacza. Ważna jest rozpoznawalność celu. Jeśli dwa linki prowadzą do tego samego miejsca, spójne nazewnictwo pomaga zrozumieć, że są równoważne. Jeżeli prowadzą do różnych wersji, warto wskazać różnicę, na przykład tekst i nagranie.

Test polega na przeczytaniu samych nazw linków. Czy bez otaczającego akapitu wiadomo, co zostanie otwarte? Uważaj na nazwy nadmiernie ogólne, takie jak „Dokument” lub „Informacja”. Nie zastępuj jednak jasnej nazwy ogromnym opisem, który utrudnia przeglądanie listy. Najlepsza nazwa jest krótka, konkretna i zgodna z treścią strony docelowej. Przy plikach użyteczne może być podanie formatu, szczególnie gdy otwarcie uruchamia inną aplikację albo pobieranie.

Kryterium 2.4.10 — Nagłówki sekcji. Poziom AAA

Treść powinna być organizowana za pomocą nagłówków sekcji. Wymaganie dotyczy rzeczywistego porządkowania informacji, a nie dekoracyjnego wstawiania dużych napisów. Objaśnienie W3C: 2.4.10.

Wyobraźmy sobie instrukcję liczącą kilkanaście stron tekstu. Czytelnik potrzebuje tylko odpowiedzi na pytanie o załącznik. Bez nagłówków musi przeglądać kolejne akapity. Podział na przygotowanie dokumentów, wypełnianie formularza, wysyłanie i sprawdzanie potwierdzenia pozwala szybko znaleźć właściwy fragment. Osoba używająca czytnika może przeskakiwać między sekcjami, zamiast słuchać całości.

Nagłówki pomagają również po przerwie. Użytkownik wraca do tekstu następnego dnia i pamięta temat, ale nie dokładne zdanie. Zrozumiała struktura ułatwia odnalezienie miejsca. W materiałach edukacyjnych dobrze oddzielać wyjaśnienie od przykładu i ćwiczenia. Nie trzeba jednak nadawać nagłówka każdemu pojedynczemu zdaniu. Nadmierne rozdrobnienie może utrudnić zrozumienie związku między informacjami.

Sprawdź, czy podział odpowiada pytaniom odbiorcy. Czy nagłówki mają logiczną hierarchię? Czy nie pominięto dużych fragmentów, które zawierają kilka różnych tematów? Warto zacząć od planu, a dopiero potem pisać treść. Dodawanie nagłówków na końcu bez przemyślenia struktury często prowadzi do nazw ogólnych. W długim przewodniku przydatny jest także klikalny spis treści. Sam spis nie zastępuje nagłówków, lecz pozwala wybrać drogę czytania i wracać do potrzebnych rozdziałów.

Kryterium 2.4.11 — Fokus niecałkowicie zasłonięty. Poziom AA

Element otrzymujący fokus klawiatury nie może być całkowicie zasłonięty przez treść utworzoną przez autora strony. Kryterium zawiera wyjaśnienia dotyczące między innymi treści przemieszczanych przez użytkownika. Objaśnienie W3C: 2.4.11.

Na dole ekranu przyklejono szeroki pasek zgód. Użytkownik przechodzi klawiaturą do przycisku formularza, który znajduje się dokładnie pod paskiem. Fokus istnieje, ale elementu nie widać. Osoba obsługująca stronę bez myszy nie wie, gdzie jest i co zrobi Enter. Projekt powinien uwzględnić zajętą przestrzeń albo zapewnić takie zachowanie, aby aktywny element pozostawał widoczny.

Podobny problem powoduje stały nagłówek u góry. Po przejściu do pola strona przewija je pod nagłówek. Użytkownik widzi tylko etykietę innego elementu i może pomylić miejsce. W powiększeniu paski zajmują większą część widoku, dlatego problem bywa znacznie silniejszy. Sprawdzanie wyłącznie na dużym monitorze przy domyślnym rozmiarze pomija ważny scenariusz.

Przejdź klawiaturą przez stronę ze wszystkimi widocznymi banerami i oknami. Sprawdź także dolne pola formularza oraz elementy pojawiające się dynamicznie. Minimalny wymóg dotyczy całkowitego zasłonięcia, ale częściowe zasłonięcie również może utrudniać pracę. Warto dążyć do pełnej widoczności, którą opisuje kolejne kryterium. Nie traktuj małego widocznego fragmentu jako celu projektowego. Standardowe minimum pomaga rozstrzygać zgodność, natomiast dobry interfejs powinien umożliwiać spokojne rozpoznanie elementu.

Kryterium 2.4.12 — Fokus całkowicie widoczny. Poziom AAA

Żadna część elementu otrzymującego fokus klawiatury nie powinna być zasłonięta przez treść utworzoną przez autora. Jest to bardziej wymagający wariant ochrony widoczności aktywnego elementu. Objaśnienie W3C: 2.4.12.

W formularzu przyklejony pasek zasłania dolną połowę przycisku. Na poziomie minimalnym sytuacja może wymagać innej oceny niż całkowite ukrycie, lecz użytkownik nadal nie widzi pełnej nazwy. Jeśli widoczny pozostaje tylko fragment „Usuń”, nie wiadomo, czy chodzi o załącznik, szkic czy konto. Pełna widoczność pozwala podjąć świadomą decyzję.

W portalu z dużym menu górnym pole wyszukiwania częściowo chowa się pod nagłówkiem po przewinięciu. Osoba słabowidząca, która korzysta z klawiatury i powiększenia, musi dodatkowo przesuwać widok. Projekt powinien przewidzieć odpowiedni odstęp i sposób przewijania. Nie warto pozostawiać użytkownikowi zadania ręcznego odsłaniania każdego pola, zwłaszcza gdy problem powtarza się na kolejnych ekranach.

Testuj wszystkie obszary blisko krawędzi oraz stany z otwartymi komunikatami. Sprawdź, czy pomocniczy panel nie zasłania elementu, do którego właśnie przenosi się fokus. Jeżeli użytkownik sam przemieszcza pewne bloki, należy uwzględnić szczegółowe warunki standardu, zamiast oceniać sytuację bez kontekstu. Dobrą praktyką jest projektowanie stałych pasków możliwie oszczędnie. Każdy dodatkowy element przyklejony do ekranu zabiera miejsce potrzebne do czytania i działania, szczególnie po dużym powiększeniu.

Kryterium 2.4.13 — Wygląd wskaźnika fokusu. Poziom AAA

Widoczny wskaźnik fokusu powinien mieć odpowiednią powierzchnię oraz zmianę kontrastu. Wymagana powierzchnia odpowiada co najmniej obwódce o grubości dwóch pikseli CSS wokół elementu bez fokusu, a kontrast tych samych pikseli między stanami wynosi co najmniej 3:1. Istnieją wyjątki dotyczące wskaźników przeglądarki. Objaśnienie W3C: 2.4.13.

Osoba starsza porusza się klawiaturą po liście przycisków. Aktywny przycisk różni się jedynie delikatnym cieniem. Zmiana jest tak mała, że trudno ją zauważyć. Wyraźna obwódka może pokazać miejsce bez potrzeby wpatrywania się w ekran. Nie chodzi wyłącznie o istnienie dowolnej różnicy. Różnica musi być wystarczająco widoczna.

Warto odróżnić kontrast wskaźnika względem sąsiedniego tła od zmiany tych samych pikseli między stanem z fokusem i bez niego. To powiązane, ale różne pomiary. Projektant może zastosować obwódkę albo inne rozwiązanie o odpowiedniej powierzchni. Nie musi trzymać się jednego kształtu, lecz powinien umieć wykazać spełnienie parametrów. Praktycznie często łatwiej zaprojektować wyraźny wskaźnik niż obliczać rozwiązanie ledwie mieszczące się na granicy.

Sprawdź przyciski o różnych rozmiarach, linki zawijające się do kilku wierszy i elementy na różnych tłach. Czy wskaźnik skaluje się wraz z kontrolką? Czy nie zostaje obcięty przez sąsiedni blok? Użytkownik powinien dostrzegać go szybko. Dobrze przeprowadzić próbę również przy powiększeniu, kiedy na ekranie widać tylko niewielką część interfejsu i trudniej porównywać aktywny element z pozostałymi.

Kryterium 2.5.1 — Proste alternatywy dla gestów. Poziom A

Funkcje wykorzystujące gesty wielopunktowe albo zależne od określonej ścieżki ruchu powinny mieć odpowiednik obsługiwany pojedynczym wskaźnikiem bez takiego gestu, chyba że gest jest istotny. Sama obsługa klawiaturą nie zastępuje tej alternatywy. Objaśnienie W3C: 2.5.1.

Osoba używająca jednego palca chce powiększyć mapę. Nie może wykonać gestu rozsuwania dwóch palców. Przyciski „Powiększ” i „Pomniejsz” pozwalają uzyskać ten sam efekt prostym dotknięciem. Powinny mieć odpowiednie nazwy i być łatwe do trafienia. Dodanie ich nie wymaga usunięcia gestu dla osób, które wolą taką obsługę.

W galerii zdjęć przejście do kolejnego obrazu wymaga narysowania określonego łuku. Użytkownik z drżeniem rąk nie potrafi dokładnie odtworzyć ścieżki. Zwykłe przyciski poprzedniego i następnego zdjęcia rozwiązują problem. Nie należy zakładać, że instrukcja pokazująca gest uczyni go możliwym dla każdego. Bariera może wynikać z możliwości ruchowych, a nie z braku wiedzy.

Sprawdź funkcje obsługiwane dotykiem i wskaźnikiem. Czy da się je wykonać pojedynczym kliknięciem lub serią prostych kliknięć? Czy alternatywa jest widoczna i dostępna bez wcześniejszego wykonania trudnego gestu? Trzeba odróżnić gest zależny od ścieżki od przeciągania, które ma osobne kryterium w WCAG 2.2. W praktyce najlepiej zaprojektować proste kontrolki dla obu sytuacji. Użytkownik nie powinien znać klasyfikacji gestu, aby móc zmienić skalę mapy albo przejść do następnej fotografii.

Kryterium 2.5.2 — Możliwość anulowania działania wskaźnika. Poziom A

Działanie pojedynczego wskaźnika powinno dawać ochronę przed przypadkową aktywacją: nie wykonywać się ostatecznie przy samym naciśnięciu, umożliwiać anulowanie lub cofnięcie albo spełniać inną przewidzianą w standardzie możliwość. Wyjątek dotyczy działania przy naciśnięciu, które jest istotne. Objaśnienie W3C: 2.5.2.

Osoba z drżeniem dłoni dotyka niewłaściwego przycisku. Jeśli akcja następuje dopiero po zwolnieniu dotyku, może odsunąć palec i zrezygnować. Gdy system wykonuje czynność natychmiast po dotknięciu, szansa korekty znika. Różnica jest szczególnie ważna przy usuwaniu elementów, wysyłaniu wiadomości i przechodzeniu do kolejnych etapów.

Przykład dotyczy listy załączników. Obok nazwy znajduje się mała ikona usunięcia. Użytkownik chciał otworzyć dokument, ale trafił obok. Bezpieczniejsza obsługa pozwala anulować naciśnięcie lub odzyskać usunięty element. Dodatkowo można zwiększyć obszar przycisku i odsunąć go od nazwy. Te rozwiązania odpowiadają na różne kryteria, ale razem ograniczają skutki pomyłki.

Podczas testu naciśnij przycisk, przesuń wskaźnik poza jego obszar i zwolnij. Sprawdź, kiedy następuje działanie oraz czy można je cofnąć, jeśli projekt korzysta z tej możliwości. Nie testuj destrukcyjnych funkcji na prawdziwych danych. Warto sprawdzić zachowanie osobno myszą i dotykiem. Użytkownik nie powinien ponosić poważnych skutków dlatego, że interfejs uznał pierwszy kontakt ze szkłem za ostateczną decyzję. Jednocześnie nie każda interakcja ma identyczną naturę, dlatego wyjątki wymagają oceny konkretnej funkcji.

Kryterium 2.5.3 — Widoczna etykieta w nazwie dostępnej. Poziom A

Jeżeli kontrolka ma widoczną etykietę tekstową lub obraz tekstu, jej nazwa dostępna powinna zawierać ten tekst. Nazwa dostępna to informacja przekazywana technologiom asystującym, która może różnić się od tego, co widzi użytkownik. Objaśnienie W3C: 2.5.3.

Na ekranie przycisk nazywa się „Wyślij”, ale programowo otrzymał nazwę „Zatwierdź formularz kontaktowy”. Osoba sterująca głosem mówi „Kliknij Wyślij”, a system nie znajduje elementu. Użytkownik postępuje logicznie: odczytuje widoczne słowo. Projekt nie powinien wymagać poznania ukrytej nazwy. Najprościej zachować widoczny tekst w nazwie przekazywanej programom.

Można dodać potrzebne doprecyzowanie, na przykład „Usuń załącznik: zdjęcie wejścia”, jeśli widoczny przycisk brzmi „Usuń”. Trzeba jednak zadbać o zgodność. Zbyt kreatywne nadpisywanie nazw bywa szkodliwe, nawet jeśli miało pomóc czytnikowi. Użytkownicy mogą łączyć wzrok, mowę i klawiaturę, dlatego te warstwy powinny opisywać ten sam element w spójny sposób.

Sprawdź widoczny tekst i nazwę dostępną w narzędziu badającym strukturę dostępności. Następnie wykonaj próbę sterowania głosem, jeśli jest dostępne. Czy można odwołać się do przycisku jego widoczną nazwą? Zwróć uwagę na przyciski ikonowe z tekstem dodanym obok oraz elementy, których etykieta zmienia się po działaniu. Jeśli „Włącz” zmieni się w „Wyłącz”, nazwa programowa powinna odzwierciedlać właściwy stan i cel. Spójność pomaga także konsultantowi prowadzącemu użytkownika przez usługę.

Kryterium 2.5.4 — Alternatywa dla poruszania urządzeniem. Poziom A

Funkcje uruchamiane ruchem urządzenia lub użytkownika powinny mieć odpowiednik w interfejsie, a reagowanie na ruch powinno dać się wyłączyć, z określonymi wyjątkami. Objaśnienie W3C: 2.5.4.

Aplikacja pozwala cofnąć wpisany tekst przez potrząśnięcie telefonem. Osoba mająca urządzenie w uchwycie nie może tego wykonać. Przycisk „Cofnij” zapewnia prostą alternatywę. Ktoś inny porusza telefonem mimowolnie i przypadkowo uruchamia cofanie. Możliwość wyłączenia reakcji na ruch chroni przed utratą pracy. Obie potrzeby mogą wystąpić w tej samej funkcji.

W kolejnym przykładzie aplikacja wymaga przechylenia urządzenia, aby odsłonić dodatkowe informacje. Użytkownik leżący w łóżku ma ograniczoną możliwość zmiany pozycji. Dostępna kontrolka pozwala wyświetlić treść bez fizycznego manewrowania telefonem. Nie trzeba usuwać zabawnej funkcji dla pozostałych osób, ale nie powinna być jedyną drogą do ważnej informacji.

Sprawdź ustawienia i spróbuj wykonać zadanie z nieruchomym urządzeniem. Czy wszystkie istotne funkcje mają alternatywę? Czy wyłączenie ruchu nie blokuje całej aplikacji? Trzeba przy tym rozróżnić zwykły interfejs od sytuacji, w których ruch jest istotą zadania lub pochodzi z obsługiwanej technologii asystującej. Wyjątek nie powinien być stosowany automatycznie. W dokumentacji warto opisać, dlaczego dana funkcja wymaga ruchu i jakie inne sposoby działania są dostępne. Użytkownik powinien móc świadomie wybrać metodę, która odpowiada jego możliwościom.

Kryterium 2.5.5 — Duży obszar celu. Poziom AAA

Obszar aktywowany wskaźnikiem powinien mieć co najmniej 44 na 44 piksele CSS, z wyjątkami dotyczącymi między innymi równoważnej kontrolki, linków w tekście, kontrolek przeglądarki i istotnej prezentacji. Liczy się rzeczywisty obszar działania, a nie tylko rozmiar narysowanej ikony. Objaśnienie W3C: 2.5.5.

Osoba z ograniczoną precyzją ruchu próbuje zamknąć okno. Krzyżyk jest bardzo mały, a obok znajduje się reklama. Użytkownik wielokrotnie trafia w niewłaściwe miejsce. Można pozostawić niewielki symbol, ale zapewnić mu większy obszar kliknięcia i odpowiedni odstęp od innych funkcji. Warto również użyć czytelnej nazwy dla technologii asystujących.

W aplikacji do rezerwacji przyciski zmiany liczby osób są drobnymi znakami plus i minus. Większe kontrolki pomagają nie tylko osobie z drżeniem rąk, lecz także użytkownikowi obsługującemu telefon jedną ręką. Szczególnie ważne są działania wykonywane często lub mające poważniejsze skutki. W projekcie nie należy poświęcać całej przestrzeni na dekorację, pozostawiając funkcjom minimalny obszar.

Zmierz rzeczywisty aktywny cel i sprawdź, czy kliknięcie przy krawędzi działa. Nie oceniaj wyłącznie wielkości grafiki. Zwróć uwagę na stan po powiększeniu i na mniejsze ekrany. Kryterium AAA jest bardziej wymagające niż nowe minimum AA z 2.5.8. Nie należy mieszać tych progów w raporcie. Jeśli zespół świadomie przyjmuje większe cele jako własny standard, warto zastosować go konsekwentnie w całym serwisie, także w oknach zgód, pomocy i ustawień.

Kryterium 2.5.6 — Różne sposoby wprowadzania danych. Poziom AAA

Treść nie powinna ograniczać dostępnych sposobów wprowadzania danych, chyba że ograniczenie jest istotne, potrzebne dla bezpieczeństwa albo wynika z ustawień użytkownika. Osoba może chcieć łączyć dotyk, klawiaturę, mysz i mowę. Objaśnienie W3C: 2.5.6.

Użytkownik tabletu wybiera elementy dotykiem, ale dłuższe teksty wpisuje klawiaturą. Aplikacja rozpoznaje ekran dotykowy i wyłącza obsługę klawiatury. To niepotrzebne ograniczenie. Sam typ urządzenia nie mówi, jak dana osoba będzie z niego korzystać. Laptop również może mieć ekran dotykowy, a telefon może współpracować z zewnętrzną klawiaturą lub innym urządzeniem.

Osoba z bólem dłoni zmienia sposób pracy w ciągu dnia. Rano używa myszy, później dyktowania i klawiatury. Jeśli aplikacja wymusza wybór jednego trybu na całą sesję, zwiększa obciążenie. Elastyczność pozwala dostosować obsługę do aktualnej sytuacji bez ponownego logowania i bez utraty danych. Warto unikać projektowania interfejsu na podstawie zbyt prostych założeń o „użytkowniku mobilnym”.

Sprawdź przechodzenie pomiędzy metodami w ramach jednego zadania. Czy po dotknięciu ekranu fokus klawiatury nadal działa? Czy elementy nie znikają po rozpoznaniu myszy? Czy użytkownik może wpisać tekst głosem i zatwierdzić go klawiszem? Ograniczenia związane z bezpieczeństwem wymagają konkretnego uzasadnienia, a nie ogólnego hasła. Dobrze jest projektować funkcje tak, aby różne metody prowadziły do tego samego rezultatu i nie wymagały oddzielnej, uboższej wersji usługi.

Kryterium 2.5.7 — Alternatywa dla przeciągania. Poziom AA

Funkcje wykorzystujące przeciąganie powinny dać się wykonać pojedynczym wskaźnikiem bez przeciągania, chyba że przeciąganie jest istotne albo działanie pochodzi z niezmodyfikowanej funkcji przeglądarki. Obsługa klawiaturą pozostaje potrzebna, ale sama nie spełnia tego wymagania. Objaśnienie W3C: 2.5.7.

Osoba porządkuje załączniki do wniosku. System wymaga chwycenia wiersza, utrzymania nacisku i przesunięcia go w odpowiednie miejsce. Przy drżeniu dłoni element ciągle wypada. Przyciski „Przenieś wyżej” i „Przenieś niżej” pozwalają wykonać tę samą czynność prostymi kliknięciami. Można też udostępnić wybór pozycji z listy, jeśli jest zrozumiały i wygodny.

W formularzu zakres ceny ustawia się suwakiem. Użytkownik ma trudność z przeciągnięciem uchwytu do dokładnej wartości. Pola do wpisania kwoty albo przyciski zmiany wartości dają alternatywę. Warto zadbać, aby rezultat był ten sam: osoba nie powinna mieć dostępu tylko do kilku ogólnych przedziałów, jeśli inni mogą wybrać dokładną kwotę.

Test polega na wykonaniu każdej funkcji wymagającej przeciągania za pomocą prostych naciśnięć. Czy da się przesunąć element, zmienić kolejność i wybrać zakres? Czy alternatywne kontrolki są widoczne? Ukrycie ich w trudno dostępnym menu może osłabić praktyczną korzyść. Nie należy mylić tego kryterium z samą możliwością wykonania zadania klawiaturą. Osoba używająca ekranu dotykowego może nie mieć klawiatury, a mimo to potrzebuje metody niewymagającej utrzymywania i prowadzenia ruchu.

Kryterium 2.5.8 — Minimalny rozmiar celu. Poziom AA

Cel wskaźnika powinien mieć co najmniej 24 na 24 piksele CSS albo spełniać jeden z wyjątków. Wyjątek odstępu wymaga określonego układu: okrąg o średnicy 24 pikseli CSS wyśrodkowany na małym celu nie może przecinać innego celu ani analogicznego okręgu innego małego celu. Są też wyjątki dotyczące równoważności, tekstu, przeglądarki i istotnej prezentacji. Objaśnienie W3C: 2.5.8.

W kalendarzu daty są ciasno ułożone. Osoba z drżeniem dłoni wybiera wtorek, ale uruchamia środę. Większy obszar lub odpowiednie odstępy zmniejszają ryzyko. Nie wystarczy zapewnić, że „da się trafić”, ponieważ ocena sprawnego projektanta nie odzwierciedla potrzeb wszystkich użytkowników. Minimalny próg jest punktem odniesienia, a nie zaleceniem, by każdy przycisk był możliwie mały.

W pasku narzędzi obok siebie znajdują się ikony zapisu, usuwania i wysyłania. Pomyłka może mieć duże skutki. Warto zwiększyć cele ponad minimum i wyraźnie oddzielić działania. Jeżeli korzysta się z wyjątku odstępu, trzeba sprawdzić również sąsiedztwo nad i pod kontrolką, a nie tylko w jednym rzędzie. Układ zmieniający się na telefonie może sprawić, że wcześniej poprawne odstępy przestaną wystarczać.

Pomiar dotyczy pikseli CSS i rzeczywistego celu. Powiększenie strony przez użytkownika nie jest sposobem spełnienia wymagania przez autora. Sprawdź przyciski zamykania, paginację, menu i małe ikony przy polach. Wyjątek dla linków w zdaniu nie oznacza zwolnienia całego menu z oceny. Zawsze najpierw ustal rodzaj elementu, a dopiero potem właściwy warunek. Dla ważnych czynności warto rozważyć większy próg opisany w 2.5.5.

Zrozumiałość: Jasna treść i przewidywalne działanie

Strona może być technicznie obsługiwana klawiaturą, a mimo to pozostawać trudna do wykorzystania. Użytkownik nie rozumie pytania, nie wie, czy dane zostały wysłane, albo obawia się nacisnąć przycisk o niejasnej nazwie. Zrozumiałość obejmuje język oraz zachowanie interfejsu. Pomocna strona prowadzi przez zadanie bez nagłych zmian, wyjaśnia błędy i pozwala je poprawić. Nie wymaga od odbiorcy znajomości wewnętrznych procedur organizacji.

Kryterium 3.1.1 — Język strony. Poziom A

Główny język strony powinien być możliwy do określenia programowo. Dzięki temu narzędzia mogą dobrać między innymi reguły wymowy. Sama obecność polskiego tekstu nie zastępuje odpowiedniego oznaczenia. Objaśnienie W3C: 3.1.1.

Osoba niewidoma otwiera polską instrukcję, ale czytnik wymawia wyrazy według zasad języka angielskiego. Zrozumienie staje się trudniejsze, szczególnie przy nazwach i liczbach. Autor strony powinien wskazać język polski w odpowiednim miejscu struktury dokumentu. Użytkownik nie powinien ręcznie zmieniać ustawień przy każdej podstronie, aby skorygować brak informacji od autora.

W portalu wielojęzycznym polska i angielska wersja mogą korzystać z tego samego szablonu. Jeśli oznaczenie języka pozostaje niezmienne, jedna wersja będzie błędnie opisana. To częsty skutek kopiowania treści bez aktualizacji metadanych. Dobrze jest powiązać wybór wersji językowej z właściwym oznaczeniem dokumentu, zamiast traktować go jako osobną czynność, o której redaktor musi zawsze pamiętać.

Sprawdź język w kodzie lub narzędziu analizy dostępności, a następnie odsłuchaj fragment z odpowiednio skonfigurowanym czytnikiem. Sam odsłuch może zależeć od ustawień użytkownika, dlatego nie zastępuje kontroli oznaczenia. Zwróć uwagę także na strony błędów, potwierdzenia i formularze pochodzące z innych modułów. Często główna strona ma poprawny język, lecz ekran logowania zachowuje domyślne ustawienie zagranicznego szablonu. Dla użytkownika cały proces powinien być spójny.

Kryterium 3.1.2 — Język fragmentów. Poziom AA

Język poszczególnych fragmentów powinien być określony programowo, z wyjątkami dotyczącymi między innymi nazw własnych, terminów technicznych, słów nieokreślonego języka oraz wyrazów przyjętych w otaczającym języku. Objaśnienie W3C: 3.1.2.

Polski artykuł zawiera kilka zdań po angielsku. Czytnik powinien otrzymać informację o zmianie języka, aby móc odczytać fragment właściwą wymową. Bez oznaczenia cytat może stać się niezrozumiały. Nie chodzi o oznaczanie każdego popularnego zapożyczenia, lecz o sensowne rozpoznanie rzeczywistej zmiany językowej zgodnie z zakresem kryterium.

W materiale edukacyjnym uczący się hiszpańskiego ma porównać polskie wyjaśnienie z hiszpańskim zdaniem. Poprawne oznaczenie pomaga usłyszeć różnicę. Jeżeli cały tekst zostanie potraktowany jako polski, ćwiczenie wymowy traci wartość. Podobny problem występuje w instrukcjach obsługi zawierających oryginalny komunikat z zagranicznego programu i jego tłumaczenie.

Sprawdź dłuższe obcojęzyczne cytaty, nazwy sekcji w innym języku oraz przełączniki wersji językowych. Upewnij się, że oznaczenie obejmuje właściwy fragment i kończy się tam, gdzie wraca język główny. Błędnie rozciągnięte oznaczenie może sprawić, że cała dalsza część dokumentu będzie wymawiana niewłaściwie. W redakcji warto przygotować prostą instrukcję stosowania oznaczeń w edytorze. Nie należy oczekiwać, że autor każdego artykułu będzie ręcznie analizował kod, jeśli system publikacji może zapewnić wygodny i poprawny mechanizm.

Kryterium 3.1.3 — Nietypowe słowa. Poziom AAA

Dostępny powinien być mechanizm wyjaśniający słowa użyte w nietypowym lub ograniczonym znaczeniu, w tym idiomy i żargon. Użytkownik nie powinien zgadywać znaczenia ważnego terminu. Objaśnienie W3C: 3.1.3.

W instrukcji pojawia się zdanie „Uwierzytelnij operację”. Osoba, która rzadko korzysta z usług cyfrowych, nie wie, czego się od niej oczekuje. Można wyjaśnić: „Potwierdź, że to Ty wykonujesz tę czynność, korzystając z podanej metody”. Jeśli termin ma dokładne znaczenie prawne lub techniczne, warto zachować go i dodać objaśnienie, zamiast zastępować nieprecyzyjnym synonimem.

Inny przykład dotyczy komunikatu „Wniosek pozostawiono bez rozpoznania”. Czytelnik może błędnie uznać, że sprawa nadal czeka w kolejce. Proste objaśnienie skutku oraz wskazanie następnego kroku pomaga zrozumieć sytuację. Sam słownik na końcu bardzo długiego dokumentu może być trudny do odnalezienia, dlatego przy ważnych terminach warto dodać dostępny odsyłacz lub wyjaśnienie w pobliżu.

Sprawdź tekst z osobą spoza branży. Poproś, aby własnymi słowami opisała znaczenie kluczowych pojęć. Nie pytaj wyłącznie „Czy wszystko jest jasne?”, ponieważ ludzie często potwierdzają z grzeczności. Mechanizm objaśnień powinien działać klawiaturą i na telefonie. Dymek dostępny tylko po najechaniu myszą może stworzyć kolejną barierę. Warto także unikać wyjaśniania jednego trudnego słowa trzema równie trudnymi. Dobry przykład sytuacyjny często pomaga bardziej niż definicja napisana stylem encyklopedii.

Kryterium 3.1.4 — Skróty. Poziom AAA

Użytkownik powinien mieć możliwość poznania rozwinięcia lub znaczenia skrótów. Nie każdy odbiorca zna terminologię instytucji, branży czy systemu. Objaśnienie W3C: 3.1.4.

Formularz prosi o wybór „JST”, „NGO” albo „MŚP”. Dla pracownika są to codzienne oznaczenia, lecz użytkownik może nie wiedzieć, gdzie należy. Rozwinięcie skrótu i krótkie wyjaśnienie pozwalają dokonać wyboru. Jeśli rozwinięcie również jest specjalistyczne, warto dodać przykład. Sam długi pełny termin nie zawsze rozwiązuje problem zrozumienia.

W portalu edukacyjnym pojawia się skrót „PJM”. Przy pierwszym użyciu można napisać „polski język migowy”, a potem stosować skrót. W dokumentach odczytywanych fragmentami dobrze zapewnić także łatwy dostęp do słownika. Czytelnik nie zawsze zaczyna od pierwszej strony. W długim formularzu może trafić bezpośrednio do pola, którego opis wymaga wyjaśnienia.

Sprawdź skróty w nagłówkach, przyciskach, tabelach i załącznikach. Czy rozwinięcie jest dostępne dla czytnika i użytkownika dotykowego? Nie zakładaj, że atrybut wyświetlany po zatrzymaniu myszy będzie wystarczający w każdej sytuacji. Warto stosować prosty tekst lub dostępne objaśnienie. Nie trzeba rozwijać każdego skrótu po każdym wystąpieniu, jeśli mechanizm pozwala ustalić znaczenie. Kluczowe jest to, aby użytkownik nie musiał przerywać zadania i szukać terminu w zewnętrznej wyszukiwarce, ryzykując znalezienie niewłaściwego znaczenia.

Kryterium 3.1.5 — Poziom trudności czytania. Poziom AAA

Gdy tekst po usunięciu nazw własnych i tytułów wymaga umiejętności czytania wyższych niż poziom niższego szkolnictwa średniego, trzeba zapewnić treść uzupełniającą albo prostszą wersję, zgodnie z warunkami standardu. Nie jest to automatycznie wymaganie, aby każdy specjalistyczny dokument utracił precyzję. Objaśnienie W3C: 3.1.5.

Osoba chce dowiedzieć się, jak odebrać dokument. Otrzymuje wielokrotnie złożone zdanie z licznymi odesłaniami. Prosta wersja może wskazywać trzy kroki: przygotuj dokument tożsamości, przyjdź do wskazanego miejsca, odbierz decyzję. Pełne objaśnienie prawne może pozostać obok. Ważne, aby prostszy tekst nie pomijał warunku, od którego zależy możliwość załatwienia sprawy.

W materiałach medycznych lub finansowych nadmierne upraszczanie może zniekształcić znaczenie. Dlatego warto rozdzielić podstawowe instrukcje, wyjaśnienie terminów i szczegóły. Przykład: zamiast usuwać informację o wyjątku, można opisać go osobnym krótkim akapitem. Użytkownik powinien rozumieć, kiedy ogólna zasada go nie dotyczy. Prosty język nie oznacza języka dziecinnego ani protekcjonalnego tonu.

Sprawdź tekst z odbiorcami, prosząc o wskazanie następnego kroku. Czy potrafią powiedzieć, co mają zrobić i czego potrzebują? Automatyczny wskaźnik trudności może być pomocą, lecz nie ocenia wszystkich aspektów znaczenia. Warto kontrolować także liczby, negacje i kolejność informacji. Tekst łatwy do czytania i zrozumienia jest osobnym podejściem redakcyjnym; nie należy utożsamiać go z każdym uproszczonym akapitem. Dobór formy powinien odpowiadać potrzebom odbiorców.

Kryterium 3.1.6 — Wymowa. Poziom AAA

Należy zapewnić sposób ustalenia wymowy słów tam, gdzie ich znaczenie w danym kontekście jest niejednoznaczne bez znajomości wymowy. Nie jest to obowiązek dodawania nagrania do każdego słowa. Objaśnienie W3C: 3.1.6.

W materiale językowym dwa wyrazy zapisane podobnie mają odmienne znaczenie zależne od akcentu lub wymowy. Uczeń korzystający z tekstu potrzebuje wskazówki, która wersja jest zamierzona. Można zastosować zapis fonetyczny, objaśnienie albo dostępne nagranie. Dobór rozwiązania zależy od odbiorcy: sam specjalistyczny alfabet fonetyczny może nie być dla niego zrozumiały.

Przykład praktyczny dotyczy kursu, w którym zadanie polega na rozróżnieniu znaczeń obcego słowa. Jeśli autor podaje tylko zapis, a kontekst nie rozstrzyga, użytkownik nie wie, którą formę odczytać. Krótkie wyjaśnienie usuwa niejednoznaczność. W zwykłej polskiej instrukcji większość słów nie wymaga takiego dodatku, dlatego trzeba oceniać rzeczywistą potrzebę, a nie mechanicznie dodawać przyciski odsłuchu wszędzie.

Sprawdź miejsca, w których wymowa zmienia sens. Czy odbiorca ma dostęp do wyjaśnienia również bez myszy? Jeśli użyto dźwięku, czy przycisk ma nazwę i można kontrolować odtwarzanie? Czy istnieje forma odpowiednia dla osób, które nie słyszą? Warto pamiętać, że mechanizm pomagający jednej grupie nie powinien być jedyną drogą poznania ważnej informacji, jeśli wyklucza inną. Dobrze przygotowane objaśnienie może połączyć zapis, kontekst i przykład użycia, dzięki czemu nie wymaga zgadywania.

Kryterium 3.2.1 — Brak zmiany kontekstu po samym uzyskaniu fokusu. Poziom A

Samo przejście fokusu na element nie powinno wywoływać zmiany kontekstu. Użytkownik musi móc zapoznać się z kontrolką bez nieoczekiwanego przeniesienia do innej strony lub okna. Objaśnienie W3C: 3.2.1.

Osoba przechodzi Tabem po menu. Gdy trafia na „Kontakt”, strona natychmiast otwiera formularz, choć użytkownik nie nacisnął Enter. Nie może spokojnie obejrzeć pozostałych pozycji. Lepsze rozwiązanie wymaga świadomej aktywacji linku. Fokus służy nawigacji i rozpoznawaniu elementów, a nie powinien automatycznie oznaczać zgody na każdą czynność.

W formularzu pole numeru telefonu po uzyskaniu fokusu otwiera nowe okno z ofertą kontaktu. Osoba korzystająca z czytnika nagle znajduje się w innym miejscu. Traci orientację i może nie wiedzieć, jak wrócić. Informacja pomocnicza wyświetlona bez zmiany kontekstu to inna sytuacja, ale trzeba uważać, aby nie przejmowała obsługi w nieprzewidywalny sposób.

Testuj stronę, przechodząc przez elementy bez ich aktywowania. Czy zmienia się strona, okno lub główne miejsce pracy? Czy fokus nagle przeskakuje? Nie każda zmiana wizualna jest zmianą kontekstu; podświetlenie przycisku jest normalne. Ważne jest, czy użytkownik nadal kontroluje swoje położenie i zadanie. Warto oddzielić w projekcie trzy stany: wskazanie, wybór i wykonanie. Ich zlewanie może szczególnie utrudniać pracę osobom, które poruszają się sekwencyjnie i muszą przejść przez wiele elementów, zanim dotrą do właściwego.

Kryterium 3.2.2 — Przewidywalność po zmianie wartości. Poziom A

Zmiana ustawienia kontrolki nie powinna automatycznie powodować zmiany kontekstu, chyba że użytkownik został wcześniej o tym poinformowany. Chodzi między innymi o wybór opcji i wpisywanie danych. Objaśnienie W3C: 3.2.2.

Użytkownik wybiera województwo z listy. Po pierwszym naciśnięciu strzałki formularz od razu przechodzi na nową stronę. Osoba korzystająca z klawiatury nie zdążyła dotrzeć do właściwej opcji. Bezpieczniej pozwolić wybrać wartość, a następnie użyć przycisku potwierdzenia. Jeśli określony wybór ma od razu przenosić do innego miejsca, trzeba to jasno zapowiedzieć.

Dynamiczne pokazanie pola zależnego od odpowiedzi nie musi oznaczać niedozwolonej zmiany kontekstu. Przykład: po zaznaczeniu „Chcę fakturę” pojawiają się dodatkowe dane. Ważne, aby użytkownik rozumiał, co się stało, i mógł przejść dalej w logicznej kolejności. Nie należy jednak automatycznie wysyłać całego formularza po zaznaczeniu ostatniej opcji, jeśli nie zostało to odpowiednio przewidziane i wyjaśnione.

Sprawdź listy wyboru, pola typu tak lub nie oraz filtry. Czy zmiana wartości nie przenosi użytkownika bez ostrzeżenia? Czy wpisanie ostatniej cyfry nie uruchamia nieodwracalnej czynności? Warto przetestować obsługę strzałkami, ponieważ zachowanie może różnić się od wyboru myszą. Projekt powinien dawać czas na zapoznanie się z opcjami. Użytkownik ma prawo zmienić zdanie przed zatwierdzeniem, a samo przeglądanie możliwych wartości nie powinno być traktowane jako ostateczne polecenie.

Kryterium 3.2.3 — Spójna nawigacja. Poziom AA

Mechanizmy nawigacyjne powtarzające się na wielu stronach powinny występować w tej samej względnej kolejności, chyba że zmianę inicjuje użytkownik. Spójność pomaga budować orientację. Objaśnienie W3C: 3.2.3.

Osoba słabowidząca pamięta, że po wyszukiwarce znajduje się link do usług. Na kolejnej stronie elementy zamieniają miejsca bez wyraźnego powodu. Przy dużym powiększeniu użytkownik widzi niewielki fragment ekranu i musi od nowa szukać potrzebnej funkcji. Stały porządek ogranicza ten wysiłek. Nie wymaga identycznej zawartości każdej podstrony, lecz przewidywalności powtarzanych mechanizmów.

W serwisie edukacyjnym przyciski „Poprzednia lekcja”, „Spis lekcji” i „Następna lekcja” powinny zachowywać kolejność. Jeżeli autor jednego modułu odwraca ją dla estetyki, uczestnik może nieświadomie cofnąć się zamiast przejść dalej. Osoby z trudnościami pamięciowymi szczególnie korzystają ze stałych wzorców. To samo dotyczy pomocy, ustawień i wylogowania.

Porównaj kilka szablonów: artykuł, formularz, wyniki wyszukiwania i stronę kontaktową. Czy wspólne menu zachowuje względny układ? Czy wersja mobilna jest przewidywalna w swoim układzie? Nie należy interpretować wymagania jako zakazu dostosowania strony do małego ekranu. Ważna jest spójność w porównywalnych warunkach i możliwość rozpoznania funkcji. Warto korzystać ze wspólnych komponentów, ponieważ ręczne odtwarzanie menu na każdej stronie sprzyja przypadkowym różnicom oraz utrudnia późniejsze poprawki.

Kryterium 3.2.4 — Spójne rozpoznawanie funkcji. Poziom AA

Elementy pełniące tę samą funkcję w zestawie stron powinny być oznaczane spójnie. Użytkownik nie powinien uczyć się nowej nazwy tego samego działania na każdym ekranie. Objaśnienie W3C: 3.2.4.

W jednym miejscu przycisk zapisu szkicu nazywa się „Zapisz”, w drugim „Zachowaj”, a w trzecim „Archiwizuj”, choć działanie jest identyczne. Osoba z trudnościami poznawczymi może uznać, że są to różne funkcje. Spójne nazwy ograniczają konieczność interpretowania interfejsu. Jeżeli funkcje rzeczywiście się różnią, nazwy powinny tę różnicę wyjaśniać.

Podobna zasada dotyczy ikon. Symbol lupy nie powinien raz oznaczać wyszukiwania, a raz usuwania filtrów bez dodatkowego wyjaśnienia. Nazwy dostępne dla czytników również powinny zachowywać spójność. Czasami warstwa wizualna jest uporządkowana, ale ukryte etykiety pochodzą z różnych komponentów i opisują to samo inaczej. Użytkownik technologii asystującej otrzymuje wtedy mniej przewidywalny serwis niż osoba patrząca na ekran.

Sprawdź powtarzające się działania na kilku stronach. Zestaw ich widoczne nazwy, ikony i nazwy dostępne. Zapytaj, czy różnica wynika z rzeczywistej zmiany celu. Przycisk „Pobierz fakturę” i „Pobierz umowę” może być spójny, ponieważ zachowuje nazwę działania i doprecyzowuje obiekt. Nie chodzi o identyczność wszystkich słów. Chodzi o to, aby użytkownik mógł przenieść wiedzę z jednego ekranu na drugi. Warto prowadzić prosty słownik nazw stosowanych w całym produkcie.

Kryterium 3.2.5 — Zmiany na żądanie. Poziom AAA

Zmiany kontekstu powinny następować na żądanie użytkownika albo istnieć mechanizm ich wyłączenia. To szersza ochrona przewidywalności niż wymagania dotyczące samego fokusu i zmiany wartości. Objaśnienie W3C: 3.2.5.

Osoba czyta instrukcję, a strona po kilkunastu sekundach automatycznie przenosi ją do formularza. Użytkownik nie zdążył poznać warunków. Lepszy projekt pokazuje przycisk „Przejdź do formularza” i pozostawia decyzję czytelnikowi. Szybkość czytania jest różna, a niektórzy potrzebują odsłuchać fragment ponownie lub zrobić przerwę.

W innym przykładzie po zakończeniu filmu automatycznie otwiera się kolejny materiał i przejmuje główny obszar strony. Osoba chciała wrócić do notatek, lecz system decyduje za nią. Możliwość wyłączenia automatycznych zmian pozwala zachować kontrolę. Nie należy zakładać, że każde zachowanie popularne w serwisach rozrywkowych będzie właściwe w usłudze publicznej lub edukacyjnej.

Sprawdź stronę po upływie czasu oraz po zakończeniu mediów. Czy następują nieoczekiwane przekierowania, otwarcia okien lub zmiany miejsca pracy? Czy ustawienie wyłączenia jest łatwo dostępne? Warto jasno oznaczać działania prowadzące do nowego okna lub innego środowiska. Użytkownik powinien rozumieć, kiedy opuszcza bieżący proces. Projektowanie na żądanie nie oznacza zakazu wszystkich dynamicznych zmian. Oznacza, że ważne przejścia mają być przewidywalne i podlegać kontroli, zamiast zaskakiwać osobę w trakcie czytania lub wpisywania danych.

Kryterium 3.2.6 — Spójna pomoc. Poziom A

Jeżeli określone mechanizmy pomocy powtarzają się w zestawie stron, powinny występować w tej samej względnej kolejności względem innych treści, chyba że zmianę inicjuje użytkownik. Dotyczy to między innymi kontaktu z człowiekiem, samoobsługowej pomocy i automatycznego kontaktu. Kryterium nie nakazuje samo w sobie dodania wszystkich tych kanałów. Objaśnienie W3C: 3.2.6.

Osoba z trudnościami pamięciowymi nauczyła się, że pomoc znajduje się na końcu formularza. Na kolejnym etapie link znika i pojawia się mała ikona w innym rogu. Użytkownik może uznać, że wsparcie nie jest już dostępne. Stałe umiejscowienie pozwala wrócić do poznanego sposobu uzyskania informacji bez ponownego szukania.

W portalu rezerwacji na każdej stronie znajduje się blok kontaktu: najpierw instrukcja, potem czat i dane kontaktowe. Zachowanie tego układu pomaga przewidzieć, gdzie jest potrzebna opcja. Jeżeli na telefonie blok przyjmuje inną postać, powinien być spójny w tym wariancie. Nie chodzi o zamrożenie wszystkich pikseli, lecz o przewidywalność relacji między elementami.

Sprawdź mechanizmy pomocy w całym procesie, także przy błędach i na ekranie logowania. Czy nazwy i kolejność są podobne? Czy kontakt nie znika w momencie największej trudności? Dostępność samego kanału wymaga osobnej oceny. Stałe położenie numeru telefonu nie rozwiązuje potrzeb osoby, która nie może rozmawiać głosowo. Warto więc połączyć spełnienie kryterium z szerszym projektem obsługi, zapewniając użyteczne sposoby kontaktu odpowiadające odbiorcom i charakterowi sprawy.

Kryterium 3.3.1 — Rozpoznanie błędu. Poziom A

Jeżeli system automatycznie wykrywa błąd danych, powinien wskazać element z błędem i opisać problem tekstowo. Sam kolor, dźwięk lub znak wykrzyknika nie wystarcza. Objaśnienie W3C: 3.3.1.

Użytkownik wysyła formularz i widzi czerwone obramowanie trzech pól. Nie wie, czy brakuje odpowiedzi, czy format jest niewłaściwy. Osoba niewidoma może nie otrzymać żadnej informacji. Komunikat „W polu E-mail brakuje znaku @” pozwala zrozumieć problem. Jeśli system nie potrafi wskazać tak szczegółowej przyczyny, powinien przynajmniej jasno określić, które dane zostały odrzucone.

W formularzu wyboru terminu błąd brzmi „Nieprawidłowa wartość”. Użytkownik nie wie, czy termin jest zajęty, data przeszła, czy wymagany jest inny zapis. Lepsza informacja odnosi się do rzeczywistej przyczyny. Nie należy obwiniać osoby komunikatem „Źle wypełniłeś formularz”, gdy problem wynika z niewyjaśnionych wymagań. Ton powinien pomagać w poprawieniu sytuacji.

Sprawdź celowo pominięte pole i nieprawidłowy format w środowisku testowym. Czy komunikat jest tekstowy, powiązany z polem i dostępny dla technologii asystujących? Czy podsumowanie błędów pozwala dotrzeć do właściwego miejsca? Nie usuwaj poprawnych danych po błędzie. Użytkownik powinien poprawić to, co wymaga zmiany, a nie powtarzać całą pracę. Warto też upewnić się, że błąd nie jest ogłaszany przy każdym naciśnięciu klawisza, zanim osoba zdąży dokończyć wpisywanie wartości.

Kryterium 3.3.2 — Etykiety i instrukcje. Poziom A

Gdy treść wymaga wprowadzania danych, należy zapewnić etykiety lub instrukcje. Użytkownik powinien wiedzieć, czego dotyczy pole i jakie informacje są potrzebne. Objaśnienie W3C: 3.3.2.

Formularz zawiera puste prostokąty, a ich znaczenie pokazują tylko blade przykłady wewnątrz. Po wpisaniu pierwszej litery przykład znika. Osoba z trudnościami pamięciowymi nie wie już, czy w danym polu miał znaleźć się adres zamieszkania czy korespondencyjny. Stała etykieta pozostaje widoczna podczas pracy i pozwala sprawdzić dane przed wysłaniem.

Instrukcja powinna pojawić się przed problemem. Jeśli hasło musi spełniać określone warunki, nie należy ujawniać ich dopiero po kilku nieudanych próbach. Jeżeli wymagany jest konkretny format daty, można podać go przy polu. Warto też wyraźnie oznaczyć pola obowiązkowe i wyjaśnić użyty symbol. Sam czerwony kolor lub gwiazdka bez legendy mogą być niezrozumiałe.

Sprawdź formularz oczami osoby, która korzysta z niego po raz pierwszy. Czy wiadomo, jakie dane przygotować? Czy instrukcje są zwięzłe i znajdują się blisko odpowiednich pól? Czy są dostępne również programowo? Nie przeładowuj każdego pola wieloma akapitami. Dodatkowe szczegóły można udostępnić w dobrze opisanej pomocy, pozostawiając podstawową instrukcję na widoku. Dobrze zaprojektowana etykieta zmniejsza liczbę błędów, ale nie zastępuje prawidłowego powiązania z polem, opisanego także w innych kryteriach. Warstwa wizualna i techniczna powinny działać razem.

Kryterium 3.3.3 — Podpowiedź poprawienia błędu. Poziom AA

Jeżeli błąd został wykryty automatycznie i znany jest sposób jego poprawienia, należy podać odpowiednią sugestię, chyba że zagrażałoby to bezpieczeństwu lub celowi treści. Objaśnienie W3C: 3.3.3.

Osoba wpisuje datę jako dzień, miesiąc i rok oddzielone kropkami. System oczekuje innego zapisu i odpowiada „Błąd”. Lepszy komunikat podaje przykład właściwego formatu. Jeszcze lepszy projekt może przyjmować kilka jednoznacznych formatów i normalizować dane. Kryterium dotyczy podpowiedzi, ale warto także ograniczać niepotrzebne wymagania, które generują błędy.

W formularzu załączników użytkownik przesyła plik zbyt duży. Komunikat powinien wskazać limit oraz możliwe działanie, na przykład wybór mniejszego pliku. Nie powinien obiecywać funkcji kompresji, której system nie udostępnia. W przypadku pola adresu można zaproponować sprawdzenie brakującej części, ale nie należy samodzielnie zmieniać danych na podstawie niepewnego domysłu.

Testuj typowe pomyłki i oceniaj, czy po przeczytaniu komunikatu wiadomo, co zrobić. „Wartość nie spełnia walidacji” jest opisem dla programisty, a nie wskazówką dla użytkownika. Trzeba jednak uważać przy logowaniu: zbyt szczegółowa informacja może ujawnić, czy konkretne konto istnieje. W takich sytuacjach sposób komunikacji należy pogodzić z bezpieczeństwem. Dostępność nie wymaga ujawniania tajnych informacji, lecz jasnej pomocy w granicach właściwych dla danej funkcji. Użytkownik powinien otrzymać możliwą drogę dalszego działania.

Kryterium 3.3.4 — Zapobieganie poważnym błędom. Poziom AA

Przy określonych czynnościach prawnych, finansowych, zmianie lub usuwaniu danych użytkownika oraz przesyłaniu odpowiedzi testowych należy zapewnić co najmniej jeden z mechanizmów: odwracalność, sprawdzenie danych z możliwością poprawy albo przegląd i potwierdzenie przed ostatecznym wysłaniem. Objaśnienie W3C: 3.3.4.

Osoba przygotowuje płatność i omyłkowo wpisuje dodatkową cyfrę. Ekran podsumowania pokazuje odbiorcę i kwotę w czytelnej formie oraz pozwala wrócić do edycji. Dzięki temu użytkownik może zauważyć błąd przed zatwierdzeniem. Samo pytanie „Czy na pewno?” bez danych nie daje wystarczającej informacji do oceny decyzji. Warto pokazać, co dokładnie zostanie wykonane.

W innym przykładzie użytkownik usuwa zapisany wniosek. System może zapewnić możliwość odzyskania albo odpowiedni etap potwierdzenia, zależnie od przyjętego rozwiązania. Nie należy dodawać wielu identycznych ostrzeżeń przy każdej drobnej czynności, ponieważ ludzie przestają je czytać. Ochrona powinna odpowiadać skutkom działania. Szczególnie ważne jest rozróżnienie zapisania szkicu od ostatecznego wysłania.

Sprawdź, czy podsumowanie jest dostępne czytnikiem, klawiaturą i po powiększeniu. Czy przycisk poprawy prowadzi do właściwego miejsca? Czy poprawka zachowuje pozostałe dane? Czy nazwa końcowego przycisku jasno wskazuje skutek? Nie testuj realnych zobowiązań tylko po to, aby sprawdzić interfejs. Organizacja powinna zapewnić bezpieczne środowisko lub kontrolowaną procedurę. Użytkownik ma otrzymać ochronę przed pomyłką bez konieczności rozumienia technicznych szczegółów systemu.

Kryterium 3.3.5 — Pomoc kontekstowa. Poziom AAA

Użytkownik powinien mieć dostęp do pomocy związanej z wykonywanym zadaniem. Ogólny adres kontaktowy nie zawsze odpowiada na pytanie o konkretne pole lub etap. Objaśnienie W3C: 3.3.5.

Formularz prosi o numer dokumentu. Osoba nie wie, gdzie go znaleźć. Krótkie wyjaśnienie przy polu może wskazać nazwę oznaczenia i miejsce na dokumencie. Jeśli używa się ilustracji, trzeba zadbać o jej alternatywę. Pomoc powinna wyjaśniać czynność, a nie zmuszać do przeczytania całego regulaminu. Warto też odróżnić numer dokumentu od innych podobnych numerów.

W portalu rezerwacji pytanie dotyczy liczby osób towarzyszących. Użytkownik nie wie, czy wliczyć opiekuna. Pomoc kontekstowa wyjaśnia zasady tej konkretnej usługi. Nie należy podawać ogólnej odpowiedzi, która nie odpowiada rzeczywistemu sposobowi naliczania miejsc. Treść pomocy musi być utrzymywana razem z formularzem, inaczej po zmianie procedury zacznie wprowadzać w błąd.

Sprawdź, czy pomoc jest dostępna w momencie potrzeby i nie powoduje utraty wpisanych danych. Czy można ją otworzyć klawiaturą, przeczytać i wrócić do pola? Czy działa na telefonie? Jeśli kontakt z człowiekiem jest częścią rozwiązania, użytkownik powinien wiedzieć, kiedy i jak otrzyma odpowiedź. Pomoc nie powinna być wyłącznie automatycznym powtarzaniem komunikatu błędu. W badaniu warto obserwować momenty wahania: właśnie one często wskazują miejsca, gdzie krótkie objaśnienie przyniesie większą korzyść niż rozbudowana instrukcja ogólna.

Kryterium 3.3.6 — Zapobieganie błędom przy każdym przesłaniu informacji. Poziom AAA

Ochrona przez odwracalność, sprawdzenie albo potwierdzenie obejmuje tutaj wszystkie strony wymagające przesłania informacji przez użytkownika, a nie tylko wskazane w 3.3.4 sytuacje o poważniejszych skutkach. Objaśnienie W3C: 3.3.6.

Osoba pisze wiadomość do organizatora wydarzenia i przypadkowo naciska przycisk wysłania, zanim dopisze ważny szczegół. Możliwość sprawdzenia wiadomości albo jej cofnięcia w odpowiednio zaprojektowanym procesie ogranicza skutek pomyłki. Nie każda wiadomość tworzy zobowiązanie prawne, ale nadal może zawierać informacje, których użytkownik nie chciał jeszcze przekazać.

W ankiecie uczestnik zaznacza niewłaściwą odpowiedź. Ekran podsumowania pozwala wrócić i poprawić wybór. Trzeba jednak zachować sens zadania: w określonych testach zasady zmiany odpowiedzi mogą być częścią procedury. Projektant powinien jasno określić przyjęty mechanizm i sprawdzić zgodność z właściwym zakresem. Nie wystarczy umieścić komunikatu „Dane zostały wysłane”, gdy nie ma już żadnej możliwości kontroli.

Przejdź wszystkie formularze, także krótkie zgłoszenia, ustawienia i komentarze. Czy istnieje odpowiednia ochrona? Czy możliwość cofnięcia jest dostępna wystarczająco jasno, aby użytkownik ją zauważył? Bardzo krótki komunikat znikający po sekundzie może być praktycznie bezużyteczny. Warto unikać nadmiaru pustych potwierdzeń. Najlepsze rozwiązanie pokazuje konkretną treść i skutek, a użytkownik może świadomie zakończyć czynność. Ochrona przed błędem powinna współpracować z prostym językiem, logiczną kolejnością oraz odpowiednim czasem na podjęcie decyzji.

Kryterium 3.3.7 — Bez ponownego wpisywania tych samych danych. Poziom A

Informacje wcześniej wpisane lub przekazane użytkownikowi, wymagane ponownie w tym samym procesie, powinny być automatycznie uzupełnione albo dostępne do wyboru. Wyjątki dotyczą między innymi istotnej potrzeby ponownego wpisania, bezpieczeństwa i nieaktualności danych. Objaśnienie W3C: 3.3.7.

Klient podaje adres dostawy, a na kolejnym ekranie musi wpisać identyczny adres do faktury. Dla osoby z ograniczeniami ruchowymi oznacza to podwójną pracę. Opcja „Użyj adresu dostawy” pozwala wybrać wcześniej podane dane. Użytkownik nadal powinien móc wskazać inny adres, jeśli rzeczywiście go potrzebuje. Automatyzacja ma ograniczać wysiłek, a nie narzucać błędne założenie.

W formularzu urzędowym system pokazuje numer sprawy, a następnie prosi o jego przepisanie do kolejnego pola. Osoba z trudnościami pamięciowymi przełącza się między ekranami i myli cyfry. Jeśli numer można przekazać bezpośrednio, nie należy obciążać użytkownika rolą pośrednika między częściami tego samego systemu. Dotyczy to również danych przekazanych przez usługę, nie tylko wpisanych ręcznie.

Sprawdź cały proces i zaznacz powtarzające się informacje. Czy są dostępne do wyboru? Czy powrót do poprzedniego kroku nie usuwa danych? Nie należy rozciągać kryterium na dowolne informacje wpisane wiele miesięcy wcześniej w zupełnie innej sprawie. Ważny jest zakres tego samego procesu i przewidziane wyjątki. Warto jednak szerzej ograniczać zbędne przepisywanie, ponieważ zmniejsza liczbę błędów. Użytkownik powinien poświęcać uwagę decyzjom, a nie wielokrotnemu odtwarzaniu tych samych ciągów znaków.

Kryterium 3.3.8 — Dostępne uwierzytelnianie, minimum. Poziom AA

Na etapach uwierzytelniania nie należy wymagać testu funkcji poznawczych, chyba że istnieje odpowiednia alternatywa, mechanizm pomocy albo zastosowanie ma wyjątek dotyczący rozpoznawania obiektów lub osobistych treści nietekstowych. Zapamiętywanie i przepisywanie mogą stanowić taki test. Objaśnienie W3C: 3.3.8.

Osoba korzysta z menedżera haseł, ale formularz blokuje wklejanie. Musi przepisać długi ciąg znaków, co przy trudnościach pamięciowych lub ruchowych staje się barierą. Umożliwienie wklejenia i współpracy z menedżerem pomaga wykonać zadanie bez osłabiania hasła. Kryterium nie zakazuje haseł jako takich; ważne są dostępne sposoby przejścia procesu.

Drugi przykład dotyczy kodu jednorazowego. Użytkownik przechodzi do wiadomości, zapamiętuje cyfry i wraca, ale myli kolejność. Możliwość wklejenia całego kodu lub odpowiednie automatyczne uzupełnienie może pomóc. Formularz podzielony na kilka pól powinien prawidłowo obsłużyć takie działanie. Nie należy wymagać ręcznego przenoszenia każdej cyfry, jeśli technicznie można przyjąć cały ciąg.

Sprawdź logowanie, odzyskiwanie dostępu i dodatkowe potwierdzenia. Czy każda wymagana ścieżka zawiera dostępny sposób przejścia? Czy alternatywa nie prowadzi do kolejnego równie trudnego testu? Nie można z faktu dopuszczenia określonego wyjątku wywnioskować, że każda CAPTCHA jest dostępna. Nadal obowiązują inne kryteria i potrzeby użytkowników. Projekt powinien zapewniać bezpieczeństwo oraz samodzielność, a nie zmuszać osoby z niepełnosprawnościami do przekazywania hasła komuś, kto rozwiąże zadanie za nie.

Kryterium 3.3.9 — Dostępne uwierzytelnianie, wariant rozszerzony. Poziom AAA

Wariant rozszerzony nie przewiduje wyjątków opartych na rozpoznawaniu obiektów lub osobistych treściach nietekstowych. Test funkcji poznawczych wymaga odpowiedniej alternatywy albo mechanizmu pomocy. Objaśnienie W3C: 3.3.9.

Portal prosi o wskazanie zdjęć określonego przedmiotu. Dla osoby niewidomej lub mającej trudność z rozpoznawaniem obrazów może to być przeszkoda. Na poziomie rozszerzonym nie wystarczy powołać się na kategorię rozpoznawania obiektów. Trzeba zaprojektować inną drogę lub odpowiedni mechanizm zgodny z kryterium. Użytkownik nie powinien udowadniać sprawności wzrokowej, aby uzyskać dostęp do własnego konta.

W innym scenariuszu system pyta o wybrane wcześniej zdjęcie. Użytkownik nie pamięta wyboru lub korzysta z urządzenia, na którym trudno ocenić miniatury. Dostępne uwierzytelnianie powinno opierać się na metodach, które rzeczywiście może zastosować. Konkretne rozwiązanie trzeba ocenić razem z bezpieczeństwem, prywatnością i obsługą technologii asystujących. Nie ma jednej metody idealnej dla wszystkich osób i wszystkich sytuacji.

Przetestuj proces od początku do końca, w tym sytuację utraty zwykłego sposobu logowania. Czy droga odzyskania dostępu jest równie dostępna jak codzienne wejście? Czy użytkownik może skorzystać z pomocy bez ujawniania tajnych danych osobie trzeciej? Warto unikać deklarowania pełnej dostępności na podstawie jednego poprawnego pola hasła. Proces obejmuje także wybór metody, komunikaty, kody, błędy i powrót do zadania. Każdy z tych etapów może stać się miejscem wykluczenia, jeśli zostanie oceniony osobno od pozostałych.

Solidność: Współpraca z technologiami asystującymi

Ta zasada przypomina, że strona ma nie tylko wyglądać i reagować, ale także przekazywać programom właściwe informacje. Czytnik ekranu potrzebuje wiedzieć, czy element jest przyciskiem, jak się nazywa i jaki ma stan. Użytkownik powinien otrzymywać wiadomości o wynikach działania bez konieczności przeszukiwania całej strony po każdym kliknięciu. Poprawna warstwa techniczna pozwala różnym sposobom obsługi korzystać z tej samej usługi.

Kryterium 4.1.1 — Dlaczego ten numer jest historyczny

Kryterium dotyczące poprawności składni zostało uznane za przestarzałe i usunięte z WCAG 2.2. Nie należy wpisywać go jako obowiązującego kryterium tej wersji. W3C wyjaśnia zmianę również w dokumentacji dotyczącej starszych wersji. Usunięcie nie oznacza jednak, że błędy kodu przestały mieć znaczenie dla dostępności. Objaśnienie W3C: historyczne 4.1.1.

Jeżeli błąd struktury sprawia, że pole traci etykietę, problem nadal należy ocenić według właściwego kryterium, na przykład dotyczącego informacji, relacji lub nazwy kontrolki. W raporcie trzeba opisać rzeczywisty skutek. Nie warto zgłaszać każdego ostrzeżenia walidatora jako automatycznego naruszenia dostępności bez analizy. Z drugiej strony brak tego kryterium nie usprawiedliwia ignorowania usterek, które uniemożliwiają obsługę.

Przykład: dwa różne pola odwołują się do niewłaściwych etykiet, ponieważ autor pomylił identyfikatory. Użytkownik słyszy „Nazwisko” przy polu adresu. Istotą problemu jest błędne przekazanie znaczenia, a nie samo wystąpienie technicznego ostrzeżenia. Naprawa powinna przywrócić właściwe powiązanie i zostać sprawdzona w rzeczywistym formularzu.

Przy analizie starszej umowy lub normy trzeba ustalić, do jakiej wersji dokumentu się odwołuje. Nie należy automatycznie przenosić zmiany w standardzie na każdy obowiązek prawny. Ten przewodnik opisuje WCAG 2.2 i zachowuje numer historyczny po to, aby czytelnik rozumiał, dlaczego pojawia się on w dawnych raportach, a nie w aktualnym zestawie 86 kryteriów tej wersji.

Kryterium 4.1.2 — Nazwa, rola i wartość. Poziom A

Elementy interfejsu powinny udostępniać programowo nazwę i rolę, a ustawiane przez użytkownika stany, właściwości i wartości powinny być odpowiednio dostępne oraz aktualizowane. Dotyczy to również elementów zbudowanych samodzielnie przez autora. Objaśnienie W3C: 4.1.2.

Na stronie znajduje się przełącznik powiadomień. Osoba widząca rozpoznaje jego położenie, ale czytnik mówi tylko „Element”. Użytkownik nie wie, czy może go nacisnąć ani czy powiadomienia są włączone. Poprawna kontrolka przekazuje nazwę, typ i stan. Po zmianie stan powinien być aktualny. Nie wystarczy poprawnie opisać go tylko podczas pierwszego wczytania strony.

W innym przykładzie sekcja z dodatkowymi informacjami rozwija się po naciśnięciu. Przycisk powinien informować, czy sekcja jest rozwinięta. Jeżeli program stale słyszy „Zwinięte”, mimo że treść jest już pokazana, użytkownik może wielokrotnie naciskać i nie rozumieć rezultatu. Warto korzystać z odpowiednich standardowych elementów, a niestandardowe komponenty projektować zgodnie z ich rzeczywistym zachowaniem.

Sprawdź kontrolki w narzędziu pokazującym strukturę dostępności i podczas obsługi czytnikiem. Czy nazwa odpowiada celowi? Czy rola jest właściwa? Czy zmiana wartości jest przekazywana? Dodanie atrybutu ARIA nie naprawia automatycznie całego działania. Element nazwany przyciskiem musi także działać jak przycisk. Należy łączyć semantykę, klawiaturę, widoczność fokusu i reakcję na działanie. Użytkownik potrzebuje spójnego zestawu informacji, a nie samej etykiety dopisanej do nieobsługiwanej grafiki.

Kryterium 4.1.3 — Komunikaty o stanie. Poziom AA

Komunikaty o stanie powinny być możliwe do określenia programowo tak, aby technologie asystujące mogły je przedstawić bez konieczności przenoszenia fokusu. Dotyczy to określonych informacji o rezultacie działania, postępie lub stanie aplikacji. Objaśnienie W3C: 4.1.3.

Klient dodaje produkt do koszyka. W rogu pojawia się napis „Dodano”, ale czytnik niczego nie ogłasza. Użytkownik nie wie, czy polecenie zadziałało, więc naciska ponownie. W koszyku lądują dwie sztuki. Prawidłowy komunikat pozwala poznać rezultat bez przeszukiwania całej strony. Nie musi przy tym przenosić użytkownika do koszyka i przerywać dalszych zakupów.

W wyszukiwarce po zmianie filtrów pojawia się liczba wyników. Osoba niewidoma powinna móc dowiedzieć się, że lista została zaktualizowana. Jednocześnie nie należy ogłaszać agresywnie każdej drobnej zmiany i przerywać odczytu co ułamek sekundy. Dobór sposobu i momentu komunikacji ma znaczenie. Zbyt wiele automatycznych wypowiedzi może być równie dezorientujące jak całkowita cisza.

Sprawdź dodawanie do koszyka, zapis szkicu, ładowanie danych i wyniki wyszukiwania. Czy użytkownik otrzymuje informację bez utraty miejsca? Czy komunikat jest krótki i jednoznaczny? Nie każda zmiana strony jest komunikatem o stanie w rozumieniu tego kryterium, dlatego trzeba ocenić kontekst. W praktyce warto projektować komunikację wyniku razem z samą funkcją. Pytanie „Skąd użytkownik będzie wiedział, że się udało?” powinno paść przed wdrożeniem, a nie dopiero po zgłoszeniu powtarzających się zamówień.

Przykłady całych procesów: Jak kryteria działają razem

Poniższe scenariusze są autorskimi przykładami edukacyjnymi. Nie opisują wyników badań konkretnego portalu. Ich celem jest pokazanie, że jedno zadanie może wymagać jednoczesnego spełnienia wielu kryteriów. Wskazane usprawnienia obejmują zarówno wymagania WCAG, jak i dodatkowe dobre praktyki. Nie każda pojedyncza propozycja jest samodzielnym obowiązkiem wynikającym ze standardu. Najważniejsze pytanie brzmi: czy osoba może samodzielnie i świadomie zakończyć sprawę?

Przykład pierwszy — Umówienie wizyty bez używania myszy

Marta ma ograniczoną sprawność dłoni. Korzysta z klawiatury, ponieważ precyzyjne prowadzenie myszy jest dla niej bolesne. Chce umówić wizytę w poradni. Na stronie głównej bez problemu odnajduje przycisk rejestracji, lecz po jego uruchomieniu pojawia się kalendarz. Tab przechodzi pomiędzy miesiącami i przyciskiem zamknięcia. Żaden dzień nie otrzymuje fokusu. Marta wie, jaki termin chce wybrać, ale nie ma sposobu przekazania decyzji.

Pierwsza poprawka polega na zapewnieniu pełnej obsługi kalendarza klawiaturą. Można także udostępnić listę wolnych terminów. Lista powinna zawierać datę, godzinę i inne informacje potrzebne do wyboru. Sama alternatywa „Zadzwoń do rejestracji” nie zapewnia tej samej samodzielności, jeśli użytkownik chciał skorzystać z usługi internetowej wieczorem. Telefon może być dodatkowym wsparciem, lecz nie naprawia mechanizmu wyboru na stronie.

Po naprawie kalendarza ujawnia się następny problem. Marta wybiera termin, a fokus wraca na sam początek portalu. Musi przejść przez całe menu, aby znaleźć przycisk potwierdzenia. Zespół powinien poprawić kolejność i przeniesienie fokusu. Gdy wybór się powiedzie, komunikat powinien wskazywać wybraną datę. Użytkownik nie powinien zgadywać, czy kliknięcie zostało przyjęte.

Na końcu potrzebne jest czytelne podsumowanie: miejsce, termin i sposób ewentualnej zmiany rezerwacji. Potwierdzenie może być dostępne tekstowo na stronie oraz w wiadomości. W scenariuszu współdziałają kryteria klawiatury, kolejności fokusu, nazw kontrolek i komunikatów o stanie. Warto też zadbać o odpowiedni czas i brak zbędnego ponownego wpisywania danych. Test kończy się dopiero wtedy, gdy Marta potrafi nie tylko wybrać termin, ale także rozpoznać potwierdzenie i później odnaleźć informację o wizycie.

Przykład drugi — Zakupy z czytnikiem ekranu

Tomasz jest niewidomy i samodzielnie robi zakupy internetowe. Wyszukuje czajnik, przechodzi do opisu i poznaje cenę. Zdjęcie ma opis „Produkt”, więc nie dowiaduje się o układzie przycisków ani oznaczeniach, które mogą być ważne dla jego wyboru. Nie każda cecha wizualna musi znaleźć się w krótkim opisie, ale informacje istotne dla decyzji powinny być dostępne w tekście produktu.

Po dodaniu do koszyka strona nie ogłasza wyniku. Tomasz naciska ponownie. Dopiero w koszyku zauważa dwie sztuki. Poprawa komunikatu o stanie ogranicza ryzyko takiej pomyłki. Następnie użytkownik chce zmniejszyć liczbę produktów. Przyciski są opisane tylko jako „Przycisk”. Potrzebne są nazwy wyjaśniające działanie i powiązanie z konkretnym produktem. W koszyku zawierającym kilka pozycji samo „Usuń” może być zbyt mało pomocne bez odpowiedniego kontekstu.

W kolejnym kroku sklep prosi o adres. Dane podane przy zakładaniu zamówienia trzeba wpisać ponownie do faktury. Możliwość użycia tego samego adresu ogranicza wysiłek. Przy wyborze dostawy ważne jest pełne opisanie opcji, ceny i ewentualnych ograniczeń. Nazwa „Standard” bez dalszych informacji nie pozwala ocenić, co użytkownik otrzyma.

Przed końcowym potwierdzeniem Tomasz powinien mieć dostęp do zestawienia produktów, ilości, kosztów i danych. Przyciski poprawy muszą prowadzić do odpowiednich miejsc, zachowując pozostałe informacje. Jeżeli płatność odbywa się w zewnętrznym module, ocena procesu nie kończy się na przekierowaniu. Trzeba sprawdzić powrót i potwierdzenie rezultatu. Dostępność sklepu nie jest sumą ładnych kart produktów. Jest możliwością wykonania całego zakupu, z kontrolą kosztu i bez konieczności udostępniania konta osobie pomagającej.

Przykład trzeci — Reklamacja bez rozmowy telefonicznej

Anna jest głucha. Otrzymała uszkodzony przedmiot i chce opisać problem. Formularz reklamacji jest czytelny, ale ostatni krok wymaga telefonicznego potwierdzenia. Na stronie nie wskazano innej drogi. Ten przykład pokazuje granicę patrzenia wyłącznie na pojedynczy ekran. Nawet dobrze opisane pola nie zapewniają dostępnego procesu, jeśli organizacja narzuca później kanał, z którego użytkownik nie może skorzystać.

W projektowaniu obsługi warto zapewnić odpowiedni kontakt tekstowy i jasno wyjaśnić kolejne etapy. To szersza dobra praktyka organizacyjna, której nie należy sprowadzać do jednego numeru WCAG. Sam formularz powinien mieć etykiety, instrukcje dodawania plików i zrozumiałe błędy. Jeśli zdjęcie przekracza limit, system powinien podać przyczynę i możliwy sposób dalszego działania. Nie może usuwać całego opisu reklamacji.

Anna wysyła zgłoszenie. Potrzebuje potwierdzenia, które zawiera numer sprawy i informację, gdzie otrzyma odpowiedź. Komunikat „Skontaktujemy się” jest zbyt ogólny, jeśli nie wiadomo, jakim kanałem. W naszym scenariuszu formularz pozwala wybrać wiadomość tekstową i zachowuje tę preferencję. Pracownik obsługi widzi ją podczas dalszego prowadzenia sprawy. W przeciwnym razie dostępny formularz zostanie osłabiony przez niedostosowaną praktykę zespołu.

Przy testowaniu należy przejść również odpowiedź i ewentualne uzupełnienie danych. Czy wiadomość zawiera dostępny link? Czy załącznik da się odczytać? Czy nie wymaga odsłuchania instrukcji bez transkrypcji? Anna powinna móc poznać decyzję, zadać pytanie i zakończyć sprawę tym samym dostępnym sposobem. Taki scenariusz łączy wymagania dotyczące formularzy z oceną całej obsługi. Pokazuje też, że deklaracja „mamy formularz internetowy” nie mówi jeszcze, czy organizacja faktycznie umożliwia komunikację bez głosu.

Przykład czwarty — Wniosek wypełniany etapami

Piotr korzysta z komputera krótko, ponieważ szybko się męczy. Wniosek wymaga kilkunastu odpowiedzi oraz danych z dokumentów. Nie może przygotować wszystkiego podczas jednej nieprzerwanej sesji. Na początku potrzebuje informacji, jakie materiały będą wymagane i czy można zapisać szkic. Pozwala to zaplanować pracę bez niepewności, czy przerwa oznacza utratę danych.

Pierwsza wersja formularza kończy sesję po kilku minutach bez wpisywania. Piotr w tym czasie czyta instrukcję. Po powrocie wszystkie pola są puste. Zespół powinien przeanalizować kontrolę czasu, ostrzeganie i bezpieczne zachowanie pracy. Są to powiązane, ale odrębne kwestie. Samo wydłużenie limitu nie rozwiązuje sytuacji, jeśli użytkownik nadal nie wie, ile ma czasu i co stanie się z danymi.

W poprawionej wersji szkic jest zapisany w sposób odpowiedni do charakteru informacji. Po ponownym zalogowaniu Piotr widzi, które części są ukończone. Nagłówki etapów mają konkretne nazwy. Nie musi pamiętać, co oznacza „Sekcja B”. Może wrócić do danych kontaktowych lub załączników. Jeśli wcześniej podał adres, system udostępnia go do ponownego użycia tam, gdzie jest potrzebny w tym samym procesie.

Przed wysłaniem formularz pokazuje podsumowanie. Piotr może poprawić jedną odpowiedź bez powtarzania wszystkich kroków. Nazwa końcowego przycisku wyjaśnia, że następuje wysłanie, a nie kolejny zapis szkicu. Po zakończeniu otrzymuje jasne potwierdzenie. Test takiego procesu powinien obejmować przerwę, wygaśnięcie sesji i powrót, ponieważ właśnie te sytuacje są naturalną częścią sposobu pracy użytkownika. Sprawdzenie wyłącznie szybkiego przejścia przez formularz przez sprawnego testera nie ujawni najważniejszej bariery.

Przykład piąty — Regulamin czytany w dużym powiększeniu

Elżbieta czyta tekst przy znacznym powiększeniu. Otwiera regulamin usługi i zwiększa skalę. Akapity zawijają się poprawnie, lecz przyklejony nagłówek zajmuje połowę ekranu. Na dole pozostaje pasek zgód. Między nimi widać tylko dwa wiersze. Formalnie część tekstu nadal jest obecna, ale praktyczna lektura staje się bardzo męcząca. Projekt powinien uwzględniać ilość przestrzeni pozostawionej na treść.

Pierwsza poprawka polega na ograniczeniu stałych elementów oraz umożliwieniu ich obsługi. Druga dotyczy szerokości akapitów i braku przewijania w dwóch kierunkach. Elżbieta nie powinna przesuwać strony w prawo po każdym wierszu, a potem wracać do początku następnego. Tabele wymagają osobnej oceny, lecz zwykły tekst powinien dopasować się do dostępnej szerokości.

Czytelniczka zwiększa także odstępy między wierszami. W jednym miejscu ważne zastrzeżenie zostaje ucięte przez blok o stałej wysokości. To pokazuje, dlaczego test powiększenia nie zastępuje testu odstępów. Różne dostosowania mogą ujawnić różne usterki. W poprawionej wersji blok rośnie wraz z treścią, a przyciski przesuwają się niżej bez nakładania.

Na końcu regulaminu znajdują się linki do kilku załączników. Ich nazwy powinny wyjaśniać zawartość, aby Elżbieta nie otwierała wszystkich po kolei. Nagłówki i spis treści pozwalają wrócić do konkretnego zagadnienia. Dodatkowa prosta informacja o najważniejszych zasadach może pomóc, ale nie powinna pomijać istotnych warunków ani udawać pełnego dokumentu. W tym scenariuszu współdziałają kontrast, powiększenie, dopasowanie, odstępy, struktura oraz cel linków. Poprawa jednego parametru nie zastępuje oceny całego doświadczenia czytania.

Przykład szósty — Kurs z filmami i ćwiczeniami

Karol korzysta z kursu internetowego. Słabo słyszy i potrzebuje napisów. Pierwszy film ma napisy, lecz kolejny już nie, ponieważ przygotował go inny wykładowca. Użytkownik nie może ukończyć całego modułu. Organizacja powinna ustalić wspólny standard publikacji, zamiast pozostawiać dostępność każdemu autorowi jako indywidualny wybór. Dotyczy to również materiałów dodatkowych i nagrań aktualizowanych po rozpoczęciu kursu.

W ćwiczeniu prowadzący mówi „Zobacz, co zmieniło się tutaj”, pokazując fragment programu. Napisy wiernie zapisują te słowa, ale nie wyjaśniają obrazu. Dla osoby niewidomej potrzebne jest przekazanie istotnej informacji wizualnej. Warto już w scenariuszu nazwać zmianę: który przycisk się pojawił, jaki komunikat wyświetlono i co należy zrobić. Dobra narracja może ograniczyć konieczność późniejszego dodawania osobnego opisu.

Po filmie kurs uruchamia test z krótkim licznikiem. Jeśli celem ćwiczenia jest utrwalenie wiedzy, zespół powinien rozważyć, czy presja czasu ma uzasadnienie. Karol może potrzebować wrócić do fragmentu napisów. Inny uczestnik będzie czytał pytania wolniej albo obsługiwał odpowiedzi alternatywnym urządzeniem. Równość dostępu nie polega na założeniu identycznego tempa pracy.

Na końcu pojawia się animacja gratulacyjna i automatycznie zaczyna następna lekcja. Warto umożliwić kontrolę ruchu oraz przejścia. Uczestnik może chcieć zrobić notatkę lub przerwę. Test dostępności kursu powinien objąć odtwarzacz, napisy, treść obrazu, ćwiczenia, błędy i zapis postępu. Samo stwierdzenie, że platforma ma funkcję napisów, nie mówi, czy wszystkie opublikowane materiały rzeczywiście z niej korzystają i czy uczestnik potrafi ją uruchomić.

Przykład siódmy — Mapa dostępna więcej niż jednym sposobem

Zofia planuje dojazd do instytucji. Na stronie znajduje się mapa z oznaczonym wejściem, lecz brak adresu tekstowego. Osoba niewidoma nie otrzymuje informacji potrzebnej do podróży. Pierwszym krokiem jest udostępnienie adresu, opisu wejścia i innych istotnych wskazówek jako tekstu. Mapa może nadal być użyteczna dla wielu odbiorców, ale nie powinna być jedynym nośnikiem podstawowej informacji.

Drugi użytkownik widzi mapę, lecz nie może wykonać gestu dwoma palcami. Potrzebuje przycisków zmiany skali. Trzeci korzysta z klawiatury i musi móc opuścić obszar mapy. Czwarty powiększa stronę i potrzebuje czytelnej instrukcji poza samym widokiem przestrzennym. Każda z tych sytuacji dotyczy innej bariery. Dodanie jednego opisu alternatywnego nie rozwiązuje obsługi interaktywnej mapy.

W naszym przykładzie instytucja podaje: nazwę ulicy, numer budynku, położenie wejścia i sposób kontaktu w razie problemu. Informacje powinny być sprawdzone i aktualizowane. Nie należy wpisywać, że wejście jest dostępne, wyłącznie na podstawie zdjęcia. Można opisać konkretne cechy, które organizacja zna, oraz wyjaśnić zakres informacji. Użytkownik sam oceni, czy odpowiadają jego potrzebom.

Przy testowaniu mapy trzeba rozróżnić elementy, które rzeczywiście wymagają układu dwuwymiarowego, od otaczającej treści. Opis, przyciski i dane kontaktowe powinny pozostać czytelne po powiększeniu. Lista lokalizacji może stanowić dodatkową drogę wyboru punktu. Dobrą praktyką jest sprawdzenie zadania od pytania „Dokąd mam dotrzeć?” do uzyskania konkretnych danych. Dostępność mapy nie polega na samym ogłoszeniu przez czytnik, że na stronie znajduje się mapa.

Przykład ósmy — Czat, który daje czas na odpowiedź

Michał korzysta z komunikatora generującego mowę i wolno wpisuje tekst. Chce porozmawiać z obsługą przez czat. System zamyka rozmowę po krótkiej bezczynności, mimo że użytkownik właśnie układa odpowiedź. Konsultant interpretuje brak szybkiej wiadomości jako odejście. Projekt powinien uwzględnić różne tempo komunikacji oraz jasno informować o limitach i możliwościach kontynuacji.

Interfejs czatu potrzebuje odpowiedniej obsługi klawiaturą i komunikatów o nowych wiadomościach. Nie powinien jednak przerywać odczytu całej strony każdą informacją „Konsultant pisze”. Użytkownik musi móc przeczytać wcześniejsze wiadomości i wrócić do pola odpowiedzi. Automatyczne przewijanie, które ciągle odbiera miejsce, utrudnia spokojne zapoznanie się z historią.

W naszym scenariuszu czat pozwala poprosić o dodatkowy czas prostym przyciskiem. Konsultant otrzymuje informację, że użytkownik nadal pracuje nad odpowiedzią. To przykład dobrej praktyki obsługi, a nie jeden uniwersalny wymóg techniczny. Ważne jest także zachowanie rozmowy po przejściu do innej części portalu, jeśli proces wymaga sprawdzenia danych. Użytkownik nie powinien tracić całego kontekstu przy każdej zmianie strony.

Przed zakończeniem rozmowy warto przedstawić krótkie podsumowanie ustaleń i umożliwić dostęp do historii w czytelnej postaci. Jeśli wysyłany jest plik, powinien być dostępny. Nie należy uznawać, że tekstowy kanał automatycznie zapewnia dostępność każdej osobie. Znaczenie mają tempo, struktura, sposób ogłaszania zmian i zrozumiałość odpowiedzi. Test powinien obejmować dłuższe przerwy między wiadomościami oraz obsługę bez myszy, a nie tylko szybką wymianę dwóch zdań między pracownikami zespołu.

Przykład dziewiąty — Panel zgód bez pułapek

Użytkownik otwiera stronę i najpierw widzi duży panel ustawień prywatności. Zanim dotrze do właściwej treści, musi zdecydować o dostępnych opcjach. Panel ma drobne przełączniki, słaby kontrast i przycisk zamknięcia bez nazwy. Dla osoby korzystającej z czytnika lub klawiatury staje się bramą blokującą cały serwis. Nie można oceniać dostępności strony z pominięciem tego pierwszego ekranu.

Kontrolki powinny mieć nazwy i stany. Jeśli użytkownik wyłącza opcję, technologia asystująca powinna otrzymać aktualną informację. Kolejność przechodzenia klawiaturą musi być logiczna, a zamknięcie dostępne. Po dokonaniu wyboru fokus powinien znaleźć się w sensownym miejscu. Osoba nie powinna zostać na niewidocznym elemencie usuniętego panelu.

Przy dużym powiększeniu panel nie może zasłonić przycisków, do których nie da się przewinąć. Tekst powinien się zawijać, a odstępy pozostać czytelne. Małe cele położone blisko siebie zwiększają ryzyko wyboru innej opcji niż zamierzona. Warto projektować je z zapasem przestrzeni. Nazwy powinny wyjaśniać funkcję, zamiast opierać się na branżowych skrótach niezrozumiałych dla odbiorcy.

Ten scenariusz nie rozstrzyga prawnej oceny zgód ani tego, które przetwarzanie danych wymaga określonej podstawy. Pokazuje techniczną i komunikacyjną stronę dostępności decyzji. Użytkownik powinien rozumieć dostępne możliwości i móc je świadomie wybrać. W testach trzeba otworzyć stronę w stanie, w którym panel rzeczywiście się pojawia. Osoba stale korzystająca z tego samego profilu przeglądarki może go już nie widzieć i przez to przeoczyć barierę dotyczącą nowych odwiedzających.

Przykład dziesiąty — Dokument dostępny również po pobraniu

Użytkownik znajduje na stronie instrukcję z prawidłowymi nagłówkami i czytelnym tekstem. Następnie pobiera formularz, który okazuje się skanem. Nie może odczytać pól ani wpisać danych w dostępny sposób. Ten przykład pokazuje, dlaczego dostępność treści strony nie kończy się na granicy pliku. Materiał do pobrania jest częścią zadania, jeśli bez niego nie można załatwić sprawy.

W praktyce warto przygotować formularz w odpowiednio dostępnej postaci i rozważyć wersję internetową. Dokument powinien mieć logiczną strukturę, prawidłową kolejność odczytu, etykiety pól i instrukcje. Samo rozpoznanie tekstu przez OCR nie gwarantuje poprawnych relacji w tabelach ani dostępności interaktywnych elementów. Użytkownik może otrzymać słowa, ale nadal nie wiedzieć, do którego pola należą.

Osoba słabowidząca potrzebuje także możliwości wygodnego powiększenia. Dokument o sztywnym układzie może wymagać szczególnego opracowania lub alternatywnej prezentacji. Nie należy uznawać, że format pliku sam w sobie przesądza o dostępności. Znaczenie ma sposób przygotowania i rzeczywiste zachowanie w odpowiednich narzędziach. Wymagania dotyczące dokumentów i oprogramowania mogą wymagać dodatkowych źródeł poza samym przewodnikiem po treści internetowej.

Test powinien obejmować otwarcie, odczytanie, wypełnienie, zapisanie i przekazanie dokumentu. Czy po zapisie dane nadal są obecne? Czy nazwy pól są zrozumiałe? Czy użytkownik może sprawdzić wynik przed wysłaniem? Link do pliku powinien jasno opisywać jego zawartość. Jeśli istnieje alternatywna wersja, musi być łatwa do odnalezienia i aktualna. Nie pomaga dostępny formularz z poprzedniego roku, gdy aktualna procedura wymaga innego zestawu informacji.

Przykład jedenasty — Wyszukiwanie informacji bez znajomości urzędowych nazw

Alicja chce zmienić dane kontaktowe w instytucji. Nie zna nazwy komórki organizacyjnej ani formalnego określenia procedury. Wpisuje w wyszukiwarkę „nowy adres”, ale otrzymuje brak wyników. W menu informacje znajdują się pod hasłem zrozumiałym wyłącznie dla pracowników. Technicznie pole wyszukiwania działa, lecz droga do usługi pozostaje trudna. To przykład potrzeby połączenia wymagań dotyczących nawigacji z badaniem języka odbiorców.

Zespół może dodać zrozumiałe nazwy stron, używać słów, którymi posługują się użytkownicy, i zapewnić alternatywną drogę przez uporządkowany spis usług. Wyniki powinny mieć konkretne tytuły oraz krótkie opisy. Dziesięć pozycji nazwanych „Informacja” nie pomaga wybrać właściwej. Osoba korzystająca z czytnika potrzebuje również logicznych nagłówków i rozpoznawalnej listy wyników.

Po zmianie filtra liczba rezultatów powinna być przekazana w dostępny sposób. Nie należy automatycznie przenosić użytkownika na pierwszy wynik, jeśli chciał tylko ograniczyć listę. W przypadku braku rezultatów warto podać możliwe następne kroki: inne słowo, przejście do listy usług albo kontakt. Komunikat nie powinien sugerować, że to użytkownik popełnił błąd, skoro system może po prostu nie rozpoznawać jego sformułowania.

Test można przeprowadzić z osobami, które nie znają struktury organizacji. Poproś o znalezienie konkretnej informacji, nie podając nazwy działu. Obserwuj używane słowa i miejsca wahania. Warto sprawdzić także zachowanie po wpisaniu literówki. Nie każda funkcja wyszukiwarki wynika bezpośrednio z pojedynczego kryterium WCAG, ale razem decydują o możliwości odnalezienia treści. Dostępny przycisk „Szukaj” jest konieczny, lecz sam nie gwarantuje skutecznego wyszukiwania.

Przykład dwunasty — Logowanie bez przepisywania długich ciągów

Robert ma trudności z pamięcią roboczą. Korzysta z menedżera haseł i potrafi samodzielnie obsługiwać konto. Nowy portal blokuje jednak wklejanie hasła i wymaga przepisania kodu z wiadomości do sześciu osobnych pól. Robert wraca wielokrotnie do wiadomości, myli cyfry i przekracza czas. Nie jest to dowód, że nie powinien korzystać z konta. To sygnał, że proces narzuca niepotrzebne obciążenie.

Poprawiony formularz współpracuje z menedżerem haseł i przyjmuje wklejenie całego kodu. Etykiety wyjaśniają, co należy wpisać. Komunikaty nie ujawniają zbędnych informacji o kontach, ale wskazują dostępną drogę dalszego działania. Jeśli kod wygasł, użytkownik wie, jak uzyskać nowy i czy wcześniej wpisane dane zostały zachowane. Nie powinien domyślać się, czy błąd wynika z formatu, czasu czy innej przyczyny.

Warto też sprawdzić odzyskiwanie dostępu. Często codzienne logowanie jest proste, lecz procedura awaryjna wymaga rozwiązania niedostępnego zadania obrazkowego lub rozmowy głosowej. Dostępność musi obejmować sytuację, w której użytkownik stracił zwykłą metodę. Alternatywa powinna być realnie możliwa do wykorzystania, z zachowaniem odpowiedniej ochrony tożsamości i danych.

Testuj cały przebieg na koncie testowym. Sprawdź wklejanie, automatyczne uzupełnianie, czytnik, klawiaturę, błędy i powrót do pierwotnej sprawy. Nie wyłączaj zabezpieczeń tylko po to, aby skrócić proces. Celem jest projektowanie zabezpieczeń, z których różni ludzie mogą korzystać samodzielnie. Robert nie powinien być zmuszony do przekazania hasła członkowi rodziny, ponieważ interfejs nie akceptuje narzędzia, które pozwala mu bezpiecznie zarządzać własnym dostępem.

Przykład trzynasty — Rezerwacja miejsca bez przeciągania

Ewa chce wybrać miejsce na wydarzeniu. Plan sali wymaga przeciągnięcia małego znacznika na krzesło. Korzysta z urządzenia wskazującego, ale nie potrafi długo utrzymać nacisku. Za każdym razem znacznik wraca na początek. Dla niej problemem nie jest rozpoznanie planu, lecz sposób przekazania wyboru. Alternatywa klawiaturowa może pomóc innym osobom, ale Ewa potrzebuje także prostego działania wskaźnikiem.

Można umożliwić wybranie miejsca przez kliknięcie albo udostępnić listę rzędów i numerów. Jeśli rozmieszczenie przestrzenne ma znaczenie, lista powinna przekazywać potrzebne informacje, na przykład położenie względem wejścia. Nie należy ograniczać alternatywy do przypadkowych miejsc, gdy pozostali użytkownicy mają pełny wybór. Ważne jest zachowanie równoważności funkcji, a nie tylko stworzenie jakiejkolwiek ścieżki do zakupu.

Po wyborze system powinien jasno pokazać numer miejsca, cenę i ewentualne warunki. Kolor na planie nie może być jedyną informacją o dostępności. Osoba nierozróżniająca barw powinna wiedzieć, które miejsca są wolne. Użytkownik czytnika potrzebuje nazw i stanów. Jeżeli występuje limit czasu rezerwacji, trzeba ocenić go według właściwych wymagań i wyjaśnić sposób działania.

Praktyczny test obejmuje wybór, zmianę, anulowanie i potwierdzenie. Sprawdź, czy po zmianie miejsca poprzedni wybór rzeczywiście przestaje obowiązywać. Czy komunikat o zajęciu miejsca przez inną osobę jest dostępny i daje możliwość dalszego działania? Czy użytkownik zachowuje pozostałe dane? Ten scenariusz pokazuje, że dostępność planu sali nie kończy się na dodaniu opisów do symboli. Potrzebny jest spójny proces decydowania i poprawiania wyboru.

Przykład czternasty — Powiadomienia, które nie odbierają koncentracji

Kamil pracuje z portalem edukacyjnym i łatwo traci wątek po przerwaniu. Podczas czytania co kilka chwil pojawia się nowe powiadomienie. Jedno informuje o wiadomości, drugie o promocji kursu, trzecie o rankingu. Każde przesuwa treść i wymaga zamknięcia. Kamil po kilku minutach nie pamięta, na czym skończył. Problemem nie jest brak informacji, lecz nadmiar niekontrolowanych przerwań.

Zespół powinien ustalić priorytety. Informacje niezwiązane z bieżącym zadaniem mogą trafić do spokojnego centrum powiadomień. Użytkownik powinien móc je odłożyć lub wyłączyć w odpowiednim zakresie. Komunikaty rzeczywiście pilne wymagają innej oceny, ale nie należy nadawać takiego statusu każdej wiadomości marketingowej. Dobrze zaprojektowany interfejs pomaga odróżnić rezultat własnego działania od informacji napływających z zewnątrz.

Kamil włącza tryb ograniczonego ruchu. Strona powinna respektować go również w powiadomieniach, a nie tylko w dekoracyjnym tle. Zamiast wjeżdżającego panelu można zastosować spokojny komunikat. Jeśli informacja dotyczy zapisu odpowiedzi, powinna być przekazana zrozumiale, ale bez niepotrzebnego przejmowania fokusu. Osoba korzystająca z czytnika nie powinna słyszeć długiego ogłoszenia za każdym razem, gdy system zapisuje pojedynczą literę.

Testuj usługę w warunkach realistycznych, z kilkoma typami komunikatów. Sprawdź, czy ustawienia faktycznie działają i czy użytkownik potrafi później odnaleźć odłożone informacje. Warto zapytać, które powiadomienia są potrzebne podczas pracy, a które mogą poczekać. Nie wszystkie decyzje da się wyprowadzić z samej listy kryteriów. Badanie z odbiorcami pozwala zaprojektować rytm komunikacji, który wspiera zadanie zamiast stale z nim konkurować.

Przykład piętnasty — Tabela opłat, której można zaufać

Danuta porównuje opłaty w tabeli. Korzysta z czytnika ekranu, ale czasem również powiększa widok. Tabela zawiera kilka kolumn, scalone komórki i skróty. Podczas odczytu słyszy kolejne kwoty bez nazw usług. Nie może ustalić, która cena dotyczy jej sprawy. Pierwsza poprawka dotyczy struktury i powiązania danych z nagłówkami. Wygląd tabeli nie powinien być jedynym źródłem relacji.

Zespół upraszcza układ. Każdy wiersz opisuje jedną usługę, a nagłówki wyjaśniają rodzaj opłaty. Nietypowe skróty mają objaśnienia. Jeśli kolor oznacza zwolnienie z opłaty, dodano również tekst. Ważne wyjątki są opisane w sposób pozwalający ustalić, do którego wiersza należą. Gwiazdka bez wyjaśnienia może prowadzić do błędnej decyzji, nawet gdy same liczby są odczytywane poprawnie.

Po powiększeniu tabela wymaga przewijania w dwóch kierunkach. Może to wynikać z jej dwuwymiarowego charakteru, lecz nie powinno wymuszać takiego przewijania dla całej strony. Opis i instrukcja powinny się dopasować. Warto rozważyć także prostszą prezentację danych lub możliwość wyboru interesującej usługi, jeśli tabela jest bardzo rozbudowana. To dobra praktyka, którą trzeba ocenić pod kątem zachowania pełnej informacji.

Test polega na zadaniu konkretnego pytania: „Ile zapłacę za tę usługę w tej sytuacji?”. Danuta powinna znaleźć odpowiedź i warunki jej zastosowania. Sam odczyt wszystkich komórek nie dowodzi zrozumiałości. Trzeba sprawdzić relacje, kolejność, skróty i przypisy. Jeżeli informacje są aktualizowane, należy pilnować spójności wersji tekstowej i graficznej. Użytkownik nie powinien otrzymywać innych kwot zależnie od sposobu korzystania z tego samego serwisu.

Przykład szesnasty — Wysyłanie załączników bez utraty opisu

Paweł przygotował długi opis problemu i chce dodać dokument. Formularz przyjmuje plik, ale po chwili pokazuje ogólny błąd i kasuje wszystko. Użytkownik nie wie, czy dokument był zbyt duży, miał niewłaściwy format czy wystąpiła awaria. Musi ponownie napisać opis. Dla osoby piszącej wolno oznacza to znaczną stratę wysiłku, a nie tylko chwilową niedogodność.

Instrukcja powinna wcześniej wyjaśniać dopuszczalne formaty i rozmiar. Po błędzie system powinien zachować poprawne dane i wskazać, co należy zmienić. Jeśli problem dotyczy połączenia, komunikat nie powinien udawać błędu użytkownika. Warto zapewnić możliwość ponowienia przesłania konkretnego pliku. Nazwa załącznika powinna być odczytywana wraz z jego stanem, aby osoba niewidoma wiedziała, co już dodano.

Lista załączników potrzebuje dostępnych przycisków usuwania i zmiany kolejności, jeśli kolejność ma znaczenie. Nie należy wymagać przeciągania jako jedynej metody. Po usunięciu pliku fokus powinien trafić do sensownego miejsca, a komunikat wyjaśnić rezultat. Użytkownik nie powinien przypadkowo usunąć kolejnego dokumentu dlatego, że elementy przesunęły się pod wskaźnikiem bez czytelnego potwierdzenia.

Test obejmuje poprawny plik, nieobsługiwany format, zbyt duży rozmiar i przerwane przesyłanie w bezpiecznych warunkach. Sprawdź, czy opis pozostaje zachowany. Czy użytkownik rozumie stan każdego załącznika? Czy końcowe podsumowanie pokazuje właściwy zestaw? Nie należy przesyłać prawdziwych wrażliwych dokumentów do przypadkowego środowiska testowego. Dobrze przygotowane pliki próbne pozwalają sprawdzić działanie bez ujawniania danych. Dostępny proces powinien wspierać poprawienie błędu, a nie karać utratą całej dotychczasowej pracy.

Przykład siedemnasty — Formularz obsługiwany głosem

Joanna steruje komputerem głosem. Na ekranie widzi przycisk „Dalej” i wypowiada polecenie z tą nazwą. Program nie reaguje, ponieważ ukryta nazwa brzmi „Przejdź do następnej sekcji danych osobowych”. Autor chciał doprecyzować funkcję dla czytnika, ale usunął z nazwy widoczny tekst. W efekcie pomoc dla jednego sposobu obsługi stała się przeszkodą dla innego.

Poprawka zachowuje widoczną etykietę w nazwie dostępnej. Jeżeli potrzebne jest doprecyzowanie, można je dodać w sposób zgodny z wymaganiem. Warto również ograniczyć liczbę identycznych nazw tam, gdzie powodują niejasność. Kilka przycisków „Edytuj” przy różnych sekcjach powinno mieć odpowiedni kontekst. Użytkownik powinien móc wskazać właściwą czynność bez odgadywania technicznej struktury strony.

Joanna dyktuje dłuższy opis. Portal ma globalne skróty z pojedynczych liter, które uruchamiają funkcje podczas wprowadzania tekstu. Potrzebna jest możliwość ich wyłączenia, zmiany albo ograniczenia zgodnie z kryterium. Nie należy zakładać, że skoro skróty przyspieszają pracę jednego użytkownika, będą korzystne dla wszystkich. Dobre ustawienia pozwalają zachować zalety bez narzucania konfliktu.

Test głosowy powinien obejmować wybieranie kontrolek, dyktowanie, poprawianie i przechodzenie między polami. Sprawdź, czy aplikacja nie blokuje zmiany metody wejścia. Joanna może czasem użyć klawiatury albo pomocy urządzenia wskazującego. Warto projektować wspólne, spójne nazwy widoczne i programowe. Taki porządek pomaga także podczas rozmowy z konsultantem, który może powiedzieć „Wybierz Dalej”, wiedząc, że użytkownik widzi i może uruchomić właśnie tak nazwaną funkcję.

Przykład osiemnasty — Telefon zamocowany w uchwycie

Andrzej korzysta z telefonu przymocowanego do wózka. Urządzenie pozostaje w poziomie. Otwiera stronę usługi, która wyświetla komunikat „Obróć telefon”, choć formularz mógłby działać w obu układach. Andrzej nie może samodzielnie zmienić mocowania. Projekt narzucił warunek fizyczny niezwiązany z istotą zadania. Elastyczny układ pozwoliłby mu korzystać z tej samej usługi bez pomocy.

Po poprawie orientacji pojawia się kolejna trudność: rozwinięcie dodatkowej informacji wymaga potrząśnięcia urządzeniem. Trzeba zapewnić dostępną kontrolkę i możliwość wyłączenia reakcji na ruch w odpowiednim zakresie. Użytkownik nie powinien wykonywać manewrów sprzętem, który stanowi część jego stanowiska pracy. To samo dotyczy osób korzystających z telefonu leżącego na stole lub zamocowanego przy łóżku.

Andrzej wybiera opcje za pomocą pojedynczych dotknięć. Małe przyciski umieszczone blisko siebie powodują pomyłki. Większe cele i odstępy ułatwiają działanie. Ważne jest również anulowanie przypadkowego naciśnięcia oraz brak obowiązkowych gestów wielopunktowych. Nie ma potrzeby tworzenia osobnej, ubogiej wersji strony. Wiele tych usprawnień można wprowadzić w zwykłym interfejsie.

Test powinien odtworzyć rzeczywiste ograniczenia ruchu urządzenia, ale nie wymaga naśladowania czyjejś niepełnosprawności. Wystarczy sprawdzić zadanie w obu orientacjach i przy założeniu, że sprzęt pozostaje nieruchomy. Następnie warto zaprosić użytkowników do oceny wygody. Projektant może potwierdzić, że przycisk działa, lecz dopiero praktyka pokaże, czy jest łatwo osiągalny i czy proces nie wymaga wielu męczących powtórzeń. Dostępność obejmuje możliwość wyboru metody zgodnej z własnym sposobem korzystania.

Przykład dziewiętnasty — Informacja o sukcesie bez zgadywania

Barbara wysyła zgłoszenie do organizatora szkolenia. Po naciśnięciu przycisku formularz znika, a na górze strony na chwilę pojawia się zielony pasek. Barbara korzysta z czytnika i nie słyszy żadnej informacji. Nie wie, czy zgłoszenie dotarło. Wraca do formularza i wysyła je ponownie. Organizator otrzymuje duplikaty, a użytkowniczka nadal nie ma pewności.

Komunikat powinien jasno wyjaśniać rezultat: zgłoszenie zostało przyjęte, co stanie się dalej i gdzie można odnaleźć potwierdzenie. Jeśli jest to komunikat o stanie, powinien być przekazany programowo bez niepotrzebnego przenoszenia fokusu. W innych przypadkach nowa strona potwierdzenia wymaga odpowiedniej struktury i orientacji. Ważne jest rozpoznanie rzeczywistego rodzaju zmiany, a nie mechaniczne dodanie jednego atrybutu do każdej wiadomości.

Barbara potrzebuje także odróżnić zapis szkicu od wysłania. Dwa komunikaty o identycznej treści „Gotowe” mogą być mylące. Warto nazwać rezultat konkretnie. Jeżeli system dopiero rozpoczął przetwarzanie, nie powinien twierdzić, że cała sprawa zakończyła się sukcesem. Użytkownik powinien wiedzieć, czy trzeba poczekać, czy można opuścić stronę i jak sprawdzić stan później.

Test obejmuje sukces, błąd i stan oczekiwania. Sprawdź, czy komunikat nie znika zbyt szybko, czy można do niego wrócić i czy jego znaczenie nie zależy wyłącznie od koloru. Dodatkowe potwierdzenie w wiadomości może pomóc, lecz nie powinno zastępować jasnej reakcji interfejsu. Dobrze zaprojektowana informacja o wyniku ogranicza liczbę ponownych prób i kontaktów z obsługą. Przede wszystkim daje użytkownikowi poczucie kontroli nad tym, co rzeczywiście zrobił.

Przykład dwudziesty — Aktualizacja strony, która nie psuje dostępności

Organizacja ma poprawnie działający formularz i dobre wyniki wcześniejszego sprawdzenia. Po kilku miesiącach zmienia bibliotekę komponentów. Nowe okno wyboru daty wygląda nowocześniej, ale nie obsługuje części klawiszy. Jednocześnie redaktor dodaje film bez napisów. Dostępność nie jest cechą nabytą raz na zawsze. Każda zmiana może wprowadzić nowe bariery, nawet jeśli intencją było ulepszenie produktu.

Zespół powinien określić, które scenariusze trzeba sprawdzać po aktualizacji. W przypadku formularza będą to między innymi wejście, wybór wartości, błędy, poprawa i potwierdzenie. W przypadku publikacji filmu potrzebna jest kontrola napisów, informacji wizualnych i odtwarzacza. Nie należy polegać wyłącznie na wcześniejszym raporcie. Raport opisuje określony stan i zakres, a nie wszystkie przyszłe wersje.

Warto ustalić odpowiedzialność za treść i komponenty. Redaktor powinien wiedzieć, jak przygotować nagłówki oraz opisy obrazów. Programista powinien znać wymagania dotyczące klawiatury i stanów. Osoba zamawiająca materiały powinna uwzględnić dostępne wersje już w zleceniu. Dzięki temu poprawki nie trafiają zawsze do jednej osoby na samym końcu, gdy termin publikacji jest bliski.

Test po zmianie powinien być proporcjonalny do ryzyka. Zmiana koloru wymaga kontroli kontrastu, a przebudowa logowania pełnego sprawdzenia procesu. Warto zachowywać opis wykrytego problemu, sposób naprawy i wynik ponownej próby. Nie chodzi o tworzenie dokumentacji dla samej dokumentacji. Chodzi o to, aby zespół potrafił wykazać, że konkretna bariera zniknęła i nie wróciła przy następnej aktualizacji. Użytkownicy potrzebują stabilnej usługi, a nie krótkiego okresu dostępności po jednorazowym audycie.

Warsztat redakcyjny: Proste poprawki przed publikacją

Poniższe ćwiczenia można wykonać podczas przygotowania artykułu, formularza albo instrukcji. Są propozycją pracy zespołu, a nie osobnym zestawem kryteriów zgodności. Ich zaletą jest to, że wiele problemów można usunąć przed publikacją, bez oczekiwania na skargę. Warto przeprowadzać je na prawdziwej treści, ponieważ krótki tekst zastępczy rzadko ujawnia problemy z długością etykiet, kolejnością informacji i zrozumiałością warunków.

Ćwiczenie — Zamień wskazówkę wizualną na nazwę działania

Weź instrukcję „Kliknij niebieski prostokąt po prawej”. Najpierw ustal, co ten element rzeczywiście robi. Jeśli otwiera formularz, nazwij go „Otwórz formularz”. Jeśli wysyła dane, napisz „Wyślij zgłoszenie”. Następnie sprawdź, czy taka nazwa znajduje się również na przycisku. Użytkownik powinien rozpoznawać tę samą czynność w instrukcji i interfejsie. Rozbieżność między opisem a etykietą może być szczególnie trudna podczas obsługi głosem.

Teraz przeczytaj instrukcję bez patrzenia na ekran. Czy nadal wiadomo, co zrobić? Wyobraź sobie, że element przesunął się na telefonie niżej. Czy zdanie zachowuje sens? Kolor i położenie mogą pozostać dodatkową wskazówką, ale nie powinny być jedyną. Na końcu sprawdź, czy nazwa nie obiecuje innego skutku. Przycisk „Dalej” nie powinien bez wyjaśnienia kończyć sprawy i wysyłać dokumentu, jeśli użytkownik oczekuje kolejnego ekranu.

Ćwiczenie — Przepisz komunikat błędu tak, aby prowadził do poprawy

Zacznij od komunikatu „Niepoprawne dane”. Zadaj trzy pytania: które dane, co jest nie tak i co użytkownik może zrobić? Jeśli problem dotyczy daty, komunikat może wskazać pole i dopuszczalny format. Jeśli plik jest zbyt duży, podaj limit i możliwą drogę dalszego działania. Nie wpisuj automatycznie porady, która nie odpowiada rzeczywistej przyczynie. Błąd serwera nie powinien być przedstawiany jako pomyłka osoby wypełniającej formularz.

Następnie sprawdź ton. Użytkownik może być zmęczony albo zestresowany, dlatego komunikat powinien być spokojny i konkretny. Nie musi zawierać długich przeprosin ani żartów. Ważne, aby pomagał odzyskać kontrolę. Na końcu sprawdź dostępność techniczną: czy tekst jest powiązany z polem, czy użytkownik może do niego dotrzeć i czy poprawne dane pozostały zachowane. Dobrze napisany komunikat nie pomoże, jeśli osoba go nie otrzyma.

Ćwiczenie — Sprawdź opis zdjęcia przez jego cel

Przygotuj dwa zdania: po co zdjęcie jest na stronie i czego ma się z niego dowiedzieć odbiorca. Zdjęcie budynku może pokazywać architekturę, wejście albo miejsce wydarzenia. Każdy z tych celów prowadzi do innego opisu. Nie zaczynaj od mechanicznego wyliczania kolorów i przedmiotów. Najpierw ustal znaczenie. Jeśli fotografia jest tylko dekoracją i nie wnosi informacji, rozważ sposób jej pominięcia przez technologię asystującą.

Przeczytaj opis razem z sąsiednim akapitem. Czy nie powtarza całej treści? Czy nie pomija jedynej ważnej informacji widocznej na zdjęciu? Czy nie zawiera domysłów, na przykład oceny emocji osoby albo twierdzenia o dostępności wejścia bez podstaw? Przy wykresie zastanów się, czy potrzebne jest dłuższe objaśnienie i dane. Krótki opis „Wykres wyników” identyfikuje rodzaj obiektu, ale nie przekazuje wyniku. Dobry opis wynika z zadania czytelnika.

Ćwiczenie — Przeczytaj formularz jako rozmowę

Ułóż etykiety i instrukcje w kolejności, w jakiej napotyka je użytkownik. Przeczytaj je na głos jak pytania zadawane drugiej osobie. Czy wiadomo, dlaczego potrzebne są dane? Czy pytanie „Numer” ma jednoznaczne znaczenie? Czy po odpowiedzi pojawia się zrozumiały następny krok? Jeżeli rozmowa brzmi jak zestaw wewnętrznych kodów organizacji, formularz prawdopodobnie wymaga redakcji. Warto zachować dokładność, ale wyjaśnić ją językiem odbiorcy.

Następnie sprawdź, co się dzieje, gdy osoba odpowie inaczej niż zakładano. Czy może wskazać brak numeru mieszkania? Czy otrzyma informację o wymaganym załączniku przed końcem? Czy wybranie opcji nie przenosi jej niespodziewanie do innej strony? Takie ćwiczenie pomaga znaleźć luki w logice, których nie ujawnia oglądanie pustego formularza. Na końcu warto poprosić osobę spoza zespołu o opisanie, co zostanie wysłane. Jej odpowiedź pokazuje, czy proces jest rzeczywiście zrozumiały.

Ćwiczenie — Zaplanuj potwierdzenie przed zaprojektowaniem przycisku

Zanim powstanie przycisk kończący zadanie, napisz komunikat, który użytkownik zobaczy po jego uruchomieniu. Powinien wyjaśniać rezultat, dalszy krok i sposób odnalezienia informacji później. Jeśli nie potrafisz napisać takiego komunikatu, być może sam skutek działania nie został jeszcze jasno ustalony. „Gotowe” może oznaczać zapis szkicu, wysłanie dokumentu albo rozpoczęcie przetwarzania. Te sytuacje wymagają różnych informacji.

Następnie zaplanuj wariant błędu oraz oczekiwania. Co użytkownik ma zrobić, gdy odpowiedź systemu trwa dłużej? Czy ponowne naciśnięcie spowoduje duplikat? Czy można bezpiecznie opuścić stronę? Jak rezultat dotrze do czytnika? Dobrze zaprojektowane potwierdzenie ogranicza niepewność i niepotrzebne kontakty z obsługą. Nie powinno być ozdobą dodaną na końcu wdrożenia. Jest częścią funkcji, ponieważ dopiero dzięki niemu człowiek wie, że jego działanie przyniosło zamierzony efekt.

Ćwiczenie — Rozdziel minimum od dodatkowej pomocy

Wybierz jedno usprawnienie i ustal, czy wynika z konkretnego kryterium, czy jest dodatkową dobrą praktyką. Na przykład możliwość obsługi klawiaturą ma wyraźną podstawę w WCAG. Szczegółowa instrukcja dla konsultanta, jak spokojnie czekać na odpowiedź osoby korzystającej z komunikatora, jest szerszym elementem organizacji obsługi. Oba działania mogą być bardzo ważne, ale nie należy przypisywać im tej samej podstawy bez sprawdzenia.

Takie rozróżnienie pomaga pisać uczciwe raporty i planować pracę. Nie wolno odrzucać potrzeb tylko dlatego, że nie mieszczą się w jednym kryterium. Nie należy też ogłaszać naruszenia konkretnego wymagania wyłącznie na podstawie osobistej preferencji. Dobra analiza opisuje fakt, skutek dla użytkownika, właściwe odniesienie i proponowane rozwiązanie. Dzięki temu rozmowa między użytkownikiem, redaktorem, programistą i zamawiającym staje się bardziej konkretna, a poprawki można sprawdzić w praktyce.

Jak sprawdzić stronę bez udawania pełnego audytu

Podstawowe sprawdzenie może rozpocząć osoba, która nie jest programistą. Trzeba jednak jasno określić jego granice. Kilka prób pozwala wykryć część barier, lecz nie potwierdza automatycznie zgodności całej usługi. Dobry zapis wyniku mówi, co sprawdzono, w jakich warunkach i jaki był rezultat. Zdanie „Nie zauważyłem problemu” jest uczciwsze niż „Strona jest w pełni dostępna”, jeśli test obejmował tylko jeden ekran.

Zacznij od zadania ważnego dla odbiorcy. Może to być odnalezienie informacji, zapis na wydarzenie albo wysłanie formularza testowego. Opisz początek i oczekiwany rezultat. Dzięki temu nie zatrzymasz się na przypadkowym elemencie. Jeżeli celem jest zapis na wydarzenie, rezultat obejmuje także rozpoznanie potwierdzenia. Jeżeli celem jest pobranie instrukcji, trzeba sprawdzić również plik, a nie wyłącznie odsyłacz.

Następnie przejdź zadanie bez myszy. Zwracaj uwagę na miejsce fokusu, możliwość uruchomienia funkcji i wyjścia z okien. Zapisuj konkretne objawy. „Nie mogę wybrać dnia klawiaturą” jest bardziej użyteczne niż ogólna ocena „Kalendarz zły”. Nie trzeba od razu wskazywać przyczyny w kodzie. Osoba odpowiedzialna za naprawę powinna ją ustalić, korzystając z opisu i możliwości odtworzenia problemu.

Kolejna próba dotyczy powiększenia. Sprawdź zwykły tekst, formularze i komunikaty. Upewnij się, że nie znika nazwa przycisku ani ważna część informacji. Osobno sprawdź zmianę odstępów. Te dwie próby badają różne zachowania. Warto użyć dłuższych przykładowych nazw i komunikatów, ponieważ krótki tekst często mieści się nawet w źle zaprojektowanym bloku. Rzeczywisty użytkownik może mieć długie nazwisko, adres lub opis sprawy.

Następnie oceń treści nietekstowe. Czy ważne zdjęcia mają odpowiednie opisy? Czy film ma napisy i przekaz istotnych informacji wizualnych? Czy wykres da się zrozumieć bez rozróżniania kolorów? Nie oceniaj jakości opisu na podstawie samej obecności pola. Tekst „Grafika” formalnie istnieje, ale zwykle nie wyjaśnia przekazu. Podobnie automatyczne napisy mogą zawierać błędy odwracające sens zdania.

Na końcu sprawdź błędy i sytuacje nietypowe. Pomiń wymagane pole, wpisz błędny format i spróbuj wrócić do poprzedniego kroku. Rób to na danych testowych i bez wywoływania rzeczywistych skutków. Czy system wyjaśnia problem? Czy zachowuje poprawne dane? Czy można poprawić tylko jedną odpowiedź? Wiele usług dobrze działa w idealnym przebiegu, lecz staje się niedostępnych, gdy użytkownik potrzebuje korekty. Właśnie dlatego test powinien obejmować także potknięcia, a nie tylko najszybszą ścieżkę.

Jak zapisać wynik sprawdzenia, żeby dało się naprawić problem

Użyteczny opis zawiera nazwę zadania, adres strony lub miejsce w aplikacji, kroki prowadzące do problemu, oczekiwany rezultat i rzeczywisty rezultat. Można dodać wersję przeglądarki oraz technologię asystującą. Jeśli numer kryterium jest znany, warto go wskazać, ale nie powinien zastępować opisu. Programista musi wiedzieć, co użytkownik próbował zrobić i w którym momencie został zatrzymany.

Przykład dobrego zgłoszenia: „W formularzu zapisów przechodzę klawiszem Tab do wyboru terminu. Otwieram kalendarz klawiszem Enter. Mogę przejść do zmiany miesiąca, ale nie do dni. Oczekuję możliwości wybrania daty bez myszy. Obecnie nie mogę ukończyć zapisu”. Taki opis jest konkretny i nie wymaga podawania diagnozy. Pokazuje skutek dla zadania oraz pozwala odtworzyć sytuację.

Warto odróżnić obserwację od przypuszczenia. „Czytnik nie ogłasza komunikatu” jest obserwacją. „Programista zapomniał dodać określony atrybut” jest hipotezą, która może być błędna. Przyczyna może leżeć w momencie aktualizacji, strukturze, sposobie ukrycia albo konflikcie komponentów. Rzetelny raport nie powinien udawać pewności tam, gdzie wykonano tylko podstawową próbę. Trafny opis skutku często wystarcza, aby rozpocząć diagnozę.

Po naprawie należy powtórzyć te same kroki i sprawdzić rezultat. Samo zapewnienie wykonawcy, że zmienił kod, nie dowodzi usunięcia bariery. Warto również sprawdzić najbliższe powiązane działania. Jeśli poprawiono otwieranie okna, trzeba sprawdzić zamykanie i powrót fokusu. Nie ma potrzeby za każdym razem wykonywać wszystkich możliwych testów, lecz zakres ponownej próby powinien odpowiadać zmianie i ryzyku jej skutków.

Jak współpracować z użytkownikami o różnych potrzebach

Badanie z użytkownikami powinno dotyczyć rzeczywistych zadań, a nie egzaminowania ludzi z obsługi technologii. Uczestnik nie ma udowadniać, że potrafi obejść błąd. Jeśli używa nietypowej drogi, warto zapytać, dlaczego. Być może zwykła ścieżka jest niedostępna, a obejście zostało wypracowane przez lata doświadczeń. Sukces osiągnięty dużym wysiłkiem nie oznacza automatycznie dobrego projektu.

Nie należy traktować jednej osoby jako przedstawiciela wszystkich użytkowników z daną niepełnosprawnością. Dwie osoby niewidome mogą korzystać z różnych czytników, urządzeń i skrótów. Dwie osoby słabowidzące mogą mieć odmienne potrzeby dotyczące kontrastu. Warto dobierać uczestników do istotnych sposobów korzystania z usługi i jasno opisywać zakres badania. Mała próba może ujawnić ważne problemy, ale nie daje podstaw do uniwersalnych twierdzeń o wszystkich odbiorcach.

Uczestnik powinien wiedzieć, jakie zadanie ma wykonać, jakie dane są testowe i kiedy może przerwać. Nie należy wymagać ujawniania prywatnych haseł, dokumentów czy informacji zdrowotnych. Jeśli potrzebna jest demonstracja własnych ustawień, zakres powinien być uzgodniony i ograniczony do celu badania. Dostępność badań obejmuje także zaproszenie, instrukcję, sposób kontaktu oraz możliwość zrobienia przerwy.

Podczas obserwacji warto zapisywać nie tylko niepowodzenia, ale także wysiłek. Użytkownik może ukończyć formularz, lecz potrzebować kilkukrotnie więcej kroków z powodu złej struktury. Może też zrezygnować z części funkcji, uznając je za nieosiągalne. Pytania po zadaniu pomagają zrozumieć te decyzje. Nie należy jednak sugerować odpowiedzi ani przekonywać uczestnika, że rozwiązanie jest łatwe. Celem jest poznanie doświadczenia, a nie obrona projektu.

Jak ustalać kolejność poprawek

Pierwszeństwo powinny otrzymać bariery blokujące ważne zadania, zwłaszcza gdy nie ma równoważnej dostępnej drogi. Niedostępne logowanie może uniemożliwić korzystanie z całej usługi. Brak możliwości wysłania wniosku może mieć poważniejsze skutki niż drobna niespójność w mało używanym materiale. Nie oznacza to, że pozostałe problemy można ignorować. Oznacza potrzebę świadomego planu napraw, opartego na skutkach dla ludzi.

Warto uwzględniać zasięg komponentu. Błąd we wspólnym przycisku lub menu może występować na setkach stron. Naprawienie go przyniesie szeroką korzyść. Z kolei pojedynczy problem na rzadko odwiedzanej stronie może być bardzo ważny, jeśli strona służy do pilnej czynności. Sama liczba odwiedzin nie powinna decydować o priorytecie. Osoby wykluczone mogą nie pojawiać się w statystykach ukończonych zadań właśnie dlatego, że nie potrafią przejść procesu.

Przy planowaniu dobrze określić odpowiedzialną osobę, przewidywany termin i sposób weryfikacji. Zgłoszenie bez właściciela łatwo pozostaje nierozwiązane. Użytkownik potrzebuje również informacji, jak wykonać pilną czynność w okresie naprawy. Rozwiązanie tymczasowe powinno być rzeczywiście dostępne i jasno opisane. Nie należy przedstawiać go jako dowodu, że bariera techniczna przestała istnieć, jeśli nadal występuje w głównej usłudze.

Po poprawkach warto sprawdzić, czy problem nie wynika z procesu tworzenia treści. Jeśli stale brakuje opisów obrazów, potrzebne może być szkolenie redaktorów i zmiana formularza publikacji. Jeśli każda nowa biblioteka wprowadza pułapki klawiaturowe, trzeba poprawić sposób wyboru komponentów. Usuwanie objawów bez zmiany przyczyny prowadzi do powtarzania tych samych kosztów. Dostępność powinna być częścią normalnej pracy, a nie serią interwencji po skargach.

Jak zamówić dostępny serwis i odebrać wynik

W zamówieniu warto jasno wskazać wersję standardu, poziom, zakres treści i procesów oraz sposób sprawdzania. Sformułowanie „zgodne z WCAG” pozostawia zbyt wiele niewiadomych. Czy chodzi o stronę główną, wszystkie szablony, formularze, dokumenty, materiały multimedialne i elementy zewnętrzne? Czy zakres obejmuje treści już istniejące, czy tylko nowe? Im wcześniej odpowie się na te pytania, tym mniej sporów pojawi się przy odbiorze.

Kryteria zgodności należy stosować do pełnych stron i kompletnych procesów. Nie można wybrać tylko dostępnego fragmentu formularza, pomijając niedostępny etap potwierdzenia, a następnie ogłosić zgodności procesu. Trzeba też uwzględnić technologie wspierające dostępność oraz zasadę, że treści niespełniające wymagań nie mogą blokować korzystania z pozostałych. Źródło: W3C, wymagania zgodności.

Przy odbiorze warto wymagać konkretnych dowodów: zakresu badania, opisanych scenariuszy, wyników i wykazu pozostałych problemów. Sama liczba punktów ze skanera nie wystarcza. Narzędzie może wykryć brak niektórych oznaczeń, lecz nie rozstrzygnie, czy opis zdjęcia przekazuje właściwe znaczenie albo czy instrukcja jest zrozumiała. Testy automatyczne są przydatną częścią pracy, ale nie zastępują oceny człowieka.

Dobrze ustalić również zasady utrzymania. Kto sprawdzi nowe filmy? Kto odpowiada za dokumenty? Co dzieje się po zmianie modułu logowania? Jak użytkownik zgłasza barierę? Dostępny produkt może stopniowo tracić jakość, jeśli po odbiorze nie ma właściciela procesu. Warto zadbać o szkolenie zespołu oraz proste instrukcje redakcyjne. Dzięki temu dostępność pozostaje normalnym wymaganiem kolejnych zmian, a nie wspomnieniem z dnia uruchomienia serwisu.

Słownik pojęć używanych w przewodniku

Fokus oznacza aktualne miejsce obsługi klawiaturą. Można go porównać do wskazania, który element otrzyma następne polecenie. Nie jest tym samym co kursor myszy ani zaznaczenie wybranego wariantu. Użytkownik widzący potrzebuje widocznego wskaźnika, a technologia asystująca informacji o elemencie. Gdy fokus znika lub przeskakuje, człowiek może stracić orientację nawet na prostej stronie.

Czytnik ekranu to program przedstawiający informacje z interfejsu między innymi mową syntetyczną lub na monitorze brajlowskim. Nie polega wyłącznie na odczytywaniu tego, co widać na ekranie. Korzysta również ze struktury i informacji programowych. Dlatego wyglądający poprawnie przycisk może być dla niego nierozpoznawalny, jeśli nie ma właściwej roli i nazwy. Z drugiej strony dobra struktura pozwala szybko przeskakiwać między nagłówkami i obszarami.

Nazwa dostępna to określenie elementu przekazywane technologiom asystującym. Może pochodzić z widocznego tekstu lub innego poprawnego powiązania. Rola mówi, czym jest element, na przykład przyciskiem lub polem wyboru. Stan informuje, czy coś jest zaznaczone, rozwinięte lub włączone. Wartość może oznaczać na przykład pozycję suwaka. Te informacje powinny odpowiadać rzeczywistemu działaniu i aktualizować się razem z interfejsem.

Transkrypcja to tekstowy zapis treści dźwiękowej, z uwzględnieniem istotnych informacji potrzebnych do zrozumienia. Napisy są powiązane z czasem odtwarzania i pozwalają śledzić materiał na bieżąco. Audiodeskrypcja przekazuje dźwiękiem ważne informacje wizualne. Pełna alternatywa dla mediów może łączyć opis obrazu, dźwięku i działań w uporządkowany tekst. Te formy nie są dowolnie wymienne; ich zastosowanie zależy od rodzaju materiału i odpowiedniego kryterium.

Piksel CSS jest jednostką używaną przy określaniu wymiarów w układzie strony. Nie należy utożsamiać go bezpośrednio z pojedynczym fizycznym punktem ekranu. Dlatego pomiar celu lub szerokości powinien korzystać z właściwych narzędzi, a nie linijki przyłożonej do telefonu. Dla zwykłego użytkownika najważniejszy pozostaje skutek: czy przycisk można wygodnie uruchomić i czy tekst dopasowuje się do widoku. Parametry pomagają zespołowi sprawdzić rozwiązanie w sposób powtarzalny.

Źródła i sposób korzystania z opracowania

Podstawą części normatywnej są dokumenty W3C: WCAG 2.2 oraz osobne wyjaśnienia każdego kryterium w serii Understanding. Bezpośredni odsyłacz znajduje się przy każdym kryterium. Wyjaśnienia w tym przewodniku są autorskimi omówieniami, a przykłady scenariuszami edukacyjnymi. W razie szczegółowej oceny zgodności należy sprawdzić pełne brzmienie wymagania, definicje i wyjątki w źródle. Krótkie objaśnienie nie zastępuje specyfikacji.

• W3C: Web Content Accessibility Guidelines 2.2.
• W3C: Zbiór dokumentów Understanding WCAG 2.2.
• W3C: Wyjaśnienie zgodności.
• Ministerstwo Cyfryzacji: Cztery zasady dostępności cyfrowej.
• Kompendium: Wybrane zagadnienia techniczne WCAG.

Opracowanie opisuje dostępność jako możliwość samodzielnego i świadomego korzystania z informacji oraz usług. W praktyce warto wracać do trzech pytań: co użytkownik chce zrobić, co go zatrzymuje i po czym pozna, że się udało. Numery kryteriów pomagają uporządkować odpowiedzi, ale celem pracy pozostaje człowiek, który może przeczytać informację, podjąć decyzję, poprawić pomyłkę i zakończyć własną sprawę.