Zasady WCAG – kryteria sukcesu istotne dla użytkowników niewidomych

Web Content Accessibility Guidelines (WCAG) to zbiór wytycznych mających na celu zapewnienie dostępności treści internetowych dla osób o różnych niepełnosprawnościach. W niniejszym raporcie skupiono się na kryteriach sukcesu WCAG istotnych z punktu widzenia osób niewidomych – czyli użytkowników, którzy nie widzą treści strony i korzystają głównie z technologii asystujących, takich jak czytniki ekranu lub brajlowskie linijki. Wymieniono kryteria ze wszystkich poziomów zgodności (A, AA, AAA), jednak pominięto te, które dotyczą wyłącznie innych rodzajów niepełnosprawności (np. napisy dla niesłyszących czy kontrast dla słabowidzących). Dla każdego kryterium podano jego numer i nazwę, wyjaśniono cel z perspektywy osoby niewidomej oraz przedstawiono przykłady prawidłowych realizacji i typowych błędów.

Kryteria sukcesu poziomu A istotne dla osób niewidomych

1.1.1 Treść nietekstowa (Poziom A)

Cel i istota: Zapewnienie tekstowego odpowiednika dla wszystkich treści, które nie są tekstem (obrazy, grafiki, ikony, wykresy itp.). Dzięki temu osoba niewidoma korzystająca z czytnika ekranu może „usłyszeć” opis elementu graficznego i zrozumieć jego znaczenie. Alternatywa tekstowa (np. atrybut alt obrazka) powinna przekazywać tę samą informację lub funkcję, jaką pełni dany element wizualny. Bez takiego opisu czytnik ekranu pominie grafikę lub odczyta jedynie jej nazwę pliku, co nie dostarcza żadnej użytecznej informacji.

Przykłady dobrych zastosowań:
– Dodanie zwięzłego, lecz opisowego tekstu alternatywnego do istotnych obrazów (np. alt=”Zdjęcie zabytkowego ratusza w Poznaniu” dla fotografii na stronie turystycznej).
– Zastosowanie pustego alt=”” dla grafik czysto dekoracyjnych, aby zostały pominięte przez czytniki ekranu (nie zagłuszając treści).
– Opisanie ikon przycisków (np. ikony „drukuj”, „udostępnij”) za pomocą aria-label lub ukrytego tekstu, jeśli nie towarzyszy im widoczny podpis.

Typowe błędy:
– Brak atrybutu alt przy istotnych obrazach – czytnik odczytuje wtedy jedynie „graphic” lub nazwę pliku, co nic nie mówi osobie niewidomej o zawartości grafiki.
– Używanie opisów alternatywnych zbyt ogólnych lub bezużytecznych (np. alt=”obrazek” albo alt=”zdjęcie” zamiast opisania, co znajduje się na zdjęciu).
– Umieszczanie tekstu w formie obrazu bez dostarczenia jego tekstowego odpowiednika. Jeśli np. na grafice jest ważne hasło promocyjne, należy podać je również w tekście (albo przynajmniej w alt obrazu).

1.2.1 Tylko audio lub tylko wideo (nagranie) (Poziom A)

Cel i istota: Zapewnienie alternatywy dla treści multimedialnych, które pozbawione są jednej ze składowych (tylko dźwięk lub tylko obraz). Dla osób niewidomych szczególnie istotne jest zapewnienie opisu materiałów wideo pozbawionych dźwięku. Jeśli na stronie osadzono nagranie wideo bez ścieżki audio (np. animacja, sam obraz), to niewidomy użytkownik potrzebuje opisu treści tego nagrania. Kryterium wymaga, by dostarczyć alternatywę tekstową albo audiodeskrypcję dla takiego materiału wideo, dzięki czemu osoba niewidoma pozna przekaz wizualny. (Analogicznie, w przypadku nagrania dźwiękowego bez warstwy wizualnej wymagany jest transkrypt tekstowy, ale to dotyczy głównie osób niesłyszących.)

Przykłady dobrych zastosowań:
– Dołączenie opisu w tekście obok osadzonego nagrania wideo prezentującego np. postęp jakiegoś procesu (gdy wideo nie ma narracji). Taki opis streszcza, co dzieje się na ekranie.
– Udostępnienie osobnej ścieżki audio z narracją opisującą obraz (audiodeskrypcja) dla filmu instruktażowego pozbawionego komentarza słownego.
– Oznaczenie multimediów spełniających rolę czysto dekoracyjną lub będących alternatywą dla już istniejącego tekstu jako takie (by było jasne, że dodatkowy opis nie jest wymagany).

Typowe błędy:
– Osadzenie na stronie cichego filmu (np. klip wideo ze scenami przyrody bez lektora) bez żadnego podpisu, opisu czy audiodeskrypcji. Osoba niewidoma nie ma wtedy możliwości dowiedzieć się, co przedstawia film.
– Uznanie, że sam tytuł wideo wystarczy – tytuł (np. „Widok z drona – park narodowy”) może dać ogólne pojęcie, ale nie zastąpi pełnego opisu scen, jeśli niosą one istotne informacje.
– Traktowanie transkrypcji dźwięku jako wystarczającej alternatywy w przypadku filmów niemych. Dla filmu bez dźwięku potrzebny jest opis obrazu, a nie transkrypcja (bo nie ma czego transkrybować).

1.2.3 Audiodeskrypcja lub alternatywa tekstowa dla mediów (nagranie) (Poziom A)

Cel i istota: Udostępnienie osobom niewidomym treści zawartych w nagraniach wideo (ze ścieżką audio), jeśli ważne informacje przekazywane są wyłącznie wizualnie. Gdy film zawiera narrację/voice-over opisujący wszystko, co istotne, osoby niewidome go zrozumieją ze słuchu. Jeśli jednak w filmie są elementy wizualne nieomówione w dźwięku (np. napisy pojawiające się na ekranie, ważna akcja bez komentarza), to kryterium 1.2.3 wymaga dostarczenia dodatkowego opisu tych wizualnych treści. Może to być alternatywa tekstowa (szczegółowy opis filmu w formie tekstu) lub audiodeskrypcja – dodatkowa ścieżka audio opisująca obraz[7][8]. Dzięki temu użytkownik niewidomy nie ominie kluczowych informacji prezentowanych jedynie wizualnie.

Przykłady dobrych zastosowań:
– Opublikowanie pod filmem pełnego opisu tekstowego tego, co dzieje się na ekranie (jeśli film nie jest w pełni samowyjaśniający się dźwiękiem). Taki opis stanowi alternatywę, którą czytnik ekranu odczyta osobie niewidomej.
– Przygotowanie drugiej wersji filmu z osadzoną audiodeskrypcją (lub możliwości jej włączenia). Np. film edukacyjny ma wariant z dodatkowym lektorem opisującym ważne sceny.
– Zwrócenie uwagi już na etapie tworzenia filmu, by kluczowe informacje nie były zawarte jedynie w warstwie wizualnej – wtedy może wystarczyć sama ścieżka dźwiękowa bez dodatkowej audiodeskrypcji.

Typowe błędy:
– Publikacja filmu, w którym pojawiają się istotne napisy na ekranie (np. cytaty, wyniki, nazwiska mówców), bez zapewnienia, że lektor je odczyta lub bez dostarczenia transkrypcji tych informacji.
– Założenie, że napisy dla niesłyszących (transkrypcja dialogów) rozwiązują problem dla niewidomych – napisy wideo nie pomogą osobie niewidomej, jeśli nie ma oddzielnego opisu elementów wizualnych.
– Brak jakiejkolwiek informacji o treści wizualnej filmu. Osoba niewidoma słysząc dialogi może nie zrozumieć kontekstu scen, jeśli np. ważna akcja odbywa się bez słów.

1.3.1 Informacje i relacje (Poziom A)

Cel i istota: Zapewnienie semantycznej struktury treści, tak aby relacje między elementami i ich znaczenie były rozumiane przez technologie asystujące. Osoby niewidome nie widzą wizualnego formatowania (np. nagłówków, list, tabel, przycisków), ale czytnik ekranu może przekazać im te strukturalne informacje, jeśli strona jest poprawnie zbudowana. Dzięki właściwym znaczniko­m HTML (nagłówki <h1>-<h6>, listy <ul>/<ol>, tabele z <th> itp.) strona jest odczytywana w logiczny, zrozumiały sposób – np. pozwala szybko przeskakiwać między nagłówkami sekcji lub zrozumieć hierarchię informacji[9]. Kryterium to ma zagwarantować, że informacje nie są przekazywane wyłącznie poprzez prezentację wizualną, ale są zakodowane w strukturze, co czyni je dostępnymi dla czytników ekranu.

Przykłady dobrych zastosowań:
– Stosowanie nagłówków HTML do tytułów i podrozdziałów strony (zamiast np. tylko powiększonej czcionki). Poprawnie oznaczone nagłówki pozwalają niewidomemu nawigować po sekcjach za pomocą skrótów klawiaturowych w czytniku.
– Używanie list HTML do wymieniania elementów (zamiast wstawiać ręcznie punktorów czy liczb). Czytnik poinformuje użytkownika np. „lista z 5 elementami”, co daje mu kontekst struktury.
– Oznaczanie pól formularza etykietami (<label>) powiązanymi atrybutem for z danym polem. Zapewnia to, że czytnik odczyta nazwę pola wejściowego[10][11].

Typowe błędy:
– Używanie zwykłego tekstu o dużym rozmiarze lub pogrubieniu zamiast faktycznych nagłówków – osoba niewidoma nie będzie wiedziała, że dany tekst jest tytułem sekcji, ponieważ dla czytnika to wciąż zwykły akapit.
– Niewłaściwe użycie tabel do układania zawartości strony (layoutu). Powoduje to, że czytnik może odczytywać fragmenty w dziwnej kolejności kolumnami lub wstawiać komunikaty o nagłówkach kolumn tam, gdzie to nie pasuje.
– Brak logicznej hierarchii w nagłówkach (np. przeskok od <h1> od razu do <h4>). Taka struktura utrudnia budowanie mapy strony w głowie użytkownika niewidomego.

1.3.2 Zrozumiała kolejność (Poziom A)

Cel i istota: Zapewnienie, że kolejność odczytu treści przez technologie asystujące odpowiada logicznej kolejności prezentacji treści. Osoby widzące mogą wykorzystać układ graficzny strony (pozycje bloków, kolumny itp.) do zrozumienia relacji między elementami. Natomiast dla użytkownika czytnika ekranu liczy się kolejność elementów w kodzie HTML, ponieważ czytnik odczytuje zawartość liniowo, zgodnie z kolejnością w DOM[12][13]. Kryterium wymaga, by ta kolejność była logiczna i sensowna bez arkuszy stylów – czyli nawet gdy odłączymy CSS, treść powinna zachować czytelny przekaz[14]. W praktyce chodzi o to, by nie rozmieszczać ważnych informacji wyłącznie poprzez CSS w miejscu innym niż w strukturze kodu. Niezachowanie właściwej kolejności może dezorientować osoby niewidome, bo usłyszą informacje w chaotycznym, niespójnym porządku[13][15].

Przykłady dobrych zastosowań:
– Układanie elementów na stronie w HTML w takiej kolejności, w jakiej powinny być logicznie odczytywane. Jeśli np. na górze strony wizualnie są dwa panele obok siebie (kolumny), to w kodzie HTML ich zawartość powinna następować jedna po drugiej w sensownej kolejności (najpierw ta, którą chcemy przedstawić jako pierwszą).
– Stosowanie CSS do zmiany układu (np. kolumny flexbox/grid), ale tylko jeśli nie zaburzy to znaczenia kolejności. Zasada: po wyłączeniu CSS treść nadal powinna mieć sens (ciągłość narracji).
– Gdy wyświetlane są dynamiczne elementy (np. okienko tooltip po najechaniu lub modal po kliknięciu), zadbanie by były one w kodzie tam, gdzie koncepcyjnie pasują lub by ich pojawienie się przenosiło fokus – tak, aby czytnik odczytał je we właściwym momencie[16].

Typowe błędy:
– Przemieszczanie elementów ważnych wizualnie na stronie wyłącznie za pomocą CSS, bez zmiany kolejności w HTML. Np. istotny komunikat jest umieszczony w kodzie na końcu strony, ale CSS-em wyświetlany na górze – czytnik przeczyta go dopiero na końcu, więc użytkownik może go nie powiązać z kontekstem.
– Wstawianie treści, która powinna być czytana ciągiem, w przeplataną strukturę (np. przeplatanie fragmentów tekstu kodem HTML tabeli lub innym układem, który rozrywa logiczną narrację).
– Brak uwzględnienia kolejności focusa przy elementach interaktywnych – jeśli modalne okno otwiera się na wierzchu, ale fokus nie zostanie do niego przeniesiony, użytkownik klawiatury (w tym niewidomy) może „ominąć” odczytanie jego treści, bo czytnik nadal podąża za elementami pod spodem.

1.3.3 Właściwości zmysłowe (Poziom A)

Cel i istota: Uniezależnienie przekazu od cech percepcyjnych, takich jak kolor, kształt, rozmiar, położenie czy dźwięk. Osoba niewidoma nie widzi kolorów ani kształtów, zatem jeśli instrukcje lub informacje opierają się tylko na takich cechach („kliknij zielony przycisk w prawym górnym rogu”), to będą dla niej bezużyteczne. Kryterium wymaga, by informacje korzystające z cech zmysłowych były dostępne również w innej formie, niewizualnej. Innymi słowy, opisy i instrukcje powinny być deskryptywne w sposób niezależny od wzroku – odwoływać się do etykiet, nazw czy funkcji elementów zamiast wyłącznie do ich wyglądu lub położenia.

Przykłady dobrych zastosowań:
– Zamiast pisać „ważne informacje są zaznaczone kolorem czerwonym”, lepiej napisać „ważne informacje są oznaczone ikoną wykrzyknika i pogrubieniem” – tak, aby także niewidomi mogli to wychwycić (przez ikonę z alt i zmianę tonu czytnika dla pogrubienia).
– Podczas opisywania interfejsu unikać wyrażeń typu „po prawej znajduje się panel” bez dodatkowego kontekstu. Lepiej: „na stronie znajduje się panel Filtrowanie wyników (z prawej strony)”, czyli podać nazwę panelu.
– Jeśli pole formularza obowiązkowe oznaczamy kolorem (czerwoną obwódką), to dodajmy również komunikat tekstowy „(wymagane)” w etykiecie lub atrybut aria-required=”true”.

Typowe błędy:
– Instrukcje w stylu: „Wybierz opcję oznaczoną zielonym kwadratem” – dla niewidomego takie wskazanie jest niemożliwe do zinterpretowania (powinno się podać np. tekst etykiety opcji).
– Określanie błędów w formularzu tylko poprzez kolor pól (np. czerwone tło) bez komunikatu tekstowego – użytkownik niewidomy nie dowie się, które pole zawiera błąd, jeśli usłyszy tylko ponowną prośbę o wysłanie formularza bez wskazówek.
– Poleganie na samych dźwiękach w interfejsie (np. sygnał dźwiękowy oznaczający ukończenie zadania) bez alternatywy wizualnej lub tekstowej. Niewidomy być może usłyszy dźwięk, ale nie wszyscy użytkownicy używają głośników; ponadto nie każdy dźwięk jest jednoznaczny w przekazie.

1.4.1 Użycie koloru (Poziom A)

Cel i istota: Zagwarantowanie, że kolor nie jest jedynym nośnikiem informacji. Ponieważ osoby niewidome w ogóle nie widzą (a osoby słabowidzące czy daltoniczne mogą nie rozróżniać barw), przekazywanie istotnych treści wyłącznie za pomocą różnic kolorystycznych powoduje ich całkowitą utratę dla tych użytkowników. Kryterium wymaga więc, by wszystkie informacje zakodowane kolorem były dostępne także w inny sposób – np. poprzez tekst, symbole, wzorce czy etykiety. Dzięki temu użytkownik niewidomy odbierze tę informację np. poprzez czytnik ekranu, który odczyta dodatkowy tekst opisujący stan elementu (zamiast polegać na kolorze). Ważne komunikaty nie mogą zależeć tylko od barwy tła czy tekstu[17][18].

Przykłady dobrych zastosowań:
– Oznaczenie linków nie tylko kolorem, ale i dodatkowym stylem (np. podkreśleniem). Osoba niewidoma i tak usłyszy przez czytnik, że to link, jednak rozwiązanie to pomaga też osobom słabowidzącym i zapewnia konsekwencję – link rozpoznawalny jest nie tylko barwą.
– Wykorzystanie kształtu lub tekstury obok koloru w grafice przekazującej informacje. Np. na wykresie słupkowym różne kategorie oprócz kolorów są oznaczone różnymi wzorkami lub podpisami – dzięki temu opis tekstowy może te różnice przekazać (np. „zielony prążkowany słupek – kategoria A, niebieski kropkowany słupek – kategoria B”).
– Pola formularza z błędami oznaczone kolorem oraz komunikatem tekstowym (np. „Błąd: to pole jest wymagane”). Czytnik odczyta komunikat, więc użytkownik wie, w którym polu wystąpił problem, zamiast polegać na czerwonym kolorze obramowania.

Typowe błędy:
– Podawanie instrukcji typu „Wymagane pola są zaznaczone na czerwono” – dla osoby niewidomej ta informacja jest nieprzydatna, bo nie ma innego sposobu identyfikacji tych pól.
– W samym tekście odwoływanie się do kolorów („patrz fragment zaznaczony żółtym kolorem…”) zamiast opisowo wskazać fragment. Niewidomy nie wie, który fragment jest żółty.
– Legenda do wykresu oparta tylko na kolorach (np. „czerwony – sprzedaż 2024, zielony – sprzedaż 2025”) bez dodatkowych oznaczeń. Osoba niewidoma, słuchając opisu takiego wykresu, nie rozróżni serii danych, jeśli będą referowane jedynie barwami.

1.4.2 Kontrola odtwarzania dźwięku (Poziom A)

Cel i istota: Zapewnienie użytkownikowi możliwości wyłączenia, zatrzymania lub przyciszenia dźwięku, który uruchamia się automatycznie na stronie. Dla osoby niewidomej korzystającej z czytnika ekranu jest to szczególnie ważne – jednoczesne odtwarzanie niespodziewanego audio i komunikatów czytnika powoduje chaos i utrudnia zrozumienie treści. Jeśli np. strona automatycznie odtwarza muzykę lub film, niewidomy użytkownik może mieć trudność ze zlokalizowaniem na szybko przycisku „Stop”, nie widząc go. Dlatego WCAG wymaga, by żaden dźwięk trwający dłużej niż 3 sekundy nie startował samoczynnie bez kontroli dla użytkownika[17][19]. Dzięki temu osoba niewidoma nie zostanie zagłuszona przez niechciany dźwięk i zachowa kontrolę nad tym, co słyszy.

Przykłady dobrych zastosowań:
– Nieodtwarzanie żadnego dźwięku automatycznie – zamiast tego umieszczenie widocznego i dostępnego za pomocą klawiatury przycisku „Odtwórz”, który użytkownik może wcisnąć, jeśli zechce.
– Zapewnienie mechanizmu globalnego wyciszenia (mute) lub pauzy dla multimediów. Np. gdy na stronie gra tło muzyczne, powinien być dostępny kontroler głośności albo przycisk „Wyłącz dźwięk”.
– Wyskakujące reklamy wideo z dźwiękiem (tzw. autoplay) całkowicie wyeliminowane lub domyślnie wyciszone, dopóki użytkownik sam nie aktywuje dźwięku.

Typowe błędy:
– Strona automatycznie odtwarza nagranie audio (np. podcast, utwór muzyczny) natychmiast po załadowaniu, bez opcji pauzy. Osoba niewidoma traci wtedy możliwość korzystania z czytnika (obie ścieżki dźwiękowe się nakładają).
– Umieszczenie odtwarzacza audio/wideo, który zaczyna grać po kilku sekundach, a przy tym przycisk stop jest słabo dostępny – np. wymaga najechania myszą. Użytkownik niewidomy może nie zdążyć w porę zatrzymać dźwięku.
– Animowane reklamy z dźwiękiem, które trudno zlokalizować na stronie (brak natychmiastowego fokusu na nie). Powoduje to, że niewidomy słyszy dźwięk, ale może nie wiedzieć skąd pochodzi ani jak go wyłączyć.

2.1.1 Klawiatura (Poziom A)

Cel i istota: Zapewnienie pełnej dostępności funkcji strony za pomocą klawiatury. Osoby niewidome zazwyczaj nie korzystają z myszy – poruszają się po stronie tabulatorem (Tab) i innymi klawiszami, a czytnik ekranu informuje je o aktywnym elemencie[20][21]. Jeśli jakaś funkcjonalność (link, przycisk, rozwijane menu, kontrolka multimediów, itp.) nie jest dostępna przez klawiaturę, to dla niewidomego praktycznie nie istnieje. Kryterium 2.1.1 wymaga, by wszystko co interaktywne dało się obsłużyć z poziomu klawiatury (czy to poprzez standardowe focuse na elementach HTML, czy poprzez własne mechanizmy obsługi zdarzeń klawiszy). Dzięki temu użytkownik niewidomy może nawigować i korzystać ze strony bez potrzeby widzenia ekranu.

Przykłady dobrych zastosowań:
– Upewnienie się, że każdy link i przycisk na stronie można kliknąć, używając klawisza Enter lub Spacja, gdy element ma fokus (co standardowo zapewniają natywne elementy HTML typu <a> czy <button>).
– Tworzenie rozwijanych menu, które otwierają się zarówno przy najechaniu myszą, jak i po naciśnięciu Enter/Spacji na fokusowanym elemencie menu. Ponadto umożliwienie poruszania się po opcjach menu strzałkami w dół/górę.
– Zapewnienie kontroli nad odtwarzaczami multimedialnymi z klawiatury (np. Play/Pauza przypisane do przycisku, który otrzymuje fokus i można go aktywować klawiaturą).

Typowe błędy:
– Element interaktywny (np. niestandardowy przycisk zbudowany ze <div>) reaguje tylko na kliknięcie myszą, bo deweloper nie przewidział obsługi zdarzenia klawisza. W efekcie fokus może co prawda na nim stanąć, ale naciśnięcie Enter nic nie robi – dla użytkownika klawiatury element jest martwy.
– Część zawartości (np. panel boczny) staje się widoczna dopiero po najechaniu kursorem – użytkownik niewidomy korzystający z klawiatury nigdy nie „najada” kursora, więc nie uaktywni tego panelu.
– Aplikacja internetowa wykorzystuje gesty myszą (drag & drop) bez alternatywy klawiaturowej. Np. żeby ułożyć listę elementów, trzeba je przeciągnąć – co jest niemożliwe do wykonania za pomocą klawiatury (chyba że przewidziano np. przyciski do przesuwania pozycji, co jest właściwym rozwiązaniem).

2.1.2 Bez pułapki na klawiaturę (Poziom A)

Cel i istota: Zapobieżenie sytuacji, w której użytkownik klawiatury zostaje „uwięziony” w jakimś obszarze strony i nie może z niego wyjść ani przejść dalej. Dla osoby niewidomej, nawigującej wyłącznie klawiaturą, pułapka taka oznacza zablokowanie dostępu do pozostałej zawartości serwisu. Kryterium wymaga, by focus (aktywny element) nie został zablokowany w żadnym miejscu – użytkownik zawsze powinien móc użyć np. klawisza Tab lub odpowiedniej kombinacji, aby przenieść focus poza dany komponent. Jeśli jakiś element (np. okno modalne, widżet) przechwytuje focus, to musi także zapewniać mechanizm jego opuszczenia (np. klawisz Escape zamykający okno).

Przykłady dobrych zastosowań:
– Implementacja wyskakujących okien dialogowych (modalnych) tak, by focus automatycznie przenosił się do okna przy otwarciu, a po zamknięciu wracał tam, skąd przyszedł. Użytkownik może opuścić okno klawiszem Escape bez problemu.
– Unikanie konstrukcji, w których elementy interaktywne mają niespójną nawigację Tab. Np. kontrolka typu „slider” (suwak) – powinno dać się z niej wyjść Tabem jak z innych elementów. Jeśli suwak wymaga strzałek do zmiany wartości, to Tab nadal powinien przenosić dalej po jednym naciśnięciu, a nie utknąć w obrębie suwaka.
– Testowanie aplikacji: próba przejścia klawiaturą kolejno przez całą stronę i sprawdzenie, czy w którymś miejscu focus nie krąży w kółko (np. między dwoma polami na zmianę) albo nie zatrzymuje się bez wyjścia.

Typowe błędy:
– Otwarcie okna modalnego, w którym fokus został zamknięty wewnątrz okna i nie przywrócono obsługi zamknięcia klawiszem (brak obsługi Escape). Użytkownik niewidomy po wejściu do takiego okna nie może go zamknąć ani przejść do niczego innego.
– Strona z niestandardowym układem nawigacji, gdzie klawisz Tab przestaje działać po wejściu do pewnej sekcji (np. focus wpada w element <iframe> bez mechanizmu wyjścia). Bez myszy użytkownik zostaje tam na zawsze, chyba że odświeży stronę.
– Użycie skryptu przechwytującego nadmiernie obsługę Tab (np. dla stworzenia niestandardowego sposobu poruszania się) i zapomnienie o sytuacjach brzegowych – focus może ominąć pewne elementy albo utknąć, jeśli skrypt nie przekazuje poprawnie zdarzeń.

2.1.4 Jednoznakowe skróty klawiaturowe (Poziom A)

Cel i istota: Zapobieganie konfliktom między wbudowanymi w stronę skrótami klawiszowymi (zwłaszcza jednoklawiszowymi), a nawigacją czytnika ekranu. Wielu użytkowników niewidomych korzysta ze skrótów klawiaturowych w czytnikach (np. klawisze liter H do przechodzenia między nagłówkami, K – linkami, B – przyciskami itp.). Jeśli strona internetowa zdefiniuje własny skrót na pojedynczy klawisz (np. naciśnięcie „1” rozwija menu, naciśnięcie „H” przenosi do strony głównej), to może to kolidować z trybem nawigacji czytnika. Kryterium wymaga, by takie skróty jednoklawiszowe były albo: a) wyłączalne/przestawialne, albo b) aktywowane tylko w określonym kontekście (np. po ustawieniu focusu na konkretnym elemencie)[22]. Dzięki temu osoba niewidoma może nadal używać znanych skrótów czytnika bez niechcianych efektów w działaniu strony.

Przykłady dobrych zastosowań:
– W aplikacji webowej, gdzie wprowadzono skróty (np. „N” = nowy dokument), dodanie opcji konfiguracji skrótów lub przestawienia ich na kombinacje z modifierem (np. Alt+N) zamiast pojedynczych liter.
– Unikanie domyślnego przechwytywania popularnych klawiszy jak H, B, L itp. – jeżeli konieczne, to przynajmniej ograniczenie ich działania tylko do momentu, gdy dany element ma fokus (np. listy wiadomości obsługiwane literami j/k jak w Gmail – ale tylko po wejściu w listę).
– Dokumentacja dla użytkownika informująca o wszystkich skrótach klawiaturowych strony oraz możliwości ich zmiany lub wyłączenia.

Typowe błędy:
– Strona rezerwuje klawisz „B” (bez modyfikatorów) do otwarcia bocznego panelu – użytkownik niewidomy, chcąc przejść do następnego przycisku (czytnik NVDA używa „B” do skoku do przycisku), nieświadomie ciągle otwiera i zamyka panel, dezorientując się co się dzieje.
– Ustawienie skrótu na klawisz „H” (home) w celu przewijania do góry – koliduje to z nawigacją nagłówków w czytniku, przez co niewidomy traci możliwość wygodnego przeglądu sekcji strony.
– Brak możliwości wyłączenia lub zmiany skrótów – nawet jeśli użytkownik zorientuje się o konflikcie, nie ma sposobu na dostosowanie strony do swoich potrzeb.

2.2.1 Dostosowanie czasu (Poziom A)

Cel i istota: Zapewnienie użytkownikom, którzy potrzebują więcej czasu (co dotyczy także osób niewidomych), możliwości wydłużenia limitów czasowych na stronie. Osoba niewidoma często nawigując za pomocą syntezatora mowy robi to wolniej niż przeciętny użytkownik widzący – np. wolniej wypełnia formularze, bo musi odsłuchać etykiety pól, instrukcje, komunikaty. Jeśli strona ma zdefiniowane limity (czas na wprowadzenie kodu, wygaśnięcie sesji, odliczanie na quiz itp.), powinny one być elastyczne. Kryterium wymaga umożliwienia wyłączenia, dostosowania lub przedłużenia limitu czasu (chyba że czas jest esencją usługi, np. gra czasu rzeczywistego). Dzięki temu użytkownik niewidomy może spokojnie przeczytać i zareagować na treści bez obawy, że coś mu zniknie sprzed oczu (uszu) zanim zdąży zareagować.

Przykłady dobrych zastosowań:
– Podczas logowania, jeśli sesja wygasa po 30 sekundach nieaktywności, wyświetlenie (i odczytanie przez czytnik) komunikatu z opcją „przedłuż sesję”, zanim nastąpi wylogowanie.
– W formularzu zamówienia online dodanie funkcji „przedłuż czas” gdy użytkownik nie zdąży wypełnić w porę – np. przy wykryciu bezczynności zapyta, czy potrzeba więcej czasu.
– Informowanie użytkownika od razu na początku o istnieniu ograniczenia czasu i sposobach jego wydłużenia lub wyłączenia.

Typowe błędy:
– Automatyczne wylogowanie użytkownika po krótkim czasie bezczynności bez ostrzeżenia. Osoba niewidoma może nawet nie zauważyć, że czas upłynął – wpisuje dalej dane, a po zatwierdzeniu okazuje się, że musi zalogować się ponownie i straciła wpisane informacje.
– Brak możliwości wstrzymania odliczania podczas rozwiązywania testu/quizu online. Użytkownik niewidomy, słuchając treści pytań i odpowiedzi, może nie nadążyć w limicie – a strona natychmiast kończy test po upływie czasu.
– Zbyt krótki czas domyślny na podjęcie akcji (np. baner cookie znikający po 5 sekundach). Osoba korzystająca z czytnika może nie przeczytać komunikatu dostatecznie szybko, by zareagować.

2.4.1 Możliwość pominięcia bloków (Poziom A)

Cel i istota: Ułatwienie nawigacji klawiaturą poprzez omijanie powtarzalnych sekcji strony. Osoby niewidome doceniają możliwość szybkiego przejścia od razu do głównej zawartości, pomijając np. nagłówek, menu czy bloki boczne pojawiające się na każdej podstronie[23]. Kryterium to najczęściej realizuje się poprzez tzw. skip link, czyli ukryty link „Przejdź do treści” dostępny od razu jako pierwszy element dla fokusu. Po aktywowaniu takiego linku focus przeskakuje do sekcji głównej, co oszczędza czas i zbędne klikanie Tab. Alternatywnie lub uzupełniająco stosuje się strukturalne elementy jak nagłówek główny czy landmarki ARIA (np. <main> dla treści głównej), które czytniki ekranu również mogą wykorzystać do szybkiego przeskoku.

Przykłady dobrych zastosowań:
– Umieszczenie na początku strony (zaraz po <body>) linku tekstowego „Przejdź do treści głównej”, który staje się widoczny po focuse (np. po naciśnięciu Tab z poziomu adresu strony)[23]. Po wybraniu go focus ląduje np. na nagłówku artykułu czy innym początkowym elemencie contentu.
– Stosowanie elementu HTML5 <main> dla głównej części strony oraz <nav> dla nawigacji. Wiele czytników ekranowych pozwala wtedy skrótem przechodzić do regionu głównego, co spełnia założenia tego kryterium.
– Przy bardzo długich stronach – dodanie spisu treści z linkami do sekcji. To także forma ułatwienia nawigacji (użytkownik niewidomy może szybko przeskoczyć do interesującej go części).

Typowe błędy:
– Brak mechanizmów ułatwiających pominięcie powtarzalnych bloków. Użytkownik zmuszony jest za każdym razem przewijać Tabem przez cały nagłówek, menu, bannery zanim dotrze do właściwej treści – co jest frustrujące i czasochłonne[24].
– Skip link jest, ale nie działa prawidłowo – np. link „Przejdź do treści” nie ma href lub wskazuje zły identyfikator elementu, więc kliknięcie go nic nie robi.
– Nieczytelna treść skip linku lub brak tłumaczenia – np. na polskiej stronie link brzmi „Skip to content”. Powinno się go lokalizować, aby użytkownik od razu zrozumiał (czytnik odczyta tekst w danym języku interfejsu).

2.4.2 Tytuły stron (Poziom A)

Cel i istota: Dostarczenie każdej stronie unikalnego i opisowego tytułu (<title> w kodzie HTML), który informuje użytkownika o zawartości lub celu danej strony. Osoba niewidoma tuż po wejściu na stronę słyszy jako pierwszy komunikat właśnie tytuł okna/zakładki odczytywany przez czytnik. Jeśli tytuł jest znaczący, od razu daje kontekst – np. „Sklep XYZ – Koszyk” jasno komunikuje, że użytkownik jest w koszyku sklepu. Kryterium to jest istotne, bo pomaga orientować się w nawigacji między stronami. Bez dobrego tytułu niewidomy może mieć problem ze zidentyfikowaniem, czy poprawnie załadowała mu się właściwa strona (np. czy link przeniósł go tam, gdzie chciał).

Przykłady dobrych zastosowań:
– Nadawanie tytułów zaczynających się od nazwy konkretnej podstrony, a potem ewentualnie nazwy serwisu. Np. „Kontakt – Urząd Miasta Gdańska” zamiast wszystkiego „Urząd Miasta Gdańska” (które nic nie mówi o podstronie).
– Zwięzłe streszczenie zawartości w tytule. Np. strona wyników wyszukiwania może mieć tytuł: „Wyniki wyszukiwania dla ‘praca’ – SerwisOgłoszeń.pl”. Użytkownik usłyszy, że to wyniki dla zapytania „praca”.
– Unikanie identycznych tytułów na wielu różnych stronach (np. „Galeria zdjęć” jako tytuł dla wielu galerii). Lepiej: „Galeria: Wydarzenia szkolne 2023 – Strona szkoły…”, aby je rozróżnić.

Typowe błędy:
– Puste tytuły stron lub domyślne nic nieznaczące teksty („Untitled Page” lub „Nowy dokument”). Czytnik przeczyta coś nieprzydatnego albo nic – użytkownik nie ma informacji, gdzie jest.
– Zbyt ogólny tytuł, np. tylko nazwa serwisu bez wskazania sekcji. W dużym portalu tytuł „Portal XYZ” każdej podstrony nic nie mówi – lepiej dodać unikalną część (artykuł, dział).
– Nieaktualizowanie tytułu przy dynamicznej zmianie treści jednoplenerowej (SPA). Niewidomy użytkownik może nie zauważyć, że jest w nowym „widoku”, jeśli tytuł zakładki pozostał taki sam jak poprzednio.

2.4.3 Kolejność fokusu (Poziom A)

Cel i istota: Zapewnienie, że fokus (aktywne zaznaczenie elementu) przemieszcza się po stronie w sposób logiczny i intuicyjny. Dla osoby niewidomej fokus to „wskazówka”, co aktualnie czytnik będzie czytał lub z czym użytkownik może wejść w interakcję, więc kolejność jego przemieszczania determinuje kolejność odbioru treści. Kryterium wymaga, by porządek fokusa odzwierciedlał relacje i układ strony – np. zachowywał hierarchię menu, formularzy, sekwencję czytania akapitów. Użytkownik nawigujący Tabem powinien przechodzić do elementów w kolejności odpowiadającej układowi treści, a nie przypadkowej (chyba że celowo zmieniona kolejność poprawia dostępność). Jeśli fokus „skacze” chaotycznie po stronie, niewidomy odbiorca pogubi się, bo informacje będą docierać w niepoprawnej kolejności logicznej.

Przykłady dobrych zastosowań:
– Domyślne zachowanie przeglądarki zwykle zapewnia prawidłową kolejność – jeśli elementy HTML są w logicznym porządku w kodzie (zgodnie z 1.3.2), to Tab przejdzie po nich kolejno. Deweloper powinien unikać nadmiernego manipulowania tabindexami (poza wyjątkami).
– W formularzu kolejność pól w HTML odpowiada naturalnemu przebiegowi wypełniania (np. najpierw pole Imię, potem Nazwisko, potem Email…). Dzięki temu Tab prowadzi użytkownika krok po kroku w poprawnej kolejności.
– W menu nawigacyjnym fokus przechodzi po kolejnych pozycjach menu zgodnie z ich wizualnym/logicznym ułożeniem (np. kategoriami). Jeśli submenu jest rozwijane, tabulator może przechodzić do jego elementów po rozwinięciu – ważne, by nie przeskoczyć istotnych opcji.

Typowe błędy:
– Ustawienie atrybutów tabindex w złej kolejności (np. wymuszenie kolejności 1-2-3 dla niektórych elementów, co przełamuje naturalny porządek i prowadzi do dziwnych przeskoków fokusa).
– Elementy, które pojawiają się dynamicznie (np. modale, tooltipy), nie otrzymują fokusa w momencie pojawienia się. Użytkownik klawiatury może je „ominąć” i usłyszeć dopiero po przeczytaniu reszty strony.
– Całkowity brak kontroli nad kolejnością przy skomplikowanych widgetach – np. w karuzeli focus krąży tylko w obrębie slidera, a potem nagle wychodzi na koniec strony, omijając część treści.

2.4.4 Cel łącza (w kontekście) (Poziom A)

Cel i istota: Zapewnienie, że przeznaczenie linków (hiperłączy) jest zrozumiałe dla użytkownika niewidomego, gdy słucha on strony w kontekście otaczającej treści. Czytniki ekranu pozwalają na odczytywanie samego tekstu linku lub listy wszystkich linków na stronie, dlatego ważne jest, by tekst odnośnika przekazywał informację dokąd prowadzi lub co uruchamia. Kryterium 2.4.4 dopuszcza, że kontekst wokół linku (np. akapit, w którym link się znajduje, lub nagłówek tabeli) może wyjaśniać jego cel – niekoniecznie sam tekst linku musi być jednoznaczny, ale całość powinna dawać jasność. Dla osoby niewidomej minimalny wymóg to to, by nie trafiała na odsyłacze typu „kliknij tutaj”, „więcej” bez żadnego kontekstu. W przeciwnym razie nie wie, co się stanie po aktywacji takiego linku.

Przykłady dobrych zastosowań:
– Tworzenie tekstów linków opisowych, np. zamiast „[Więcej]” pisać „[Więcej o programie szkolenia]”. Dzięki temu nawet wyjęty z kontekstu link jest jasny, a w treści nie trzeba szukać dodatkowych informacji.
– Jeśli link musi być krótki (np. „Czytaj dalej…” pod zajawką artykułu), to zadbać, by w pobliżu (np. w nagłówku artykułu lub alt obrazka) pojawiła się nazwa artykułu. Wówczas czytnik może odczytać to razem – np. Nagłówek: „Nowości techniczne 2025”. Link: „Czytaj dalej” – i użytkownik wie, że link prowadzi do pełnej treści o nowościach 2025.
– W panelach, gdzie jest wiele „więcej…”, stosować ukryty tekst dodatkowy w samym linku, np. „Więcej [tytuł wpisu]” ukryte CSS-em dla wzroku, ale obecne dla czytnika (technika dostępności).

Typowe błędy:
– Odnośniki o niejasnej treści: „kliknij tutaj”, „więcej”, „tutaj”. Lista linków złożona z wielu pozycji „więcej…” jest bezużyteczna dla niewidomego – musi on odsłuchać okoliczny tekst, by się domyślić, czego dotyczą[25].
– Linki obrazkowe bez alt (lub z alt „link” zamiast opisu). Niewidomy usłyszy tylko „link grafika”, nie wiedząc, co ta grafika reprezentuje. Należy dodać tekst alternatywny opisujący cel (np. alt=”Przejdź do koszyka” na ikonie koszyka).
– Zbyt długie linki obejmujące całe zdania nie będące potrzebne. Np. w newsach bywa, że cały akapit jest klikalny – czytnik przeczyta bardzo długą treść jako jeden link, co jest męczące. Lepiej objąć linkiem tylko sensowną frazę.

2.5.1 Gesty dotykowe (Poziom A)

Cel i istota: Zapewnienie alternatywy dla złożonych gestów dotykowych w interfejsach webowych. Osoby niewidome korzystające z urządzeń dotykowych często używają uproszczonych gestów w asystujących trybach (np. pojedyncze stuknięcia, przesuwanie palcem, podwójne tapnięcia są mapowane przez system na fokus i aktywacje elementów). Jeśli strona wymaga wykonania skomplikowanego gestu (np. przeciągnięcia elementu w prawo, uszczypnięcia dwoma palcami, narysowania jakiegoś wzoru), może to być nieobsługiwalne przez standardowe mechanizmy dostępności. Kryterium nakazuje, by czynności dostępne przez gest wielopunktowy lub zależny od ścieżki ruchu były dostępne także przez prostszy gest pojedynczy lub interfejs klawiaturowy. Dla niewidomego oznacza to, że nie natrafi na funkcję, której nie może użyć bez precyzyjnego kontrolowania gestu dotykiem.

Przykłady dobrych zastosowań:
– Zamiast wymagać przeciągnięcia karty produktu w lewo, by ją usunąć z koszyka, dodać również zwykły przycisk „Usuń” dla każdego produktu. Użytkownik niewidomy, korzystając z czytnika na telefonie, może tapnąć dwukrotnie ten przycisk (co jest tłumaczone na klik), zamiast wykonywać trudny gest.
– Dla galerii zdjęć obsługującej gest „szczypnięcia” do powiększenia – zapewnić plus/minus przyciski do zoomu.
– Jeśli gra przeglądarkowa wymaga np. narysowania kształtu, rozważyć alternatywny interfejs (przyciski kierunkowe, wybór opcji z listy), który nie wymaga ciągłego śledzenia palcem po konkretnym torze.

Typowe błędy:
– Funkcjonalność „przeciągnij i upuść” bez żadnej innej metody. Np. sortowanie listy zadań odbywa się tylko poprzez złapanie i przeciągnięcie – osoba niewidoma na komputerze nie zrobi tego myszą, a na telefonie tryb czytnika może blokować takie przeciąganie.
– Gest „przesuń w bok, aby usunąć” bez widocznego przycisku – niewidomy użytkownik może nie mieć pojęcia, że istnieje taka akcja. Jeśli nie ma zamiennika (przycisku usuń), funkcja jest dla niego niedostępna.
– Poleganie na gestach wielodotykowych (np. obrót dwoma palcami, potrójne stuknięcie) przy braku innych sposobów. Tryby ułatwień często używają własnych gestów z wieloma palcami, co może kolidować – lepiej dać prosty przycisk czy suwak, by osiągnąć tę samą funkcję.

2.5.4 Aktywowanie ruchem (Poziom A)

Cel i istota: Zapewnienie alternatywy dla funkcji, które są wyzwalane poruszeniem urządzeniem lub gestami urządzeniem (np. potrząśnięciem, przechyleniem, podniesieniem telefonu do ucha). Osoba niewidoma może nie być świadoma, że dana interakcja wymaga ruchu – zwłaszcza jeśli instrukcja jest podana tylko wizualnie na ekranie. Ponadto, korzystając z czytnika ekranu mobilnego, urządzenie może być zablokowane na pewne ruchy. Kryterium wymaga, by czynności wywoływane ruchem urządzenia (wbudowany akcelerometr/żyroskop) były dostępne także w inny sposób – np. poprzez standardowy element interfejsu. Dla użytkownika niewidomego oznacza to, że nie musi „wiedzieć” o magicznym ruchu ani go wykonywać – może po prostu wcisnąć przycisk, aby osiągnąć ten sam efekt.

Przykłady dobrych zastosowań:
– Jeśli aplikacja pozwala potrząsnąć telefonem, by zresetować ustawienia, to powinna oferować także zwykły przycisk „Reset” na ekranie.
– Gdy witryna wykorzystuje gest przechylenia urządzenia (np. do poruszania postacią w grze online), dobrze jest zapewnić w ustawieniach przełączenie na sterowanie dotykowe lub klawiaturowe.
– Jeżeli strona ma „tryb AR”, w którym użytkownik ma się rozejrzeć aparatem (czyli ruszać urządzeniem), należy upewnić się, że istnieje alternatywny sposób eksploracji (np. dotykowe wybieranie elementów, menu sceny).

Typowe błędy:
– Ukryte funkcje uruchamiane ruchem, o których brak informacji dla użytkownika. Np. niektóre aplikacje mobilne mają „ukryte” skróty – bez powiadomienia niewidomy nigdy z nich nie skorzysta.
– Wymuszanie machnięcia urządzeniem (np. potrząśnij, aby cofnąć ostatnią akcję) jako jedynej opcji. Osoba o ograniczonej mobilności lub niewidoma może fizycznie nie wykonać właściwego gestu.
– Brak wykrywania trybu ułatwień – iPhone np. blokuje niektóre gesty ruchowe, gdy aktywny jest VoiceOver (by nie kolidowały). Jeśli strona tego nie obejdzie alternatywą, funkcja będzie niedostępna.

3.1.1 Język strony (Poziom A)

Cel i istota: Poinformowanie technologii asystujących o języku naturalnym, w jakim jest napisana strona (lub dokument). Czytniki ekranu bazują na tej informacji, by zastosować odpowiednią wymowę i reguły odczytu tekstu. Osoba niewidoma, odwiedzając np. polskojęzyczną stronę, powinna usłyszeć polską syntezę mowy – jest to możliwe tylko, jeśli w kodzie strony poprawnie określono język (np. lang=”pl” w elemencie <html>). Bez tego czytnik może domyślnie użyć złego języka (np. angielskiej wymowy dla polskiego tekstu), co brzmi bardzo niezrozumiale. Kryterium 3.1.1 jest krytyczne, by cały tekst strony był czytelny dla niewidomego odbiorcy – ustawia właściwy kontekst językowy.

Przykłady dobrych zastosowań:
– Deklaracja języka głównego w HTML, np. <html lang=”pl”> dla strony w języku polskim.
– Jeśli strona jest wielojęzyczna, ustawianie atrybutu lang dynamicznie w zależności od wersji (np. dla wersji angielskiej <html lang=”en”>).
– Testowanie strony czytnikiem: gdy język jest poprawnie ustawiony, czytnik automatycznie zmienia głos na polski/angielski/etc. i czyta ze właściwym akcentem oraz intonacją.

Typowe błędy:
– Brak atrybutu lang w ogóle – wiele czytników wtedy zakłada domyślnie angielski. Polski tekst czytany syntetycznym angielskim akcentem staje się bełkotem (np. „szkoła” zabrzmi jak „skoola”).
– Złe ustawienie języka (np. literówka w kodzie języka albo pozostawienie lang=”en” na polskiej stronie, bo skopiowano szablon). Powoduje to analogiczne problemy z wymową.
– Niepodanie języka stronii lub ramki osadzonej (iframe) – jeśli w serwisie składamy treści z różnych źródeł, każdy dokument powinien mieć określony język.

3.2.1 Po otrzymaniu fokusu (Poziom A)

Cel i istota: Zapobieganie niespodziewanym zmianom kontekstu strony w momencie, gdy element otrzymuje fokus. Dla użytkownika niewidomego skoki kontekstu (np. automatyczne przeładowanie strony, przejście do nowej podstrony, otwarcie dużego panelu) mogą być trudne do zrozumienia, jeśli następują bez jego wyraźnej inicjatywy. Kryterium wymaga, by samo wejście fokusem (np. tabulatorem) na jakiś element nie powodowało natychmiast istotnej zmiany – zmiana powinna nastąpić dopiero przy aktywnym działaniu użytkownika (np. kliknięciu czegoś), chyba że użytkownik został uprzedzony. Dzięki temu osoba niewidoma nie zostanie wybita z rytmu czytania lub nawigacji przez nagłą zmianę, której nie oczekiwała.

Przykłady dobrych zastosowań:
– Menu rozwijane typu „hover” przerobione tak, że nie otwiera się automatycznie przy samym focuse Tab, tylko dopiero gdy użytkownik np. naciśnie Enter lub strzałkę w dół.
– Pole wyboru (select) – samo zaznaczenie go Tabem nie przenosi od razu na inną stronę. Zamiast onfocus=submit, lepiej dodać osobny przycisk „Idź” lub wykonywać akcję w onChange, ale dopiero gdy użytkownik zmieni wartość.
– Linki czy przyciski, które otwierają nowe okno/pop-up, nie robią tego na sam fokus. Niewidomy użytkownik wchodząc Tabem na link powinien mieć szansę usłyszeć jego opis, a dopiero Enterem wywołać działanie.

Typowe błędy:
– Element mający zdarzenie onfocus, które od razu przenosi na inną stronę lub wywołuje dużą zmianę (np. focus na polu powoduje automatyczne rozwinięcie długiej listy, przez co czytnik zaczyna czytać nową zawartość – użytkownik może nie zrozumieć, co wywołał).
– Ukryte linki lub skrypty, które reagują na focus w sposób nieoczekiwany – np. focus na reklamie powoduje przekierowanie. Osoba poruszająca się klawiaturą nie zdążyła nawet kliknąć, a tu strona nagle się zmienia.
– Przełączanie widoków w aplikacji webowej na samo wejście w kontrolkę. Np. fokus na zakładce od razu przełącza zakładkę – lepiej, by użytkownik potwierdził wybór (Enter), inaczej może to być mylące.

3.2.2 Podczas wprowadzania danych (Poziom A)

Cel i istota: Podobnie jak 3.2.1, to kryterium ma uniemożliwić niespodziewane zmiany kontekstu, ale tym razem wskutek zmiany ustawień kontrolki przez użytkownika. Chodzi np. o sytuację, gdy użytkownik niewidomy zaznacza opcję w polu wyboru albo wpisuje coś w pole, a strona natychmiast np. przeładowuje się lub przenosi go gdzieś. Takie automatyczne akcje mogą zaskoczyć – czytnik nagle zacznie czytać zupełnie inną część strony. Kryterium wymaga, by zmiana wartości elementu interfejsu nie powodowała automatycznie dużej zmiany kontekstu (np. przejścia na inną stronę, otwarcia nowego okna, znaczącej zmiany treści) bez ostrzeżenia. Dzięki temu osoba niewidoma ma pełną kontrolę nad przepływem wydarzeń – wie, że dopóki sama nie zatwierdzi, nic radykalnego się nie stanie.

Przykłady dobrych zastosowań:
– Formularz z wyborem kraju, który zmienia listę regionów – zamiast automatycznie przeładowywać listę po wybraniu kraju (co mogłoby zaskoczyć), lepiej dodać przycisk „Zastosuj” lub przynajmniej komunikat „zmiana kraju odświeży listę regionów po wybraniu”.
– Witryna e-commerce: zmiana opcji sortowania nie powinna natychmiast przeładowywać wyników, tylko np. po zatwierdzeniu przyciskiem lub po upływie chwili, dając czas na zorientowanie się.
– Jakiekolwiek automatyczne przekierowania w oparciu o wpisywane znaki (autouzupełnianie itp.) powinny wymagać potwierdzenia – np. Enter aby przejść do wybranej sugestii, zamiast natychmiast przenosić po pierwszej literze.

Typowe błędy:
– Pole select zmieniające kategorię strony, które natychmiast przy zmianie wartości wykonuje location.href na inną podstronę. Niewidomy wybierze np. inną kategorię, i nagle znajdzie się na innej stronie bez komunikatu – może nawet nie być pewny, czy jego akcja się powiodła, czy nastąpiło coś innego.
– Pole tekstowe z autouzupełnianiem, które automatycznie przechodzi do strony wyniku przy wpisaniu pełnej frazy bez możliwości potwierdzenia. Użytkownik mógł chcieć jeszcze poprawić wpis, a został przeniesiony.
– Formularz, w którym po zaznaczeniu checkboxa ukryte sekcje stają się widoczne i focus skacze gdzieś indziej. To dezorientuje – lepiej, by albo focus pozostał na checkboxie, a użytkownik sam przeszedł dalej, albo by zmiana była na tyle oczywista (z komunikatem), że nie zaskoczy.

3.3.1 Identyfikacja błędu (Poziom A)

Cel i istota: Zapewnienie, że jeśli użytkownik (np. w formularzu) popełni błąd, to błąd ten zostanie odpowiednio zakomunikowany i wskazany. Dla osoby niewidomej kluczowe jest, by komunikat o błędzie był tekstowy i powiązany z konkretnym polem – inaczej może on umknąć uwadze. Niewidomy nie zobaczy czerwonej ramki czy ikonki przy polu, potrzebuje usłyszeć np. „Błąd: pole X jest wymagane”. Kryterium wymaga, by wystąpienie błędu wejściowego było przedstawione tekstowo i łatwe do odnalezienia (np. fokus może przejść do komunikatu). Dzięki temu użytkownik dowiaduje się co jest nie tak i gdzie, zamiast błądzić bez informacji dlaczego formularz nie został wysłany.

Przykłady dobrych zastosowań:
– Po walidacji formularza strona ustawia fokus na pierwszy błędny element lub jego komunikat błędu, a czytnik odczytuje np. „Błąd: Proszę podać adres e-mail w formacie użytkownik@domena.pl”[26]. Użytkownik od razu wie, co poprawić.
– Komunikaty o błędach są umieszczone tuż obok odpowiednich pól (w kodzie HTML), z odpowiednim oznaczeniem (np. aria-describedby łączącym pole z komunikatem). Dzięki temu gdy fokus znajdzie się na polu, czytnik może też odczytać komunikat błędu.
– Użycie czytelnego języka w komunikatach: zamiast technicznych zwrotów typu „Error 123”, napisać konkretnie co jest źle (np. „Nie wpisano hasła” albo „Hasło musi mieć co najmniej 8 znaków”).

Typowe błędy:
– Walidacja formularza zwraca tylko ogólny komunikat na górze strony „Wystąpiły błędy, popraw je” bez wyszczególnienia jakie pola. Niewidomy słyszy tylko taki komunikat i nie wie, które pola wymagają uwagi – musi zgadywać.
– Komunikaty błędów są prezentowane wyłącznie wizualnie (np. kolor pola zmienia się na czerwono, pojawia się symbol ❗) bez tekstu. Osoba niewidoma nie dowie się o błędzie wcale, chyba że formularz nie przejdzie dalej – ale nie będzie wiedziała dlaczego.
– Brak powiązania komunikatu z polem – np. komunikat jest, ale czytnik nie odczytuje go automatycznie, bo nie jest prawidłowo umieszczony w strukturze. Użytkownik musi samodzielnie szukać informacji o błędzie (co bywa frustrujące).

3.3.2 Etykiety lub instrukcje (Poziom A)

Cel i istota: Zapewnienie, że wszystkie pola formularza i elementy wymagające interakcji mają jasno zidentyfikowane etykiety lub dostępne instrukcje obsługi. Dla osoby niewidomej etykieta (label) to jedyny sposób, by usłyszeć, co należy wpisać lub wybrać w danym polu. Jeśli pole tekstowe nie ma etykiety, czytnik ekranu ogłosi je np. jako „edit text” bez kontekstu – użytkownik nie wie, jakie dane tam podać. Kryterium wymaga więc, by każde pole było opatrzone tekstową nazwą (widoczną lub ukrytą)[10], a jeżeli wpis wymaga szczególnego formatu lub ma dodatkowe instrukcje, to żeby były one również dostępne. Dzięki temu użytkownik niewidomy może prawidłowo zrozumieć, jak wypełnić formularz i z niego skorzystać.

Przykłady dobrych zastosowań:
– Każde pole <input> ma powiązany element <label> z opisem, np. <label for=”email”>Adres email:</label><input id=”email” …>. Czytnik czytając pole odczyta najpierw „Adres email: edit text…” – użytkownik wie, co wpisać[10].
– Jeśli nie można użyć widocznej etykiety (np. w polach wyszukiwania często brak opisu „Szukaj:”), to stosuje się atrybut aria-label=”Szukaj”.
– Dostarczenie podpowiedzi co do formatu danych w tekście obok pola lub za pomocą placeholder (choć placeholder nie jest idealny, bo zanika – lepiej stały tekst). Przykład: „Data (RRRR-MM-DD)” jako etykieta lub notka obok pola daty. Czytnik to odczyta i użytkownik wie, w jakim formacie wpisać datę.

Typowe błędy:
– Pola formularza bez etykiet (samotne <input> z placeholderem, który znika po fokusie) – po wejściu w takie pole czytnik powie np. „edit text, blank”, nie przekazując żadnej nazwy. Użytkownik musi zgadywać, co to za pole.
– Etykiety niepowiązane formalnie z polami (brak atrybutu for lub nieprawidłowe id). Wizualnie tekst może być koło pola, ale czytnik tego nie powiąże i znów użytkownik może go nie usłyszeć w kontekście pola.
– Instrukcja tylko wizualna, np. „Wprowadź kwotę bez spacji” napisana obok pola, ale jeśli nie powiązano jej z polem, użytkownik słuchając szybko formularza może ją pominąć. Lepiej użyć aria-describedby by czytnik czytał taką instrukcję razem z polem.

4.1.1 Poprawność kodu (Poziom A)

Cel i istota: Zapewnienie, że kod strony jest wolny od poważnych błędów składni i zgodny ze specyfikacją, tak aby przeglądarki i technologie asystujące mogły go jednoznacznie interpretować. Osoby niewidome polegają na czytnikach ekranu, które „parsują” kod HTML – jeżeli kod jest np. niezamknięty prawidłowo lub zagnieżdżony w niepoprawny sposób, może dojść do zaburzenia odczytu. Np. pominięty znacznik zamykający tabeli może sprawić, że czytnik pomiesza treść tabeli z kolejnymi akapitami. Poprawny, walidujący się kod minimalizuje ryzyko takich problemów. Kryterium 4.1.1 wskazuje, by unikać błędów typu duplikaty ID, niezamknięte tagi, błędne atrybuty – bo choć wizualnie strona może działać, to w trybie asystującym może dojść do nieprzewidzianych zachowań. Dla niewidomego to różnica między poprawnym, a chaotycznym odczytem strony.

Przykłady dobrych zastosowań:
– Użycie narzędzi walidujących HTML (validator) i naprawianie błędów: zamknięcie wszystkich otwartych znaczników, zagnieżdżanie elementów zgodnie ze specyfikacją (np. <li> tylko wewnątrz <ul> lub <ol>), unikanie powtarzających się identyfikatorów elementów itp.
– Test z czytnikiem ekranu: jeśli jakaś część strony jest odczytywana niespodziewanie (np. fragmenty zlewają się, czytnik nie ogłasza listy tam gdzie jest lista), sprawdzić kod – często to wynik np. brakującego znacznika kończącego listę czy tabelę.
– Stosowanie standardowych kontrolek HTML tam, gdzie to możliwe, zamiast generowania ich w dziwny sposób. Np. zamiast udawać checkbox za pomocą <div> i CSS, lepiej użyć <input type=”checkbox”> i stylować – to gwarantuje poprawną strukturę i mniejszą podatność na błędy interpretacji.

Typowe błędy:
– Niezamknięte elementy (np. <p><em>tekst bez zamknięcia </em></p>). Czytnik może odczytywać wszystko dalej jako część tego akapitu lub kursywy, gubiąc strukturę.
– Duplikaty atrybutu id – może to zakłócić mechanizmy identyfikacji elementów, np. powiązanie etykiety z polem może nie zadziałać, jeśli id nie jest unikatowe.
– Osadzanie elementów interaktywnych w sposób niezgodny ze specyfikacją (np. link zawierający inny link) – to może sprawić, że czytnik pominie lub źle odczyta zawartość.

4.1.2 Nazwa, rola, wartość (Poziom A)

Cel i istota: Zapewnienie, że wszelkie niestandardowe elementy interfejsu są odpowiednio opisane dla technologii asystujących. Gdy deweloper tworzy własne komponenty (np. customowy przycisk, karuzelę, rozwijane menu w JavaScript), musi zadbać o przekazanie czytnikom informacji o nazwie elementu, jego roli i bieżącej wartości/stanie. Osoba niewidoma usłyszy dzięki temu, z czym ma do czynienia i w jakim jest to stanie. Jeśli np. jest przycisk w postaci samej ikony „❤”, to dla czytnika należy podać nazwę („Ulubione”) – inaczej usłyszy tylko „przycisk bez nazwy”. Rola (np. listbox, przełącznik, menuitem) informuje, jak element się zachowuje, a wartość – jaki ma stan (np. zaznaczony/odznaczony dla checkboxa, rozwinięty/zwinięty dla menu). Kryterium 4.1.2 wymaga, by wszystkie elementy interfejsu miały te atrybuty zdefiniowane, czy to przez natywne HTML (które robi to automatycznie), czy przez właściwe wykorzystanie ARIA.

Przykłady dobrych zastosowań:
– Dla przycisku będącego ikoną kosza dodać aria-label=”Usuń element” albo umieścić tekst dla czytnika wewnątrz (np. <span class=”sr-only”>Usuń element</span>). Wtedy osoba niewidoma usłyszy „Usuń element – przycisk”.
– Własny komponent „accordion” (rozwijana sekcja) oznaczyć rolami ARIA: nagłówek sekcji jako przycisk z aria-expanded, a sekcję jako region z aria-hidden kontrolowanym przez ten nagłówek. Czytnik powie np. „Sekcja FAQ, przycisk, zwinięte” i użytkownik wie, że może go rozwinąć.
– Dynamiczne aktualizowanie atrybutów stanu. Jeśli element ma stan np. on/off, stosować aria-pressed=”true/false” lub odpowiedni role=„switch” i aria-checked. Dzięki temu zmiana jest odczytywana (czytnik powie „Włączone” lub „Wyłączone” przy przełączeniu).

Typowe błędy:
– Niestandardowy suwak (slider) stworzony bez ARIA – czytnik widzi go jako zwykły element (np. div) bez informacji, że to suwak, jaka wartość itd. Użytkownik niewidomy nie wie, jak wchodzić w interakcję, i nie zna bieżącej wartości.
– Ikona linku (np. znaczek PDF) bez alt/aria-label – czytnik odczyta sam „link grafika”, nie podając, że to link do pliku PDF.
– Element interfejsu zmienia swój stan wizualnie (np. gwiazdka „dodaj do ulubionych” zmienia kolor po kliknięciu), ale brak atrybutu dostępności sygnalizującego stan (np. aria-pressed). Osoba niewidoma nie otrzyma informacji, czy element został dodany, bo dla niej nic się nie „powiedziało”.

4.1.3 Komunikaty o stanie (Poziom AA)

Cel i istota: Zapewnienie, że dynamiczne komunikaty o zmianach stanu strony (np. wyniki akcji, powiadomienia) są automatycznie ogłaszane przez czytniki ekranu. Osoba niewidoma może nie zauważyć pojawienia się na stronie komunikatu, który nie zmienia fokusu (np. alert „Produkt dodany do koszyka” wyświetlony w rogu ekranu). Kryterium 4.1.3 wymaga, by takie komunikaty miały odpowiednie cechy (np. rola status lub użycie aria-live), dzięki którym zostaną odczytane na głos bez potrzeby ręcznej nawigacji przez użytkownika[27]. To zapewnia równoważność z doświadczeniem wizualnym – gdy widzący zobaczy baner z informacją, niewidomy powinien ją usłyszeć w tym samym momencie.

Przykłady dobrych zastosowań:
– W formularzu kontaktowym po naciśnięciu „Wyślij” pojawia się komunikat „Formularz wysłany pomyślnie”. Dla tego elementu dodano atrybut role=”status” lub aria-live=”polite”[27], dzięki czemu czytnik od razu anonsuje tę informację.
– Na stronie e-commerce kliknięcie „Dodaj do koszyka” dodaje produkt i wyświetla komunikat „Produkt X dodany do koszyka (Liczba przedmiotów: 3)”. Ten komunikat jest w elemencie z aria-live=”assertive” (ważny komunikat natychmiast odczytywany) – niewidomy użytkownik od razu o tym wie, nie musi szukać.
– Walidacja pola formularza w locie: np. przy wpisywaniu hasła strona na bieżąco mówi „Za krótkie hasło”/„Dobre hasło”. Realizuje się to przez element <div> pod polem z atrybutem aria-live, do którego skrypt wpisuje odpowiednie komunikaty podczas wpisywania. Czytnik odczyta zmiany na bieżąco.

Typowe błędy:
– Pokazywanie ważnych komunikatów tylko na stronie bez informowania czytnika. Np. strona dynamicznie uaktualnia koszyk, ale użytkownik niewidomy nic nie słyszy – może nie wiedzieć, że dodanie do koszyka się powiodło.
– Używanie niewłaściwych technik: np. aktualizacja tekstu w <span> bez żadnych atrybutów ARIA. Czytnik z reguły nie ogłosi takiej zmiany, bo nie wie, że to komunikat dla użytkownika.
– Dodawanie komunikatu poprzez alert() JavaScriptu (modal okienko przeglądarki) – co prawda to może zostać przeczytane, ale nie jest dostępne dla kogoś, kto nie widzi kontekstu, może też zaburzyć fokus. Lepiej użyć mechanizmów ARIA które są płynniejsze.

Kryteria sukcesu poziomu AA istotne dla osób niewidomych

1.2.5 Audiodeskrypcja (nagranie) (Poziom AA)

Cel i istota: Zapewnienie audiodeskrypcji dla nagrań wideo (z dźwiękiem), czyli dodatkowej narracji opisującej to, co widać na ekranie, w momentach kiedy film nie zawiera istotnego dialogu. Na poziomie AA wymaga się już, aby materiały wideo zawierające ważne treści wizualne miały dostępną audiodeskrypcję (albo przynajmniej alternatywę tekstową, jeśli audiodeskrypcja nie jest możliwa). Dla osób niewidomych oznacza to, że przy większości profesjonalnych filmów edukacyjnych, informacyjnych itp., które oglądają online, mogą włączyć opcję audiodeskrypcji i usłyszeć opis scen, gestów, wykresów czy napisów pojawiających się w filmie[28]. Na poziomie A dopuszczalne było albo AD, albo tekst – tutaj preferowana jest już audiodeskrypcja jako wygodniejsza i bardziej równoważna forma odbioru w czasie rzeczywistym.

Przykłady dobrych zastosowań:
– Film na stronie instytucji (np. muzeum) posiada ścieżkę z audiodeskrypcją, którą można włączyć w odtwarzaczu (lub jest osobna wersja filmu z lektorem opisującym obraz). Niewidomy użytkownik słyszy np. „Na ekranie pojawia się obraz Mona Lisy…” itd., podczas gdy obraz jest pokazywany[28].
– Serwisy VOD i platformy e-learningowe oferują audiodeskrypcję jako jedną z opcji językowych ścieżki dźwiękowej.
– Gdy produkcja audiodeskrypcji jest zbyt trudna, twórcy treści przynajmniej udostępniają skrypt opisujący film (spełnienie kryterium 1.2.3 na poziomie A) – choć na AA wymagana jest stricte audiodeskrypcja dźwiękowa, to lepiej mieć jakikolwiek opis niż żaden.

Typowe błędy:
– Ważny film informacyjny (np. prezentacja wyników finansowych z wykresami) publikowany bez audiodeskrypcji, mimo że widać na ekranie napisy i grafiki, których nikt w filmie nie czyta. Osoba niewidoma traci te informacje.
– Uznawanie, że napisy dla niesłyszących zastępują audiodeskrypcję – nie, bo napisy nie zawierają opisu obrazu, a jedynie dialogi/lektora.
– Oferowanie audiodeskrypcji, ale w trudno dostępny sposób – np. plik MP3 do pobrania osobno, niesynchronizowany z filmem. To utrudnia korzystanie. Najlepiej, gdy audiodeskrypcja jest zintegrowana z odtwarzaczem wideo.

1.4.13 Treść spod kursora lub fokusu (Poziom AA)

Cel i istota: Zapewnienie, że dodatkowa treść pojawiająca się przy najechaniu kursorem lub ustawieniu fokusu (np. podpowiedzi, dymki, rozwijane menu) jest dostępna dla użytkowników niewidomych korzystających z klawiatury. Chodzi o to, by wszelkie informacje ujawniane on-hover były także dostępne on-focus. Dla osoby niewidomej krytyczne jest, by to co widać po najechaniu było również odczytane przez czytnik w odpowiednim momencie. Kryterium wymaga m.in., żeby: po pierwsze – elementy wywoływane myszą dały się też wywołać klawiaturą (focus), po drugie – żeby treść, która się pokaże, nie znikała nagle, uniemożliwiając jej przeczytanie, oraz po trzecie – by można ją było zamknąć/opuścić bez kłopotu. Przykładowo, jeśli pole formularza ma podpowiedź pojawiającą się po najechaniu, to niewidomy użytkownik musi ją móc wywołać focusem (czytnik na polu) i przeczytać, zanim zniknie.

Przykłady dobrych zastosowań:
– Tooltip (dymek z podpowiedzią) pojawiający się na hover ikonki został zaimplementowany tak, że pojawia się również przy fokusie na ikonke (klawiszem Tab). Dodatkowo ma ustawione aria-describedby, które łączy go z ikonką – gdy ikonka jest w fokusie, czytnik odczyta od razu treść podpowiedzi.
– Menu rozwijane „mega menu” pojawiające się przy najechaniu myszką – zrobione tak, że jak fokus przejdzie klawiaturą na element menu, to też się pojawia, i fokus zostaje do niego przeniesiony, pozwalając na przegląd opcji strzałkami. Kiedy użytkownik wyjdzie z menu (Tab dalej), menu się chowa.
– Dymek z ostrzeżeniem (np. „Hasło za słabe”) pojawiający się przy polu – nie znika dopóki pole jest w błędzie lub dopóki użytkownik nie wykona innej akcji. To daje czas na przeczytanie komunikatu przez czytnik.

Typowe błędy:
– Treść dostępna tylko przez najechanie myszką, której nie da się uruchomić klawiaturą (np. brak obsługi focus). Niewidomy użytkownik nigdy jej nie zobaczy, bo nie używa myszy – tym samym traci potencjalnie ważną informację.
– Dodatkowa treść znika natychmiast po opuszczeniu kursora, nie dając szansy na jej odczytanie. Np. tooltip jest widoczny dopóki mysz jest na ikonie. Gdy użytkownik klawiaturą wejdzie na ikonę, tooltip może migać za krótko – trzeba zapewnić mechanizm utrzymania go, dopóki fokus jest na nim lub ikonie.
– Brak możliwości łatwego zamknięcia dodatkowej treści – np. pojawia się popup przy fokusie, ale użytkownik nie wie jak go zamknąć klawiaturą (powinno działać np. Escape). W rezultacie może mieć trudność z dalszą nawigacją.

2.4.5 Wiele dróg (Poziom AA)

Cel i istota: Udostępnienie użytkownikowi więcej niż jednego sposobu na znalezienie treści lub poruszanie się po serwisie. Dla osoby niewidomej niektóre metody mogą być łatwiejsze niż inne – np. zamiast przeklikiwać się przez wielopoziomowe menu (co bywa żmudne słuchowo), może woleć skorzystać z wyszukiwarki na stronie lub spisu treści. Kryterium 2.4.5 wymaga, by poza standardową nawigacją istniała co najmniej jedna alternatywa: wewnętrzna wyszukiwarka, mapa strony, indeks liter, lista popularnych linków itp. Dzięki temu niewidomy użytkownik ma swobodę wyboru ścieżki dotarcia do informacji. Jeśli np. trudno mu rozeznać się w rozbudowanym menu, zawsze może wpisać to, czego szuka, w pole szukania.

Przykłady dobrych zastosowań:
– Pole wyszukiwania dostępne na każdej stronie serwisu, umożliwiające szybko znalezienie potrzebnej podstrony po słowach kluczowych.
– Strona „Mapa serwisu” wylistowana w stopce – zawiera hierarchicznie wszystkie linki. Niewidomy może jej użyć, by jednym miejscem objąć strukturę portalu (czytnik może np. przeskakiwać po nagłówkach działów).
– Dla serwisów alfabetycznych (np. encyklopedie, słowniki) – indeks liter lub mechanizm skoku do litery.

Typowe błędy:
– Brak jakiejkolwiek alternatywy – użytkownik jest skazany tylko na główne menu. Jeśli menu jest nieintuicyjne lub obszerne, osoba niewidoma może mieć problem z odnalezieniem konkretnej informacji.
– Wyszukiwarka jest, ale niedostępna (np. brak etykiety pola, co utrudnia jej użycie – niewidomy nie wie, że to pole wyszukiwania).
– Mapa strony istnieje, lecz nie jest aktualizowana i pomija kluczowe sekcje – wprowadza w błąd lub nie pomaga.

2.4.6 Nagłówki i etykiety (Poziom AA)

Cel i istota: Zapewnienie, że nagłówki sekcji oraz etykiety formularzy są opisowe i jasno wskazują swój cel. Dla osób niewidomych dobrze sformułowany nagłówek pozwala zorientować się w strukturze i treści sekcji, gdy skaczą po stronie za pomocą skrótów (np. przeglądają listę nagłówków). Jeśli nagłówki są enigmatyczne lub nieadekwatne, nawigacja staje się trudniejsza. Podobnie z etykietami pól: muszą jednoznacznie określać, czego dane pole dotyczy (np. nie tylko „Wartość:”, ale „Wartość zamówienia (PLN):”). Kryterium to dopełnia 1.3.1 – skupia się na jakości opisów tych elementów. Dzięki temu niewidomy użytkownik szybciej pojmie kontekst różnych części strony i poprawnie wypełni formularze, wiedząc dokładnie, czego oczekuje każde pole.

Przykłady dobrych zastosowań:
– Nagłówki sekcji strony głównej serwisu informacyjnego: zamiast ogólnikowego „Aktualności” (gdzie nie wiadomo, czy chodzi o wszystkie newsy czy konkretne), użyto „Aktualności – Polska”, „Aktualności – Świat”, „Sport”, „Kultura” itp. Osoba niewidoma przeglądając nagłówki łatwo wybierze interesujący dział[9].
– Formularz zamówienia: etykiety pól precyzyjne, np. „Imię i nazwisko:”, „Adres e-mail:”, „Nr telefonu (9 cyfr):”. Gdy czytnik je czyta, użytkownik nie ma wątpliwości, co wpisać.
– Sekcje strony mające ikony lub grafiki z tekstem w nich – projektant dodał ukryte nagłówki tekstowe. Np. sekcja promocyjna z dużym numerem „50%” (grafika) ma nagłówek tekstowy „Promocja 50% na wybrane produkty”, więc niewidomy też rozumie, o co chodzi.

Typowe błędy:
– Zbyt ogólne lub powtarzalne nagłówki: np. strona produktu i strona kategorii obu mają nagłówek „Informacje”. Taki nagłówek nic nie mówi – powinien wskazywać kontekst, np. „Informacje o produkcie X” vs „Informacje – Kategoria Y”.
– Etykiety formularza niejednoznaczne: np. pole opisane „Wartość:” – niewidomo, czy chodzi o kwotę, czy inną wartość. Albo etykieta „Numer:” – numer czego? Zaleca się doprecyzować („Numer klienta”, „Numer zamówienia” itd.).
– Brak nagłówków tam, gdzie by się przydały. Np. długa strona tekstu podzielona wizualnie na sekcje, ale bez nagłówków HTML – niewidomy słyszy ciągły tekst i może nie wychwycić zmiany tematu czy sekcji.

3.1.2 Język części (Poziom AA)

Cel i istota: Oznaczanie fragmentów tekstu, które są w innym języku niż reszta strony. Osoba niewidoma dzięki temu usłyszy prawidłową wymowę obcojęzycznych wstawek. Np. gdy na polskiej stronie pojawia się cytat po francusku, atrybut lang=”fr” na tym fragmencie spowoduje, że czytnik przełączy się na francuską wymowę dla tych słów. Bez takiego oznaczenia tekst byłby czytany po polsku (brzmiałby niezrozumiale). Kryterium ma znaczenie zwłaszcza dla stron dwujęzycznych lub zawierających wiele zapożyczeń, nazw własnych itp. Zapewnia, że każda część treści jest czytelna brzmieniowo, a niewidomy użytkownik rozpozna, że to inny język.

Przykłady dobrych zastosowań:
– Oznaczanie cytatów i zwrotów obcojęzycznych: np. „Znana maksyma to Cogito ergo sum <span lang=”la”>Cogito ergo sum</span> (łac. ‚Myślę, więc jestem’).” – czytnik odczyta poprawnie łacińską sentencję.
– Na dwujęzycznym blogu, gdzie część wpisu jest po angielsku, otoczenie tej części znacznikiem z lang=”en”. Czytnik płynnie przejdzie na angielski voice dla tego fragmentu i wróci do polskiego po zakończeniu.
– W menu językowym strony (przełącznik języków) – jeśli nazwy języków są w ich własnych językach („English, Deutsch, Polski”), to warto każdy zlinkowany napis oznaczyć odpowiednim lang (np. lang=”en” dla „English”). Czytnik polski poprawnie wypowie „English” z angielską wymową, a nie złamanym polskim akcentem.

Typowe błędy:
– Nieoznaczone wtrącenia obcojęzyczne – np. artykuł polski zawiera zdanie „To był prawdziwy game changer dla nas.”. Bez lang=”en” na „game changer” czytnik powie to po polsku („gamę czanżer”), co może być niezrozumiałe od razu.
– Całe sekcje w innym języku (np. regulamin po angielsku na końcu polskiej strony) pozostawione jako polski. Niewidomy usłyszy bełkot, chyba że sam ręcznie przestawi język w swoim czytniku (ale nie każdy to potrafi lub zauważy potrzebę).
– Błędne wskazanie języka – np. ustawienie lang=”pl” na akapicie, który jest po angielsku, co tylko pogorszy sprawę (czytnik wymusi polską wymowę na angielskim tekście).

3.2.3 Spójna nawigacja (Poziom AA)

Cel i istota: Zapewnienie konsekwencji w układzie i mechanizmach nawigacyjnych na wszystkich podstronach serwisu. Dla osoby niewidomej powtarzalność menu i elementów sterujących oznacza łatwiejszą orientację – gdy nauczy się raz struktury menu, oczekuje, że na każdej stronie po kolei fokus przechodzi przez te same główne pozycje w tej samej kolejności. Kryterium wymaga, by elementy nawigacyjne powtarzające się w witrynie były zorganizowane za każdym razem tak samo (o ile nie zmieniono ich globalnie). Dzięki temu niewidomy użytkownik nie musi za każdym razem poznawać od nowa układu – przewidywalność wzrasta. Np. jeśli link „Kontakt” jest ostatni w menu na stronie głównej, powinien być ostatni w menu również na stronie „O nas”, a nie nagle w środku lub pod inną nazwą.

Przykłady dobrych zastosowań:
– Stała kolejność głównego menu witryny. Np. jeśli kolejność to „O nas – Oferta – Cennik – Kontakt” na stronie głównej, to na każdej podstronie menu jest identyczne. Niewidomy szybko skanując nagłówki lub linki menu zawsze znajdzie „Kontakt” na końcu.
– Spójne rozmieszczenie bloków nawigacyjnych: np. pasek wyszukiwania zawsze tuż po menu, link do mapy strony zawsze w stopce itp. Czytnik odczytuje te elementy w znanym porządku, więc użytkownik wie, kiedy je spodziewać.
– Jeżeli w serwisie jest nawigacja okruszkowa (breadcrumb), jest ona obecna i wygląda tak samo na wszystkich podstronach strukturalnych.

Typowe błędy:
– Losowa kolejność menu na różnych stronach (np. na stronie A kolejność linków to X, Y, Z, a na stronie B: Y, Z, X). Osoba niewidoma może pomyśleć, że brakuje jakiegoś linku lub że nawigacja jest inna – musi tracić czas na ponowne zapoznanie się, zamiast od razu wybrać znaną pozycję.
– Zmiana nazw elementów w różnych miejscach – np. link do tej samej sekcji raz nazywa się „FAQ”, a raz „Pytania”. Może to wprowadzać w błąd (użytkownik nie wie, że to ten sam cel). Powinno być ujednolicone[29].
– Inconsistent placement of skip links or landmark regions – np. na jednych stronach skip link „Przejdź do treści” jest, a na innych go nie ma, albo raz prowadzi do #main, a raz do #content. To dezorientuje i łamie spójność doświadczenia.

3.2.4 Spójna identyfikacja (Poziom AA)

Cel i istota: Zapewnienie, że elementy o tej samej funkcji mają spójne etykiety i opisy w całym serwisie. Osoba niewidoma polega na tekście linków, przycisków, etykiet – jeśli ta sama akcja raz jest opisana inaczej, może nie zorientować się, że chodzi o to samo. Kryterium wymusza jednolite nazewnictwo: np. przycisk „Szukaj” powinien zawsze tak samo się nazywać, a nie raz „Szukaj”, a raz „Znajdź”. Dzięki temu użytkownik nie będzie mylnie sądził, że to dwie różne funkcje. W skrócie: konsekwentna terminologia i etykiety pomagają niewidomym szybciej odnaleźć pożądane funkcje na różnych stronach serwisu.

Przykłady dobrych zastosowań:
– Przycisk wysyłający formularz wszędzie nazwany „Wyślij” (zamiast np. w jednym miejscu „Wyślij”, w innym „Submit” czy „Gotowe”).
– Link do strony głównej zawsze nazywa się „Strona główna” w całym serwisie, a nie zamiennie „Start”/„Home”/„Main”.
– Ikony mediów społecznościowych mają ujednolicone opisy alt/aria-label. Np. ikona Facebooka zawsze ma alt „Facebook” (a nie raz „FB”, raz „Odwiedź nasz Facebook”).

Typowe błędy:
– Niespójne nazwy czynności: np. link do pobrania dokumentu PDF raz opisany „Pobierz PDF”, a innym razem tylko „Pobierz” albo „Ściągnij plik”. Użytkownik może się zastanawiać, czy to ten sam rodzaj akcji.
– Ten sam element menu na różnych stronach ma nieco inną nazwę (np. dla podkreślenia kontekstu). Przykładowo w dziale „Usługi” link do „Kontakt” nazwano „Kontakt do działu usług” – to może niepotrzebnie wydłużać i komplikować przekaz.
– Ikony bez tekstu alternatywnego opisane w title (widoczne po najechaniu myszą) mają różne zapisy – title=”drukuj stronę” vs title=”wydrukuj”. Czytnik ekranowy nie zawsze czyta title, a nawet jeśli, niespójność może być myląca.

3.3.3 Sugestie korekty błędów (Poziom AA)

Cel i istota: Gdy użytkownik popełni błąd, oprócz samego stwierdzenia tego faktu (3.3.1) warto udzielić mu podpowiedzi, jak ten błąd naprawić. Dla osoby niewidomej, która nie widzi kontekstu, jednoznaczne wskazówki są bardzo cenne – oszczędzają czas i zmniejszają frustrację. Kryterium 3.3.3 wymaga, by w przypadku wykrycia błędu wejściowego (np. źle wypełniony formularz) strona proponowała poprawkę lub informowała o oczekiwanym formacie. Dzięki temu użytkownik nie błądzi po omacku, tylko wie, co zrobić, by osiągnąć sukces.

Przykłady dobrych zastosowań:
– Jeśli użytkownik wpisze niepoprawny format adresu e-mail, komunikat błędu nie tylko stwierdza „Błędny e-mail”, ale dodaje sugestię: „Proszę podać adres e-mail w formacie użytkownik@domena.pl”[26]. Teraz niewidomy użytkownik wie, jak powinien wyglądać prawidłowy wpis.
– W formularzu rejestracji, gdy hasło nie spełnia wymogów, komunikat: „Hasło za krótkie – musi mieć min. 8 znaków”. Konkretna wskazówka (min. 8 znaków) pozwala od razu poprawić błąd.
– Przy wpisywaniu kodu pocztowego – jeśli oczekiwany jest format „XX-XXX”, komunikat przy błędzie: „Format kodu: 12-345” pokazuje przykład.

Typowe błędy:
– Komunikaty błędów mówią tylko „źle” bez wytłumaczenia dlaczego. Np. „Hasło niepoprawne” – użytkownik nie wie, czy chodzi o długość, niedopasowanie do potwierdzenia, niedozwolone znaki czy coś innego.
– Sugestia jest zbyt ogólna lub niejednoznaczna. Np. „Proszę poprawić błędne pola” – nie wskazuje, jak poprawić. Lub: „Nieprawidłowa data” – bez podania oczekiwanego formatu (czy to RRRR-MM-DD, czy inny).
– Brak jakichkolwiek wskazówek w skomplikowanych formularzach – użytkownik może utknąć, nie wiedząc, co wpis jest nie tak. To bywa krytyczne np. w polach numerów identyfikacyjnych (PESEL, NIP), gdzie format bywa specyficzny.

4.1.3 Komunikaty o stanie (Poziom AA) – [omówiono wyżej w sekcji Poziom A]

(Patrz wyżej kryterium 4.1.3 w sekcji poziomu A – zostało już opisane, ponieważ jest kluczowe dla użytkowników niewidomych. Na poziomie AA jest obowiązkowe.)[27]

Kryteria sukcesu poziomu AAA istotne dla osób niewidomych

1.2.7 Rozszerzona audiodeskrypcja (nagranie) (Poziom AAA)

Cel i istota: Zapewnienie dodatkowego czasu na audiodeskrypcję w materiałach wideo, gdzie standardowa audiodeskrypcja (wpleciona w naturalne przerwy dialogowe) nie wystarcza. Na poziomie AAA wymaga się, by w razie potrzeby przerwać lub spowolnić akcję filmu, aby zmieścić opisy wizualne. Dla niewidomego widza oznacza to pełniejsze zrozumienie nawet bardzo dynamicznych czy skomplikowanych scen – nic istotnego mu nie umknie, bo film zostanie opatrzony szerszym komentarzem lektorskim. W praktyce stosuje się to np. w edukacyjnych filmach z szybkim montażem lub prezentujących złożone infografiki – tworzy się wersję z „rozszerzoną audiodeskrypcją”, gdzie odtwarzanie filmu jest co jakiś czas wstrzymywane, by lektor mógł dopowiedzieć szczegóły.

Przykłady dobrych zastosowań:
– W filmie dokumentalnym prezentującym tabele i wykresy, lektor audiodeskrypcji robi pauzę filmu przy każdym wykresie i szczegółowo opisuje jego osie i słupki, zanim film ruszy dalej.
– Nagranie przedstawienia teatralnego – w zwykłej audiodeskrypcji trudno opisać wszystkie kostiumy i scenografię między dialogami, więc rozszerzona audiodeskrypcja wprowadza dodatkowe pauzy przed rozpoczęciem aktu, by opisać scenę, kostiumy postaci itp.
– Transmisja ceremonii (np. rozdania nagród) – z rozszerzoną audiodeskrypcją prowadzący pauzuje po każdej kategorii, by opisać wizualne reakcje laureata, scenografię, ubiór, co normalnie nie zmieściłoby się między przemówieniami.

Typowe błędy:
– Pominięcie tej opcji w treściach, gdzie zwykła audiodeskrypcja mimo szczerych chęci nie pokrywa wszystkich informacji wizualnych. Niewidomy odbiorca wciąż może czegoś nie zrozumieć, bo lektor nie miał kiedy tego powiedzieć podczas filmu.
– Niewyraźne zaznaczenie, że istnieje wersja z rozszerzoną audiodeskrypcją – powinno być to łatwo dostępne z poziomu odtwarzacza lub wyboru wersji filmu.
– Brak zgody na potencjalnie dłuższy odbiór – niektóre systemy mogłyby nie chcieć wydłużać filmu. Jednak dla dostępności AAA zakłada się, że wygoda niewidomego (kompletność opisu) jest ważniejsza niż utrzymanie oryginalnego tempa materiału.

1.2.8 Alternatywa dla mediów (nagranie) (Poziom AAA)

Cel i istota: Dostarczenie pełnej alternatywy tekstowej dla materiałów wideo (ze ścieżką audio). To rozszerzenie zasad 1.2.3 i 1.2.5 – na poziomie AAA wymaga się, by użytkownik mógł zapoznać się z całą treścią nagrania w formie tekstu (transkryptu opisowego), nie oglądając ani nie słysząc nagrania. Dla osób niewidomych jest to dodatkowa opcja: mogą np. przeczytać (odsłuchać czytnikiem) szczegółowy opis filmu zamiast polegać na audiodeskrypcji. Może to być korzystne, gdy ktoś woli szybko przeczytać niż słuchać całego nagrania (np. przeszukać tekst w poszukiwaniu konkretnej informacji). Alternatywa tekstowa zawiera zarówno dialogi, jak i opisy akcji i wizualiów.

Przykłady dobrych zastosowań:
– Obok osadzonego filmu zamieszczono link „Transkrypcja filmu”, prowadzący do strony lub dokumentu z pełnym zapisem narracji i opisem scen. Niewidomy użytkownik może ten dokument przejrzeć swoim czytnikiem, korzystając z nawigacji po tekście.
– Dla webinaru lub lekcji online przygotowano materiał PDF zawierający opracowanie wszystkich slajdów i słów prowadzącego, uzupełnione opisami czynności wykonywanych na ekranie.
– W przypadku nagrań historycznych, gdzie nagranie jest trudno dostępne lub nieczytelne, strona może dostarczyć szczegółowy opis tekstowy każdej sceny (np. film niemy – transkrypcja opisuje każde ujęcie).

Typowe błędy:
– Brak takiej alternatywy w serwisach edukacyjnych – nie każdy chce lub może obejrzeć godzinny wykład; dla niektórych (także niewidomych) wygodniej jest przeczytać.
– Alternatywa tekstowa niepełna – np. zawiera tylko dialogi, ale nie opisuje ważnych zdarzeń wizualnych (jak reakcje, demonstracje pokazywane w filmie). To nie spełnia w pełni kryterium.
– Utrudniony dostęp do transkrypcji – np. transkrypcja jest dostępna, ale tylko na żądanie e-mailem, zamiast bezpośrednio na stronie. Powinna być łatwo osiągalna, by realnie służyła użytkownikom.

2.1.3 Klawiatura (bez wyjątków) (Poziom AAA)

Cel i istota: Wzmocnienie wymogu dostępności z klawiatury – żadna funkcjonalność strony nie może wymagać użycia myszy i nie istnieją wyjątki (w WCAG na poziomie A dopuszczano pewne bardzo nieliczne przypadki, tutaj już nie). Dla osób niewidomych to potwierdzenie pełnej swobody: absolutnie wszystko, co da się zrobić na stronie, muszą móc zrobić za pomocą klawiatury lub technologii asystującej opierającej się na klawiaturze. W praktyce na poziomie AAA oznacza to konieczność przemyślenia wszystkich elementów interaktywnych – nawet takich jak rysowanie podpisu odręcznego czy interaktywne mapy – i zapewnienia im obsługi klawiaturowej.

Przykłady dobrych zastosowań:
– Jeśli strona ma grę lub aplikację z nietypową interakcją (np. gra pamięciowa wymagająca odsłaniania kart myszką), to na AAA należałoby zapewnić tryb tekstowy lub inny mechanizm obsługiwany z klawiatury (np. lista kart, wybieranie numerami).
– Kompletny audyt klawiaturowy: twórcy strony testują dosłownie każdy element, czy można do niego dotrzeć Tabem i czy da się go obsłużyć Enterem/spacją/strzałkami. Usuwane są też wszelkie akcje „tylko hover” bez zamiennika focus (co już raczej spełniono wcześniej).
– Nawet interaktywne mapy czy wykresy mają alternatywę – np. lista odnośników do punktów na mapie, która pozwala przejść do informacji o danym punkcie bez klikania na mapie myszą.

Typowe błędy:
– Przyjęcie założenia, że pewne rzeczy „nie muszą być dostępne” (częsty błąd na niższych poziomach, na AAA już całkiem dyskwalifikujący). Np. osadzony suwak kolorów nie ma obsługi klawiatury, bo „to tylko dodatek” – na AAA tak nie wolno, wszystko musi mieć obsługę.
– Złożone widgety dostępne częściowo – np. da się Tabem wejść w odtwarzacz audio, ale już nie obsłużyć suwaka przewijania utworu strzałkami. Na AAA oczekujemy pełnej funkcjonalności (np. dodatkowe przyciski skoków zamiast suwaka lub obsługa strzałek do zmiany czasu).
– Nieuwzględnienie rzadkich interakcji – np. brak sposobu na zrobienie „drag and drop” z klawiatury (można by pomyśleć o przyciskach „przesuń w górę/dół” lub klawiszach skrótów).

2.4.8 Lokalizacja (Poziom AAA)

Cel i istota: Dostarczenie użytkownikowi informacji o bieżącej lokalizacji w strukturze serwisu czy procesu, np. poprzez okruszki nawigacyjne (breadcrumbs) lub wyraźne nagłówki wskazujące miejsce. Dla osoby niewidomej to ważne, bo na podstawie samego tytułu strony czasem trudno odgadnąć, gdzie w hierarchii strony się znajduje. Breadcrumbs (w formie tekstowej listy linków) czy inne wskaźniki pozwalają szybko zorientować się, np. że aktualnie jest w dziale „/Produkty/Komputery/Laptopy”. Czytnik odczyta ten łańcuch i użytkownik wie, w jakim kontekście się porusza. To kryterium zwiększa orientację przestrzenną w serwisie dla kogoś, kto nie widzi struktury menu.

Przykłady dobrych zastosowań:
– Na każdej podstronie produktowej sklep internetowy wyświetla na górze ścieżkę: „Strona główna > Kategoria X > Podkategoria Y > [Nazwa produktu]”. Jest to zrealizowane w HTML jako lista linków, więc czytnik czyta np. „Strona główna, link. Kategoria X, link. Podkategoria Y, link. [Nazwa produktu], tekst (bieżąca pozycja).”
– W portalu informacyjnym artykuły posiadają nagłówek działu lub kategorię nad tytułem artykułu, np. „/Kultura/ Teatr” – użytkownik słyszy, że ten artykuł jest z działu Kultura, sekcji Teatr.
– W aplikacji wieloetapowej (np. proces rejestracji) wyświetla się pasek postępu z oznaczeniem kroków, np. „Krok 2 z 3: Dane adresowe”. Dla niewidomego to też istotne – powinno być jako tekst, by czytnik przekazał tę informację.

Typowe błędy:
– Brak okruszków ani wskazówek kontekstu – użytkownik na stronie głębokiego poziomu może nie być pewny, jak się tam znalazł, zwłaszcza jeśli np. trafił z wyszukiwarki. Musi cofać się lub eksplorować menu, co zajmuje czas.
– Breadcrumbs istnieją, ale są zrealizowane w nietypowy sposób (np. jako grafika lub jako menu rozwijane). Powinny być po prostu tekstem/odsyłaczami w linii.
– Nieaktualizowanie wskazania bieżącego miejsca – np. menu boczne nie pokazuje, w którym dziale jesteśmy (wizualnie może jest podświetlone, ale dla czytnika brak informacji). Warto dodawać np. aria-current=”page” dla aktywnej pozycji menu.

2.4.9 Cel łącza (z samego łącza) (Poziom AAA)

Cel i istota: Dopracowanie wymagań co do opisowości linków – na poziomie AAA tekst każdego linku sam w sobie (bez kontekstu) powinien być wystarczająco zrozumiały. Czyli link powinien zawierać informację o swoim celu nawet wyjęty z otoczenia. Dla osób niewidomych posługujących się np. mechanizmem czytnika „lista linków na stronie” jest to ogromne udogodnienie – mogą szybko przejrzeć wszystkie odnośniki i od razu wiedzieć, co który zrobi[25]. Na poziomie A dopuszczano kontekst, tutaj wymaga się, by każdy link był samodzielnie opisowy (chyba że jest np. wynikiem dynamicznego generowania).

Przykłady dobrych zastosowań:
– Zamiast linków „czytaj dalej” pod kilkoma artykułami, stosowanie pełniejszych linków: np. „Czytaj dalej: Historia teatru greckiego”, „Czytaj dalej: Nowa wystawa w Luwrze” – tak, by w liście linków nie było samych „Czytaj dalej”.
– Linki-akcje określone wprost: nie „Kliknij tutaj, aby pobrać raport”, tylko od razu „Pobierz raport (PDF)”.
– Linki nawigacyjne też można ulepszyć: np. zamiast samego „[1] [2] [3] … (numer strony)” dla paginacji, dodać aria-label z kontekstem, np. „Strona 2”. Czytnik wtedy może z samych linków wyczytać, że to numeracja stron.

Typowe błędy:
– Poleganie wyłącznie na otaczającym tekście dla zrozumienia linku. Na AAA to niewystarczające – każdy odsyłacz powinien być jasny. Jeśli mamy listę gołych linków „więcej…”, to jest to błąd tego kryterium.
– Zbyt długie linki próbujące obejść to kryterium przez włączenie nadmiarowego tekstu. Np. całe zdanie jako link, bo autor chciał, by link był sam w sobie zrozumiały. Lepiej skrócić i sensownie nazwać – chodzi o zwięzłość i jasność.
– Linki-ikony (np. ikona drukarki jako link do wersji do druku) nie mające tekstu – na AAA to niedopuszczalne. Ikona musi mieć aria-label=”Drukuj stronę” lub podobny tekst, żeby link nawet bez otoczenia był czytelny.

2.4.10 Nagłówki sekcji (Poziom AAA)

Cel i istota: Używanie nagłówków do dzielenia i opisywania wszystkich ważnych sekcji treści na stronie. Dla osób niewidomych oznacza to bogatszą strukturę do nawigacji i lepsze zrozumienie organizacji strony. Kryterium to zachęca do tego, by nawet tam, gdzie nie jest to ściśle wymagane niższymi poziomami, dodawać nagłówki dla przejrzystości. Przykładowo, dłuższy artykuł powinien mieć śródtytuły, formularz może mieć nagłówek opisu sekcji formularza, strona FAQ powinna mieć pytania jako nagłówki itd. Dzięki temu niewidomy użytkownik może skanować zawartość za pomocą skrótu „następny nagłówek” i szybciej znaleźć interesujący fragment.

Przykłady dobrych zastosowań:
– Strona FAQ: każde pytanie jest oznaczone jako nagłówek (np. <h3>), a odpowiedź jako paragraf pod nim. Czytnik pozwala wtedy przeskakiwać od pytania do pytania szybko.
– Długi artykuł z podrozdziałami: autor używa nagłówków (<h2>, <h3>) dla tych podrozdziałów z krótkim tytułem streszczającym zawartość akapitu. Niewidomy może ominąć mniej interesujące fragmenty, kierując się nagłówkami.
– Sekcja komentarzy pod wpisem blogowym poprzedzona nagłówkiem „Komentarze użytkowników”. Bez tego osoba niewidoma mogłaby nie od razu zorientować się, że przeszła z treści wpisu do sekcji komentarzy – nagłówek to klarownie oddziela.

Typowe błędy:
– Duże bloki tekstu bez żadnych nagłówków pośrednich. Użytkownik niewidomy musi wówczas słuchać całości lub ręcznie przewijać fragmentami, nie mając punktów orientacyjnych.
– Używanie tylko wyróżnień wizualnych zamiast nagłówków – np. pogrubienie pierwszego zdania sekcji zamiast nagłówka. Dla czytnika to nie jest nagłówek, więc tracimy możliwość skoku.
– Chaotyczna hierarchia nagłówków (pominięta logiczna kolejność) lub nieopisowe nagłówki jak „Sekcja 1” – to nie pomaga użytkownikowi. Nagłówek powinien coś znaczyć i być we właściwej kolejności.

3.2.5 Zmiana na żądanie (Poziom AAA)

Cel i istota: Gwarancja, że żadna zmiana kontekstu nie nastąpi bez wyraźnej akcji użytkownika. To rozszerzenie zasad 3.2.1 i 3.2.2 – na poziomie AAA przyjmuje się, że nawet automatyczne zmiany czy zmiany przy fokusie/input nie powinny w ogóle zachodzić, o ile użytkownik tego nie zażądał. Osoba niewidoma zyskuje tym samym pełną kontrolę: nic nie przeładuje się, nie przeniesie ani nie otworzy dopóki sam tego nie zainicjuje w świadomy sposób (np. kliknięciem przycisku „Idź”). Ta zasada jest bardzo surowa, ale eliminuje wszelkie potencjalne niespodzianki.

Przykłady dobrych zastosowań:
– Żadne menu nie rozwija się automatycznie – zawsze jest jakaś interakcja użytkownika potrzebna (klik, naciśnięcie klawisza).
– Strona nie przekierowuje nigdzie sama z siebie; zamiast tego np. po wybraniu opcji z listy rozwijanej pojawia się przycisk „Przejdź”, który trzeba nacisnąć, aby nastąpiło przeładowanie.
– W aplikacji po wypełnieniu pola formularza nie wywołuje się automatycznie walidacja przenosząca fokus – raczej pokazuje się pasywnie komunikat (ew. odczytywany dzięki 4.1.3), ale dopóki użytkownik nie potwierdzi, nie ma innych efektów.

Typowe błędy:
– Nadal obecne automatyczne przekierowania czy odświeżania treści. Na AAA to już błąd – np. odliczanie i przeniesienie na inną stronę bez pytania użytkownika (powinien być mechanizm „Kliknij, aby przejść dalej” zamiast automatu).
– Mechanizmy auto-save w formularzach zmieniające coś w interfejsie (np. zapis powoduje nagłe zamknięcie formularza) – lepiej, by zapisywało w tle, a komunikat mówił „zapisano”, zostawiając użytkownika w tym samym miejscu dopóki sam nie wyjdzie.
– Jakakolwiek niespodziewana zmiana stanu UI triggered by script on events jak onhover, onfocus, onchange – na AAA należy ich unikać lub uczynić tak dyskretnymi, by nie dezorientowały (i oczywiście komunikować przez ARIA).

3.3.5 Pomoc (Poziom AAA)

Cel i istota: Zapewnienie dodatkowej pomocy kontekstowej dla użytkownika, zwłaszcza w złożonych interakcjach czy formularzach. Dla osób niewidomych, które nie mogą polegać na podpowiedziach wizualnych, istotne jest, by istniały łatwo dostępne instrukcje, wskazówki lub możliwość szybkiego uzyskania pomocy (np. FAQ, infolinia) na stronach, gdzie mogą pojawić się trudności. Kryterium to wymaga, aby przy bardziej skomplikowanych czynnościach (np. wypełnienie wniosku, proces wieloetapowy) była łatwa do znalezienia pomoc – czy to w formie tekstu (instrukcji krok po kroku), czy mechanizmu (przycisk „Pomoc”, chat, numer kontaktowy). Dla niewidomego użytkownika oznacza to, że nie utknie bez wyjścia – ma gdzie sprawdzić, jak coś zrobić, jeśli nie jest to oczywiste.

Przykłady dobrych zastosowań:
– Na stronie rejestracji konta jest link „Jak wypełnić formularz?” lub ikony „?” obok trudniejszych pól, które po fokusu wyświetlają dodatkowe wyjaśnienia. Czytnik może je odczytać (ważne by były dostępne tekstowo).
– Sklepy internetowe na stronie płatności umieszczają np. numer telefonu do biura obsługi lub czat „Masz problem? Napisz do nas” – użytkownik niewidomy może łatwo znaleźć tę informację, jeśli utknie podczas finalizacji zakupu.
– Strony rządowe z formularzami mają sekcje pomocy wypełnione instrukcjami i najczęściej zadawanymi pytaniami. Niewidomy może przed wypełnieniem formularza odsłuchać instrukcję i zrozumieć, jakie dane przygotować.

Typowe błędy:
– Brak jakiejkolwiek podpowiedzi na stronie, gdzie logika nie jest oczywista. Np. formularz składania zeznania podatkowego online – wiele pól, zawiłości, a ani jednego linku do objaśnień czy definicji. Użytkownik (nie tylko niewidomy) może być zagubiony.
– Pomoc istnieje, ale jest ukryta za myślnikiem niedostępnym dla czytnika (np. tylko w postaci graficznej instrukcji kroków). Wszystkie instrukcje muszą być dostępne tekstowo.
– Ograniczenie się do ogólnikowego linku „Pomoc” prowadzącego do ogromnej sekcji FAQ, bez powiązania z kontekstem. Lepsze jest kontekstowe wsparcie – np. FAQ od razu filtruje się do danego procesu lub wyświetla najczęstsze pytania dotyczące tego, co użytkownik robi.

Podsumowanie: Powyższe kryteria WCAG adresują kluczowe potrzeby użytkowników niewidomych w zakresie dostępu do treści internetowych. Zapewnienie tekstów alternatywnych dla wszelkich mediów wizualnych, pełna obsługa za pomocą klawiatury, czytelna struktura semantyczna oraz komunikaty zwrotne dostosowane do czytników ekranu to fundamenty dostępności dla osób z dysfunkcją wzroku[30][31]. Stosowanie się do tych wytycznych nie tylko umożliwia niewidomym pełnoprawne korzystanie z witryn i aplikacji, ale często poprawia użyteczność dla wszystkich odbiorców. Jak pokazują dobre praktyki (i błędy do uniknięcia) – dostępność wymaga dbałości o szczegóły w projekcie i kodowaniu, lecz procentuje serwisem przyjaznym i efektywnym w obsłudze przez każdego użytkownika. Wszystkie opisane zasady, od poziomu A po AAA, mają na celu uczynienie internetu przestrzenią równie dostępną dla osób niewidomych, jak i dla widzących, zapewniając równy dostęp do informacji i funkcjonalności cyfrowych.

Źródła: Web Content Accessibility Guidelines (WCAG) 2.1 – dokumentacja i tłumaczenie na język polski[32][7]; artykuły i przewodniki dotyczące WCAG oraz dostępności dla osób niewidomych[31][11]; dobre praktyki opisane przez specjalistów dostępności cyfrowej[27][33].

[1] [5] [6] [7] [8] [32] Wytyczne dla dostępności treści internetowych (WCAG) 2.1

https://www.w3.org/Translations/WCAG21-pl/

[2] [3] [4] [9] [10] [11] [15] [17] [18] [19] [20] [21] [23] [24] [25] [26] [27] [28] [29] [30] [31] [33] Dostosowanie stron do WCAG 2.1 – kompletny przewodnik

https://icomseo.pl/blog/wcag-2-1-od-a-do-z-kompletny-przewodnik-po-dostepnosci-dla-kazdego/

[12] [13] [14] [16] Kryterium 1.3.2 – Zrozumiała kolejność (poziom A) – perfekcyjneStrony.pl

https://perfekcyjnestrony.pl/kryterium-1-3-2—zrozumiala-kolejnosc-poziom-a

[22] Jak spełnić WCAG (Krótki przewodnik)

https://wcag.lepszyweb.pl/