Osoby z niepełnosprawnościami poznawczymi (np. trudności w uczeniu się, dysleksja, ADHD) oraz neurologicznymi (np. epilepsja, zaburzenia przetwarzania sensorycznego) napotykają specyficzne bariery w internecie. Wytyczne WCAG 2.1 zawierają szereg kryteriów sukcesu istotnych dla tej grupy – ich spełnienie ułatwia takim użytkownikom percepcję, nawigację i zrozumienie treści internetowych[1][2]. Poniżej przedstawiono szczegółowe omówienie tych kryteriów (na poziomach A, AA i AAA), z uwzględnieniem ich celu (istoty) z perspektywy użytkowników poznawczych i neurologicznych, przykładów dobrych praktyk oraz typowych błędów w implementacji.
Zasada 1: Postrzegalność
(Treści muszą być prezentowane w sposób dostrzegalny dla zmysłów użytkownika – m.in. poprzez możliwość adaptacji i czytelny, zrozumiały wygląd. Dla osób z dysfunkcjami poznawczymi oznacza to zapewnienie elastycznego prezentowania treści (np. możliwość powiększenia tekstu, zmiany orientacji ekranu czy odstępów), jak również unikanie nadmiernego obciążenia percepcyjnego[3][4].)
1.3.1 Informacje i relacje (poziom A)
Cel i istota: Treść powinna być strukturalnie poprawna – informacje przekazywane układem wizualnym muszą być dostępne także poprzez strukturę semantyczną. Dla użytkowników z niepełnosprawnościami poznawczymi oznacza to, że logiczne grupowanie treści (np. sekcje z nagłówkami, listy, opisy tabel) ułatwia im zrozumienie relacji między elementami. Gdy strona jest właściwie zorganizowana i opisana w kodzie (nagłówki, listy, regiony itp.), osoby z zaburzeniami uwagi lub pamięci łatwiej pojmują układ informacji, mogą skanować treść i koncentrować się na istotnych fragmentach zamiast próbować samodzielnie odgadnąć strukturę dokumentu.
Przykłady dobrych zastosowań:
– Zastosowanie nagłówków HTML (<h1>…<h6>) do podziału strony na sekcje logiczne. Dzięki temu osoby z trudnościami poznawczymi mogą szybciej pojąć hierarchię treści (np. tytuł, podrozdziały) i odnaleźć potrzebne informacje.
– Grupowanie powiązanych pól formularza za pomocą kontenerów (np. <fieldset> z legendą) – użytkownik rozumie, które pola są ze sobą powiązane (np. dane adresowe).
– Opisywanie związków w tabelach (nagłówki kolumn/wierszy z <th> oraz atrybuty scope lub headers dla połączenia nagłówków z komórkami). Ułatwia to zrozumienie danych osobom mającym kłopot z interpretacją układu wizualnego tabeli.
Typowe błędy:
– Używanie jedynie wizualnego wyróżnienia (np. powiększona czcionka, pogrubienie) zamiast semantycznych nagłówków. Powoduje to, że struktura nie jest dostępna dla technologii asystujących ani dla użytkowników korzystających z własnych arkuszy stylów (np. dla uproszczenia wyglądu strony).
– Brak uporządkowania sekcji na stronie – np. przypadkowe rozmieszczenie treści, które powinny być zgrupowane, przez co użytkownik może mieć trudności z pojęciem, co do czego się odnosi.
– Poleganie wyłącznie na rozmieszczeniu elementów na ekranie (np. kolumny tekstu) bez odpowiedniego odzwierciedlenia tego układu w kodzie HTML. Taki „płaski” przekaz informacji utrudnia zrozumienie zawartości osobom z zaburzeniami poznawczymi, które korzystają np. z czytników ekranu lub personalizują styl wyświetlania treści.
1.3.2 Zrozumiała kolejność (poziom A)
Cel i istota: Kolejność prezentacji treści powinna być logiczna i zgodna z intencją autora, niezależnie od zastosowanego sposobu przeglądania (np. stylów CSS czy kolejności fokusu). Dla osób z dysfunkcjami poznawczymi spójna kolejność odczytywania elementów jest kluczowa – treść powinna „opowiadać historię” w odpowiednim porządku. Jeśli kolejność jest zaburzona (np. ważne informacje są czytane po pobocznych wskazówkach), użytkownik może się zagubić lub błędnie zinterpretować przekaz.
Przykłady dobrych zastosowań:
– Upewnienie się, że w kodzie HTML elementy są ułożone w takiej kolejności, w jakiej powinny być czytane. Nawet jeśli CSS zmienia położenie elementów wizualnie, kolejność w kodzie (np. w drzewie DOM) pozostaje logiczna.
– W formularzu umieszczanie etykiety tekstowej tuż przed polem input w kodzie, aby czytniki ekranu (lub linearne czytanie) przekazywały pytanie przed odpowiedzią.
– W kompleksowym artykule zachowanie naturalnego toku: najpierw wprowadzenie do tematu, potem rozwinięcie, na końcu podsumowanie – bez wstawek wyświetlanych wcześniej niż wyjaśnienia, które na nie wpływają.
Typowe błędy:
– Stosowanie CSS do wizualnego przemieszczania bloków tekstu (np. przy użyciu position:absolute), co skutkuje nielogiczną kolejnością w kodzie. W efekcie osoba korzystająca z klawiatury lub czytnika ekranu usłyszy/ujrzy fragmenty w chaotycznej kolejności.
– Niewłaściwe użycie znaczników (np. listy określane za pomocą tabel) prowadzące do utraty logicznej kolejności podczas czytania liniowego.
– Automatyczne sortowanie lub przegrupowywanie treści po stronie klienta bez wyraźnego sygnału dla użytkownika – np. skrypt przenoszący element na początek strony w sposób niezauważalny może spowodować nagłą zmianę kolejności przekazu.
1.3.3 Właściwości zmysłowe (poziom A)
Cel i istota: Treści nie powinny przekazywać istotnych informacji wyłącznie za pomocą cech zmysłowych, takich jak kolor, kształt, rozmiar czy położenie. Osoby z niepełnosprawnościami poznawczymi mogą mieć trudności z interpretacją takich wskazówek – np. zapamiętanie, że „zielony przycisk oznacza zatwierdzenie”, albo zrozumienie polecenia typu „kliknij okrągły przycisk w prawym górnym rogu”. To kryterium wymaga, by wszelkie instrukcje i informacje były dostępne w formie zrozumiałej bez konieczności polegania wyłącznie na intuicyjnych skojarzeniach sensorycznych.
Przykłady dobrych zastosowań:
– Zamiast pisać „ważne linki oznaczono kolorem czerwonym”, lepiej dodać także informację tekstową lub ikonę (np. gwiazdkę) przy ważnych linkach. Dzięki temu użytkownik, który może nie kojarzyć funkcji koloru, zrozumie przekaz alternatywną drogą.
– W instrukcjach unikanie określeń wyłącznie wizualnych: zamiast „kliknij niebieski kwadrat, by przejść dalej”, lepiej użyć etykiety: „kliknij przycisk Dalej (niebieska ikona kwadratu)”. Dodanie słownej etykiety „Dalej” sprawia, że nawet jeśli ktoś nie skojarzy koloru/kształtu, zrozumie co zrobić.
– W formach interaktywnych (quizy, gry edukacyjne) zapewnienie, że polecenia nie bazują jedynie na wrażeniach zmysłowych. Np. w grze dla dzieci zamiast „dopasuj przedmioty tak, by były ułożone jak na obrazku powyżej” (gdzie trzeba zrozumieć układ obrazka), dodać opis: „ułóż przedmioty w kolejności od największego do najmniejszego”.
Typowe błędy:
– Oznaczanie wymaganych pól formularza tylko kolorem (np. czerwonym obramowaniem) bez dodatkowego komunikatu „(wymagane)”. Osoba z zaburzeniami poznawczymi może nie skojarzyć czerwonej ramki z błędem, a dodatkowo taka praktyka łamie też zasady użycia koloru (1.4.1) dla osób niewidzących kolorów.
– Instrukcje polegające na określeniach przestrzennych, np. „informacja znajduje się po prawej stronie w zielonym polu”. Użytkownik z trudnością w rozróżnianiu stron lub kolorów może nie wykonać polecenia poprawnie, bo nie będzie pewny, który element jest właściwy.
– Stosowanie ikon bez etykiet tekstowych i oczekiwanie, że użytkownik zrozumie ich znaczenie po wyglądzie. Przykład: posługiwanie się samą ikoną koła zębatego dla ustawień – wiele osób (nie tylko poznawczo niepełnosprawnych) może tego nie skojarzyć. Bez opisu „Ustawienia” obok ikony, intencja może być niejasna.
1.3.4 Orientacja (poziom AA)
Cel i istota: Treść nie powinna wymagać konkretnej orientacji ekranu (pionowej lub poziomej), chyba że jest to niezbędne dla jej funkcji. Dla niektórych osób z niepełnosprawnościami poznawczymi zablokowanie orientacji może być poważnym utrudnieniem – np. widok poziomy może pokazywać zbyt wiele informacji naraz, co przytłacza użytkownika. Możliwość obrócenia urządzenia i uzyskania widoku pionowego (węższego) pozwala takim osobom skupić się na mniejszym fragmencie treści naraz i lepiej go zrozumieć[5]. Podobnie, osoby z ograniczeniami motorycznymi (wynikającymi z uszkodzeń neurologicznych) mogą mieć urządzenie na stałe zamocowane w jednej orientacji – treść musi się do tego dostosować.
Przykłady dobrych zastosowań:
– Strona internetowa reagująca na zmianę orientacji (tzw. responsywność). Np. serwis edukacyjny działa zarówno w widoku pionowym (smartfon trzymany zwyczajnie), jak i poziomym (smartfon obrócony), zmieniając układ z wielokolumnowego na jednokolumnowy. Dzięki temu użytkownik może wybrać orientację, w której jest mu łatwiej czytać (np. pionowo, aby widzieć jedną kolumnę tekstu na raz bez rozpraszaczy).
– Aplikacja do czytania książek pozwalająca na dowolne ułożenie urządzenia – tekst automatycznie dostosowuje się i zawija linie odpowiednio. Osoba mająca problem z ogarnianiem długich linii tekstu może preferować tryb pionowy z krótszymi wierszami.
– Gdy jakaś funkcjonalność musi mieć konkretną orientację (np. aplikacja do skanowania odcisku palca – wymaga pionu, by przyłożyć palec – czy wirtualne pianino wymagające układu poziomego klawiszy), spełnienie kryterium polega na ograniczeniu wyjątku tylko do takich koniecznych sytuacji. Przykład wyjątku: mobilna gra planszowa może działać tylko poziomo, bo graficzna plansza musi być szeroka – to jest uzasadnione względami funkcjonalnymi.
Typowe błędy:
– Wymuszanie orientacji bez potrzeby. Np. strona informacyjna blokuje obrót ekranu i zawsze wyświetla się poziomo, mimo że nie ma ku temu technicznej konieczności. Użytkownik z ADHD lub zaburzeniami koncentracji, który woli czytać w trybie pionowym (by mieć mniej tekstu w linii), nie ma takiej możliwości i czuje się przytłoczony szerokim akapitem tekstu.
– Prezentacje i slajdy osadzone na stronie, które działają tylko w jednym układzie (np. pionowym) i ulegają rozpikselowaniu lub obcięciu po obróceniu ekranu – co zniechęca do użycia trybu preferowanego przez użytkownika.
– Brak komunikatu o koniecznej orientacji w sytuacji wyjątkowej. Jeśli aplikacja faktycznie wymaga np. widoku poziomego (bo np. to aplikacja astronomiczna ukazująca horyzont), a autorzy blokują orientację pionową, to błędem jest niepoinformowanie użytkownika dlaczego ekran się nie obraca. Osoba może sądzić, że to awaria lub nie rozumieć, czemu nic się nie dzieje.
1.3.5 Określenie pożądanej wartości (poziom AA)
Cel i istota: Autor treści powinien programowo określić przeznaczenie pól formularza, takich jak imię, nazwisko, adres, e-mail itp. – najczęściej poprzez odpowiednie atrybuty autouzupełniania (autocomplete) lub role. Dzięki temu przeglądarki i technologie pomocnicze mogą oferować podpowiedzi i automatyczne uzupełnianie. Dla osób z niepełnosprawnością poznawczą oznacza to ogromne ułatwienie: nie muszą pamiętać i ręcznie wpisywać powtarzalnych danych, co jest przydatne przy słabej pamięci roboczej, dysleksji (mniejsza liczba literówek) czy trudności z koncentracją[6]. Innymi słowy, strona „wie”, że dane pole to np. adres dostawy, więc przeglądarka może użytkownikowi podpowiedzieć jego adres zapisany w profilu – ograniczając wysiłek umysłowy.
Przykłady dobrych zastosowań:
– Dodanie w kodzie HTML atrybutu autocomplete=”name” przy polu imienia, autocomplete=”email” przy polu e-mail, autocomplete=”cc-number” przy numerze karty kredytowej itp. Dzięki temu przeglądarka lub wtyczka menedżera haseł może automatycznie wstawić właściwe informacje lub zasugerować je użytkownikowi wprost w formularzu[7]. Osoba mająca kłopot z przypomnieniem sobie np. numeru karty lub z przepisaniem go bez błędów skorzysta na tym, że system zrobi to za nią.
– Używanie semantycznych typów pól (<input type=”email”>, <input type=”tel”>, <input type=”date”> itd.), co również pomaga w identyfikacji celu pola. Np. w telefonie pojawi się odpowiednia klawiatura numeryczna przy polu numeru telefonu, co przyspiesza i ułatwia wprowadzenie danych (mniej pomyłek).
– Stosowanie spójnych, zrozumiałych etykiet i dodatkowo ich mapowanie do uniwersalnych celów. Np. pole z etykietą „Kod pocztowy” otrzymuje autocomplete=”postal-code”. Użytkownik z trudnościami poznawczymi widzi jasną etykietę (pomaga to wszystkim), a przeglądarka rozpoznaje cel i np. na podstawie wcześniejszych danych uzupełnia ten kod.
Typowe błędy:
– Nieuzupełnienie atrybutów autocomplete lub niewłaściwe ich wartości – np. wpisanie literówki w tokenie atrybutu albo pomylenie autocomplete=”address-line1″ między polem ulicy i numeru domu. To sprawia, że przeglądarka nie rozpozna pola lub błędnie podpowie dane, co może dodatkowo zdezorientować użytkownika.
– Całkowite wyłączanie funkcji autouzupełniania (np. poprzez autocomplete=”off” lub skrypty blokujące) bez ważnego powodu. Czasami deweloperzy wyłączają autowypełnianie, np. w polach powtórzenia e-maila, co zmusza użytkownika do ponownego, ręcznego wpisania informacji – taka praktyka uderza szczególnie w osoby z zaburzeniami uwagi i pamięci, które mogą drugi raz popełnić ten sam błąd.
– Niestandardowe widgety formularza nieinformujące o swoim celu. Np. własny komponent daty (z suwakami czy dropdownami) bez poprawnych atrybutów ARIA lub bez użycia natywnego <input type=”date”>. W efekcie asystujące narzędzia nie są w stanie pomóc (np. odczytać, że to pole daty) i użytkownik musi sam zrozumieć i obsłużyć bardziej skomplikowany interfejs.
1.3.6 Określenie przeznaczenia (poziom AAA)
Cel i istota: Każdy element interfejsu użytkownika (przycisk, ikona, kontrolka) oraz region strony powinien mieć możliwe do zidentyfikowania przeznaczenie – programowo określone. Chodzi o to, by narzędzia lub personalizowane nakładki mogły rozpoznać, że np. ikona lupy oznacza wyszukiwanie, „kosz” oznacza usunięcie, a sekcja w bocznej kolumnie to nawigacja itp. Jest to szczególnie istotne z punktu widzenia osób z niepełnosprawnościami poznawczymi, które mogą nie rozpoznawać znaczenia ikon lub nietypowych metafor graficznych. Jeśli cel jest określony w kodzie, przeglądarka lub asystent personalizujący treść może np. zamienić ikonę na bardziej zrozumiały dla danej osoby symbol lub dodać widoczny opis[8].
Uwaga: To kryterium wybiega w przyszłość – ma stworzyć fundamenty pod mechanizmy personalizacji interfejsu. Dziś (2025 r.) przeglądarki jeszcze w pełni nie wykorzystują tych znaczników do automatycznych zamian ikon na preferowane przez użytkownika, ale sama idea kieruje się potrzebą osób o zróżnicowanych możliwościach poznawczych[9].
Przykłady dobrych zastosowań:
– Zastosowanie atrybutów ARIA definiujących rolę regionu strony, np. <nav role=”navigation”> dla obszaru nawigacji, <main role=”main”> dla głównej treści. Osoba mająca trudności z ogarnięciem układu strony może skorzystać z narzędzia, które na podstawie tych ról wyeksponuje jej najważniejsze sekcje (np. pozwoli skupić się tylko na głównej zawartości, pomijając boczne menu).
– Wykorzystanie ontologii Common Purpose (opracowanej przez W3C) – np. dodanie danych przeznaczenia do elementów formularza i linków zgodnie z definicjami z rozdziału 9 WCAG 2.1. Przykładowo znacznik wskazujący, że dany link jest linkiem „logowania” albo że przycisk z ikoną kosza służy do „usuwania” elementu. Dzięki temu w przyszłości oprogramowanie będzie mogło np. wyświetlić użytkownikowi własny, zrozumiały opis tych elementów (np. zamienić ikonę kosza na tekst „usuń” lub inną ikonę, którą użytkownik rozpoznaje).
– Konsekwentne stosowanie tekstu alternatywnego i dostępnej nazwy dla ikon. Jeśli przycisk ma ikonę lupy, powinien mieć np. aria-label=”Szukaj” lub widoczny tekst „Szukaj”. To co prawda wymóg niższego poziomu (3.3.2 i 4.1.2), ale spełnienie go zapewnia też częściowo realizację określenia przeznaczenia – maszyna może stwierdzić, że skoro przycisk ma nazwę „Szukaj”, to jego celem jest wyszukiwanie.
Typowe błędy:
– Różne oznaczenia dla tego samego celu na różnych podstronach. Np. na stronie głównej przycisk wyszukiwania ma ikonę lupy, a na stronie wyników – tekst „Znajdź”. Użytkownik z deficytami pamięci może nie zorientować się, że to ta sama funkcja (brak spójnej identyfikacji), a dodatkowo trudno o programowe określenie celu, skoro brakuje konsekwencji. (Ten błąd narusza również kryterium 3.2.4 Spójna identyfikacja).
– Ikony bez alternatyw tekstowych lub metadanych celu. Jeżeli gdziekolwiek używane są same grafiki jako interaktywne kontrolki, które nie mają w kodzie jasnego opisu (nazwy) – np. wspomniany „hamburger” menu bez aria-label – to ani użytkownik, ani narzędzie personalizujące nie rozpozna przeznaczenia takiego elementu. Konsekwencja: Osoba poznawczo zaburzona może nie odgadnąć, co kryje się pod trzema kreskami menu, co prowadzi do zagubienia na stronie.
– Nieuwzględnianie kryterium wcale. Ponieważ to poziom AAA, częstym „błędem” jest po prostu brak implementacji mechanizmów identyfikacji przeznaczenia. Strony mogą formalnie pomijać ten aspekt, ale wtedy nie wykorzystują szansy na ulepszenie dostępności dla tej grupy. Dla użytkowników oznacza to brak możliwości skorzystania z ewentualnych narzędzi zamieniających interfejs na bardziej zrozumiały.
1.4.1 Użycie koloru (poziom A)
Cel i istota: Informacja nie może być przekazywana wyłącznie przy pomocy koloru. Z perspektywy poznawczej jest to ważne z dwóch powodów: po pierwsze, osoby z zaburzeniami kognitywnymi mogą nie wychwycić subtelnych wskazówek kolorystycznych (np. że coś jest ważne, bo jest czerwone), a po drugie – jednokanałowe przekazywanie informacji utrudnia zrozumienie, jeśli ktoś nie kojarzy ustalonego kodu kolorów. Kryterium to tradycyjnie chroni głównie przed problemami osób niewidomych na barwy, ale również użytkownicy z problemami poznawczymi odnoszą korzyść z dodatkowych oznaczeń (np. etykiet tekstowych, symboli, wzorców) zamiast samego koloru.
Przykłady dobrych zastosowań:
– Wskazywanie błędów w formularzu nie tylko kolorem czerwonym, ale i komunikatem tekstowym lub ikoną. Np. pole obramowane na czerwono dodatkowo posiada komunikat „Proszę wprowadzić wartość” lub ikonę ostrzeżenia z odpowiednim alt-em. Osoba, która nie kojarzy czerwieni z błędem, zobaczy ikonę/tekst i zrozumie problem.
– Linki na stronie wyróżnione kolorem są jednocześnie np. podkreślone. Dzięki temu nawet jeśli ktoś nie zwróci uwagi na kolor, samo podkreślenie (powszechnie rozpoznawalna konwencja oznaczania linków) pozwoli rozpoznać element interaktywny.
– Wykresy i diagramy: użycie kolorów do oznaczenia serii danych plus dołączenie legendy z opisami lub etykiet bezpośrednio na wykresie. Jeżeli ktoś może nie skojarzyć, że np. zielony słupek to „Przychody”, to legenda z tekstem „🟩 Przychody” rozwiązuje problem.
Typowe błędy:
– Oznaczenie odnośników tylko kolorem (np. wszystkie linki w tekście są niebieskie, ale niepodkreślone). Użytkownik, który nie zauważy różnicy koloru (lub nie rozumie koncepcji, że odmienny kolor = link), nie zorientuje się, że coś jest klikalne.
– Pisanie instrukcji w stylu „Wypełnij pola oznaczone na niebiesko” – to oczywiste naruszenie, bo ktoś może nie dostrzec koloru albo nie zrozumieć, czemu pole jest niebieskie. Bez innego wskazania (np. gwiazdki „*”) taka instrukcja może zostać przeoczona.
– Interaktywne elementy (przyciski, kafelki) odróżniane tylko kolorem tła od elementów nieklikalnych. Jeśli np. sekcja ma tło szare, a przyciski tylko trochę ciemniejsze szare, to część użytkowników nie zorientuje się, że to w ogóle przycisk – zwłaszcza, jeżeli nie ma obrysu, ikony lub innego wskaźnika poza kolorem.
1.4.2 Kontrola odtwarzania dźwięku (poziom A)
Cel i istota: Jeżeli na stronie uruchamia się dźwięk (audio) trwający dłużej niż 3 sekundy, użytkownik musi mieć możliwość wyłączenia go, wstrzymania lub regulacji głośności niezależnie od ogólnego systemowego poziomu głośności. Dla użytkowników z niepełnosprawnościami poznawczymi i neurologicznymi jest to o tyle istotne, że niespodziewany lub niechciany dźwięk może całkowicie odwrócić ich uwagę, wywołać rozproszenie, a nawet reakcję lękową. Na przykład osoba z zaburzeniem koncentracji może nie być w stanie czytać tekstu, gdy w tle gra muzyka – dlatego powinna móc ją natychmiast wyłączyć[10]. Również osoby z nadwrażliwością słuchową (o podłożu neurologicznym) muszą mieć kontrolę nad dźwiękiem, by uniknąć dyskomfortu.
Przykłady dobrych zastosowań:
– Na stronie z automatycznie odtwarzanym filmem promocyjnym umieszczenie wyraźnego przycisku „✕ Wyłącz dźwięk” albo opcji pauzy. Dzięki temu jeśli użytkownik nie życzy sobie podkładu muzycznego, może go łatwo zatrzymać.
– Lepsze podejście: domyślnie nie włączać dźwięku automatycznie. Jeśli jednak nastąpi autoodtwarzanie (np. tło dźwiękowe), strona powinna wykrywać interakcje – np. po przewinięciu lub kliknięciu – i wtedy dopiero włączyć dźwięk, co daje użytkownikowi poczucie kontroli.
– Jeżeli treść ma zawartość audio (np. radio internetowe) i z definicji dźwięk jest kluczowy, dobrą praktyką jest umożliwienie dostosowania głośności z poziomu strony (suwak głośności). Osoba z nadwrażliwością dźwiękową może chcieć przyciszyć tylko tę stronę, a nie cały system – np. aby słyszeć lektora, ale ciszej niż domyślnie.
Typowe błędy:
– Auto-play audio bez jakiejkolwiek kontroli. Np. strona główna ma podkład muzyczny, który leci w kółko, a użytkownik nie ma żadnego przycisku do wyłączenia. To rażąco łamie kryterium – użytkownik może opuścić stronę w frustracji, bo nie jest w stanie skupić się na czytaniu jej treści przy niechcianym dźwięku.
– Ukrycie sterowania dźwiękiem w trudno dostępnym miejscu. Jeśli przycisk „stop” jest mały, słabo widoczny lub pojawia się dopiero po najechaniu myszką, wiele osób (zwłaszcza z problemami uwagi) może go nie znaleźć na czas. W tym czasie głośny dźwięk zdąży ich rozproszyć.
– Poleganie na systemowej kontroli głośności. Niektórzy deweloperzy mogą założyć: „Użytkownik zawsze może ściszyć głośniki”. Jest to błędne założenie – interakcja ze sprzętem lub systemem operacyjnym to dodatkowy krok, na który nie powinno się wymuszać, zwłaszcza że nie zawsze możliwe jest szybkie wyciszenie (np. użytkownik nie wie, który program gra dźwięk, albo używa urządzenia mobilnego bez szybkiego dostępu do regulacji).
1.4.3 Kontrast (minimum) (poziom AA)
Cel i istota: Tekst i istotne elementy graficzne muszą odznaczać się odpowiednim kontrastem w stosunku do tła – co najmniej 4.5:1 dla zwykłego tekstu i 3:1 dla dużego tekstu lub grafiki interfejsu. Choć wymóg kontrastu adresuje głównie potrzeby osób słabowidzących, jest on również ważny dla użytkowników z trudnościami poznawczymi. Słaby kontrast utrudnia odczytanie tekstu nawet osobom z pełnosprawnym wzrokiem w sensie medycznym, jeśli jednak mają one np. dysleksję czy zaburzenia koncentracji, niski kontrast dodatkowo pogarsza czytelność i wymaga większego wysiłku poznawczego do rozszyfrowania treści. Zapewnienie wyraźnego kontrastu poprawia ogólną czytelność strony dla wszystkich.
Przykłady dobrych zastosowań:
– Używanie ciemnego tekstu na jasnym tle lub vice versa w odpowiedniej proporcji. Np. ciemnoszary tekst (#333) na białym tle ma kontrast ok. 15:1, co przekracza wymagane minimum – jest czytelny dla osób z różnymi dysfunkcjami (w porównaniu np. do jasnoszarego tekstu #888 na białym tle, który miałby kontrast ~3:1 i byłby zbyt słabo widoczny).
– Testowanie kontrastu za pomocą narzędzi (wskaźników kontrastu) i poprawianie elementów, które nie spełniają normy. Deweloper zapewnia np., że tekst na kolorowych przyciskach w interfejsie (np. biały napis na niebieskim tle) ma współczynnik kontrastu > 4.5:1. Dzięki temu osoba, która ma trudności z rozczytywaniem tekstu (np. literki „zlewają się” jej z tłem), będzie miała większą szansę poprawnie odczytać zawartość.
– Zwrócenie uwagi nie tylko na kontrast tekstu, ale i istotnych ikon czy grafiki przekazującej treść. Jeśli np. infografika zawiera istotne podpisy kolorem, zadbanie by kontrast tych podpisów również spełniał minimum (3:1 dla dużego tekstu/grafiki).
Typowe błędy:
– Używanie jasnoszarego tekstu na białym tle z powodów estetycznych. Choć wygląda nowocześnie, wiele osób (zwłaszcza z problemami percepcji wzrokowej lub koncentracji) ledwo odróżnia tekst od tła. Takie praktyki designerskie rażąco obniżają dostępność.
– Kolorowe przyciski z białym tekstem bez sprawdzenia kontrastu. Np. żółty przycisk z białym napisem ma bardzo niski kontrast. Użytkownik może nawet nie zauważyć napisu na przycisku, przez co nie wie, co dany przycisk robi.
– Mały kontrast w stanie focus czy hover. Czasem projektanci stosują ledwo widoczne obramowanie lub zmianę koloru linku, którą trudno dostrzec. Jeśli np. zaznaczony link zmienia kolor z czarnego na granatowy na ciemnym tle – osoba może nie zorientować się, że link jest aktualnie wybrany/fokusowany.
1.4.4 Zmiana rozmiaru tekstu (poziom AA)
Cel i istota: Użytkownik powinien móc powiększyć tekst do 200% w stosunku do domyślnego rozmiaru bez użycia technologii wspomagających (czyli np. za pomocą wbudowanego skalowania przeglądarki) i bez utraty zawartości czy funkcjonalności strony. Dla osób z niepełnosprawnościami poznawczymi zapewnienie skalowalności tekstu jest ważne, bo wiele z nich może mieć współwystępujące problemy z widzeniem lub po prostu łatwiej im się czyta większą czcionkę. Nawet bez problemów ze wzrokiem większy tekst bywa mniej obciążający poznawczo – wymaga mniejszego wysiłku przy śledzeniu kształtu liter. Kluczowe jest też, aby po powiększeniu układ strony nadal był czytelny i nic się nie „zgubiło”.
Przykłady dobrych zastosowań:
– Tworzenie strony z zastosowaniem elastycznych jednostek (procenty, em, rem) zamiast sztywno w pikselach – tak, aby gdy użytkownik wybierze w przeglądarce „Powiększ tekst”, cała typografia proporcjonalnie się zwiększyła. Osoba z osłabionym wzrokiem lub nawet zaburzeniem uwagi może nastawić sobie większe litery, co ułatwi jej czytanie, a strona nadal będzie działać poprawnie (bez nakładania się elementów).
– Testowanie witryny przy 200% powiększeniu: czy wszystkie przyciski są widoczne, czy tekst się mieszcza w polach, czy nie trzeba przewijać poziomo. Np. w dobrej implementacji menu hamburgerowe może się pojawić wcześniej (przy mniejszym szerokości widoku) albo układ jednokolumnowy zastąpi wielokolumnowy, tak by tekst swobodnie zawijał się w wąskiej kolumnie.
– Użycie mechanizmów w CSS jak max-width zamiast stałej szerokości: jeśli kontener ma stałą szerokość np. 300px i w nim jest tekst, po dwukrotnym powiększeniu tekst może wyjść poza kontener; jeśli natomiast kontener ma max-width:300px i szerokość 100%, to przy powiększeniu tekst zwiększy wysokość kontenera bez przepełnienia.
Typowe błędy:
– Blokowanie możliwości skalowania strony – np. poprzez meta tag viewport z user-scalable=no w aplikacjach mobilnych. To całkowicie uniemożliwia spełnienie tego kryterium i jest szczególnie dotkliwe dla osób, które polegają na powiększaniu (bo np. nie radzą sobie z małym tekstem, a nie korzystają z dedykowanego czytnika powiększającego).
– Elementy o stałych wymiarach, które po powiększeniu powodują nałożenie tekstu lub pojawienie się suwaka poziomego. Przykład: sidebar o stałej szerokości 400px zawiera tekst w 14px. Po powiększeniu do 28px tekst się nie mieści i wychodzi poza sidebar lub generuje scroll w poziomie – to dezorientuje użytkownika i zmusza do przewijania na boki, co łamie zasadę prostoty odbioru treści.
– Tekst w formie grafiki (patrz 1.4.5), który nie skaluje się w ogóle przy użyciu narzędzi przeglądarki. Użytkownik powiększa stronę, a napisy w obrazkach pozostają małe i nieczytelne – to oczywiście problematyczne poznawczo (ktoś może nie odczytać kluczowych informacji zapisanych w obrazie).
1.4.5 Obrazy tekstu (poziom AA)
Cel i istota: Należy unikać przedstawiania tekstu w formie obrazu (grafiki) tam, gdzie możliwe jest użycie prawdziwego tekstu. Wyjątki są nieliczne (logo lub sytuacje, gdy obrazek tekstu jest niezbędny ze względów wizualnych). Dla osób z niepełnosprawnościami poznawczymi tekst osadzony w obrazkach jest problematyczny, bo nie można go łatwo powiększyć, zmienić czcionki ani dostosować odstępów między literami/słowami według potrzeb. Ponadto technologie wspomagające (np. czytniki ekranu czy narzędzia do zamiany tekstu na mowę używane przez osoby z dysleksją) nie odczytają tekstu w obrazie, chyba że zostanie dodany tekst alternatywny – ale alt to tylko substytut, który nie zawsze równa się pełnemu doświadczeniu, jakie daje prawdziwy tekst.
Przykłady dobrych zastosowań:
– Zamiast wstawiać na stronę skan dokumentu z tekstem, lepiej dostarczyć ten tekst jako HTML lub chociaż PDF z warstwą tekstową. Osoba z dysleksją może wtedy korzystać z ułatwień – np. zwiększyć interlinię w CSS, użyć własnej preferowanej czcionki, albo włączyć lektora tekstu. Skan jako obraz nie pozwala na żadne z tych usprawnień (dopóki nie zostanie rozpoznany przez OCR).
– Jeśli design wymaga konkretnego efektu typograficznego (nietypowa czcionka, stylizacja), należy użyć CSS (czyli osadzić font i zastosować go do rzeczywistego tekstu). Wtedy tekst nadal pozostaje tekstem – jest skalowalny, można go zaznaczyć, przeczytać maszynowo – a strona wizualnie spełnia projekt.
– Logo zawierające nazwę firmy jest jednym z niewielu usprawiedliwień obrazu tekstu (znak firmowy często jest grafiką). W takich przypadkach trzeba pamiętać o tekście alternatywnym opisującym treść logo (np. alt=„Nazwa Firmy – głowa słonia w logo”). Użytkownik z deficytem poznawczym, korzystający z czytnika, usłyszy nazwę firmy i skojarzy, gdzie się znajduje, zamiast pomijać ten element.
Typowe błędy:
– Wykorzystywanie obrazków z cytatami czy ważnymi informacjami bez podania ich w tekście. Przykład: infografika z kluczowymi danymi liczbowymi jest wstawiona jako obraz JPEG bez dodatkowego opisu tekstowego. Osoba, która ma trudności z czytaniem drobnego tekstu na tej infografice, nie może go powiększyć (bo rozmyje się pikselowo) ani przeczytać w trybie Reader.
– Przyciski nawigacyjne wykonane jako obrazy z tekstem (np. „Start”, „Dalej” jako plik PNG). Po pierwsze, jeśli alt takich obrazów jest niepoprawny lub brak, użytkownik korzystający z TTS nie dowie się, co to za przycisk. Po drugie – nie da się zmienić języka interfejsu automatycznie (tekst w obrazie nie podlega internacjonalizacji) ani dostosować wyglądu.
– Nakładanie napisów na tło w grafikach bez odpowiedniego kontrastu i bez alternatywy. Często spotykane – zdjęcie w tle, na nim slogan firmy. Jeśli to jest obraz bez alt, to wszyscy tracą: osoba słabowidząca/dyslektyk nie odczyta, bo kontrast może być słaby i nie powiększy sobie liter, a czytnik nic nie odczyta bo alt brak.
1.4.6 Kontrast (wzmocniony) (poziom AAA)
Cel i istota: Na poziomie AAA wymagania kontrastu są jeszcze surowsze – tekst i grafiki tekstowe muszą mieć kontrast co najmniej 7:1 (dla dużego tekstu 4.5:1). Celem jest zapewnienie maksymalnej czytelności dla osób ze znacznymi problemami wzroku oraz poznawczymi. Wysoki kontrast może pomóc np. osobom z zaburzeniami percepcji wzrokowej wynikającymi z urazów neurologicznych – jaskrawy kontrast ułatwia im odróżnianie liter, gdy normalny kontrast to za mało. Choć ten poziom nie jest zwykle wymagany prawnie, jego spełnienie dodatkowo poprawia komfort czytania dla wielu użytkowników, w tym seniorów z osłabionym wzrokiem i osób z niepełnosprawnościami poznawczymi, którym wyraźny tekst „mniej znika przed oczami”.
Przykłady dobrych zastosowań:
– Stosowanie czystej czerni na bieli (#000 na #FFF) dla drobnych tekstów lub istotnych informacji. Taki kontrast 21:1 znacznie przekracza minimum AAA i zapewnia maksymalną wyrazistość.
– Projektowanie tzw. wysokokontrastowej wersji kolorystycznej strony (opcja dostępności). Niektóre witryny oferują przełącznik trybu wysokiego kontrastu – kolory interfejsu zmieniają się wtedy na kombinacje jak żółty tekst na czarnym tle, co spełnia surowe wymagania kontrastowe. Osoba z problemami czytania może włączyć taki tryb, jeśli domyślny design jest dla niej zbyt „wyblakły”.
– Unikanie tekstu nakładanego na obrazy czy wzorzyste tła, bo tam trudno osiągnąć stały kontrast. Jeśli jednak to konieczne, to np. dodawanie półprzezroczystej warstwy pod tekstem, by zawsze był wyraźnie odcinający się od tła (ten zabieg pomaga w spełnieniu 7:1 w większości sytuacji).
Typowe błędy:
– Założenie, że skoro strona spełnia kontrast 4.5:1, to „wystarczy”. Dla niektórych użytkowników nawet ten kontrast może być niewystarczający – np. ciemnoszary tekst (#595959) na białym tle spełnia AA, ale nie AAA. Ktoś z pewnymi schorzeniami neurologicznymi oczu może nadal mieć trudność z takim poziomem kontrastu, więc nieosiągnięcie AAA to potencjalna bariera.
– Ignorowanie elementów nietekstowych przy dążeniu do wysokiego kontrastu. Np. strona przygotowała bardzo kontrastowy tekst, ale ikony lub wykresy mają wciąż tylko umiarkowany kontrast. W efekcie część informacji (zwłaszcza przekazywana graficznie) nie jest tak dostępna, jak mogłaby być, co może wpływać na zrozumiałość dla użytkownika (który np. nie zauważy ważnego piktogramu).
– Niezapewnienie możliwości zmiany stylu przez użytkownika. Jeśli strona ma wyjściowo kontrast minimalny (AA), ale mogłaby pozwolić użytkownikowi na przełączenie do stylu AAA, a tego nie robi, to jest to stracona szansa. Oczywiście brak dodatkowego trybu nie jest formalnie „błędem” wobec wymogu AAA (bo AAA jest dobrowolne), ale z punktu widzenia użytkowników – może być postrzegane jako brak udogodnienia.
1.4.7 Niska głośność lub bez dźwięków w tle (poziom AAA)
Cel i istota: Gdy strona zawiera nagranie audio z dialogiem lub ważnym przekazem słownym, wszelkie tło dźwiękowe (muzyka, efekty) nie powinno zagłuszać mowy – musi być na bardzo niskim poziomie (poniżej 20 dB względem mowy) lub całkowicie wyłączone. Choć to kryterium ma źródło w potrzebach osób z niepełnosprawnością słuchu, ma również znaczenie dla użytkowników z problemami poznawczymi i neurologicznymi: nadmiar bodźców dźwiękowych utrudnia skupienie i przetwarzanie informacji. Jeżeli lektorowi towarzyszy głośna muzyka, osoba z zaburzeniami uwagi albo z trudnościami w przetwarzaniu słuchowym (APD) może mieć kłopot ze zrozumieniem przekazu. Stonowanie lub brak tła dźwiękowego sprawia, że przekaz słowny jest wyraźniejszy i łatwiejszy do przyswojenia.
Przykłady dobrych zastosowań:
– Udostępnianie materiałów wideo z narracją, w których podkład muzyczny jest bardzo delikatny lub wręcz zrobienie pauzy w muzyce, gdy ktoś mówi. Na przykład w filmie instruktażowym, gdy lektor tłumaczy kroki, muzyka cichnie do minimum lub milknie – dzięki temu widz z ADHD nie zostanie rozproszony melodią, tylko skupi się na słowach.
– Gdy niezbędne jest zachowanie pewnego tła (np. dramatyczny efekt w trailerze, gdzie muzyka buduje nastrój), zapewnienie napisów lub transkrypcji do takiego audio. Osoba, która nie może wyłuskać słów z nałożonej muzyki, przeczyta je. W kontekście poznawczym – nawet ktoś słyszący może woleć doczytać dialog, niż trudzić się ze słuchaniem przy głośnym tle.
– Dostosowanie głośności tła w stosunku do mowy i przetestowanie na różnych poziomach systemowych. Twórca multimediów może np. zmierzyć, że ścieżka muzyczna jest ~20 dB cichsza od głosu lektora, co spełnia wymóg. W praktyce oznacza to, że melodia „schodzi na drugi plan” i nie konkuruje z treścią.
Typowe błędy:
– Filmy promocyjne z narratorem zagłuszanym przez muzykę. Często spotykane: lektor mówi o produkcie, ale dynamiczna muzyka w tle ma porwać emocje – niestety porywa też całą uwagę, przez co informacja umyka. Dla osób z trudnościami poznawczymi takie filmy są bezużyteczne, bo nie są w stanie jednocześnie przetwarzać słów i muzyki (a często nawet osoby bez takich trudności narzekają wtedy na zrozumiałość).
– Brak opcji wyciszenia tła przez użytkownika. Zakładając, że autor bardzo chce tę muzykę zachować, powinien przynajmniej dać możliwość jej wyłączenia lub zmniejszenia głośności. Błędem jest brak takiej kontroli – zmusza to użytkownika do słuchania, co narusza zarówno to kryterium, jak i zasadę autonomii użytkownika (wiążącą się z 1.4.2 i 2.2.2).
– Ignorowanie testów na różnych urządzeniach. Może zdarzyć się, że na profesjonalnych głośnikach tło brzmi cicho, ale na laptopie z podbitymi tonami niskimi – dudni i zagłusza głos. Niezapewnienie odpowiedniego miksu lub nieprzetestowanie w realnych warunkach może skutkować niespełnieniem intencji kryterium, nawet jeśli twórca myślał, że spełnił (np. „u mnie było dobrze słychać lektora, więc wszystko gra” – ale nie u każdego gra).
1.4.8 Prezentacja wizualna (poziom AAA)
Cel i istota: To kryterium zbiera szereg zaleceń dotyczących czytelnej prezentacji dłuższych bloków tekstu. Wymagania obejmują m.in.: maksymalną szerokość linii (~80 znaków w tekście ciągłym), interlinię co najmniej 1,5 × wysokość tekstu, odstęp między akapitami przynajmniej 2 × wysokość tekstu, możliwość zmiany kolorów tekstu/tła na co najmniej 7 kombinacji o wysokim kontraście, brak justowania do obu marginesów (tekst powinien być wyrównany do jednej strony, np. do lewej) itp. Wszystkie te wytyczne mają na celu zwiększenie czytelności i przyswajalności tekstu, co jest bezpośrednim wsparciem dla osób z dysleksją, z zaburzeniami koncentracji oraz innymi niepełnosprawnościami poznawczymi wpływającymi na zdolność czytania.
Przykłady dobrych zastosowań:
– Projektowanie szablonu strony tak, by tekst w kolumnie (np. artykuł) miał rozsądną szerokość – np. maksymalnie 800 px przy typowej czcionce, co daje ok. 75–80 znaków na linię. To zapobiega tzw. efektowi ściany tekstu, gdzie zbyt długa linia utrudnia przenoszenie wzroku do początku kolejnej linii (co często gubi osoby z dysleksją).
– Zastosowanie odpowiednich odstępów: CSS line-height: 1.5 dla tekstu akapitów oraz marginesów między nimi np. margin-bottom: 2em. Taki odstęp powoduje wizualne odseparowanie linii i akapitów, co bardzo pomaga osobom z dysleksją – litery i słowa nie „zlewają się”, łatwiej śledzić tekst wiersz po wierszu[4].
– Pozostawienie tekstu wyrównanego do lewej (dla języków LTR) zamiast justowania. Niejednakowe odstępy między wyrazami w tekście justowanym utrudniają czytanie osobom z trudnościami w czytaniu – mogą one mieć wrażenie nieregularności, co wybija z rytmu czytania. Tekst wyrównany do jednego marginesu (lewego) ma stałą przerwę między słowami, co ułatwia percepcję.
Typowe błędy:
– Prezentowanie długich tekstów w bardzo szerokich kolumnach (np. na pełnej szerokości dużego ekranu). Choć może to wypełnia przestrzeń, linie po 150–200 znaków są dla wielu osób męczące – trudno znaleźć początek kolejnego wiersza, łatwo się zgubić. Dla kogoś z ograniczoną pamięcią roboczą przeczytanie takiej linii i płynne przejście do następnej może być prawie niemożliwe.
– Ścieśnianie linii tekstu i akapitów ze względów estetycznych. Np. zastosowanie line-height: 1.0 (czyli brak dodatkowego odstępu) powoduje, że litery z kolejnych wierszy niemal na siebie nachodzą. Osobie z dysleksją linie mogą się zlewać, przez co traci ona miejsce, w którym czytała. Podobnie brak odstępu między akapitami utrudnia dostrzeżenie, gdzie kończy się myśl – ściana tekstu zdaje się jednolita.
– Justowanie tekstu na stronie internetowej. Choć w druku często justowanie wygląda elegancko, w sieci i w kontekście dostępności jest niewskazane. Nieregularne przerwy między słowami w justowanym tekście mogą sprawić, że np. osoba z afazją lub innym deficytem będzie interpretować te przerwy jako celowe (np. myślnik) lub po prostu będzie mieć kłopot z płynnym czytaniem, gdyż rytm zostaje zakłócony.
1.4.9 Obrazy tekstu (bez wyjątków) (poziom AAA)
Cel i istota: To kryterium wzmacnia poziom AA (1.4.5) – tekst nie powinien być przedstawiany jako obraz praktycznie w żadnym przypadku, łącznie z sytuacjami, gdzie na poziomie AA dopuszczono wyjątki (np. dla celów estetycznych). Na poziomie AAA jedyny wyjątek to sytuacja, gdy tekst w obrazie jest niezbędny do przekazania określonej informacji, której inaczej przekazać się nie da (co w praktyce niemal nie występuje). Z punktu widzenia osób z niepełnosprawnościami poznawczymi, AAA wymaga pełnego skupienia się na realnym tekście – co zapewnia maksymalną elastyczność: tekst zawsze można powiększyć, przeczytać automatycznie, zmienić kolory tła i czcionki itp. Jeśli spełni się to kryterium, użytkownik poznawczo słabszy nie natrafi na sytuację, że jakaś ważna informacja jest w formie, z którą jego narzędzia czy preferencje nie mogą nic zrobić.
Przykłady dobrych zastosowań:
– Całkowite wyeliminowanie grafik zawierających tekst ozdobny (np. cytat jako element dekoracyjny). Zamiast tego – implementacja cytatu w HTML/CSS (stylizacja odpowiednią czcionką, tłem). Osoba z dysfunkcją poznawczą może np. kliknąć taki cytat, by go odsłuchać, albo skopiować do tłumacza (jeśli w obcym języku) – przy obrazie nie mogłaby.
– Tworzenie wszystkich przycisków, menu nawigacyjnych i elementów interfejsu w postaci tekstu + CSS. Dzięki temu użytkownik może np. użyć własnego stylu wysokokontrastowego i wciąż widzieć zawartość przycisków. Gdyby były obrazkami, zmiana stylu mogłaby ich nie objąć.
– Zapewnienie, że nawet logo firmy ma dodany równoważnik tekstowy w widocznej formie (poza alt-em). Np. na stronie umieścić nazwę firmy obok logotypu. Dzięki temu ktoś, kto nie rozpozna logo (może to dotyczyć osób z agnozją wzrokową – nie rozpoznają obrazów), przeczyta nazwę obok i będzie wiedzieć, z jaką marką ma do czynienia.
Typowe błędy:
– Poleganie na argumentach estetycznych tam, gdzie AAA by tego nie uznało. Np. „Mamy unikalny krój pisma, więc tekst musi być obrazkiem, bo inaczej nie da się go tak wyświetlić” – to błędne myślenie, bo zawsze można osadzić font. Jeśli strona na AAA wciąż używa obrazów tekstu tam, gdzie mogłaby użyć czcionki, to nie spełnia kryterium.
– Publikowanie contentu (treści) jako obraz skanowany, nawet jeśli w celach archiwalnych. Często instytucje wrzucają skany starych dokumentów – na AAA to wciąż bariera. Należałoby dołączyć warstwę tekstową lub transkrypcję. Brak tego oznacza, że użytkownik np. z dysleksją nie będzie mógł skorzystać z narzędzi wspomagających (bo narzędzie „nie widzi” tekstu, tylko piksele).
– Przy tworzeniu mobilnych wersji stron – czasem używa się obrazów z tekstem, by np. łatwiej skalować elementy (np. w menu hamburgerowym grafiki z etykietą). Jeśli projektanci idą na skróty i używają grafik zamiast tekstu, zaprzepaszczają pełną dostępność. Nawet drobny link jak „Zadzwoń” w formie ikony z tekstem osadzonym w obrazie będzie mniej dostępny niż zwykły tekst z ikoną.
Zasada 2: Funkcjonalność (Operable)
(Użytkownik musi być w stanie operować interfejsem i nawigować – co obejmuje dostępność klawiaturową, odpowiedni czas na reakcje, unikanie elementów mogących wywołać napad padaczkowy, a także zapewnienie mechanizmów nawigacji i orientacji w serwisie. W przypadku osób z niepełnosprawnościami poznawczymi i neurologicznymi, ta zasada oznacza m.in. dostosowanie czasu na wykonanie zadań, eliminację niekontrolowanych bodźców (jak migotanie czy nagłe animacje) oraz przewidywalność i łatwość obsługi interfejsu.)
2.1.4 Jednoznakowe skróty klawiaturowe (poziom A)
Cel i istota: Jeśli strona/aplikacja internetowa definiuje własne skróty klawiaturowe aktywowane pojedynczym znakiem (np. same naciśnięcia liter bez żadnych modifierów), to powinna dać możliwość wyłączenia ich, zmiany na inne lub ograniczenia ich działania do sytuacji, gdy dany element ma fokus. Celem jest zapobieganie niezamierzonym aktywacjom funkcji przez przypadkowe naciśnięcia klawiszy. Osoby z pewnymi niepełnosprawnościami poznawczymi lub neurologicznymi mogą mieć tiki, mimowolne kliknięcia lub po prostu wciskać klawisze bez pełnej kontroli – pojedynczy skrót (np. „Q” kasujący wiadomość) mógłby wyrządzić szkody. Umożliwienie wyłączenia lub modyfikacji skrótów chroni przed takimi sytuacjami[11][12]. Ponadto użytkownicy korzystający z rozpoznawania mowy (co często dotyczy osób z niepełnosprawnościami ruchowymi, ale także np. niektórych osób z dysleksją, które dyktują zamiast pisać) mogą mimowolnie aktywować skróty – dlatego warto wymagać dodatkowych klawiszy (np. Ctrl+Alt+<klawisz> zamiast samego <klawisza>).
Przykłady dobrych zastosowań:
– Aplikacja webowa (np. poczta Gmail) oferująca w ustawieniach przełącznik „Włącz/wyłącz skróty klawiaturowe”. Użytkownik, który obawia się ich używać (bo np. wciska klawisze niechcący), może je po prostu wyłączyć.
– Implementacja skrótów tak, że działają tylko gdy określony element jest aktywny. Np. jeśli klawisz „L” lajkuje wpis w aplikacji społecznościowej, to niech działa tylko wtedy, gdy focus lub aktywne zaznaczenie jest na poście (czyli użytkownik świadomie wybrał dany post). Wciśnięcie „L” gdzie indziej (np. gdy fokus jest na menu lub nigdzie) – wtedy nic się nie dzieje. Chroni to przed globalnym działaniem skrótów.
– Dobra praktyka: użycie kombinacji klawiszy zamiast pojedynczych liter. Np. wymaganie wciśnięcia Alt+S zamiast samego „S” dla zapisania szkicu. W ten sposób zmniejsza się ryzyko przypadkowego trafienia w ten skrót (muszą być spełnione dwa świadome działania naraz).
Typowe błędy:
– Aplikacja przypisuje ważne akcje do pojedynczych liter bez żadnej opcji zmiany. Np. „D” = usuń element, „E” = edytuj. Użytkownik, który pomyli się podczas pisania komentarza (np. wciśnie D zamiast F), może nagle usunąć wpis – to nie tylko frustruje, ale dla osób z problemami poznawczymi może być bardzo dezorientujące („co się stało z moim tekstem?!”).
– Skróty aktywne globalnie na całej stronie. Jeśli np. klawisz „1” otwiera panel czatu niezależnie od tego, co robimy, to osoba, która wprowadza gdzieś dane liczbowe „123”, niechcący otworzy panel czatu przy wciśnięciu „1”. Potem próbując pisać dalej (2,3) może wprowadzać te cyfry nie tam gdzie trzeba. Taka nieprzewidywalność interfejsu szkodzi zwłaszcza osobom z zaburzeniami uwagi – potrafi wytrącić z czynności i zniechęcić do dalszej interakcji.
– Brak dokumentacji skrótów. Gdy strona stosuje jednoznakowe skróty, ale nigdzie o tym nie informuje, użytkownik może być kompletnie zbity z tropu dziwnymi zachowaniami. Np. wciska klawisze i nagle coś się otwiera/zamyka – osoba może pomyśleć, że to błąd lub wirus. Brak jasnej informacji to poważny błąd użyteczności i dostępności.
2.2.1 Dostosowanie czasu (poziom A)
Cel i istota: Użytkownik powinien mieć wystarczająco dużo czasu na przeczytanie treści i użycie interfejsu. Jeśli wprowadzono jakiekolwiek limity czasowe (czas na podjęcie akcji, wypełnienie formularza, itp.), muszą istnieć mechanizmy wydłużenia, wyłączenia lub co najmniej ostrzeżenia o zbliżającym się upływie czasu. Dla osób z niepełnosprawnościami poznawczymi jest to jedno z najważniejszych kryteriów – wiele z tych osób potrzebuje więcej czasu na zrozumienie treści i podjęcie decyzji. Presja czasu może sprawić, że użytkownik w ogóle zrezygnuje z zadania lub popełni błąd z pośpiechu[10]. Zapewnienie możliwości dostosowania czasu usuwa tę barierę – użytkownik może działać we własnym tempie, bez stresu i pomyłek.
Przykłady dobrych zastosowań:
– Formularz zamówienia internetowego domyślnie ma 10-minutowy limit (ze względów np. rezerwacji koszyka). Implementacja spełniająca WCAG to taka, gdzie przed upływem czasu wyświetla się komunikat z opcją „Przedłuż sesję o kolejne 10 minut”. Użytkownik z trudnościami w skupieniu, który wolno wypełnia formularz, może kliknąć przedłużenie i spokojnie dokończyć bez utraty danych.
– Serwisy e-learningowe dające testy z limitem czasu: dobra praktyka to umożliwić ubieganie się o wydłużony czas dla osób z dysleksją lub innymi trudnościami. W kontekście WCAG, jeśli limit jest wewnątrz strony (np. licznik JavaScript), powinna być opcja regulacji – np. tryb wolniejszy lub pauza.
– Wyłączenie niekoniecznych limitów. Jeśli np. strona informacyjna automatycznie odświeża się co 60 sekund (co może utrudnić czytanie dłuższego artykułu), warto to wyłączyć dla użytkownika lub dać przycisk „Wstrzymaj automatyczne odświeżanie”. Osoba czytająca wolno nie zostanie wtedy zaskoczona nagłym przeładowaniem strony.
Typowe błędy:
– Krótkie time-outy sesji bez ostrzeżenia. Np. bank wylogowuje po 2 minutach bezczynności i nie informuje wcześniej. Użytkownik (zwłaszcza z zaburzeniami pamięci krótkotrwałej) może stracić wprowadzane dane i nawet nie rozumieć, czemu został wylogowany („nic nie klikam, bo analizuję dane do przelewu, a tu nagle strona główna – co poszło nie tak?”).
– Brak możliwości wyłączenia limitu w sytuacji demonstracyjnej lub czytelniczej. Np. prezentacja slajdów zmienia się automatycznie co 15 sekund, bez pauzy. Osoba, która czyta wolniej slajd nr 1, nie zdąży przeczytać do końca zanim pojawi się slajd 2. Jeśli nie ma kontroli (pauza/wstecz), traci wątek i czuje frustrację.
– Formuła quizu „5 sekund na odpowiedź” bez możliwości zmiany. Dla użytkownika z deficytami poznawczymi 5 sekund to może być za mało nawet na przeczytanie pytania, a co dopiero przemyślenie odpowiedzi. Takie ustawienie z góry dyskwalifikuje tę osobę z udziału w teście. (Jeśli ograniczenie czasu jest istotą ćwiczenia – np. test na czas – to może podlegać wyjątkom, ale w większości interfejsów webowych limity nie są istotą samą w sobie.)
2.2.2 Pauza, zatrzymanie, ukrycie (poziom A)
Cel i istota: Jeżeli na stronie są jakiekolwiek ruchome, migające lub przewijające się informacje, które (a) uruchamiają się automatycznie, (b) trwają dłużej niż 5 sekund, i (c) są prezentowane równolegle z inną treścią, to musi istnieć mechanizm pozwalający użytkownikowi zatrzymać, wstrzymać lub ukryć te treści. Dotyczy to np. automatycznie przewijających się karuzel, scrollujących tekstów (marquee), animowanych banerów reklamowych itp. Dla osób poznawczo i neurologicznie wrażliwych ruch na stronie jest potężnym rozpraszaczem – może uniemożliwić skupienie na statycznej treści, a u niektórych wywołać objawy choroby symulacyjnej lub napad (np. w przypadku intensywnego migotania). Możliwość wyłączenia animacji daje tym osobom kontrolę nad tym bodźcem i pozwala skupić się na tym, co ważne.
Przykłady dobrych zastosowań:
– Baner rotacyjny ze zmieniającymi się co kilka sekund slajdami zaopatrzony w widoczne kontrolki: „Pauza ⏸️ / Odtwórz ⏵️” oraz strzałki „Dalej / Wstecz”. Dzięki temu użytkownik może w dowolnym momencie zatrzymać zmianę slajdów, gdy np. chce dłużej przeczytać aktualny. Osoba z ADHD nie będzie bombardowana wciąż nowym obrazkiem co chwila – zatrzyma i przeczyta spokojnie.
– Aktualności przewijane pionowo (tzw. news ticker) z przyciskiem „✕ Ukryj” albo możliwością zatrzymania przesuwania. W ten sposób użytkownik decyduje, czy chce widzieć przewijający się tekst. Ktoś, kto ma problemy z koncentracją, prawdopodobnie wyłączy taki ticker, by nie kusił wzroku ciągłym ruchem.
– Strona z animowanym tłem (np. spadające śnieżynki w CSS) powinna pozwolić na ich wyłączenie. Można np. dodać przełącznik „animowane tło: włącz/wyłącz”. Użytkownik z nadwrażliwością sensoryczną wyłączy je i uniknie potencjalnego dyskomfortu.
Typowe błędy:
– Automatyczna karuzela bez żadnej kontroli dla użytkownika. Taki komponent, często spotykany, zmienia obrazki i napisy co kilka sekund. Jeśli brak opcji wstrzymania, to nie tylko narusza 2.2.2, ale dla wielu jest bardzo frustrujące: ktoś czyta opis promocji, a tu myk – już inny slajd. Osoby z wolniejszym czytaniem mają zerową szansę na nadążenie.
– Wyskakujące okienka reklamowe typu „pop-up” lub „pop-under” animowane w rogu ekranu, których nie da się zamknąć (albo trzeba długo szukać przycisku zamknięcia). Taki stale migający element mocno rozprasza uwagę – użytkownik może nawet nie być w stanie dokończyć czytania artykułu, bo coś mruga w polu widzenia. Brak łatwej możliwości wyłączenia to błąd.
– Elementy przewijające się lub zmieniające kolor przy hoverze i brak możliwości wyłączenia tego. Np. jeśli menu nawigacji ma auto-przewijanie elementów po najechaniu i jest to główny sposób poruszania się, użytkownik z zaburzeniem przetwarzania sensorycznego może być przeciążony. Często taki efekt nie ma oddzielnego wyłączenia – bywa więc, że jedynym rozwiązaniem jest opuszczenie strony.
2.2.3 Bez ograniczeń czasowych (poziom AAA)
Cel i istota: Żadna funkcjonalność strony nie powinna wymuszać na użytkowniku działania w określonym z góry czasie. Innymi słowy, brak sztywnych limitów czasu w interakcji – użytkownik ma dowolnie dużo czasu na ukończenie czynności. To kryterium jest rozszerzeniem 2.2.1 i jest szczególnie przyjazne dla osób z poważniejszymi niepełnosprawnościami poznawczymi, które potrzebują znacznie więcej czasu niż przeciętni użytkownicy. Z perspektywy AAA idealnie byłoby, gdyby wszystkie czynności (poza czasem rzeczywistym, np. transmisja live) mogły być realizowane we własnym tempie, bez presji.
Przykłady dobrych zastosowań:
– Formularze i quizy tak skonstruowane, że nie ma żadnego timera – użytkownik może nawet zostawić komputer i wrócić za godzinę, a strona wciąż pozwoli dokończyć rozpoczętą czynność.
– Gry przeglądarkowe w trybie dla jednego gracza: wprowadzenie trybu „relaksacyjnego”, gdzie zagadki czy ruchy nie są ograniczone czasowo. Np. gra logiczna nie kończy partii po 5 minutach, tylko czeka na ruch gracza tak długo, jak zechce.
– Sesje logowania utrzymywane przez bardzo długi czas (o ile to bezpieczne), ewentualnie z mechanizmem podtrzymywania – tak by użytkownik nie został nagle wylogowany. Np. aplikacja do wypełniania wniosku urzędowego mogłaby nie mieć limitu bezczynności (AAA), zamiast standardowych 10 minut. Wówczas nawet jeśli osoba z ADHD rozproszy się na 15 minut, wracając nie utraci swojej pracy.
Typowe błędy:
– Projektowanie interfejsu, gdzie szybkość jest istotą mimo że mogłaby nie być. Np. strona automatycznie przełącza widoki po kilku sekundach (pokaz slajdów, tutorial), chociaż nic nie stoi na przeszkodzie, by użytkownik sam klikał „Dalej” w swoim tempie. Taki design z góry wyklucza spełnienie AAA i może denerwować tych, którzy nie nadążają.
– Zostawienie ograniczeń systemowych tam, gdzie można by je usunąć. Np. developer używa biblioteki, która ma domyślny timeout sesji 30 min – i nie myśli o tym, by dla trybu dostępności to zmienić.
– Zasłanianie się względami bezpieczeństwa w sytuacjach, które by pozwalały na długi czas. Często argumentuje się limity np. bezpieczeństwem (co jest zasadne w bankowości). Ale np. strona informacyjna czy sklep mógłby trzymać koszyk klienta dłużej niż parę minut. Niespełnienie AAA to nie błąd formalny, ale z punktu widzenia inkluzyjności – warto przemyśleć, czy każdy limit jest konieczny.
2.2.4 Przerywanie (poziom AAA)
Cel i istota: Użytkownik powinien mieć kontrolę nad przerwaniami – czyli nieoczekiwanymi komunikatami, powiadomieniami czy zmianami treści niezależnie od jego działań. Kryterium wymaga, by takie przerwania (np. komunikat o nowej wiadomości, wyskakujące okienko czatu, alert o promocji) mogły być odłożone lub wyłączone, z wyjątkiem sytuacji krytycznych (np. alarm o zagrożeniu bezpieczeństwa). Dla osób z zaburzeniami uwagi, pamięci czy ze spektrum autyzmu niespodziewane przerwanie potoku myślenia może być bardzo dezorientujące lub wywołać stres. Możliwość kontroli powiadomień pozwala im pracować w spokoju i zapoznać się z informacjami wtedy, gdy są na to gotowi.
Przykłady dobrych zastosowań:
– Aplikacja webowa (np. system pracy grupowej) oferuje ustawienia powiadomień: użytkownik może wyłączyć wyskakujące notyfikacje o nowych wiadomościach lub ustawić tryb „Nie przeszkadzać” na pewien czas. To spełnia kryterium – osoba z ADHD może włączyć tryb skupienia i nic nie będzie jej rozpraszać wyskakującymi okienkami.
– Sklep internetowy wyświetlający komunikat „Produkt dodano do koszyka” – zamiast modala, który musi być kliknięty, informacja pojawia się dyskretnie w rogu i nie zabiera fokusu. Użytkownik może ją zignorować na razie i kontynuować przeglądanie (komunikat nie przerywa mu czynności wymagając natychmiastowej uwagi).
– Strona z czatem na żywo, gdzie domywnie okienko czatu jest zminimalizowane, dopóki użytkownik sam nie kliknie „Pomoc”. Nawet jeśli konsultant inicjuje czat („Dzień dobry, czy pomóc?”), okienko miga tylko ikonką, ale nie wyskakuje na środek. Użytkownik decyduje, kiedy (i czy w ogóle) je otworzy.
Typowe błędy:
– Wyskakujące okienko newslettera pojawiające się po kilku sekundach na stronie i wymuszające interakcję (kliknij „X” by zamknąć). To typowy przykład przerwania – użytkownik czyta artykuł, nagle wyskakuje pop-up. Osoba z problemami poznawczymi może zupełnie stracić wątek. Brak możliwości ustawienia „nie pokazuj więcej” lub automatycznego blokowania takich pop-upów łamie ideę AAA.
– Ciągłe powiadomienia typu toast, których nie da się wyłączyć. Np. komunikator webowy co minutę pokazuje mały dymek „X jest teraz dostępny online” i nie ma opcji „wyłącz powiadomienia statusów”. Nawet jeśli to drobny komunikat, powtarzalny bodziec może mocno wybijać z rytmu osoby wrażliwe (ktoś czeka na wiadomość od kogoś innego i każdy dymek sprawia, że się rozprasza).
– Automatyczne przenoszenie fokusu lub scrollowanie strony w momencie przerwania. Przykład: strona sama przewija do góry, by pokazać pasek z informacją o ciasteczkach. Użytkownik, który czytał akapit w połowie strony, nagle zostaje przeniesiony – to dezorientuje. Takie działania zdecydowanie naruszają spokój interakcji.
2.2.5 Ponowne potwierdzenie autentyczności (poziom AAA)
Cel i istota: Jeśli sesja użytkownika wygasa (np. został automatycznie wylogowany) i aby kontynuować musi się ponownie zalogować, to po zalogowaniu powinien móc kontynuować bez utraty wcześniej wprowadzonych danych. To kryterium dotyczy głównie formularzy i procesów transakcyjnych – chroni użytkownika przed utratą pracy na skutek wygaśnięcia sesji. Dla osób z niepełnosprawnościami poznawczymi jest to kluczowe: często wykonują zadania wolniej, więc sesje mogą wygasać. Jeśli wszystko, co wpisali, przepada – może to być dla nich wręcz katastrofalne w skutkach (frustracja, zniechęcenie, stres). Zapewnienie, że dane zostaną zachowane, nawet gdy muszą się ponownie uwierzytelnić, pozwala im bez obaw podejmować się wypełniania dłuższych formularzy.
Przykłady dobrych zastosowań:
– Portal społecznościowy wylogowuje użytkownika po dłuższej bezczynności, ale gdy ten ponownie się loguje, zostaje przekierowany dokładnie do tego miejsca (i stanu), gdzie przerwał. Np. pisał komentarz – po logowaniu wraca do edycji tego komentarza, a tekst, który zdążył wpisać, nadal tam jest.
– Formularz wniosku wizowego online informuje: „Twoja sesja wygasła. Zaloguj się ponownie, aby kontynuować od miejsca, w którym skończyłeś.” Po ponownym logowaniu wszystkie wcześniej wprowadzone pola są odtworzone. Użytkownik nie musi zaczynać od zera, a jedynie kontynuować.
– Mechanizm autozapisu („draft”) przechowujący dane na bieżąco. Jeśli nawet sesja wygaśnie, po logowaniu system pyta: „Przywrócić ostatnio wprowadzone dane?” i tym sposobem odtwarza zawartość formularzy. Osoba z deficytami pamięci nie musi się martwić, że nie odtworzy z głowy wszystkiego, co już raz wpisała.
Typowe błędy:
– Całkowity reset po wylogowaniu. Np. użytkownik wypełnił 3/4 wniosku, przekroczył limit czasu, system go wylogował bez ostrzeżenia. Po ponownym logowaniu widzi pusty formularz. To ogromny problem – ktoś z trudnościami poznawczymi może w ogóle nie być w stanie drugi raz przejść przez skomplikowany proces (a nawet osoby bez niepełnosprawności często rezygnują w takiej sytuacji).
– Brak informacji o wygaśnięciu i ciche utracenie danych. Bywa, że sesja wygaśnie, strona niby pozwala dalej pisać, ale próba zapisania wyrzuca do strony logowania – a po niej dane znikają. To skrajnie nieprzyjazne: użytkownik nie miał szans wiedzieć, że pracuje „na próżno”.
– Niedopracowany mechanizm przywracania stanu. Np. tylko część danych się zachowała, a reszta znikła. Dla użytkownika to wciąż fatalne – musi odtwarzać brakujące fragmenty. W przypadku osób z zaburzeniami poznawczymi może być to zadanie ponad ich możliwości (np. zapamiętanie wszystkich sekcji, które były już zrobione).
2.2.6 Ostrzeżenie o limicie czasu (poziom AAA)
Cel i istota: Jeżeli przekroczenie limitu czasu w interakcji może skutkować utratą danych (np. wygaśnięcie sesji powoduje skasowanie rozgrzebanego wniosku), użytkownik musi być o tym fakcie poinformowany – z wyprzedzeniem i z podaniem, ile ma czasu bezczynności, zanim nastąpi utrata. Alternatywnie, dane muszą być zachowane przynajmniej przez 20 godzin bezczynności. Innymi słowy, kryterium to stawia wymóg, by użytkownik wiedział, że upływ czasu go „karze” utratą pracy, i by miał szansę temu zaradzić. Dla osób z niepełnosprawnościami poznawczymi jest to zabezpieczenie przed niespodziewanym zniknięciem efektów ich wysiłku. Nawet jeśli nie są w stanie szybko zareagować, sama wiedza o limicie pozwala im podjąć świadomą decyzję: „skupię się teraz i wyślę formularz w ciągu 5 minut” albo „skopiuję sobie to, co napisałem, na wypadek gdyby czas minął”.
Przykłady dobrych zastosowań:
– Aplikacja informuje: „Ze względów bezpieczeństwa zostaniesz wylogowany po 10 minutach braku aktywności. Pozostały czas: 2 minuty. [kliknij tu, by przedłużyć]”. Taki komunikat pojawia się np. modalnie 2 minuty przed końcem sesji. Użytkownik z problemami uwagi, widząc to, może zdać sobie sprawę „oj, długo myślałem nad odpowiedzią, zostało mi mało czasu” i kliknąć przedłużenie lub szybko zapisać postęp. Ta wiedza zapobiega utracie danych niespodziewanie[13].
– W formularzu wieloetapowym (np. rejestracja krok 1 z 4) strona podaje na początku: „Uwaga: po 15 minutach bezczynności serwer zakończy sesję i dane nie zostaną zapisane”. Taka informacja (najlepiej dobrze widoczna) pozwala użytkownikowi ocenić, czy da radę wypełnić formularz teraz, czy powinien przygotować sobie dane wcześniej. Osoba z niepełnosprawnością poznawczą może zdecydować: „15 minut to dla mnie za mało, poproszę kogoś o pomoc od razu” albo „Wypełnię, ale będę pamiętać, by nie robić przerwy”.
– System wypełniania testu online (np. egzaminu) ostrzega przed upływem czasu: zmienia kolor timera na czerwony i wyświetla komunikat dźwiękowy lub wizualny „pozostało 5 minut”. Chociaż samo istnienie limitu jest stresem, to ostrzeżenie chroni przed nagłym skończeniem testu bez szans na finalizację – daje możliwość jeszcze szybko przejrzeć odpowiedzi. Dla osoby z deficytami czasu może i tak zabraknąć, ale przynajmniej nie jest to szok z sekundy na sekundę.
Typowe błędy:
– Brak jakiejkolwiek informacji o tym, że czas mija i co się stanie po upływie. Nagle użytkownik traci dane i dopiero post factum dowiaduje się, że był limit. To oczywiście karygodne z punktu widzenia AAA (i bardzo frustrujące dla każdego).
– Zbyt późne ostrzeżenie lub mało czytelne. Jeśli komunikat pojawia się np. na 10 sekund przed końcem, to osoba z wolnym przetwarzaniem informacji może nawet go nie zdążyć przeczytać, a już będzie po limicie. Albo jeśli komunikat jest schowany (np. tylko zmiana koloru ikony gdzieś w rogu) – użytkownik może go nie zauważyć.
– Ostrzeżenie bez jasnej informacji, ile zostało czasu lub co zrobić. Np. komunikat „Twoja sesja wkrótce wygaśnie” – ale bez liczb, bez opcji. Taki komunikat może wręcz nasilić stres osoby z lękiem czy zaburzeniami – „wkrótce” to za sekundę czy za minutę? co mam zrobić?!”.
2.3.1 Trzy błyski lub wartości poniżej progu (poziom A)
Cel i istota: Treść nie może zawierać błysków o wysokiej intensywności (np. rozbłyskujących świateł, migających stroboskopowo elementów) częściej niż 3 razy na sekundę, chyba że jasność/kolory tych błysków są poniżej ustalonego progu, który uznano za bezpieczny. Najważniejszym powodem jest ochrona osób z padaczką fotogenną – intensywne, częste migotanie może wywołać u nich atak padaczki. Kryterium to ma charakter bezwzględny: dotyczy wszystkich użytkowników, bo incydent wywołania ataku może skończyć się tragicznie. W szerszym kontekście neurologicznym, nawet osoby bez padaczki mogą doznać silnego dyskomfortu, bólu głowy czy nudności od migającego ekranu. Dlatego unikanie częstego błyskania chroni ogółem zdrowie użytkowników.
Przykłady dobrych zastosowań:
– Unikanie umieszczania na stronach elementów typu „flashing GIF” – np. stara reklama „Wygrałeś milion!” z intensywnie migającym tłem. Zamiast tego reklama może używać statycznych obrazów lub płynnych przejść (fade), które nie osiągają progu niebezpiecznego błysku.
– Jeśli już pojawia się animacja z potencjałem migania, testuje się ją narzędziami (np. Photosensitive Epilepsy Analysis Tool – PEAT) w celu sprawdzenia, czy nie przekracza progu. Deweloper może np. stwierdzić: „nasze wideo zawiera szybkie przejścia scen, ale sprawdziliśmy – błyski mieszczą się w bezpiecznej normie (poniżej 3 Hz)[14]”.
– Dla bezpieczeństwa: ograniczenie liczby kontrastowych zmian na ekranie. Np. jeżeli projektant chce zrobić efekt „flicker” (migotania) tekstu, to lepiej niech to zrobi poniżej 3 Hz lub niech użyje innego efektu (np. płynna zmiana przezroczystości zamiast pełnego włącz/wyłącz).
Typowe błędy:
– Umieszczenie na stronie elementu, który miga ~10 razy na sekundę, np. neonowy napis „SALE!!!” zmieniający kolory bardzo szybko. To jawne naruszenie – taka rzecz może sprowokować atak u osób z padaczką. Oprócz zagrożenia zdrowia, właściciel strony naraża się też prawnie, bo jest to poważne nieprzestrzeganie standardów dostępności.
– Filmy wideo z efektami stroboskopowymi bez ostrzeżenia i bez filtrów. Np. błysk fleszy na koncertach – jeśli w serwisie wideo ktoś publikuje takie nagranie bez żadnego ostrzeżenia, widz z epilepsją może nie zdążyć zareagować (powinno się chociaż uprzedzić: „Uwaga, w filmie występują intensywne błyski”).
– Animowane tła lub elementy interfejsu generujące szybkie migotanie wskutek błędu. Czasem glitch lub konflikt stylów może sprawić, że jakiś element zacznie szybko migać (np. pokaz/ukryj w pętli). Jeśli strona tego nie wykryje, użytkownik może zostać narażony na niezamierzony efekt stroboskopowy – to również realne zagrożenie.
2.3.2 Trzy błyski (poziom AAA)
Cel i istota: Kryterium AAA idzie dalej – zakazuje całkowicie (bez oglądania się na progi) występowania więcej niż trzech błysków na dowolnej sekundzie. Nawet jeśli błyski są teoretycznie słabe, na poziomie AAA nie powinno być żadnych powtarzalnych migotań ponad 3 Hz. To zapewnia maksymalne bezpieczeństwo i komfort. Dla użytkowników z nadwrażliwością neurologiczną oznacza to brak szybkich migotających elementów w ogóle, co minimalizuje ryzyko nie tylko ataków padaczki, ale też np. migren wzrokowych czy ataków paniki wywołanych sensorycznym przeciążeniem.
Przykłady dobrych zastosowań:
– Wszelkie animacje i efekty są ograniczone do 3 błysków/sek. Np. jeśli ma być jakiś sygnał ostrzegawczy na ekranie, zamiast migać 5 razy na sekundę, zostaje ustawiony na 3 ×/sek. (albo i mniej). To wciąż przyciąga uwagę, ale mieści się w limicie AAA.
– W ramach testowania dostępności wyłącza się lub dostosowuje nawet te elementy, które były poniżej progu intensywności przy AA. Np. animacja gradientu co 0.5 sekundy – może spełnia AA, ale by spełnić AAA, design zostaje zmieniony na spokojniejszy (np. płynne przejście trwające 1 sekundę, czyli 1 Hz).
– Przy produkcji treści (video/games) twórcy zobowiązują się do zerowego migotania ponad 3 Hz. Np. platforma streamingowa może mieć wytyczną dla reklam: „nie akceptujemy reklam z flickerem >3 Hz”. To zapewnia, że nikt nie wrzuci migającego banera czy klipu.
Typowe błędy:
– Przy spełnianiu AA twórca stwierdza „próg intensywności jest dotrzymany, więc ok”, a ignoruje częstotliwość. Może być sytuacja, że coś miga powoli, ale intensywnie – niby AA spełnione (bo intensywność poniżej progu), ale AAA już nie (bo jednak >3 błysków). Jeżeli celem było AAA, to takie coś jest błędem.
– Założenie, że AAA nie trzeba nawet próbować, bo „to rzadko wymagane”. Strony aspirujące do najwyższej dostępności powinny dołożyć starań, by wyeliminować migotanie całkowicie. Błędem jest celowe utrzymywanie migotania, bo „i tak nikt tego nie sprawdza”. Może się zdarzyć, że klientem strony są np. osoby z epilepsją – dla nich AAA ma ogromne znaczenie.
– Pozostawienie drobnych elementów migoczących, bo wydają się niegroźne. Np. kursor tekstowy mruga typowo ~2x/s, co jest ok, ale ktoś styluje go na szybszy – i już może przekroczyć 3x/s. Albo animowany GIF dekoracyjny w stopce – niby drobnostka, ale jeśli miga 4–5 Hz, łamie AAA. Każdy element się liczy, nawet najmniejszy.
2.3.3 Animacja po interakcji (poziom AAA)
Cel i istota: Gdy interakcja użytkownika (np. kliknięcie, przewinięcie, najechanie kursorem) uruchamia animację ruchu, użytkownik musi mieć możliwość wyłączenia tej animacji, jeśli nie jest ona istotna dla funkcji lub przekazu. Przykładowo, przewijanie strony może uruchamiać efekt parallax (tło przesuwa się wolniej niż pierwszoplanowe obiekty), co dla części użytkowników jest estetyczne, ale dla innych – może wywołać zawroty głowy lub nudności (zaburzenia układu przedsionkowego)[15]. To kryterium pozwala takim osobom zrezygnować z wodotrysków animacyjnych. Dla użytkowników z niepełnosprawnościami neurologicznymi (np. choroba Ménière’a, wrażliwość przedsionkowa) oraz poznawczymi (łatwo rozpraszają ich ruchome ozdobniki) – jest to bardzo ważne, bo daje kontrolę nad bodźcami.
Przykłady dobrych zastosowań:
– Strona z animowanymi przejściami między sekcjami (elementy wjeżdżają, fade-ują itp.) oferuje ustawienie „Preferencje animacji: [ ] wyłącz animacje interfejsu”. Po zaznaczeniu, wszystkie te efekty zostają wyłączone – sekcje pojawiają się natychmiast bez płynnych ruchów. Osoba z nadwrażliwością (np. cierpiąca na chroniczne migreny) może dzięki temu korzystać ze strony bez wywoływania u siebie dolegliwości.
– Wykrywanie systemowej preferencji prefers-reduced-motion w CSS/JS: jeśli użytkownik systemowo zgłosił preferencję ograniczenia animacji (co często robią osoby wrażliwe na ruch), strona automatycznie pomija animacje po interakcjach. Np. zamiast płynnie przewijać do kotwicy, od razu skacze do sekcji; zamiast animować rozwijanie menu – natychmiast je pokazuje.
– Aplikacja webowa mająca animowane tło podczas scrollowania (np. chmury przesuwające się) zapewnia przycisk „✕ Disable Background Motion”. Po jego kliknięciu chmury zatrzymują się. Użytkownik ze zdiagnozowanym vertigo (zawroty głowy) może od razu to wcisnąć i spokojnie czytać zawartość bez dekoncentrujących ruchów.
Typowe błędy:
– Ignorowanie sygnału od użytkownika. Jeśli ktoś ma w systemie ustawione „redukcja ruchu: włączona”, a strona i tak serwuje pełne animacje, to nie spełnia tego kryterium. To powszechne zaniedbanie – deweloperzy czasem nie implementują obsługi tego mediówapytania CSS.
– Animacje „dla bajeru” bez wyłącznika. Np. galeria zdjęć, gdzie po kliknięciu następnego obrazka robi się fantazyjna animacja 3D. Brak prostej wersji (albo choćby możliwości przeskoczenia animacji) oznacza, że ktoś może poczuć dyskomfort. Ktoś z chorobą lokomocyjną może mieć wrażenie ruchu i dostać nudności.
– Rozproszenie uwagi użytkownika animacjami, których nie można powstrzymać. Np. interaktywny wykres: po najechaniu słupki „skaczą”. Osoba z ADHD może utknąć bawiąc się animacją zamiast analizować dane – w efekcie cel (zrozumienie wykresu) nie zostaje osiągnięty. Bez opcji wyłączenia ruchu, taki wykres staje się dla niej przeszkodą poznawczą.
2.4.2 Tytuł strony (poziom A)
Cel i istota: Każda strona powinna mieć zdefiniowany opisowy tytuł (w elemencie <title>), który informuje użytkownika o zawartości lub celu danej strony. Dla osób z niepełnosprawnościami poznawczymi tytuł strony pełni rolę punktu odniesienia – ułatwia orientację, przypomina kontekst i pozwala szybko zidentyfikować, gdzie się znajdują[16]. Na przykład osoba z zaburzeniami pamięci krótkotrwałej może zapomnieć, że otworzyła konkretną podstronę; patrząc na tytuł karty przeglądarki, od razu widzi np. „Mój profil – Ustawienia konta” i wie, w jakiej sekcji jest. Tytuły są także kluczowe przy nawigacji między kartami/oknami – muszą jasno komunikować zawartość, by użytkownik nie błądził.
Przykłady dobrych zastosowań:
– Strony mające schemat nazywania tytułów: najpierw unikalna nazwa zawartości, potem nazwa serwisu. Np. tytuł „Koszyk – Sklep24” jest lepszy niż tylko „Sklep24”, bo użytkownik od razu wie, że ta karta to koszyk zakupów. Osobie, która może się pogubić przy wielu otwartych kartach, takie jednoznaczne tytuły ułatwiają życie.
– Aktualizacja tytułu strony dynamicznie, gdy zmienia się kontekst. Np. aplikacja webowa zmienia <title> na „(2 nowe wiadomości) Czatuj ze Znajomym – KomunikatorX”, co informuje wprost o nowej aktywności. Osoba rozproszona bodźcami może nie zauważyć cichych powiadomień, ale zerkając na tytuł zobaczy liczbę nowych wiadomości i skupi się, jeśli to ważne.
– Tytuł odzwierciedlający pytanie lub zadanie. Np. na stronie banku tytuł „Krok 2 z 3: Dane adresowe – Zakładanie konta” komunikuje osobie z trudnościami poznawczymi zarówno co to za strona (formularz rejestracji), jak i gdzie jest w procesie (krok 2 z 3). To pomaga zmniejszyć niepokój i zrozumieć strukturę procesu.
Typowe błędy:
– Brak ustawionego tytułu (np. pozostawione „Untitled Page” lub nazwa szablonu). Ktoś, kto ma kilkanaście kart i widzi dwie zatytułowane „Untitled” – nie ma pojęcia, która jest którą. Musi każdą otworzyć, co jest obciążające poznawczo.
– Zbyt ogólny lub mylący tytuł. Np. na każdej podstronie serwisu tytuł to tylko „Portal Informacyjny” – żadnych konkretów. Osoba musi zgadywać po treści na stronie, gdzie trafiła. Albo tytuł „FAQ” w sekcji wsparcia klienta – lepiej „Pomoc – Najczęstsze pytania”, bo sam skrót FAQ nie dla każdego jest zrozumiały od razu.
– Za długie tytuły upakowane informacjami. Jeśli próbujemy wsadzić zbyt wiele (np. „Portal Informacyjny XYZ – Strona główna – Witamy na portalu informacyjnym XYZ, najświeższe wiadomości z kraju”), to w przeglądarce i tak utnie, a użytkownika poznawczo może to przytłoczyć. Lepiej zwięźle i na temat („XYZ Portal – Strona główna”).
2.4.3 Kolejność fokusu (poziom A)
Cel i istota: Nawigacja klawiaturą (fokusem) powinna przebiegać w logicznej kolejności, odzwierciedlającej znaczenie i układ treści. Gdy użytkownik używa np. klawisza Tab, fokus elementów interaktywnych powinien przechodzić w sposób przewidywalny (np. od nagłówka do kolejnych linków w treści, potem do stopki). Osoby z niepełnosprawnościami poznawczymi, zwłaszcza te korzystające z klawiatury (np. z powodu drżenia rąk, co też bywa efektem uszkodzeń neurologicznych), skorzystają na tym, że fokus nie „skacze” chaotycznie. Spójny, intuicyjny porządek ułatwia zrozumienie struktury strony bez konieczności patrzenia myszką po całym ekranie.
Przykłady dobrych zastosowań:
– Ustawienie kolejności focusem zgodnie z wizualnym układem: np. najpierw logo (jeśli klikalne), potem menu główne od lewej do prawej, potem „skip link” do treści, następnie główny przycisk „Dowiedz się więcej” na banerze, itd. Osoba idąc Tabem czuje, że przemieszcza się po stronie jak wzrokiem od góry do dołu – to logiczne i mniej obciążające.
– Gdy element jest spoza naturalnego układu (np. wysuwane menu mobilne umieszczone na końcu kodu HTML), zastosowanie atrybutów tabindex lub manipulowanie DOM tak, by pojawił się we właściwym miejscu sekwencji. Np. na małych ekranach menu może być ukryte, ale i tak gdy się otworzy, fokus powinien do niego przejść płynnie (nie zmuszając do prze-Tabowania przez nieistotne elementy).
– Testowanie kolejności: deweloper przechodzi przez stronę Tabem i sprawdza, czy fokus nie wędruje w dziwny sposób (np. nie wraca nagle do góry do banera po przejściu do sekcji artykułów). Naprawia ewentualne problemy dodając np. tabindex=”0″ we fragmentach generowanych dynamicznie tam, gdzie brakuje naturalnie fokusowalnych elementów.
Typowe błędy:
– Nielogiczna kolejność focusa spowodowana layoutem CSS. Np. w kodzie HTML najpierw jest menu boczne, a potem treść główna, ale CSS wyświetla menu po lewej a treść obok. Fokus jednak pójdzie najpierw przez linki menu, potem dopiero do początku treści – co może być okej, ale jeśli wizualnie treść zaczyna się z lewej (a menu z prawej), to kolejność Tab jest odwrotna do percepcji. Użytkownik może się pogubić („czemu po nagłówku od razu skacze mi gdzieś w prawo?”).
– Brak tabindex tam, gdzie potrzebny. Np. wyskakujące okno modalne: pojawia się na środku ekranu, ale w kodzie jest na końcu strony. Jeśli nie przechwycimy fokusu do niego, użytkownik Tabem będzie dalej skakał pod spodem modala, nie wiedząc gdzie jest (focus jest za modalem, niewidoczny). To może zdezorientować każdego, a co dopiero osobę z ograniczoną zdolnością koncentracji – widzi okno, ale klawiatura jakby „nie działa” na nie.
– Elementy, które nigdy nie dostają fokusu, bo są pominięte w kolejności. Np. customowy kontrolka (jak odtwarzacz audio) nie jest zbudowany z natywnych elementów fokusowalnych i zapomniano dać mu tabindex. Użytkownik klawiatury (być może z powodów poznawczych, bo woli tabbing niż mysz) ominie go całkowicie – nie ma jak sterować odtwarzaniem. W konsekwencji pewna funkcja strony staje się dla niego niedostępna.
2.4.4 Cel łącza (w kontekście) (poziom A)
Cel i istota: Linki (hiperłącza) powinny być opisane w taki sposób, aby cel ich prowadzenia był zrozumiały z tekstu linku albo z kontekstu, w jakim się pojawiają. Dla użytkowników z niepełnosprawnością poznawczą jasne i opisowe linki są niezwykle pomocne – pozwalają szybko zdecydować, czy chcą w nie kliknąć, bez zgadywania. Jednocześnie unika się sytuacji, gdzie link brzmi ogólnikowo („kliknij tutaj”), bo to zmusza do zapamiętania kontekstu. Osoby z problemami pamięci lub uwagi mogą nie połączyć, że trzy linie wyżej było napisane, dokąd prowadzi ten „kliknij tutaj”. Opisowy link likwiduje tę niepewność.
Przykłady dobrych zastosowań:
– Zamiast linku o treści „Więcej” albo „Dowiedz się więcej”, stosowanie fragmentu mówiącego co konkretnie: np. „Więcej o programie rehabilitacji”. Taki link wyraźnie wskazuje, czego dotyczy (program rehabilitacji), więc nawet wyrwany z kontekstu jest sensowny. Osoba przeglądająca pobieżnie stronę (co czyni wielu użytkowników z dysfunkcjami uwagi) natrafi na ten link i od razu wie, czego się spodziewać po kliknięciu[17].
– Dodawanie do ogólnych linków kontekstowego wyjaśnienia tuż obok. Jeśli z jakichś względów musimy dać link „[więcej]”, to można tuż przed nim napisać np. krótkie streszczenie lub dołączyć go do zdania: „Poznaj szczegóły oferty [Więcej informacji]”. Czytając na głos: „Poznaj szczegóły oferty – więcej informacji”, co już ma sens.
– Atrybut title lub opis ARIA (tylko jako uzupełnienie!). Jeśli link jest obrazkiem (np. ikona drukarki – link „drukuj”), to atrybut alt=”Drukuj tę stronę” zapewni opis celu. Osoba z nawet umiarkowaną zdolnością pojmowania zobaczy ikonkę drukarki + dymek z napisem Drukuj tę stronę (przy najechaniu) i będzie wiedzieć, co to znaczy.
Typowe błędy:
– Linki typu „czytaj dalej”, „kliknij tutaj”, „więcej”. Osoba z zaburzeniem poznawczym może nie pamiętać, więcej czego? Zwłaszcza gdy jest lista kilku artykułów i pod każdym „Czytaj więcej…”, to po jakimś czasie może stracić rozeznanie, który link dotyczył której wiadomości. (To kryterium dopuszcza, że z kontekstu wynika cel, np. nagłówek artykułu tuż przed linkiem – ale to wymaga sprawnego kojarzenia dwóch elementów. Dla pełnej dostępności lepiej, by link sam w sobie był jasny.)
– Zbyt długie linki – całe zdania lub akapity jako hiperłącze. To może przytłaczać i wprowadzać chaos. Ktoś ze spektrum autyzmu może nie lubić „przypadkowego” klikania w duży blok tekstu i w efekcie będzie unikał klikania tam, gdzie nie jest pewny co jest linkiem. Linki powinny być skondensowane do kluczowej frazy, a nie losowo obejmować pół akapitu.
– Linki różniące się kontekstem, ale mające ten sam tekst linku. Np. w tabeli akcji: przy każdym produkcie jest link „Otwórz”. Technicznie user w kontekście wie, że to otworzy dany produkt. Ale ktoś korzystający z czytnika ekranu lub mechanizmu wyciągającego linki może widzieć listę linków: „Otwórz, Otwórz, Otwórz, …” – nic to nie mówi. Dla kogoś z deficytem poznawczym taka powtarzalność bez informacji może być bardzo myląca. Lepiej unikalnie: „Otwórz produkt A”, „Otwórz produkt B” (np. za pomocą ukrytego tekstu w linku tylko dla SR).
2.4.5 Wiele dróg (poziom AA)
Cel i istota: Użytkownik powinien mieć więcej niż jeden sposób na zlokalizowanie określonej strony lub treści w serwisie, zwłaszcza jeśli jest to strona użytku publicznego. Oznacza to np. udostępnienie wyszukiwarki, spisu treści, mapy strony czy alternatywnych menu. Dla osób z niepełnosprawnościami poznawczymi zapewnienie kilku dróg znaczy zwiększenie szans na znalezienie informacji w sposób dopasowany do ich możliwości. Jeden użytkownik łatwiej poruszy się przez wyszukiwarkę (bo formułuje pytanie), inny woli skorzystać z mapy strony (widzi strukturę w całości, co bywa lepsze dla wzrokowców z pamięcią fotograficzną). Bez wielu dróg taka osoba może utknąć, nie wiedząc jak dotrzeć do celu.
Przykłady dobrych zastosowań:
– Pole wyszukiwania na stronie, które pozwala wpisać słowo kluczowe. Osoba, która ma trudności z nawigacją hierarchiczną (np. zrozumieniem kategorii w menu), może po prostu wpisać, czego szuka. Np. zamiast drążyć menu „Produkty -> Elektronika -> Aparaty”, wpisuje „Aparat” i otrzymuje bezpośredni link.
– Mapa strony (HTML), czyli jedna strona ze spisem wszystkich głównych sekcji i podstron serwisu. Ktoś, kto woli obraz całości, znajdzie tam od razu interesujący go dział. Np. użytkownik z zaburzeniem kognitywnym, który gubi się w zagnieżdżonych menu, otwiera mapę i widzi prostą listę: „O nas, Usługi, Kontakt, FAQ…” – łatwiej mu wybrać.
– Funkcjonalność okruszków (breadcrumbs) – pokazuje w której sekcji jesteśmy i pozwala kliknąć wyżej. To pośrednio wspiera „wiele dróg”, bo user może np. wrócić do kategorii nadrzędnej i stamtąd może pójść inną podkategorią. Dla orientacji poznawczej breadcrumbs bardzo pomagają (wiedzą, gdzie się jest w strukturze).
Typowe błędy:
– Dostęp tylko jedną ścieżką. Np. ważna informacja jest tylko poprzez link z aktualności na stronie głównej, a potem znika – i nie ma np. archiwum aktualności ani wyszukiwarki. Użytkownik, który nie zobaczył tego na głównej, nie ma już możliwości znaleźć (musi np. znać bezpośredni URL). To frustrujące, a dla osób z zaburzeniami może być wręcz niemożliwe do rozwiązania (nie wpadną na trick z URL).
– Ukrywanie alternatywnych dróg. Np. jest wyszukiwarka, ale tylko w stopce drobnym druczkiem – wiele osób jej nie zauważy. Albo mapa strony istnieje, ale link do niej jest gdzieś głęboko pochowany. To praktycznie równoważne z brakiem – bo użytkownik mający problemy z kognicją raczej nie wykombinuje, by jej szukać, jeśli nie jest widoczna.
– Zbyt skomplikowana alternatywa. Np. mapa strony generowana dynamicznie w formie drzewa, gdzie trzeba klikać plusiki by rozwinąć sekcje. Osoba z deficytami może nie poradzić sobie z tak interaktywnym spisem (a plusem mapy strony jest zazwyczaj statyczny, pełny spis na jednej stronie). Lepiej zrobić prostszą, linearną listę.
2.4.6 Nagłówki i etykiety (poziom AA)
Cel i istota: Nagłówki sekcji oraz etykiety pól/formularzy powinny być opisowe i jednoznacznie wskazywać na temat sekcji lub przeznaczenie pola. Dla użytkowników z niepełnosprawnościami poznawczymi znacząco ułatwia to zrozumienie treści i interfejsu – czytając nagłówek, mogą przewidzieć, co znajdzie się w danej części strony; czytając etykietę pola, wiedzą, jakiej informacji oczekuje. Opisowe nagłówki/etykiety także wspierają pamięć: ktoś może wrócić do sekcji „Specyfikacja techniczna” w opisie produktu, bo zapamięta tytuł tej sekcji, zamiast szukać „gdzie były te parametry…”.
Przykłady dobrych zastosowań:
– Zamiast nagłówka „Informacje”, stosuje się bardziej konkretny typu „Informacje o produkcie: wymiary i waga”. Z takiego nagłówka od razu wynika, co będzie dalej (wymiary, waga produktu). Osoba z trudnością w wyciąganiu wniosków nie musi się domyślać – nagłówek ją prowadzi.
– Etykiety formularzy zawierające kluczowe słowa, nie same skróty. Np. nie „Nr dok.”, tylko „Numer dokumentu tożsamości (np. PESEL)”. Osoba może nie rozszyfrować skrótu „dok.” lub pomylić go z czymś innym. Pełna etykieta zapobiega takiemu nieporozumieniu.
– Nagłówki jako pytania – czasem to dobry zabieg. Np. zamiast „Dostawa i płatność” jako nagłówek sekcji w checkout, można dać „Jak chcesz otrzymać i opłacić zamówienie?”. Taki styl wprost zadaje pytanie użytkownikowi – osobie z deficytem poznawczym może być łatwiej, bo to brzmi jak instrukcja do wykonania (wybierz dostawę i opłać). Podobnie w FAQ – pytania jako nagłówki pomagają szybciej znaleźć nurtujące kwestie.
Typowe błędy:
– Nagłówki zbyt ogólne lub metaforyczne. Np. sekcja nazwana „Nasza filozofia” – może to i stylowe, ale ktoś może nie zrozumieć, że chodzi o misję firmy czy wartości (a to pewnie autor ma na myśli). Lepiej bardziej dosłownie: „Misja i wartości firmy”.
– Brak etykiet (pole polega tylko na placeholderze albo kontekście). Osoba z pamięcią operacyjną na słabym poziomie może kliknąć w pole, placeholder zniknie i już nie pamięta, co tam było w środku napisane – i jest zagubiona. Zawsze powinna być trwała etykieta poza polem.
– Etykiety niejasne skrótowce: np. pole podpisane „Nr” – numer czego? (Może numer domu? numer telefonu? – dopiero z kontekstu user wydedukuje). Dla jasności powinno być np. „Nr domu” albo „Numer zamówienia”. Ktoś z deficytem poznawczym może nie umieć powiązać lakonicznego „Nr” z faktyczną oczekiwaną daną.
– Użycie żargonu lub trudnych słów w etykietach. Np. „Atrybut preferencji” – przeciętny człowiek (a tym bardziej z dysfunkcją poznawczą) nie zrozumie, o co chodzi. Trzeba pisać prostym językiem: np. „Twoje preferencje”.
2.4.7 Widoczny fokus (poziom AA)
Cel i istota: Gdy element interaktywny (link, przycisk, pole formularza itp.) zyskuje fokus klawiatury lub jest zaznaczony, powinien być wyraźnie widoczny poprzez zmianę stylu. Standardowo przeglądarki dodają obrys (np. niebieską poświatę lub kreskowaną ramkę) – nie wolno tego usuwać bez zastąpienia lepszym wskaźnikiem. Dla użytkowników z niepełnosprawnością poznawczą, którzy korzystają z klawiatury (lub urządzeń opartych o klawiaturę, w tym np. przełączników czy technologii head-pointer), widoczność fokusu jest kluczowa: pozwala śledzić, gdzie aktualnie się znajdują na stronie[16]. Bez tego łatwo stracić kontekst i nacisnąć nie ten przycisk, co trzeba.
Przykłady dobrych zastosowań:
– Strona zachowuje natywne oznaczenie fokusu (np. niebieski obrys na przycisku w Chrome). Osoba tabulująca przez linki od razu widzi, który link jest aktualnie wybrany – nie zgubi się.
– Jeszcze lepsze: dostosowany, ale wyraźny styl fokusu. Np. po fokusie element jest podkreślony grubą linią, zmienia kolor tła lub ma wyraźną poświatę 4px w kontrastowym kolorze. Taki wyróżnik jest często nawet lepiej widoczny niż domyślny styl i pomaga osobom z ograniczonym polem uwagi szybko zlokalizować kursor klawiatury na ekranie.
– Widoczność fokusu dotyczy też aktywnych elementów formularza – np. fokus na polu tekstowym zmienia jego obramowanie na wyraźny kolor. Użytkownik z dysleksją, wypełniając formularz, dzięki temu łatwo upewni się, że pisze w polu „Email”, a nie w innym (bo widzi ramkę wokół tego pola).
Typowe błędy:
– Wyłączenie stylu fokusu dla linków i przycisków (częsty błąd CSS: :focus {outline: none;} bez zastępstwa). To prowadzi do sytuacji, gdzie tabulując nie widać absolutnie, który element jest obecnie aktywny. Osoba musi zgadywać lub liczyć naciśnięcia Tab – co jest praktycznie niemożliwe dla kogoś z problemami koncentracji czy pamięci roboczej.
– Zbyt słabo widoczny focus. Np. styl jest, ale bardzo subtelny – np. lekko jaśniejszy odcień obramowania, który trudno odróżnić. Użytkownik może go wcale nie zauważyć, zwłaszcza jeśli ma też słabszy wzrok czy po prostu monitor o kiepskim kontraście. To nie spełnia intencji kryterium (focus ma być wyraźny).
– Niewidoczny focus na elementach kluczowych, bo są nieskupialne. Np. w customowej nawigacji <div>y robią za linki i reagują na klik, ale nie mają tabindex – klawiaturą da się je wybrać tylko skryptowo, a styl focusa nawet nie został przewidziany. W efekcie user niby może Tabem tam wejść (jeśli skrypt przenosi focus), ale nie ma żadnej wizualnej zmiany. Takie niekonsekwencje dezorientują – użytkownik nie wie, czy coś jest fokusem, czy nie.
2.4.8 Lokalizacja (poziom AAA)
Cel i istota: Strona powinna zapewnić mechanizm informujący użytkownika o jego aktualnej lokalizacji w strukturze serwisu. Najczęściej realizuje się to przez tzw. okruszki (ścieżkę nawigacyjną) lub wyraźne wyróżnienie aktywnej pozycji w menu. Dla osób z niepełnosprawnościami poznawczymi orientacja w serwisie bywa wyzwaniem – mogą nie pamiętać, jak się tu dostali, ani co było wcześniej. Okruszki typu „Strona główna > Kategoria > Podkategoria > Ta strona” dają natychmiastowy kontekst i pozwalają zrozumieć, gdzie się jest. To trochę jak mapa – osoba z zaburzeniami przetwarzania informacji skorzysta na tym, bo nie musi dedukować hierarchii sama, jest ona podana.
Przykłady dobrych zastosowań:
– Na podstronie z artykułem o WCAG w serwisie rządowym, widoczny jest pasek: „Dostępność cyfrowa > WCAG > Artykuły eksperckie > Niniejszy artykuł”. Dzięki temu użytkownik wie, że jest w sekcji „Artykuły eksperckie” w dziale „WCAG”. Gdy skończy, może kliknąć „WCAG”, by wrócić do listy artykułów w tym dziale, albo „Dostępność cyfrowa”, by wrócić do głównego działu. Ta możliwość zmiany kierunku nawigacji jest cenna – nie jest zmuszony do korzystania tylko z „Wstecz” przeglądarki (którego może nie rozumieć zbyt dobrze).
– Menu okruszkowe nie tylko tekstowe, ale też z linkami do poprzednich poziomów. To spełnia też kryterium „wiele dróg”. Dla nas liczy się, że pokazuje lokalizację. Osoba z problemami pamięci może spojrzeć i np. przypomnieć sobie: „aha, jestem w podkategorii Telefony, która jest w Elektronice, mogę teraz sprawdzić co jest jeszcze w Elektronice”.
– Alternatywnie lub uzupełniająco: wyróżnienie aktywnej pozycji w nawigacji. Np. w drzewku kategorii w bocznym menu jest pogrubiona bieżąca kategoria, a rodzicielska kategoria jest też wytłuszczona lub w innym kolorze. To wskazuje użytkownikowi: znajdujesz się tu. Dla kogoś z autyzmem to może być kluczowe – pomaga poczuć strukturę i porządek.
Typowe błędy:
– Brak jakiejkolwiek wskazówki „gdzie jestem”. Użytkownik wchodzi w głąb strony i nigdzie nie widzi tytułu sekcji czy ścieżki. Jeśli na dodatek strona nie ma tytułów logicznie zhierarchizowanych, to można kompletnie nie wiedzieć, czy to dział X czy Y. Dla użytkownika z zaburzeniem poznawczym taka sytuacja jest jak zgubienie drogi – może spanikować albo się sfrustrować i opuścić stronę.
– Mylenie lokalizacji z historią przeglądania. Okruszki powinny pokazywać strukturę serwisu, a nie np. sekwencję kroków (to co innego). Błędem byłoby np. dynamicznie budować okruszki jako „Poprzednia strona > Bieżąca strona” – to nie to samo. Osobie poznawczej nie pomaga wiedza, skąd przyszła (bo może nawet nie pamięta czemu kliknęła), bardziej potrzebuje wiedzieć, gdzie to umiejscowione.
– Niewidoczność mechanizmu lokalizacji. Np. okruszki istnieją, ale na urządzeniu mobilnym są schowane w menu hamburgerowym. Użytkownik może je przeoczyć całkowicie. Lepiej je wtedy dać np. zaraz pod nagłówkiem strony mobilnej, bo to istotna informacja. Częsty błąd: ukrycie okruszków „bo zajmują miejsce”. Z punktu widzenia AAA to odbieranie ważnego narzędzia.
2.4.9 Cel łącza (z samego łącza) (poziom AAA)
Cel i istota: Tutaj wymaganie jest ostrzejsze niż w 2.4.4 – tekst każdego linku (lub przypisany mu alt/title) powinien samodzielnie, bez dodatkowego kontekstu, jednoznacznie wskazywać na cel linku. To kryterium jest szczególnie korzystne dla osób przeglądających strony w sposób nieliniowy – np. tylko przeglądających listę linków albo takich, które zapamiętują punktowo informacje. Dla użytkowników z niepełnosprawnością poznawczą może to znaczyć, że każdy link jest jasny bez czytania całego zdania wokoło. Jeśli ich styl przeglądania to skanowanie linków (co bywa popularne – np. ktoś tylko „skacze po linkach”, bo nimi nawigować prościej), to opisowe linki pozwolą im zrozumieć dokąd mogą przejść bez głębszego czytania kontekstu.
Przykłady dobrych zastosowań:
– Wszystkie odnośniki w tekście doprecyzowano tak, by były zrozumiałe samodzielnie. Np. zamiast zdania: „Aby pobrać plik kliknij tutaj”, jest: „Pobierz Raport 2023 w formacie PDF”. Link „Raport 2023 w formacie PDF” jasno mówi, co dostaniemy. Gdyby ktoś użył funkcji czytnika ekranu „wylistuj linki” lub pluginu wyciągającego linki ze strony, zobaczy tam „Raport 2023 w formacie PDF” – i nie potrzebuje nic więcej, by wiedzieć, co to.
– Linki-nagłówki artykułów (popularne na portalach) – każdy nagłówek jest linkiem i jest na tyle opisowy, że już on wystarcza. Np. „Nowa ulga podatkowa dla seniorów – poradnik” jako link. Dla AAA ważne jest, by nie było np. pięciu linków „Czytaj więcej” bez kontekstu – co 2.4.9 by naruszało (w 2.4.4 to jeszcze przechodzi, jeśli w okolicy jest tytuł artykułu, ale 2.4.9 wymaga, żeby sam link wyjaśniał).
– Tworzenie unikalnych tekstów linków nawet jeśli prowadzą do podobnych treści, byle oddać różnicę. Np. zamiast listy linków: „Pobierz plik PDF” (i każdy inny PDF), zrobienie listy: „Pobierz cennik.pdf”, „Pobierz regulamin.pdf”, „Pobierz instrukcję.pdf”. W ten sposób linki są rozróżnialne i samodzielnie zrozumiałe.
Typowe błędy:
– Linki polegające na kontekście, np. „Dowiedz się więcej” pod każdym produktem. Bez przeczytania opisu produktu nie wiadomo, o czym się dowiem więcej. AAA tego nie dopuszcza – link powinien zawierać nazwę produktu: „Dowiedz się więcej o Produkcie X”.
– Seria linków „kliknij 1”, „kliknij 2” etc., co czasem się pojawia w jakichś nawigacjach wielostronicowych. To z perspektywy użytkownika nie daje nic. Zamiast tego lepiej „Strona 1, Strona 2” (co i tak jest słabe) albo, najlepiej, nazwy powiązane z treścią. W AAA – każdy link musi być przejrzysty.
– W menu nawigacji linki typu „Oferta”, „Oferta” powtarzające się (np. sekcja główna „Oferta” i podstrona też „Oferta”). Użytkownik widzi dwa linki „Oferta” – nie wie, czym się różnią (może to błąd w menu?). Należałoby nazwać je unikatowo („Oferta – usługi”, „Oferta – cennik” np.). Unikalność zapobiega pomyłkom.
2.4.10 Nagłówki sekcji (poziom AAA)
Cel i istota: Dłuższe lub złożone treści powinny być podzielone na logiczne sekcje z nagłówkami, nawet jeśli formalnie nie wymagają nagłówków. Chodzi o to, by ułatwić strukturalne zrozumienie zawartości. Dla osób z deficytami poznawczymi ściana tekstu bez podziału jest trudna do przetworzenia. Nagłówki sekcji działają jak „punkty zaczepienia” – pozwalają poskładać sobie w głowie mapę treści i potencjalnie przeskakiwać do interesujących fragmentów. To kryterium nie dotyczy stylu (czy wizualnie widać nagłówek), ale raczej samego logicznego wydzielenia fragmentów tematycznych.
Przykłady dobrych zastosowań:
– Artykuł poradnikowy jest podzielony na rozdziały i te rozdziały mają tytuły (np. „1. Wstęp”, „2. Przygotowanie dokumentów”, „3. Składanie wniosku”, „4. Częste błędy”). Osoba z trudnością w koncentracji może przeczytać nagłówki i zdecydować, którą część teraz ogarnie, zamiast walczyć z całością naraz.
– FAQ – każdy FAQ powinien mieć pytania jako nagłówki, a odpowiedź pod spodem. Dzięki temu użytkownik może szybko przeskanować listę pytań (nagłówków) i zainteresować się tylko wybranymi odpowiedziami. Bez nagłówków (czyli np. pytania wtopione w paragrafy) przeglądanie Q&A byłoby mozolne.
– Strukturyzowanie formularzy długich poprzez nagłówki grup (np. „Dane osobowe”, „Adres korespondencyjny”, „Informacje dodatkowe”). Pozwala to użytkownikowi zrozumieć sens kolejnych bloków i nie pomieszać np. adresu zamieszkania z korespondencyjnym – bo widzi wyraźnie, że to oddzielne sekcje.
Typowe błędy:
– Długi tekst bez żadnego podnagłówka. Nawet jeżeli treść zmienia wątki, brak nagłówków sprawia, że trudno to wychwycić. Osoba musi czytać „ciągiem”, co dla niektórych jest niemal niewykonalne (zwłaszcza z ADHD lub umiarkowaną dysleksją – grozi zgubieniem miejsca i powtarzaniem czytania tych samych zdań).
– Używanie formatowania wizualnego zamiast logicznych nagłówków. Np. zrobienie śródtytułu jako pogrubione zdanie, ale bez <h3> lub podobnego w kodzie. Wizualnie trochę pomaga, ale np. czytnik ekranu nie potraktuje tego jak nagłówek (trzeba by mu dodać styl ARIA roli nagłówka, co jest nienaturalne). Użytkownicy korzystający z mechanizmów typu „skocz do następnego nagłówka” nie skorzystają, bo formalnie go nie ma.
– Niechlujne lub nic nie mówiące nagłówki. Jeżeli już są sekcje, ale ich tytuły są niejasne („Uwagi”, „Inne”, „cd.”) – to nie spełnia celu. Lepiej czasem nie mieć nagłówka niż dawać mylący. Jednak AAA sugeruje, by te sekcje były sensowne, więc błąd to nieprzemyślane tytuły segmentów (np. pięć sekcji w artykule pt. „Temat A – cz.1”, „Temat A – cz.2”… lepiej je bardziej określić co w cz.2 konkretnie).
Zasada 3: Zrozumiałość
(Treść musi być zrozumiała dla użytkownika – zarówno na poziomie języka, jak i przewidywalności interfejsu oraz wsparcia przy wprowadzaniu danych. Dla osób z niepełnosprawnościami poznawczymi zasada ta jest kluczowa: obejmuje używanie prostego języka, konsekwentne zachowanie elementów na stronie oraz pomoc w unikaniu i korygowaniu błędów.)
3.1.1 Język strony (poziom A)
Cel i istota: Główny język tekstu na stronie powinien być określony w kodzie (np. atrybut lang=”pl” dla polskiej strony). Choć wydaje się to techniczną kwestią, ma wpływ na zrozumiałość: technologie asystujące, takie jak czytniki ekranu lub translatory, wiedząc w jakim języku jest treść, mogą poprawnie ją przedstawić. Osoba z niepełnosprawnością poznawczą może korzystać z np. syntezatora mowy, by odsłuchać tekst – jeśli język nie jest ustawiony prawidłowo, polski tekst czytany jest angielską wymową, co brzmi jak bełkot i uniemożliwia zrozumienie. Poprawne oznaczenie języka pomaga również osobom z trudnościami w czytaniu – mogą np. użyć narzędzia upraszczającego język czy podmieniającego trudniejsze słowa na synonimy, które często opiera się na wskazaniu języka.
Przykłady dobrych zastosowań:
– Polska strona ma w znaczniku <html lang=”pl”>. Czytnik ekranu i inne narzędzia rozpoznają język jako polski. Osoba z dysleksją, która włączyła narzędzie czytające tekst na głos, usłyszy poprawną polską wymowę słów – będzie mogła zrozumieć treść[18]. Gdyby atrybutu nie było lub był błędny, syntezator mógłby próbować czytać to np. po angielsku, co generuje niezrozumiałe brzmienie.
– Na stronie dwujęzycznej, gdzie domyślny język to polski, a niektóre fragmenty są po angielsku, główny język ustawiono na „pl”, a dla fragmentów obcojęzycznych użyto np. <span lang=”en”>Hello</span>. Dzięki temu użytkownik ze zrozumieniem tekstu słuchanego nie będzie zaskoczony: syntezator zmieni wymowę na angielską tylko dla słów „Hello”, a resztę przeczyta po polsku. Dla osób z problemami językowymi (np. afazją) takie wyraźne rozdzielenie to duża pomoc – mniej chaosu w wymowie.
– Osoba z trudnością w czytaniu może używać narzędzia do sylabizowania tekstu. Takie narzędzie musi wiedzieć, jaki język dzielić na sylaby. Oznaczenie strony jako „pl” zapewni, że użyje polskich zasad (np. dzielenie wyrazów ze zbitkami „szcz” prawidłowo). Bez tego mogłoby spróbować np. angielskich reguł, co nie ma sensu dla polskich słów.
Typowe błędy:
– Brak deklaracji języka w HTML. Wtedy narzędzia asystujące mogą zgadywać albo przyjmować domyślny (często angielski). Użytkownik z czytnikiem ekranu usłyszy polski tekst czytany z akcentem i wymową angielską – praktycznie niepojmowalne.
– Niewłaściwy kod języka. Np. ktoś pomyli i wpisze lang=”pt” zamiast „pl” (pt to portugalski). Rezultat: maszynowe odczytywanie po portugalsku polskich zdań – kompletny absurd dla słuchającego.
– Ignorowanie języka części. Jeśli strona jest wielojęzyczna lub zawiera cytaty w innych językach i nie oznaczy się tego, użytkownik może być zdezorientowany. Np. ma artykuł po polsku, nagle zdanie po francusku – ktoś z kłopotami poznawczymi może nie rozpoznać, że to inny język, tylko pomyśli, że to jakiś bełkot lub jego własny umysł płata figle. Oznaczenie lang=”fr” sprawi, że np. zostanie to przeczytane francusko albo narzędzie tłumaczące wyłapie automatycznie i przetłumaczy.
3.1.2 Język części (poziom AA)
Cel i istota: Wszelkie fragmenty tekstu, które są w innym języku niż główny język strony, powinny być oznaczone odpowiednim atrybutem (np. <span lang=”en”>This is English text</span> w polskim dokumencie). To uzupełnienie 3.1.1 – tam chodzi o główny język, tutaj o wyjątki. Dla użytkowników z niepełnosprawnościami poznawczymi, szczególnie takimi które utrudniają przetwarzanie języka pisanego, jest to istotne: np. ktoś może korzystać z translacji automatycznej – bez oznaczenia języka może zdarzyć się, że obcojęzyczny cytat nie zostanie przetłumaczony, bo system myśli że to polski (wynik: w środku tekstu zostaje niezrozumiały fragment). Albo syntezator mowy błędnie przeczyta obcy fragment polską wymową – co brzmi jak nonsens. Oznaczenie języków zapobiega takim sytuacjom.
Przykłady dobrych zastosowań:
– W artykule polskim pojawia się zdanie: Jak powiedział Churchill: <q lang=”en”>Never give in, never, never, never</q>. Atrybut lang=”en” przy cytacie sprawi, że czytnik ekranu przestawi się na angielską wymowę dla „Never give in…”, a translator przetłumaczy te słowa z angielskiego na polski, jeśli użytkownik używa trybu tłumaczenia. Osoba z dysleksją usłyszy poprawne angielskie zdanie (może go zrozumie lub rozpozna, bo np. uczyła się), albo dostanie tłumaczenie „Nigdy się nie poddawaj…”. Bez lang=”en” czytnik próbowałby czytać to po polsku – co brzmiałoby jak „Newer giwe in, newe…” – kompletny bełkot[19].
– Formularz, w którym są pola nie w języku strony. Np. strona jest polska, ale pole to wpisanie imienia i nazwiska w cyrylicy (bo to formularz dla cudzoziemców z Ukrainy). Etykieta „Ім’я та прізвище” powinna mieć lang=”uk”. Wtedy choćby w przeglądarce, która ma sprawdzanie pisowni – nie podkreśli wszystkiego na czerwono (bo będzie wiedzieć, że to ukraińskie słowa, nie polskie błędy). A czytnik ekranu czy translator prawidłowo potraktuje to jako inny język i nie spróbuje czytać „Ім’я” polskimi głoskami.
– Nawet pojedyncze słowa obcojęzyczne, jeśli istotne, można oznaczyć. Np. „Zasada Divide et impera była mu bliska.” – lepiej <em lang=”la”>Divide et impera</em>, żeby wyraźnie wskazać łacińską sentencję. Użytkownik z trudnościami językowymi może mieć ustawiony styl, że obcojęzyczne zwroty są automatycznie wyjaśniane (np. przez skrypt albo słownik). Bez oznaczenia to by nie zadziałało.
Typowe błędy:
– Brak oznaczania cytatów, nazw własnych, terminów w obcym języku. Efekt – np. w tekście polskim jest zdanie po angielsku. Czytnik polski spróbuje je wymówić – fiasko. Albo mania w polskich tekstach: wplatanie angielskich słów jak „feature” czy „performance” bez wyróżnienia. Osoba z zaburzeniem koncentracji może nawet nie zauważyć, że to inne słowo – spróbuje czytać „fe-a-tu-re?” i się zablokuje, bo to nie pasuje do polskich reguł. Jakby było wyraźnie widać (np. styl kursywą i odpowiedni lang), to wiadomo, że to obce.
– Źle oznaczony język fragmentu. Przykładowo, tekst jest polski ale zawiera zdanie po niemiecku, a ktoś omyłkowo da lang=”en”. Teraz asystujące narzędzia myślą, że to angielski – i w efekcie tłumacz google nie przetłumaczy niemieckiego zdania (bo nie próbuje tłumaczyć „angielskiego”), a syntezator przeczyta niemiecki tekst z angielską wymową – też bez sensu.
– Ignorowanie języka przy nazwach własnych, gdzie wymowa obca ma znaczenie. Np. cytuje się tytuł utworu japońskiego w oryginalnych kanji – jak nie damy lang=”ja”, to screen reader próbując to przeczytać polskim modułem może w ogóle odmówić (bo to nie są polskie znaki). Z lang=”ja” przełączy się i powie coś po japońsku (co może użytkownikowi-natywnie nie pomoże, ale przynajmniej będzie poprawne). W AAA chodzi o to, by wszystko było semantycznie jednoznaczne.
3.1.3 Nietypowe słowa (poziom AAA)
Cel i istota: Jeśli używamy w treści słów lub wyrażeń niezwyczajnych, żargonowych, idiomatycznych czy rzadko spotykanych, powinniśmy dostarczyć do nich objaśnienie (np. definicję, słowniczek, rozwinięcie skrótu). Osoby z niepełnosprawnościami poznawczymi – na przykład z trudnościami w nauce, zaburzeniami językowymi, autyzmem – mogą nie rozumieć metafor, powiedzeń, slangu czy specjalistycznej terminologii. Dla nich tekst powinien być możliwie dosłowny i klarowny. Jeśli trzeba użyć trudnego słowa, spełnienie tego kryterium oznacza: wyjaśnij, co ono znaczy. Dzięki temu użytkownik nie pozostanie z pustką w głowie czy mylnym zrozumieniem.
Przykłady dobrych zastosowań:
– Tekst zawiera idiom: „rzucić na głęboką wodę”. Autor dostrzegając, że to przenośnia, dodaje w nawiasie lub przypisie wyjaśnienie: (to znaczy: postawić kogoś od razu w trudnej sytuacji, bez przygotowania). Osoba ze spektrum autyzmu, która może interpretować język bardzo dosłownie, dzięki temu dopowiedzeniu zrozumie przekaz, a nie pomyśli o literalnym wrzucaniu kogoś do wody.
– Dokument techniczny używa specjalistycznego terminu np. „heurystyka”. Przy pierwszym użyciu autor daje definicję: „heurystyka (tj. metoda znajdowania rozwiązań na podstawie doświadczalnych reguł zamiast pewnych algorytmów)”. Ktoś z dysfunkcją poznawczą i spoza dziedziny może wówczas pojąć sens, zamiast ominąć niezrozumiałe słowo i stracić wątek.
– Na stronie używa się skrótów lub słów z języka młodzieżowego, typu „BTW”, „lifehack”. W treści, aby spełnić AAA, obok pojawia się wyjaśnienie wprost albo tooltip: „BTW (ang. by the way – tak przy okazji)”. Osoba starsza (też mogąca mieć kłopoty poznawcze związane z wiekiem) nie musi się domyślać, co to znaczy – dostaje tłumaczenie.
Typowe błędy:
– Stosowanie trudnych lub specyficznych słów bez żadnego objaśnienia. Np. „Implementacja protokołu odbywa się asynchronicznie poprzez mechanizm webhook” – jeżeli czytelnik nie wie, co to „asynchronicznie” albo „webhook”, to zdanie jest czarną magią. W AAA oczekiwalibyśmy przypisu do webhook: „(metoda powiadamiania zwrotnego: serwer wysyła żądanie HTTP do klienta)”, i ewentualnie prostrzego określenia asynchroniczności w kontekście.
– Używanie idiomów kulturowych bez kontekstu. Np. „Sytuacja była Panu Kowalskiemu solą w oku”. Ktoś o dosłownym sposobie myślenia wyobrazi sobie sól w oku i nie zrozumie, że chodzi o coś dokuczającego. Brak wyjaśnienia tego frazeologizmu to bariera – AAA wymagałoby np.: „(czyli bardzo mu przeszkadzała)”.
– Zakładanie znajomości skrótów slangowych/internetowych. Osoba z deficytem może nie odczytać „IMHO” (może próbować to przeczytać jak „imho” i nie zrozumie), lub „xD” (co to jest? buźka? litery?). Bez wyjaśnienia w słowniczku albo uniknięcia takich skrótów, tekst staje się niejasny.
3.1.4 Skróty (poziom AAA)
Cel i istota: Wszystkie skróty i akronimy użyte w tekście powinny mieć dostępną formę rozwiniętą lub objaśnienie, chyba że są powszechnie znane i oczywiste. Osoby z niepełnosprawnościami poznawczymi mogą nie rozszyfrować skrótu, zwłaszcza jeśli jest domenowo-specyficzny lub nietypowy. Zapewnienie rozwinięcia eliminuje zgadywanie. Poza tym czytniki ekranu mogą literować nieznane akronimy, co brzmi niezrozumiale – warto dostarczyć im expansion (np. za pomocą <abbr title=”rozwiniecie”>skrót</abbr>). Dla kogoś z problemami uczenia się to jak posiadanie słownika pod ręką.
Przykłady dobrych zastosowań:
– Tekst używa skrótu np. „WFOŚ”. Pierwsze wystąpienie powinno brzmieć: „Wojewódzki Fundusz Ochrony Środowiska (WFOŚ)”. Wtedy dalej w tekście można już używać WFOŚ, ale czytelnik (nawet jeśli ma trudność z pamięcią) zawsze może zerknąć wyżej i przypomnieć sobie, co to znaczy. Można też użyć <abbr title=”Wojewódzki Fundusz Ochrony Środowiska”>WFOŚ</abbr> – wtedy po najechaniu kursorem pokaże pełną nazwę.
– Gdy pojawia się skrót-zupełnie-nieoczywisty, styluje się go tak, by zwracał uwagę i sygnalizował, że jest wyjaśnienie. Np. inny kolor czy kropkowanie (CSS dla <abbr>). Osoba z dysfunkcją poznawczą zobaczy, że skrót jest jakoś wyróżniony i może intuicyjnie w niego „tapnąć” czy najchać, by poznać rozwinięcie – zamiast ignorować.
– W treściach dla szerszego grona unikanie skrótów w ogóle, a jeśli już – to dodanie w nawiasie wyjaśnienia prostym językiem. Np. „stosujemy podejście TDD (ang. Test-Driven Development, metoda tworzenia oprogramowania przez pisanie testów przed kodem).” – tu i rozwinięto akronim, i dodatkowo wytłumaczono w języku naturalnym. To jest optimum zrozumiałości.
Typowe błędy:
– Stosowanie akronimów branżowych bez rozwinięcia. Np. artykuł medyczny od razu mówi o „HCV” albo „HCC” i nie wyjaśnia (HCV = wirus zapalenia wątroby typu C). Nawet specjaliście może zająć moment zastanowienia, a co dopiero laikowi z trudnością poznawczą – prawdopodobnie w ogóle nie skojarzy, o czym mowa.
– Skracanie wyrazów w niejednoznaczny sposób. Np. „prof.” – może znaczyć profesor lub profesjonalny (zależy od kontekstu). Osoba z problemami językowymi może się zagubić, bo widzi „prof.” i nie wie, czy to tytuł osoby, czy skrót od „profesjonalny system X” itp. Bez rozwinięcia (profesor Jan Nowak) to zostawia miejsce na niejasność.
– Zakładanie, że każdy zna pewne skróty. Np. „PKP” – w Polsce niby oczywiste, ale nie każdy musi się orientować (osoba z niepełnosprawnością intelektualną może nie skojarzyć, a cudzoziemiec na pewno nie). AAA preferuje, by mimo wszystko wyjaśniać, szczególnie w materiałach edukacyjnych czy formalnych.
3.1.5 Poziom umiejętności czytania (poziom AAA)
Cel i istota: Tekst na stronie powinien być napisany prostym językiem – takim, który przeciętny nastolatek (poziom edukacji niższy niż ukończona szkoła średnia) jest w stanie zrozumieć. Jeśli przekaz wymaga wyższego poziomu czytelnictwa, należy udostępnić także wersję łatwiejszą lub streszczenie w prostych słowach. To kryterium jest wprost adresowane do osób z niepełnosprawnościami poznawczymi wpływającymi na zdolność czytania i rozumienia tekstu: dysleksja, upośledzenie umysłowe, problemy z koncentracją, a także do osób słabiej znających język (np. migrujących). Prosty język redukuje obciążenie poznawcze – nie trzeba się trudzić ze skomplikowaną składnią czy rzadkimi wyrazami[20].
Przykłady dobrych zastosowań:
– Redagowanie treści w stylu Easy-to-Read (język łatwy do czytania). Np. krótkie zdania, jedno ważne przesłanie na zdanie. Unikanie strony biernej („Decyzja została podjęta”) na rzecz strony czynnej („Zarząd podjął decyzję”). Osoba z trudnościami w uczeniu się znacznie lepiej pojmie zdanie aktywne niż bierne.
– Unikanie złożonych metafor, podwójnych przeczeń, nadmiernych wtrąceń. Tekst ma być możliwie klarowny. Np. zamiast „Nie jest to nierozsądne posunięcie” – bo to dwa negacje – lepiej „To posunięcie jest rozsądne”. Mniej kombinowania = łatwiejsze rozumienie.
– Wersja „dla każdego” obok oficjalnej. Jeśli strona musi publikować teksty trudne (np. ustawy, analizy prawne), to AAA wymagałoby np. streszczenia każdej ustawy w prostym języku. Przykładowo: pełen raport 50-stronicowy i obok 2-stronicowe omówienie najważniejszych punktów w języku codziennym. Osoba, która nie przebrnęłaby przez żargon raportu, może przeczytać wersję uproszczoną i zrozumieć sens.
Typowe błędy:
– Pisanie urzędowym, zawiłym stylem do ogółu odbiorców. Np. „W związku z przedmiotowym zapytaniem w załączeniu przesyła się wymagane dokumenty celem dalszego procedowania.” – to zdanie jest trudne nawet dla sprawnego czytelnika, a co dopiero dla kogoś z deficytami. AAA po prostu nie akceptuje takiej formy dla ogólnodostępnych treści – trzeba by to uprościć np.: „Do tego pytania dołączamy potrzebne dokumenty, aby można było zacząć załatwiać sprawę.”.
– Brak wersji łatwej w przypadku bardzo trudnych materiałów. Niektóre treści z definicji są skomplikowane (np. artykuły naukowe). AAA wymaga przynajmniej jakiegoś podsumowania po ludzku: jeśli nic takiego nie ma, to bariera dla osób z niższą sprawnością intelektualną jest całkowita.
– Zbyt duża gęstość informacji i branżowych terminów bez wyjaśnienia. Tekst może i gramatycznie prosty, ale napakowany nazwami własnymi, akronimami i datami – to też obniża czytelność. Osoba z ADHD może odpłynąć, widząc ścianę dat i skrótów. Trzeba dbać nie tylko o składnię, ale i o przyjazność przekazu: np. używać list wypunktowanych, dzielić akapity tematycznie – by ułatwić percepcję.
3.1.6 Wymowa (poziom AAA)
Cel i istota: Jeśli występują słowa lub wyrażenia, których poprawne zrozumienie zależy od znajomości ich wymowy, powinno być udostępnione wyjaśnienie tej wymowy. Dotyczy to np. nietypowych nazw własnych, homografów (wyrazów pisanych tak samo, ale różnie czytanych zależnie od znaczenia) – szczególnie w sytuacji, gdy brak wskazówki wymowy mógłby wprowadzić w błąd. Dla osób z niepełnosprawnością poznawczą, zwłaszcza mających problem z odczytywaniem takich rzeczy (np. dzieci z dysleksją, osoby uczące się języka) – notacja wymowy zapobiega nieporozumieniom. Także użytkownicy czytników ekranu skorzystają, bo można np. wymusić prawidłową wymowę danego słowa przez zamieszczenie audio lub zapisu fonetycznego.
Przykłady dobrych zastosowań:
– W tekście pojawia się nazwisko obcojęzyczne np. „Thomas Knuth (wym. Tomas Knut)”. Czytelnik widzi w nawiasie polską transkrypcję – nie będzie głowił się, jak to przeczytać. Osoba z trudnościami językowymi nie utknie na nazwisku (co to za „Kenuć”? czytając na polski), tylko ma podane jak to wymówić i może powiązać z ewentualną postacią, którą zna ze słyszenia.
– Wyraz homograficzny: np. „Zamek (czyt. zamek – budowla warowna) i zamek (czyt. zamyk – mechanizm do zamykania drzwi) to homonimy.” – tu w przykładzie edukacyjnym pokazano różną wymowę. Dla AAA chodzi o to, żeby w normalnej treści nie zostawiać pola do pomyłki. Jeśli w tekście zdanie: „Ma zamek w drzwiach”, ktoś mógłby pomyśleć o budowli (dziwne, ale formalnie możliwe), więc warto by doprecyzować (np. synonimem lub właśnie wskazując wymowę „zamyk”).
– Podanie linku do nagrania z wymową trudnego słowa. Np. w słownikach online przy hasłach bywa ikonka głośniczka – AAA nie wymaga koniecznie audio, ale może być to rozwiązanie. Jeśli np. tekst uczy wymowy jakiegoś dźwięku językowego, to najlepiej dostarczyć dźwięk. Osoba z zaburzeniami mowy czy uczenia się języka musi usłyszeć, jak dane słowo brzmi poprawnie.
Typowe błędy:
– Brak informacji przy słowach obcych, które czyta się zupełnie inaczej niż pisownia sugeruje. Np. „Wystąpił gość: Siobhan Thompson.” – imię „Siobhan” czyta się „Sziwon”. Bez wskazania, spora szansa, że czytelnik (zwłaszcza z dysleksją lub nieznajomością tego imienia) przeczyta to jako „Siobhan” po polsku i nie skojarzy, że chodzi o „Sziwon” (jeśli gdzieś słyszał). AAA zaleca dodać np. „(czyt. sziwon)”.
– Homografy i gra słów pozostawione bez komentarza. Np. zdanie: „Zatrzymać się by odpocząć czy zatrzymać się by nie iść dalej? W języku polskim stać ma wiele znaczeń.” – tu jest zabawa słowem „zatrzymać się” i różnymi odcieniami znaczeń. Ktoś z autyzmem może nie zrozumieć tej gry. W AAA powinniśmy unikać takich niejasności lub je dookreślać.
– Nieprzewidzenie problemu z wymową u czytelnika. Czasem autor może nie zdawać sobie sprawy, że dane słowo sprawi trudność. Np. „charakterystyczny” – długie, trudne słowo, może nie w kwestii wymowy, ale do przeczytania tak. AAA sugeruje: jeśli to kluczowe słowo, a trudne, można dodać podział na sylaby lub zapis fonetyczny jak w słownikach. Błędem byłoby zupełne ignorowanie, że dla pewnej grupy odbiorców to word-with-too-many-letters (słowo-długas). Jednak to dość rzadko spełniane kryterium, raczej w materiałach dla specyficznych grup (np. elementarze, logopedyczne treści).
3.2.1 Po otrzymaniu fokusu (poziom A)
Cel i istota: Element interfejsu, który otrzymuje fokus (np. poprzez nawigację klawiaturą lub skryptowo), nie powinien samoczynnie zmieniać kontekstu (np. przeładowywać strony, otwierać nowych okien, przesuwać kursora gdzie indziej). Chodzi o to, by nawigacja była przewidywalna – zaznaczenie elementu nie może od razu wywoływać akcji. Dla użytkowników z niepełnosprawnościami poznawczymi ma to znaczenie, ponieważ niespodziewana zmiana kontekstu może być dezorientująca lub frustrująca[21][22]. Ktoś np. tabuluje przez formularz i nagle samo przeskoczenie do listy rozwijanej przenosi go na inną stronę – łatwo stracić orientację. Lepiej, żeby takie akcje były dopiero po aktywacji (np. Enterem, kliknięciem), a nie tylko po wejściu fokusu.
Przykłady dobrych zastosowań:
– Użytkownik tabulatorem przechodzi przez menu rozwijane. Fokus trafia na element menu – menu się rozwija (to jest dozwolone, bo to nie zmiana kontekstu jak definicja WCAG, tylko pojawia się dodatkowa treść), ale nie następuje od razu przeniesienie na podstronę czy otwarcie czegokolwiek. Dopiero gdy użytkownik faktycznie wybierze pozycję (np. Enterem), nastąpi przejście. W ten sposób osoba może nawigować bez lęku, że samo przejście po menu gdzieś go nagle wyrzuci.
– Focus w polu formularza nie wywołuje od razu walidacji czy wyskakującego okienka. Np. pola z tooltipami pomocy mogą takowe pokazywać na fokusie (to drobna zmiana, raczej ok), ale nie mogą np. na fokus od razu wyskakiwać w nowym oknie z instrukcją – to by rozwaliło proces wypełniania.
– Programista nie używa eventu onfocus do wywołania nawigacji. Np. dawniej bywało, że lista wyboru miała event onfocus this.form.submit(). W efekcie jak tylko tabem wszedłeś na listę, formularz się wysyłał. Dostosowany kod: usunąć onfocus, ewentualnie przenieść logikę na onChange lub przycisk Wyślij.
Typowe błędy:
– Link lub przycisk, który przy focusie od razu otwiera tooltip bądź modala i automatycznie przenosi tam focus. W rezultacie user tabem idzie: „Link X otrzymuje fokus -> hop, fokus przeskakuje do okienka help, które się samo otworzyło”. Taki przeskok kontekstu na pewno wprowadzi chaos. Według WCAG to zmiana kontekstu (bo pojawia się nowe okno i zmienia fokus) – niedozwolona przy samym focusie[23][24].
– Automatyczne przesuwanie kursora. Np. skrypt: w polu PESEL, jak user wpisze 11 cyfr, to automatycznie focus skacze do następnego pola. Teoretycznie wygodne, ale może zaskoczyć – lepiej nie robić tego, bo jak ktoś pomyli się w ostatniej cyfrze i chce poprawić, to już go wywaliło do następnego pola. Dla kogokolwiek to wkurzające, a co dopiero dla kogoś z zaburzeniami, kto może nie zrozumieć co się stało.
– Focus na linku powoduje natychmiastowe przejście pod link. O to dość trudno przypadkiem, raczej jak developer specjalnie tak ustawi. W każdym razie – takie zachowanie byłoby jak hover-triggered nav tylko że dla klawiatury. Zabronione, bo user nie miał szansy potwierdzić, że chciał tam iść – może tylko chciał sprawdzić linki Tabem.
3.2.2 Podczas wprowadzania danych (poziom A)
Cel i istota: Zmiana stanu jakiegoś komponentu interfejsu (np. zaznaczenie checkboxa, wybranie opcji z listy, wpisanie tekstu) nie powinna powodować natychmiastowej, nieoczekiwanej zmiany kontekstu. To znaczy, że jeśli użytkownik dokonuje wyboru, powinien mieć kontrolę nad tym, kiedy np. nastąpi przesłanie formularza czy przeładowanie strony – zazwyczaj poprzez dodatkowe potwierdzenie (np. kliknięcie przycisku „Zastosuj filtr” po zaznaczeniu checkboxów). Bez tego osoba może zostać zaskoczona np. automatycznym przejściem do innej strony tylko dlatego, że rozwinęła listę i coś wybrała. Dla użytkowników z niepełnosprawnością poznawczą to ważne: pozwala im dokonać wyboru spokojnie, bez natychmiastowych skutków, które mogą wywołać dezorientację lub stres.
Przykłady dobrych zastosowań:
– Lista rozwijana „Wybierz kraj” nie przeładowuje formularza od razu po wyborze kraju, tylko ewentualnie odblokowuje pola regionów dla wybranego kraju na tej samej stronie (to zmiana treści, ale nie kontekstu w rozumieniu WCAG, więc ok), albo czeka na wciśnięcie przycisku „Dalej”. Użytkownik może wybrać z listy Czechy i nic niespodziewanego się nie dzieje – dopiero, gdy kliknie Dalej, strona ewentualnie się zmienia (ale to już świadoma akcja).
– CheckBox „Akceptuję regulamin” – nie kończy od razu rejestracji, tylko po prostu zaznacza zgodę. Użytkownik z problemami poznawczymi może przypadkiem kliknąć space na tym checkboxie, niechcący go odznaczyć – formularz nie powinien od razu interpretować tego np. jako „cofnij rejestrację” albo coś. Krótko: wypełnianie i zaznaczanie czegokolwiek nie powinno zabierać usera od razu gdzieś indziej.
– Pola autouzupełniania (jak wyszukiwarki, co podpowiadają w trakcie) mogą dynamicznie pokazywać listę sugestii – to nie jest zmiana kontekstu, bo user nadal jest w polu i może ignorować. Gdy jednak np. sugestie by się pojawiały i automatycznie przenosiły usera do pierwszego wyniku (bo np. programista tak chciał), to by naruszyło to kryterium.
Typowe błędy:
– Autoprzesyłanie formularza po zmianie pola. Najczęstszy przypadek: dropdown zmieniający sortowanie albo stronę. Ktoś wybiera z listy „Sortuj według ceny” i bum – strona się przeładowuje, a fokus może zgubić pozycję (zazwyczaj idzie na top). Osoba wolniej myśląca może w ogóle nie skojarzyć, co się stało – „Chciałem tylko posortować, czemu znowu muszę przewijać od góry?”.
– Checkboxy i radio implementowane tak, że od razu „akcja” (np. radio zmienia sekcję strony natychmiastowo). To może być dozwolone, jeśli nie zmienia kontekstu sensu stricto (np. radio „indywidualny” vs „firma” w formularzu – zaznaczenie może np. pokazać inne pola, to nie zmiana całej strony, więc spoko). Ale jakby radio natychmiast przenosiło do innej podstrony – błąd.
– Linki udające select i reagujące natychmiast. Czasem styluje się listę linków jako dropdown. Jak user klika (aktywuje, czyli to oninput, bo selection zmienia się), to go przenosi. Dla spełnienia 3.2.2 trzeba by dodać jeszcze przycisk „Go” obok lub inaczej potwierdzać. Bez tego – kliknął link i poszło, niby normalne, ale tutaj analogia jest jak selection=go, co jest właściwie inny scenariusz (bo link od razu jest aktywacją, nie „zmianą wyboru”; więc linki są akurat akcją usera).
(Trzeba tu rozróżnić: 3.2.2 dotyczy elementów formularza – np. select, radio, etc. Link to już aktywna kontrolka, tam 3.2.2 nie obowiązuje, bo oninput nie dotyczy linka – klik to od razu intencjonalne działanie. Czyli link może przenosić i to nie łamie 3.2.2. Jednak select zmieniający stronę automatycznie – tak, bo to by się stało podczas wprowadzania danych*, czyli podczas zmiany wyboru.)
3.2.3 Spójna nawigacja (poziom AA)
Cel i istota: Wspólne elementy nawigacyjne (menu główne, menu boczne, stopka z linkami) powinny być spójne i pojawiać się w tej samej kolejności na wszystkich stronach serwisu. Dzięki temu użytkownik nie musi za każdym razem od nowa uczyć się rozmieszczenia nawigacji. Dla osób z niepełnosprawnościami poznawczymi, rutyna i powtarzalność interfejsu jest bardzo istotna – zmniejsza obciążenie pamięci i uwagi, bo można polegać na raz wyuczonym układzie[25][26]. Jeśli np. w sklepie internetowym link „Koszyk” raz jest po prawej, raz znika, a raz zmienia nazwę, to taka niespójność zdezorientuje użytkownika, a osobie z problemami poznawczymi może wręcz uniemożliwić korzystanie (bo pomyśli, że koszyka nie ma lub to już inna strona).
Przykłady dobrych zastosowań:
– Strona ma stałe menu główne u góry: „Strona główna | Produkty | O nas | Kontakt”. Niezależnie od działu, te pozycje menu zawsze są w tej samej kolejności i wyglądają tak samo. Użytkownik szybko kojarzy, że pierwszy link to Strona główna, drugi – Produkty itd. Nawet jeżeli ma słabszą pamięć, po paru powtórzeniach utrwali sobie to. Spójność tutaj buduje przewidywalność interfejsu[17].
– Jeśli w serwisie jest sekcja z sub-nawigacją (np. w dziale „Produkty” jest boczne menu z kategoriami), to również i to menu zachowuje stały układ dla wszystkich stron w obrębie działu. Np. lista kategorii zawsze sortowana alfabetycznie albo logicznie i nie przeskakuje. Osoba z autyzmem ceni sobie taki porządek – wie, że kategorie nie będą skakać.
– Elementy nawigacyjne nie znikają i nie pojawiają się losowo. Jeśli np. link „Zaloguj” po zalogowaniu zmienia się w „Moje konto” – to w porządku, bo logiczna zamiana. Ale nie powinno być tak, że pewne linki są tylko na stronie głównej, a na podstronach ich brak (bez wyraźnego powodu). Spójność nakazuje raczej mieć stały szablon, ewentualnie wyróżnić aktywny element, ale nie rezygnować z niego.
Typowe błędy:
– Niekonsekwentne menu: np. na stronie głównej menu ma układ A-B-C-D, a na podstronach B-A-D-C. Użytkownik może nabrać złej pewności (np. klika trzeci link myśląc, że to C, a tu jest D, bo zamienione). Dla kogoś z deficytem uwagi to może w ogóle nie zostać zauważone – skutkować będzie klikanie złych miejsc i poczucie chaosu.
– Różne nazewnictwo tego samego linku w różnych miejscach. Np. raz „Koszyk”, raz „Twoje zakupy”. Osoba może nie zrozumieć, że to to samo – powinna być jedna nazwa.
– Usuwanie elementu nawigacji w pewnym kontekście. Np. w trybie mobilnym menu ma mniej pozycji (bo „mniej miejsca”). To często spotykane, ale jeśli usuniemy coś istotnego, użytkownik mobilny może nie znaleźć drogi. Lepiej schować w menu hamburgerowym, ale nie kasować opcji.
– Inny błąd: dynamiczne przerzucanie linków zależnie od historii użytkownika. Np. „ostatnio oglądane” dodane do menu, ale powodujące przesunięcie innych. Lepiej dodać extra bez naruszania kolejności stałej (np. na końcu zawsze). Zaburzenie stałego układu to złamanie spójności.
3.2.4 Spójna identyfikacja (poziom AA)
Cel i istota: Jeżeli w różnych miejscach serwisu pojawiają się elementy o tej samej funkcji (np. ikonki, przyciski, linki do tej samej akcji), to powinny być oznaczone i wyglądać spójnie – tak, by użytkownik rozpoznał, że to to samo działanie. Przykład: symbol lupy zawsze oznacza „szukaj” na wszystkich stronach (i tylko do tego jest używany). To pomaga osobom z niepełnosprawnościami poznawczymi, bo zmniejsza wymóg ponownego uczenia się: raz zrozumieją ikonę lub termin i mogą go bez trudu odnaleźć gdzie indziej w serwisie[17]. Gdyby np. raz ikona kosza usuwała produkt, a innym razem ten sam kosz oznaczał „dodaj do koszyka”, to jest przepis na pomyłkę – spójna identyfikacja tego zabrania.
Przykłady dobrych zastosowań:
– Przyciski „Drukuj stronę” zawsze nazwane „Drukuj” i zawsze z tą samą ikonką drukarki. Użytkownik wie: widzę ikonę drukarki = mogę wydrukować, niezależnie czy jestem na blogu czy w artykule pomocy. Gdyby raz była drukarka do drukowania, a raz do pobierania PDF, to by go zmyliło.
– Spójne nazewnictwo w całym serwisie: np. raz w formularzu jest „Dalej”, raz „Kontynuuj” – to niby synonimy, ale lepiej trzymać jeden wariant, aby użytkownik zawsze wiedział „to jest ten zielony guzik do przejścia dalej w procesie”.
– Ikony mediów społecznościowych – standardowo spójne (logo FB = link do FB). Serwis, gdyby użył np. logo Twittera do oznaczenia „nasz blog”, złamałby konwencję i zmyliłby wszystkich, nie tylko poznawczo słabszych. Więc spójna identyfikacja to też trzymanie się ogólnych konwencji, by nie wprowadzać niezgodności.
Typowe błędy:
– Różne etykiety dla tej samej czynności. Np. link do strony głównej: na jednych podstronach to logo (obrazek), na innych jest tekst „Home”. Lepiej jednolicie – albo zawsze klikalne logo, albo zawsze link „Strona główna”, albo oba, ale obecne wszędzie.
– Ikony wykorzystywane niespójnie. Np. symbol serduszka używany i do „ulubionych produktów”, i do „donacji” (darowizny). Użytkownik może pomyśleć, że to te same funkcje (serduszko = lubię). Gdy kliknie „serduszko” a tu mu się otwiera panel płatności donacji – będzie w szoku.
– Mieszanie stylów przycisków: np. przycisk „Zapisz” jest czasem niebieski okrągły, a czasem szary prostokątny – a to ta sama akcja. Dla usera mniej kumatego może to wyglądać jak dwie różne rzeczy (zwłaszcza jak style odróżniają np. ważność: jaskrawy vs stonowany sugeruje co innego).
– Językowa niespójność: w części serwisu po polsku, w innej po angielsku dla tych samych elementów. Np. „Next” w jednym kroku i „Dalej” w innym. Może projekt nie dopilnował tłumaczenia. To zdecydowanie myli. Osoba z problemami może nie znać angielskiego i utknie.
3.2.5 Zmiana na żądanie (poziom AAA)
Cel i istota: Ten punkt jest rozwinięciem 3.2.1 i 3.2.2 – na poziomie AAA wymaga, by żadna zmiana kontekstu (czyli np. przejście do innej strony, otwarcie nowego okna, znacząca zmiana układu) nie następowała bez świadomej inicjatywy użytkownika. Oznacza to, że nawet akcje, które mogłyby być automatyczne przy niższych poziomach, tutaj powinny być wykonywane dopiero po potwierdzeniu przez użytkownika lub na jego prośbę. Dla użytkowników z poważniejszymi niepełnosprawnościami poznawczymi to daje maksimum kontroli – nic ich nie zaskoczy, dopóki sami tego nie wywołają. Mają czas i możliwość przygotować się na zmianę, co obniża stres i zagubienie.
Przykłady dobrych zastosowań:
– Nawet jeśli w interfejsie coś mogłoby dziać się automatycznie, AAA sugeruje dodać np. checkbox „Zastosuj automatycznie” lub przycisk „Zastosuj”. Przykładowo: Filtry produktów – zamiast natychmiast zmieniać listę produktów przy zaznaczaniu filtra, w AAA byłby przycisk „Pokaż wyniki” dopiero wyzwalający odświeżenie listy.
– Potwierdzenia przed dużymi zmianami. Np. kliknięcie linku do zewnętrznej strony – AAA mogłoby chcieć, by spytać „Opuszczasz nasz serwis, kontynuować?”. To oczywiście bywa upierdliwe, ale z myślą o kognitywnie słabszych – chroni przed przypadkowym wyjściem.
– W aplikacjach wielostronicowych: nie przekierowywać automatycznie w reakcji na jakieś stany. Np. po 5 minutach braku aktywności nie wylogowywać bez zapytania. AAA raczej postulowałoby pokazanie komunikatu „Czy chcesz kontynuować? Tak/nie” – czyli zasięgnąć potwierdzenia zanim zamknie sesję (zmiana kontekstu z zalogowany na wylogowany).
Typowe błędy:
– Nadal obecne zmiany kontekstu bez akcji usera. Jeśli strona AAA robi coś sama (np. redirect po X sekundach, auto-play film przenoszący na inną stronę po zakończeniu, itp.), to łamie tę wytyczną. W AAA nic nie powinno się dziać z „magicznym automatem”.
– Brak dodatkowego potwierdzenia w krytycznych momentach. Np. user klika „Usuń konto” i od razu kasuje – AAA sugerowałoby raczej: klik -> potwierdź w dialogu. Bez tego to zmiana kontekstu z zalogowanego do wylogowanego i spore konsekwencje, a user mógł niechcący kliknąć.
– Mechanizmy, które w interfejsie nie pozwalają użytkownikowi decydować. Np. suwak głośności: w AAA można by argumentować, że suwak nie powinien automatycznie przy każdym ruchu zmieniać głośność – lepiej jak po upuszczeniu (żądanie) dopiero zmieni. To drobiazg, ale idea: nie zmieniaj podczas, zmień po.
3.3.1 Identyfikacja błędu (poziom A)
Cel i istota: Jeśli użytkownik popełni błąd przy wprowadzaniu danych (np. nie wypełni wymaganego pola, wpisze zły format e-maila), system powinien wyraźnie zasygnalizować ten błąd oraz wskazać, które elementy są błędne. Dla wszystkich użytkowników, a szczególnie dla osób z trudnościami poznawczymi, jasna informacja o błędzie jest kluczowa aby móc poprawić dane. Osoby te często nie wychwycą subtelnych sygnałów – potrzebują jednoznacznego komunikatu tekstowego, że nastąpił błąd i gdzie. Bez tego mogą nie zdać sobie sprawy, że ich akcja nie powiodła się, albo nie będą wiedzieli, co poszło źle.
Przykłady dobrych zastosowań:
– Po wysłaniu formularza rejestracji, jeśli np. hasło jest za słabe, strona wyświetla komunikat przy polu hasła w czerwonym kolorze: „Hasło musi mieć co najmniej 8 znaków.” i dodatkowo ustawia fokus na to pole lub wyróżnia obramowaniem. Użytkownik od razu widzi gdzie i co jest problemem – to spełnia kryterium[27]. Osoba z zaburzeniem uwagi nie musi się domyślać, czemu nic się nie dzieje – widzi komunikat.
– Jeśli zapomniał zaznaczyć checkbox „Akceptuję regulamin”, po próbie wysłania pojawia się komunikat przy tym checkboxie lub na górze formularza: „Musisz zaakceptować regulamin, aby kontynuować” – to informuje, co trzeba zrobić.
– Pola z błędami są wyraźnie oznaczone, np. czerwoną ramką i ikonką ostrzeżenia, oraz opisem tekstowym błędu. Wizualny i tekstowy przekaz razem zapewniają, że nawet jak ktoś nie przeczyta pełnego komunikatu, to czerwona ramka go naprowadzi, że tu coś nie tak (ale tekst i tak powinien być).
Typowe błędy:
– Brak informacji o błędzie – formularz po wysłaniu po prostu „nie idzie dalej” i nie wiadomo czemu. Użytkownik, zwłaszcza poznawczo słabszy, może zrezygnować, bo nie wie co poprawić. To rażące naruszenie.
– Informacja nazbyt ogólna. Np. tylko komunikat na górze: „Formularz zawiera błędy, popraw je.” – bez wskazania które pola. Ktoś może się domyśli, a ktoś nie. Powinno być konkretnie: „Pole E-mail jest wymagane” itp.
– Zaznaczanie błędu tylko kolorem lub ikonką, bez tekstu. Osoba niewprawna może nie rozumieć, co czerwona gwiazdka czy wykrzyknik oznacza. Tekst „to pole jest wymagane” musi być gdzieś wyświetlony obok symbolu.
– Zła lokalizacja komunikatu – np. pojawia się gdzieś daleko od pola. Użytkownik może go nie powiązać. Lepiej tuż obok/dołu pola. Jeśli musi być zbiorczo, to powinien wymieniać nazwy pól („Błąd: Nazwisko – za krótki”).
3.3.2 Etykiety lub instrukcje (poziom A)
Cel i istota: Formularze i interaktywne kontrolki powinny mieć jasno zrozumiałe etykiety lub instrukcje obsługi, szczególnie gdy oczekiwany format danych nie jest oczywisty. Dla użytkowników z niepełnosprawnościami poznawczymi daje to kontekst i wskazówki, co i jak wpisać – zmniejsza szansę popełnienia błędu. Na przykład osoba z zaburzeniem koncentracji łatwiej wypełni pole, jeśli zobaczy etykietę „Numer telefonu (9 cyfr)”, niż gdyby była tylko pusta kratka bez opisu – mogłaby nie domyślić się, czy wpisać +48, czy format z myślnikami, itd.
Przykłady dobrych zastosowań:
– Każde pole tekstowe ma widoczną etykietę tekstową. Np. przed polem jest napis „Imię:”, przy polu e-mail „Adres e-mail:”. Osoba z trudnościami nie musi zgadywać, co dane pole oznacza. Placeholder w środku pola może pomagać, ale nie zastępuje etykiety – placeholder znika podczas pisania, a etykieta powinna pozostać[28].
– Jeśli wymagany jest konkretny format, podanie instrukcji. Np. pole daty – obok tekst „RRRR-MM-DD” lub „Format: DD.MM.RRRR”. Użytkownik wie, jak wpisywać datę. Bez tego mógłby wpisać „12 września 2025” i formularz by uznał to za błąd.
– Instrukcje co do pól opcjonalnych/obowiązkowych: np. gwiazdka przy etykiecie plus wyjaśnienie „* – pole obowiązkowe”. Osoba z zaburzeniami nie przeoczy, że coś jest wymagane.
– W przypadku nietypowych interakcji, instrukcja co zrobić. Np. slider do wyboru kwoty – tekst nad nim „Przeciągnij suwak, aby wybrać kwotę”. To niby oczywiste, ale nie dla każdego. Lepiej napisać i uniknąć konsternacji.
Typowe błędy:
– Brak etykiet tekstowych – pole definiowane np. tylko poprzez ikonę (np. lupa jako input search bez labela). Użytkownik może nie skojarzyć, że ta ikona to pole wyszukiwania, albo np. osoba z dysleksją używająca czytnika nie usłyszy etykiety (bo jej nie ma).
– Etykieta niejasna lub skrótowa. Np. „Nr dok.” – lepiej „Numer dokumentu”. Ktoś może nie odgadnąć skrótu. Albo nazwy własne jako etykiety, np. „ExpressID:” – co to? Lepiej „ExpressID (unikalny identyfikator otrzymany przy rejestracji)”. Rozwinięcie w formie hintu czyni sprawę jasną.
– Brak wskazówek co do oczekiwanego formatu. Często w formularzach adresowych: „Kod pocztowy” – i nie wiadomo, czy z myślnikiem np. „00-950”, czy ciągiem „00950”. Bez instrukcji user może wpisać w zły sposób i nie rozumieć czemu błąd.
– Zbyt skomplikowane instrukcje. Czasem nadgorliwość: akapit tekstu przed każdym polem – to może przytłoczyć. Instrukcja powinna być zwięzła i przy polu, którego dotyczy. Np. przed dużym formularzem nie należy w jednym bloku wyjaśniać wszystkich wymagań – bo użytkownik z kiepską pamięcią i tak nie zapamięta. Lepiej drobne instrukcje per pole.
3.3.3 Sugestie korekty błędów (poziom AA)
Cel i istota: Gdy formularz zostanie wypełniony błędnie, poza samym zasygnalizowaniem błędu (3.3.1), dobrze jest zasugerować, jak ten błąd poprawić – przynajmniej wtedy, gdy system może taką sugestię podać. Dla osób z niepełnosprawnościami poznawczymi jest to ogromne ułatwienie: nie tylko wiedzą, że zrobili błąd, ale i dostają podpowiedź, co zrobić inaczej. To redukuje frustrację i zgadywanie. Np. jeśli wpisałem „15” w polu „wiek dziecka”, a wymagane jest „co najmniej 18 lat” (to błąd, bo za mało), to komunikat mógłby brzmieć: „Wiek dziecka jest za niski – uczestnik musi mieć przynajmniej 18 lat.”. Użytkownik rozumie, że jeśli wpisane ma 15, to nie spełnia warunku i raczej tu nic nie poradzi (poza przerwaniem rejestracji – bo dziecko za młode).
Przykłady dobrych zastosowań:
– Formularz adresowy: użytkownik wpisuje „Warszwa” – literówka w mieście. System wyłapuje, że takiego miasta nie ma i sugeruje: „Czy chodziło Ci o: Warszawa?”. Podobnie, jak wiele stron robi z literówkami. Osoba z dysleksją zrobiła błąd, ale nie musi się trudzić – dostaje propozycję poprawnej pisowni[27].
– Pola z określonym formatem: np. numer telefonu. Jeśli user wpisze tylko 6 cyfr, komunikat: „Numer telefonu powinien mieć 9 cyfr – sprawdź, czy wpisałeś pełny numer.” To nie tylko stwierdza błąd („zły format”), ale też mówi co jest nie tak (za mało cyfr) i co zrobić (wpisać pełny numer).
– Pola wybierane: np. user w polu daty urodzenia wybrał rok 2023 (przez pomyłkę – myślał miesiąc?). Komunikat: „Data urodzenia wskazuje, że masz 0 lat – upewnij się, że podałeś poprawną datę w formacie DD.MM.RRRR.” – tu system logicznie sprawdził i sugeruje, że pewnie pomylił format lub wybrał zły rok.
– Bardziej zaawansowane: user wpisuje „Feb 30, 2020” – system: „Luty 2020 ma 29 dni, skorygowano datę na 29/02/2020, proszę potwierdzić.” – wow, to już autokorekta prawie. Ale to by spełniło 3.3.3 z nawiązką, bo nie dość że sugestia, to i naprawa proponowana.
Typowe błędy:
– Błędy sygnalizowane, ale bez sugestii: np. tylko „Niepoprawny format danych” – user (zwłaszcza poznawczo ograniczony) myśli: „no ok, ale co źle zrobiłem?”. 3.3.3 wymagałoby np. „Niepoprawny format – użyj formatu YYYY-MM-DD.”.
– Sugestia ogólnikowa lub niepraktyczna: np. „Sprawdź poprawność danych.” – to nie jest sugestia, to upomnienie. Lepiej konkretnie: „Kod pocztowy powinien mieć format 00-000.”
– Brak mechanizmu sprawdzającego literówki czy powszechne błędy tam, gdzie to możliwe. Np. e-mail z literówką w domenie („gmail.con”) – dość standardowe. W AA warto by podpowiedzieć: „Czy na pewno adres jest poprawny? Może literówka w domenie?” – wiele serwisów do tego poziomu nie idzie, ale AAA raczej by do tego dążyło. AA oczekuje sugestii tam, gdzie łatwo (literówki, formaty, zakres liczb).
(Trzeba pamiętać: 3.3.3 mówi „jeśli są znane i jest to możliwe, to sugeruj”. Nie oczekuje sztucznej inteligencji, co odgadnie co user myślał. Np. jak wpisze kompletnie randomowy ciąg w imieniu – system nie zasugeruje, bo nie wie. Ale jak np. pole wymaga liczb 1-5, a user da 7 – to system może zasugerować „dozwolone wartości: 1-5”.)
3.3.4 Zapobieganie błędom (prawnym, finansowym, w danych) (poziom AA)
Cel i istota: Dla operacji, które mogą skutkować poważnymi konsekwencjami (prawnymi, finansowymi lub np. trwałą zmianą/daniem wrażliwych danych), interfejs powinien zapewnić mechanizmy zapobiegania błędom. To znaczy: możliwość potwierdzenia lub sprawdzenia danych przed finalizacją, możliwość anulowania, lub weryfikację danych przez system. Osoby z niepełnosprawnościami poznawczymi mogą łatwiej popełnić pomyłkę w takich krytycznych sytuacjach – więc interfejs musi je „ubezpieczyć” przed skutkami. Np. wypełniając deklarację podatkową, użytkownik może niechcący wpisać o jedno zero za dużo w kwocie – mechanizm walidacji/sprawdzenia pozwoli to wyłapać i poprawić, zamiast od razu wysłać i potem mieć kłopoty z urzędem.
Przykłady dobrych zastosowań:
– Formularz zaciągnięcia kredytu – przed ostatecznym zatwierdzeniem wyświetla się podsumowanie: kwota, okres, koszty, i wymaga kliknięcia „Potwierdzam, biorę kredyt”. Użytkownik ma szansę przejrzeć i zauważyć ewentualny błąd (np. pomyłka kwoty). Bez tego potwierdzenia, jedno złe kliknięcie mogłoby od razu zaciągnąć zobowiązanie finansowe.
– Sklep internetowy – przed finalnym „Kupuję i płacę” pokazuje stronę z adresami, metodą płatności i listą produktów oraz sumą. Klient, szczególnie ktoś chaotyczny w myśleniu, może tu zorientować się: „o, mam 2 sztuki tego produktu zamiast 1, poprawię koszyk zanim zatwierdzę”.
– Edycja ważnych danych (np. usunięcie konta, zmiana adresu do wysyłki): po kliknięciu „Usuń konto” wyskakuje okno „Czy na pewno chcesz usunąć konto? To działanie jest nieodwracalne. Wpisz 'USUN’ aby potwierdzić.”. To wielostopniowe potwierdzenie minimalizuje ryzyko błędu i przypadkowości. Osoba z impulsywnością (to może być objaw niektórych zaburzeń) nie zrobi tak łatwo tego pochopnie.
– System do wypełniania wniosku wizowego – na końcu daje przycisk „Sprawdź wprowadzone dane”. Klikając go, system highlightuje pola, które mogą budzić wątpliwość (np. PESEL ma złą cyfrę kontrolną) i prosi o weryfikację. To pomaga wychwycić literówki w krytycznych polach zanim wniosek pójdzie do urzędu.
Typowe błędy:
– Brak strony przeglądu/przedstawienia skutków przed finalizacją. Np. witryna od razu wykonuje transakcję po kliknięciu „Kup teraz” i obciąża kartę, bez ostatniego ekranu z potwierdzeniem zamówienia. Ktoś mógł np. błędnie wybrać adres, a już poszło. W AA to naruszenie, bo zakupy to czynność finansowa – powinna być możliwość sprawdzenia.
– Potwierdzenia zbyt subtelne lub mylące. Np. okienko „Na pewno?” bez wyjaśnienia, co się stanie. Osoba może nie w pełni zrozumieć, że kliknęła właśnie permanentne usunięcie danych. Komunikat powinien być jasny: „Czy na pewno chcesz usunąć to zamówienie? Ta operacja jest nieodwracalna.”.
– Brak możliwości poprawy po wysłaniu. O ile to zależy od systemu, ale np. złożenie deklaracji podatkowej – mogłaby być funkcja „edytuj przed zatwierdzeniem” lub w pewnym terminie, etc. Jeśli system nic takiego nie oferuje (bo „nie musi”), to jest mniej przyjazny kognitywnie. AA wymaga minimalnie pewnych mechanizmów prewencji, nie koniecznie edycji post factum, ale to by było plus.
(UWAGA: 3.3.4 dotyczy kluczowych operacji: prawnych, finansowych, danych suuuuuper krytycznych. Nie wszystkiego. Nie musimy potwierdzenia kasowania maila w skrzynce, bo to odwracalne i drobne. Ale już kasowanie konta e-mail – tak, bo utrata danych).
3.3.5 Pomoc (poziom AAA)
Cel i istota: Dla skomplikowanych lub nietypowych procesów w interfejsie powinny być dostępne dodatkowe wskazówki lub pomoc kontekstowa. Chodzi o to, by użytkownik mógł łatwo uzyskać wyjaśnienia lub wskazówki, jeśli nie rozumie jak wypełnić dany formularz lub co oznacza dana sekcja. Dla osób z niepełnosprawnościami poznawczymi to szczególnie ważne: mogą potrzebować bardziej łopatologicznego wyjaśnienia zadania albo przypomnienia krok po kroku. Zapewnienie łatwo dostępnej pomocy (np. ikona ’?’ obok trudnych sekcji, infolinia, czat do pytania) sprawia, że tacy użytkownicy nie utkną bezradnie.
Przykłady dobrych zastosowań:
– Formularz podatkowy online: obok pól są ikony „?”, na które można najechać lub kliknąć, by zobaczyć opis co wpisać, ewentualnie przykłady. Np. przy polu „Koszty uzyskania” – tooltip: „Wpisz sumę kosztów poniesionych w związku z uzyskaniem przychodu, np. opłaty, materiały. Jeśli nie masz kosztów – wpisz 0.”. Osoba, która nie wie co to „koszty uzyskania”, może z tego opisu zrozumieć.
– Sekcja serwisu dedykowana wsparciu: np. „Masz problem z wypełnieniem? Zobacz przewodnik krok po kroku [tutaj].” – i link do strony tutorialowej. Dla kogoś z problemami przetwarzania złożonych instrukcji, taki przewodnik (najlepiej graficznie zilustrowany) może pomóc.
– Wysuwany panel pomocy kontekstowej: np. po prawej stronie strony jest zakładka „Pomoc”. Kliknięcie otwiera panel z listą najczęściej zadawanych pytań i odpowiedzi, lub możliwością wyszukania pomocy. Użytkownik nie musi opuszczać bieżącej strony, by poszukać instrukcji. Osoba z ADHD doceni, bo nie rozproszy się przeniesieniem do innej sekcji – pomoc jest tuż obok.
– Dostęp do realnego wsparcia: AAA mógłby sugerować np. czat z konsultantem lub telefon, jeśli ktoś utknie. Np. „Nie wiesz jak uzupełnić? Zadzwoń na infolinię 800-…” – to wykracza poza interfejs czysto, ale zapewnia dostęp do pomocy ludzkiej, co może być ostatecznym ratunkiem.
Typowe błędy:
– Brak jakiejkolwiek dostępnej pomocy. Formularz jest zawiły, a nigdzie nie ma wyjaśnień, FAQ, nic. Użytkownik musi radzić sobie sam lub szukać w Google. W AAA to poważny minus – spodziewamy się, że powinna być wbudowana pomoc.
– Pomoc jest, ale trudno dostępna lub niekonkretna. Np. link do „Pomoc” prowadzi do strony głównej centrum pomocy, gdzie trzeba ręcznie szukać tematu – to już wysoki próg dla kogoś zagubionego. Lepsze by było link od razu do odpowiedniego artykułu, jak w przykładzie powyżej.
– Język pomocy równie skomplikowany jak oryginał. Jeśli pomoc używa żargonu i formalizmów, to nie spełnia roli. Powinna być prostszym językiem, może krokami, z przykładami. Błędem jest np. w pomocy do formularza podatkowego wkleić definicję ustawy o podatku – to przecież to samo niezrozumiałe, co treść formularza.
– Nieaktualna lub myląca pomoc. Czasem interface się zmienia, a pomoc nie. Np. instrukcja mówi „kliknij zielony przycisk w prawym dolnym rogu”, a guzik jest niebieski u góry. To wprowadzi w błąd. Trzeba dbać o spójność instrukcji z rzeczywistością.
3.3.6 Zapobieganie błędom (wszystkim) (poziom AAA)
Cel i istota: Rozszerzenie 3.3.4 – na poziomie AAA zaleca się stosować środki zapobiegania błędom nie tylko w krytycznych kontekstach (prawnych/finansowych), ale we wszystkich kontekstach. Innymi słowy, wszędzie tam gdzie użytkownik może zrobić błąd, interfejs powinien pomagać go uniknąć lub naprawić. Jest to szczególnie korzystne dla osób z niepełnosprawnościami poznawczymi, bo minimalizuje frustrację i poprawia skuteczność korzystania z serwisu. Obejmuje to np. możliwość edycji/wycofania nawet drobnych akcji, potwierdzenia przed operacjami nieodwracalnymi w każdym przypadku (nie tylko krytycznych), szerzej rozumianą tolerancję na błędy.
Przykłady dobrych zastosowań:
– Forum internetowe – AAA mogłoby wymagać opcji edycji lub usunięcia własnego postu w rozsądnym czasie. Jeśli użytkownik (np. z dysleksją) napisał posta z błędami, ma 5 minut by go poprawić. To zapobiegnie ewentualnym problemom (np. nieporozumieniom) wynikającym z literówek czy źle sformułowanych myśli.
– E-mail – pozwolenie na cofnięcie wysyłki przez kilka sekund (jak oferuje Gmail „Cofnij wysyłanie”). Ktoś może zreflektować się tuż po kliknięciu „Wyślij”, że dodał zły załącznik. AAA docenia mechanizmy typu undo dla każdej akcji, bo ludzie popełniają błędy wszędzie, nie tylko w sprawach bankowych.
– Koszyk zakupów – możliwość zwrotu/cancelacji zamówienia przez jakiś czas lub łatwa procedura zwrotu. To wykracza poza interfejs natychmiastowy, ale jest w duchu AAA: minimalizować szkody błędnych decyzji. Człowiek może zamówić zły produkt przez pomyłkę – serwis AAA stara się umożliwić korektę (np. anuluj zamówienie w ciągu godziny bez problemu).
– W formularzach – tryb „podglądu przed wysłaniem” nie tylko dla krytycznych, ale i np. dla komentarza bloga (żeby zobaczyć jak będzie wyglądać). Dla kogoś, kto ma trudność z autopoprawą, to cenna funkcja: może zobaczyć i poprawić, zamiast opublikować z błędami.
Typowe błędy:
– Ograniczanie mechanizmów undo/redo tylko do wybranych funkcji zamiast generalnie. AAA aspiruje do tego, by jak najwięcej czynności dało się odwrócić lub potwierdzić. Brak takiej możliwości w drobnych rzeczach to w AAA „można lepiej”. Np. aplikacja do pisania – brak „Cofnij” to by było mocno niezgodne z duchem AAA (i w ogóle z użytecznością).
– Akcje natychmiastowe i nieodwracalne nawet w błahostkach. Np. czat, gdzie po naciśnięciu Enter od razu idzie wiadomość i nie można jej usunąć – AAA by pewnie wolało, żeby była jednak możliwość edycji/usunięcia (bo ktoś mógł się przejęzyczyć).
– Ogólnie, AAA to wysoki ideał: błąd to ludzka rzecz, więc interfejs powinien być wyrozumiały i pomocny zawsze. Błędem byłoby więc jeśli gdziekolwiek interfejs „kara” użytkownika za błąd bez możliwości ratunku. Np. wypełnia długi formularz, kliknął niechcący „reset” i wszystko przepadło – AAA by wolało dopytać „na pewno chcesz skasować wszystkie dane?” i/lub dać możliwość przywrócenia.
– (W praktyce mało serwisów spełnia 3.3.6 w pełni, bo to trudne i nie zawsze sensowne. Ale to wyznacza kierunek: maximum fail-safe design.)
[1] Web Content Accessibility Guidelines (WCAG) 2.1
[2] [18] Wytyczne dla dostępności treści internetowych (WCAG) 2.1
https://www.w3.org/Translations/WCAG21-pl/
[3] [10] [14] [16] [17] [20] [27] [28] Web Content Accessibility Guidelines – WCAG Standards
https://reciteme.com/us/news/understanding-the-web-content-accessibility-guidelines-wcag/
[4] [5] [6] [7] [8] [9] [13] [15] WCAG 2.1: Success Criteria for Cognitive Disabilities – TPGi
https://www.tpgi.com/wcag-2-1-success-criteria-for-cognitive-disabilities/
[11] Understanding Success Criterion 2.1.4: Character Key Shortcuts | WAI
https://www.w3.org/WAI/WCAG21/Understanding/character-key-shortcuts.html
[12] 2.1.4 Character Key Shortcuts | Vially
https://vially.io/services/wcag-2-1-4
[19] Understanding WCAG 2.1 – Reviewing Cognitive Success Criteria
https://www.deque.com/blog/understanding-wcag-2-1-reviewing-cognitive-success-criteria/
[21] [22] [23] [24] Understanding Success Criterion 3.2.1: On Focus | WAI | W3C
https://www.w3.org/WAI/WCAG21/Understanding/on-focus.html
[25] WCAG (Level AA) SC 3.2.3 Consistent Navigation – AccessiCart
https://accessicart.com/wcag-level-aa-sc-3-2-3-consistent-navigation/
[26] consistent-navigation-layout | BrowserStack Docs
https://www.browserstack.com/docs/accessibility/rules/a11y-engine/3.3/consistent-navigation-layout