Web Content Accessibility Guidelines (WCAG) to zbiór wytycznych mających na celu zapewnienie dostępności treści internetowych dla jak najszerszego grona użytkowników, w tym osób z różnymi niepełnosprawnościami. Niniejszy raport skupia się wyłącznie na kryteriach sukcesu WCAG istotnych z perspektywy osób niedowidzących (słabowidzących). Omówione zostały kryteria ze wszystkich poziomów zgodności (A, AA, AAA), pogrupowane według czterech podstawowych zasad WCAG: Postrzegalność, Funkcjonalność, Zrozumiałość i Solidność. Dla każdego odpowiedniego kryterium przedstawiono jego cel i istotę w kontekście potrzeb użytkowników niedowidzących, a także praktyczne przykłady poprawnego zastosowania oraz typowe błędy. Zachowano oryginalną numerację i nazewnictwo kryteriów sukcesu zgodnie ze specyfikacją WCAG.
Uwaga: Kryteria niezwiązane bezpośrednio z problemami wzrokowymi (np. dotyczące wyłącznie dostępności dla osób niesłyszących czy z niepełnosprawnością poznawczą) zostały pominięte. W treści kompendium zamieszczono odwołania do źródeł potwierdzających przedstawiane informacje.
Postrzegalność (Perceivable)
Zasada Postrzegalność oznacza, że zawartość musi być prezentowana w taki sposób, aby użytkownicy mogli ją dostrzec za pomocą dostępnych im zmysłów (w szczególności wzroku). Dla osób niedowidzących kluczowe jest zapewnienie im możliwości wyraźnego zobaczenia treści – m.in. poprzez odpowiedni kontrast, skalowalność tekstu czy czytelną prezentację wizualną. Poniżej opisano istotne kryteria sukcesu z tej grupy.
1.3.4 Orientacja (AA)
Cel i istota: Kryterium to wymaga, aby strona nie ograniczała wyświetlania treści tylko do jednego układu ekranu (pionowego lub poziomego). Osoby niedowidzące często korzystają z takiej orientacji urządzenia, która maksymalnie ułatwia im czytanie – np. orientacja pozioma (landscape) pozwala zwiększyć rozmiar tekstu na szerszym ekranie[1]. Brak blokady orientacji ekranu umożliwia im oglądanie zawartości w preferowanym układzie (np. gdy urządzenie jest zamontowane na stałe na wózku lub używają lupy ekranowej).
Poprawne zastosowanie (przykłady):
– Strona reaguje na zmianę położenia urządzenia – w układzie pionowym i poziomym prezentuje te same treści, dostosowując jedynie rozmiar i rozmieszczenie elementów. Przykładowo serwis e-booków pozwala czytać książkę zarówno w orientacji portretowej, jak i landscape, w zależności od preferencji użytkownika[2].
– Aplikacja wideo umożliwia oglądanie filmu w trybie pionowym lub pełnoekranowym poziomym – nie wymusza obrotu ekranu komunikatem, lecz dopasowuje się do aktualnej orientacji urządzenia użytkownika.
Typowe błędy:
– Blokowanie orientacji – strona wyświetla komunikat „obróć urządzenie”, wymuszając orientację poziomą (np. dla wykresów lub zdjęć) nawet wtedy, gdy nie jest to absolutnie konieczne. Taki lock orientacji uniemożliwia niedowidzącym korzystanie z preferowanego układu[3][4].
– Nieobsługiwanie orientacji poziomej – serwis zaprojektowany tylko pod widok pionowy „łamie się” lub ukrywa część treści w widoku poziomym. Osoba słabowidząca tracąca część interfejsu w danym ułożeniu może mieć trudności z odczytaniem zawartości lub nawigacją.
1.4.1 Użycie koloru (A)
Cel i istota: Kryterium to zabrania przekazywania istotnych informacji wyłącznie za pomocą różnic w kolorze. Dla osób niedowidzących (często także z ograniczonym rozpoznawaniem barw) oznacza to, że kolor nie powinien być jedynym nośnikiem znaczenia. Należy stosować dodatkowe oznaczenia (np. tekst, symbole, obramowanie), aby informacje były czytelne nawet przy słabym widzeniu kolorów[5][6]. Wiele osób słabowidzących ma osłabioną percepcję barw lub korzysta z trybów o ograniczonej palecie (monochromatycznych)[7]. Bez alternatywy dla samego koloru takie osoby mogą nie zauważyć ważnych komunikatów.
Poprawne zastosowanie (przykłady):
– Pola obowiązkowe w formularzu są oznaczone nie tylko kolorem (np. czerwoną ramką), ale także dodatkowym symbolem lub tekstem – np. gwiazdką * i komunikatem „pole wymagane” w etykiecie. Dzięki temu użytkownik słabiej rozróżniający kolory wie, które pola musi wypełnić, nawet jeśli nie dostrzega czerwonego koloru oznaczenia[8].
– Błędy formularza są komunikowane kolorem oraz treścią tekstową – np. pola z błędem są podświetlone na czerwono i dodatkowo zawierają komunikat „Proszę wprowadzić adres e-mail”. Osoba niedowidząca, która nie zauważy koloru, odczyta komunikat i zrozumie problem.
– Linki w tekście są wyróżnione kolorem oraz podkreśleniem. Podkreślenie (różnica w kształcie linii) stanowi alternatywę wizualną dla samej różnicy barwy linku względem reszty tekstu, co ułatwia dostrzeżenie odsyłaczy.
Typowe błędy:
– Informacja tylko kolorem – np. oznaczenie błędnie wypełnionego pola jedynie czerwoną obwódką, bez komunikatu. Użytkownik niedowidzący (lub daltonista) może nie zauważyć samej zmiany koloru, przez co nie będzie świadomy błędu[8]. Podobnie linki wyróżnione wyłącznie kolorem (bez podkreślenia) mogą zlać się z tekstem dla osób słabo widzących.
– Legenda lub instrukcja bazująca tylko na barwach – np. „wykres: sprzedaż Mary – kolor czerwony, Tom – niebieski”. Osoba z ograniczonym widzeniem barw nie odróżni słupków wykresu, jeśli legenda nie zawiera opisów tekstowych odpowiadających kolorom[7].
1.4.3 Kontrast (minimum) (AA)
Cel i istota: To kryterium określa minimalny wymagany kontrast między tekstem (lub obrazem tekstu) a tłem. Dla zwykłego tekstu minimalny współczynnik kontrastu wynosi 4,5:1 (dla dużego tekstu 3:1). Wartości te zostały przyjęte, aby zrekompensować obniżoną czułość kontrastu u osób z umiarkowanie słabym wzrokiem – przykładowo osoba z ostrością 20/40 potrzebuje kontrastu ok. 4,5:1, a przy ostrości 20/80 aż 7:1[9]. Zapewnienie odpowiedniego kontrastu sprawia, że tekst jest czytelny dla osób niedowidzących, które często mają problemy z dostrzeganiem bladych liter na jasnym tle. Jak podkreśla dokument WCAG, współczynnik 4,5:1 został dobrany właśnie w celu uwzględnienia potrzeb użytkowników o obniżonej ostrości wzroku czy kontrastowości widzenia[9].
Poprawne zastosowanie (przykłady):
– Wysoki kontrast tekstu i tła: Strona używa ciemnej czcionki na jasnym tle (np. czarny tekst na białym tle, kontrast 21:1) lub odwrotnie – jasnej czcionki na ciemnym tle. Nawet przy mniejszej ostrości wzroku tekst pozostaje wyraźny. Dopuszczalne są kombinacje spełniające minimum 4,5:1 – np. ciemnoszary tekst (#444) na białym tle (#FFF) ma kontrast ok. 10:1, co przekracza wymagane minimum.
– Duży tekst nieco niższy kontrast: Dla dużych liter (np. nagłówków 18-punktowych) dopuszczalny jest niższy kontrast 3:1[10][9]. Przykładowo jasnoniebieski nagłówek na białym tle może mieć kontrast ~3,5:1 – nadal czytelny przy większym rozmiarze czcionki. Ważne, by nawet powiększony tekst zachował czytelność dla słabowidzącego użytkownika o obniżonej percepcji kontrastu.
Typowe błędy:
– Zbyt niski kontrast małego tekstu: Częstym błędem jest stosowanie jasnoszarej czcionki na białym tle (np. #CCC na #FFF, kontrast ok. 1,5:1) dla drobnego tekstu (np. opisów czy linków). Dla osoby niedowidzącej taki tekst może być praktycznie nieczytelny, nawet przy powiększeniu. Jak stwierdzono w badaniach, słaby kontrast sprawia, że przy dużym powiększeniu wciąż nie da się odnaleźć ani odczytać treści[11][12].
– Ignorowanie kontrastu w elementach interfejsu: Choć 1.4.3 dotyczy głównie tekstu, często błąd polega na niekontrastowym oznaczeniu tekstowym elementu. Przykładowo link lub przycisk w jasnym kolorze na tylko nieco ciemniejszym tle może nie spełniać 4,5:1, przez co użytkownik słabowidzący może go nie zauważyć lub nie odczytać. Wszystkie napisy – w tym na przyciskach, etykiety pól czy tekst w obrazkach – powinny spełniać wymóg kontrastu względem tła[13][14].
1.4.4 Zmiana rozmiaru tekstu (AA)
Cel i istota: Kryterium to gwarantuje, że tekst może zostać powiększony (przeskalowany) co najmniej o 200% bez użycia specjalistycznych technologii asystujących i bez utraty zawartości lub funkcjonalności strony[15][16]. Innymi słowy, użytkownik musi móc powiększyć tekst (np. poprzez funkcję zoom przeglądarki) do 200% początkowego rozmiaru, a treść nadal ma być dostępna i czytelna. Jest to kluczowe dla osób niedowidzących, z których wielu może czytać tekst dopiero w dużym powiększeniu[17]. Dzięki temu kryterium nawet bez dedykowanego programu powiększającego można skorzystać z wbudowanych w przeglądarkę mechanizmów skalowania, a strona nie „rozsypie się”.
Poprawne zastosowanie (przykłady):
– Elastyczny układ i tekst względny: Strona zbudowana w technice responsywnej używa jednostek względnych (np. em, %) do określania rozmiarów tekstu i elementów. Po zwiększeniu zoomu do 200% cała zawartość pozostaje widoczna – bloki tekstu mieszczą się w pionowym układzie bez ucinania, menu skaluje się do formy mobilnej (tzw. hamburger menu), a elementy interfejsu są nadal dostępne. Użytkownik niedowidzący może płynnie powiększyć tekst dwukrotnie, aby go przeczytać[18][19].
– Nieprzeszkadzanie przeglądarce: Autor strony unika stosowania rozwiązań, które uniemożliwiają powiększenie – np. nie blokuje zoomu w meta tagach lub skryptach. Dzięki temu przeglądarka może swobodnie powiększyć całą zawartość strony o 200% (lub więcej), a tekst nie zachodzi na inne elementy i nie wymaga czytania z przewijaniem w poziomie (patrz także kryterium 1.4.10 Reflow).
Typowe błędy:
– Stały rozmiar elementów w pikselach: Jeśli kontenery lub czcionki mają sztywno zdefiniowane w CSS rozmiary (np. szerokość na 300px), po powiększeniu tekst może się ucinać lub nachodzić na inne elementy. Często błąd objawia się tym, że przy 200% powiększeniu część tekstu znika lub trzeba przewijać stronę na boki, aby go przeczytać – co jest trudne dla niedowidzących[20][21].
– Elementy utrudniające skalowanie: Niekiedy deweloperzy wyłączają możliwość pinch-zoom na urządzeniach mobilnych lub stosują nietypowe kontrolki, które nie skalują się wraz z tekstem. Takie praktyki łamią to kryterium – użytkownik z wadą wzroku nie może wtedy dostosować tekstu do swoich potrzeb i napotyka bariery w postaci obciętej lub nieczytelnej treści.
1.4.5 Obrazy tekstu (AA)
Cel i istota: To kryterium zaleca, by nie używać obrazów zawierających tekst zamiast tekstu właściwego, chyba że jest to absolutnie niezbędne (np. logo). Dla osób niedowidzących zwykły tekst jest dużo korzystniejszy, ponieważ można go łatwo powiększyć, zmienić kontrast czy zastosować własne style. Tekst osadzony w obrazie nie skaluje się tak dobrze – przy powiększeniu ulega pikselizacji i może stać się nieczytelny[22]. Ponadto użytkownik korzystający z trybu wysokiego kontrastu systemowego czy własnych ustawień kolorów nie ma możliwości zmiany koloru tekstu w obrazie (np. czarnego napisu na białym tle grafiki). Dlatego WCAG preferuje używanie prawdziwego tekstu, co zapewnia elastyczność prezentacji dla słabowidzących[22].
Poprawne zastosowanie (przykłady):
– Witryna używa rzeczywistych fontów dla nagłówków i sloganów zamiast osadzania ich w postaci obrazków. Dzięki temu użytkownik może powiększyć czcionkę, zmienić kontrast (np. za pomocą stylów użytkownika), a tekst pozostaje ostry i czytelny. Jeśli konieczne jest użycie niestandardowej stylistyki, stosuje się nowoczesne technologie (CSS) zamiast obrazów.
– Jeśli już musi wystąpić tekst w grafice (np. logo lub element dekoracyjny), zapewniona jest wysoka rozdzielczość obrazka i odpowiedni kontrast. Dodatkowo dla kluczowych informacji obraz zawiera opis alternatywny (alt), aby w razie problemów użytkownik mógł odczytać treść za pomocą czytnika ekranu.
Typowe błędy:
– Tekst jako obraz o niskiej jakości: Umieszczenie ważnej informacji (np. adresu kontaktowego) w postaci małego obrazka z tekstem o słabym kontraście. Po powiększeniu strony obrazek staje się rozmyty, a osoby niedowidzące nie mogą zwiększyć rozmiaru czcionki ani poprawić kontrastu takiego tekstu. Taki element łamie zasadę skalowalności i czytelności.
– Brak alternatywy dla tekstu w obrazie: Nawet jeśli użyto obrazka z tekstem, często pomija się zapewnienie odpowiedniego tekstu alternatywnego. W efekcie osoba słabowidząca korzystająca z czytnika ekranu nie usłyszy zawartości napisu, a przy powiększeniu grafiki może nie być w stanie go odczytać. To podwójna bariera – obraz nieczytelny wizualnie i niedostępny technicznie.
(Uwaga: Na poziomie AAA istnieje surowsze kryterium 1.4.9 „Obrazy tekstu (bez wyjątków)”, które generalnie całkowicie zabrania użycia obrazów zamiast tekstu – poza logo. Praktyczne znaczenie jest analogiczne: wszędzie tam, gdzie to możliwe, należy stosować prawdziwy tekst.)
1.4.6 Kontrast (wzmocniony) (AAA)
Cel i istota: Jest to rozszerzenie kryterium 1.4.3 – dla zgodności na poziomie AAA wymaga się jeszcze wyższego kontrastu tekstu w stosunku do tła. Minimalny współczynnik wynosi tu 7:1 dla zwykłego tekstu (zamiast 4,5:1). Taki poziom kontrastu odpowiada potrzebom osób z poważniejszymi ubytkami wzroku, np. wspomniane wcześniej osoby z ostrością widzenia 20/80 potrzebują około 7:1 aby komfortowo czytać[9]. Celem jest zapewnienie maksymalnej czytelności – czarny na białym lub biały na czarnym to typowe przykłady spełniające ten wymóg z nadwyżką. Dla osób niedowidzących wysoki kontrast jest często kluczowy, dlatego spełnienie tego kryterium znacząco poprawia dostępność.
Poprawne zastosowanie (przykłady):
– Serwis oferuje tryb „wysoki kontrast” lub po prostu stosuje domyślnie bardzo kontrastową paletę kolorów: ciemny tekst na jasnym tle (lub odwrotnie) w każdej części interfejsu. Nawet małe napisy mają kontrast co najmniej 7:1 – np. ciemnoszare litery (#222) na białym tle (#FFFFFF) (~12:1). Osoby słabowidzące mogą dzięki temu wygodniej czytać treść bez zmęczenia wzroku.
– Projektant unika kombinacji kolorów, które choć spełniały minimalny kontrast AA, to nie osiągają poziomu AAA. Np. jasnoniebieski tekst na białym tle (kontrast ~4,8:1) zostaje zastąpiony ciemniejszym odcieniem niebieskiego (#004080 na białym, ~7,5:1), aby spełnić kryterium wzmocnionego kontrastu. Dzięki temu nawet osoby o bardzo słabym wzroku lub czytające w nieidealnych warunkach widzą tekst wyraźnie.
Typowe błędy:
– Kontrast akceptowalny na AA, ale za niski na AAA: Niektóre strony po osiągnięciu poziomu AA (4,5:1) nie rozważają dalszego zwiększania kontrastu. Przykładowo szary tekst #767676 na białym tle (~4,6:1) przechodzi na poziomie AA, ale jest daleki od 7:1. Dla wielu słabowidzących nadal będzie to mało komfortowe. Niespełnienie AAA nie jest formalnym błędem na niższych poziomach, ale oznacza mniejszą dostępność – użytkownik może potrzebować np. dodatkowych stylów wysokiego kontrastu, których strona nie przewiduje.
– Brak uwzględnienia dużych czcionek: Kryterium AAA wymaga dla dużego tekstu kontrastu min. 4,5:1 (bo duży tekst miał niższy próg na AA). Błędem bywa nieuwzględnienie tego – np. nagłówek 24 px w jasnym kolorze na jasnym tle o kontrastowości 4:1 nie spełnia wymogu AAA, choć spełniał AA. To może utrudnić czytanie nagłówków osobom z bardzo słabym wzrokiem.
1.4.8 Prezentacja wizualna (AAA)
Cel i istota: To kryterium dotyczy układu i formatowania tekstu – wymaga udostępnienia mechanizmów pozwalających użytkownikowi dostosować sposób wyświetlania bloków tekstu pod kątem czytelności. Chodzi m.in. o zapewnienie możliwości zmiany kolorów pierwszego planu i tła, regulacji odstępów między wierszami, długości linii tekstu czy justowania. Osoby niedowidzące (a także z niektórymi trudnościami w uczeniu się) często potrzebują tekstu przedstawionego w określony, mniej męczący sposób[23][24]. Na przykład zbyt długie linie mogą utrudniać śledzenie tekstu, a zbyt ciasno upakowane wiersze sprawiają, że łatwo zgubić miejsce podczas czytania. Kryterium 1.4.8 ma na celu umożliwienie takiej prezentacji tekstu, która nie zakłóca jego czytelności – usuwa rozpraszające elementy formatowania i pozwala użytkownikowi zastosować preferowane ustawienia.
Poprawne zastosowanie (przykłady):
– Kontrola kolorów: Strona oferuje możliwość zmiany kolorystyki tekstu i tła (lub jest zaprojektowana tak, że użytkownik może użyć własnych stylów CSS). Dzięki temu osoba słabowidząca może np. ustawić sobie biały tekst na czarnym tle, jeśli tak czyta najlepiej – a strona pozostanie czytelna, bo nie ma na niej konfliktowych elementów graficznych. Jak wskazuje W3C, możliwość wyboru kombinacji kolorów znacząco poprawia zrozumiałość treści dla wielu użytkowników z dysfunkcjami wzroku[25][26].
– Ograniczenie długości linii: Treść jest zawarta w wąskich kolumnach lub posiada opcję zmiany szerokości bloku tekstu tak, by linia zawierała maksymalnie ~80 znaków. Ułatwia to czytanie – osoba z problemami wzroku nie musi wodzić wzrokiem po całym szerokim ekranie, by przejść do kolejnej linii (mniejsze ryzyko zgubienia miejsca[24]). Na przykład artykuły na stronie mogą być wyświetlane w trybie „kolumnowym”, gdzie tekst zajmuje centralny wąski pas ekranu.
– Regulacja odstępów: CSS strony przewiduje możliwość zwiększenia interlinii (np. do 1,5) oraz odstępów między akapitami, literami i słowami. Użytkownik może za pomocą własnego arkusza stylów lub wbudowanego suwaka zwiększyć odstępy i treść nadal będzie kompletna – nic się na siebie nie nakłada ani nie ucieka poza obszar (patrz też kryterium 1.4.12 dotyczące odstępów tekstu). Większe odstępy pomagają osobom niedowidzącym (i dyslektykom) lepiej śledzić tekst linijka po linijce[27][28].
Typowe błędy:
– Brak możliwości modyfikacji układu tekstu: Strona ma sztywno zdefiniowane parametry (np. zablokowane kolory CSS, wymuszone justowanie obustronne, bardzo szerokie łamy tekstu) i nie zapewnia mechanizmu zmiany. Przez to użytkownik niedowidzący nie może dostosować prezentacji do swoich potrzeb – np. nie da się wyłączyć justowania (które potrafi powodować nierówne przerwy między wyrazami, utrudniające czytanie[29]) ani zmniejszyć liczby znaków w linii. Taka nieelastyczna strona może zniechęcić lub zmęczyć czytelnika słabowidzącego.
– Rozlewanie się lub ucinanie treści po zmianach stylu: Jeżeli deweloper nie przewidział możliwości zmiany odstępów czy kolorów, próba zastosowania własnych stylów przez użytkownika może skutkować błędami – np. tekst nachodzący na inne elementy po zwiększeniu interlinii albo niewidoczne fragmenty (białe litery na białym tle, gdyż grafika tła nie zmieniła się wraz z tekstem). Tego rodzaju sytuacje naruszają kryterium – właściwie zaprojektowana strona powinna znieść takie modyfikacje bez utraty treści[30][31].
1.4.10 Dopasowanie do ekranu (Reflow) (AA)
Cel i istota: Kryterium 1.4.10 – zwane potocznie „reflow” – wymaga, by powiększona zawartość strony mieściła się na ekranie bez potrzeby przewijania w dwóch wymiarach. Konkretnie, przy typowym powiększeniu do 400% (co odpowiada widokowi o szerokości 320 CSS pikseli), użytkownik powinien przewijać tylko w jednej osi (w kierunku czytania)[32][33]. Dla osób słabowidzących oznacza to, że mogą bardzo powiększyć stronę (np. wąski wycinek na pełen ekran) i czytać linia po linii, przewijając wyłącznie pionowo, zamiast mozolnie przesuwać się w lewo i prawo dla każdej linijki tekstu[34][35]. Ciągłe przewijanie poziome utrudnia czytanie – łatwo zgubić początek kolejnej linijki, co zwiększa wysiłek fizyczny i poznawczy przy lekturze[34]. Intencją tego kryterium jest więc umożliwienie korzystania z dużego powiększenia (do 400%) bez dezorientacji i nadmiernego przewijania.
Poprawne zastosowanie (przykłady):
– Elastyczny układ jednokolumnowy: Strona internetowa zaprojektowana responsywnie tak, że przy małych szerokościach ekranu (lub dużym zoomie) przechodzi na układ jednokolumnowy. Wszystkie sekcje, które poprzednio były obok siebie, ustawiają się jedna pod drugą, dzięki czemu powiększony tekst zawija się w wąskiej kolumnie[35][36]. Użytkownik niedowidzący powiększa stronę np. do 300% – w efekcie widzi tylko kolumnę tekstu, ale może swobodnie czytać przewijając tylko w dół. Przykładem są mobilne wersje portali informacyjnych, gdzie artykuły i boczne panele po powiększeniu układają się pionowo.
– Ukrywanie lub przenoszenie mniej istotnych elementów: W trybie wąskiego ekranu pewne elementy mogą zostać przekształcone – np. menu staje się wysuwane (hamburger), panele boczne zwinięte do nagłówka, duże tabele mają możliwość przewijania wewnętrznego. Ważne jednak, że treść główna nadal jest dostępna bez przewijania poziomego – łamie się w wąskim układzie. Dzięki temu osoba słabowidząca może czytać artykuł bez „biegania oczami” tam i z powrotem w każdej linijce[34]. Ewentualne wyjątki (mapy, duże grafiki) są traktowane jako wyłączone z tego wymogu, ale również starano się zminimalizować dla nich konieczność przewijania (np. możliwość przesuwania mapy wewnątrz ramki, oddzielnie od tekstu).
Typowe błędy:
– Wymóg przewijania w poziomie przy powiększeniu: Strona, która nie przystosowuje się do małych ekranów, po powiększeniu np. do 400% jest szersza niż widok i wymaga ciągłego scrollowania prawo-lewo, aby przeczytać każdy wiersz tekstu. Taki układ nie spełnia kryterium Reflow – użytkownik niedowidzący odczuwa ogromną trudność, bo po przeczytaniu fragmentu musi przewinąć, by zobaczyć koniec linijki, a następnie z powrotem w lewo, by zacząć następną linię[34][35]. To szybko prowadzi do zagubienia miejsca w tekście.
– Sztywne szerokości elementów: Jeśli na stronie zastosowano duże, nieelastyczne elementy (np. tabela o stałej szerokości 1200px), to przy powiększeniu zawartość tabeli będzie wymuszać przewijanie poziome lub wręcz wychodzić poza ekran. Brak mechanizmu alternatywnego (np. przewijania samej tabeli lub przełączenia na widok listy) oznacza, że strona nie jest w pełni dostępna dla powiększenia 400%. Osoba słabowidząca może zobaczyć tylko fragment takiego elementu i nie ma możliwości wygodnego obejrzenia całości, nawet używając najwyższego zoomu.
1.4.11 Kontrast elementów nietekstowych (AA)
Cel i istota: Kryterium to uzupełnia wymagania kontrastu o wizualne elementy interfejsu i grafiki. Nakazuje, by istotne wizualnie informacje, takie jak obramowania pól formularza, ikony, wykresy itp., miały kontrast co najmniej 3:1 względem tła[37][38]. Osoby niedowidzące muszą móc zidentyfikować wszystkie ważne elementy interfejsu – przyciski, kontrolki, zaznaczenia stanu – nawet jeśli są one przedstawione graficznie. Zbyt niski kontrast np. cienkiej szarej ramki pola formularza na białym tle sprawi, że użytkownik słabowidzący może w ogóle nie zauważyć pola[39][40]. W praktyce kryterium to wymusza, by wygląd takich elementów był równie widoczny jak duży tekst – posłużono się tu podobnym progiem kontrastu (3:1) jak dla dużej czcionki, gdyż cienkie linie i kształty też wymagają wyrazistości dla słabego wzroku[39].
Poprawne zastosowanie (przykłady):
– Wyraźne obramowania i ikonografia: Pola tekstowe formularza mają ciemną ramkę (np. #767676 na białym tle daje ok. 5:1)[41][42]. Przyciski akcji są wypełnione kolorem o odpowiednim kontraście względem tła strony – np. granatowy przycisk „Szukaj” na białym tle. Dzięki temu osoba niedowidząca łatwo dostrzeże, gdzie są pola do wypełnienia i przyciski do kliknięcia. Ważne ikony (np. koszyk sklepu, strzałka „dalej”) również odznaczają się wyraźnie od tła.
– Wykresy i grafiki informacyjne dostosowane kontrastowo: Linie i słupki na wykresach, legendy, znaczniki itp. są projektowane z myślą o czytelności – np. użyto intensywnych kolorów lub grubych linii zamiast bladych pasteli. Jeżeli pewien kolor na wykresie jest jasny, to obrys lub kształt elementu jest dodatkowo uwydatniony (np. białe kółko oznaczające punkt danych ma czarną obwódkę 3:1 względem tła wykresu). To zapewnia, że informacje w grafice nie znikną dla oczu słabowidzącego użytkownika[40].
Typowe błędy:
– Niewidoczne pola formularzy: Częsty błąd to bardzo jasne, cienkie obramowania pól lub brak wyraźnego tła przy polach. Przykładowo pole wyszukiwania z bladą szarą ramką na białym tle może zostać przeoczone przez osobę niedowidzącą. W badaniu Fundacji Widzialni okazało się, że użytkownik słabowidzący nie mógł odnaleźć na stronie wyszukiwarki właśnie z powodu zbyt niskiego kontrastu jej elementów – jasnoszarych na białym tle[12]. Takie sytuacje łamią to kryterium.
– Nieczytelne wskaźniki stanu: Jeśli zaznaczenie wyboru (np. „checkbox” z ptaszkiem) pojawia się w kolorze o niskim kontraście (np. jasnozielony znacznik na jasnym tle), osoba słabowidząca może nie zauważyć, czy element jest zaznaczony czy nie. Błąd ten obejmuje także np. wskaźnik fokusu – jeżeli focus (podświetlenie aktywnego elementu) jest zaznaczony słabą poświatą lub cienką obwódką o niskim kontraście, to użytkownik może go nie dostrzec, gubiąc orientację w nawigacji klawiaturą[43][44].
– Elementy interfejsu bez żadnej wyróżniającej granicy: Czasem minimalistyczny design zakłada brak klasycznych przycisków – np. klikane napisy bez podkreślenia czy obramowania. Jeżeli jedyną wskazówką interaktywności jest np. subtelna zmiana koloru tekstu przy najechaniu myszą, to element taki nie spełnia wymogu kontrastu stanu (focus/hover) i może zostać pominięty przez niedowidzącego. Zgodnie z WCAG, granica komponentu lub widoczny wskaźnik (np. ikonka strzałki w przycisku rozwijanym) muszą mieć kontrast ≥3:1, jeśli stanowią jedyną informację o istnieniu kontrolki[45][46].
1.4.12 Odstępy w tekście (AA)
Cel i istota: Kryterium to gwarantuje, że modyfikacja odstępów w tekście nie spowoduje utraty treści ani funkcjonalności. Użytkownik powinien móc zwiększyć (co najmniej do określonych wartości) kluczowe właściwości składu tekstu: odstęp między wierszami (line-height) do 1,5 em, odstęp między akapitami do 2 em, odstępy między literami o 0,12 em i między słowami o 0,16 em[47][48]. Ma to znaczenie dla osób z wadami wzroku, które czasem lepiej czytają tekst z większymi przerwami – ciasno upakowane zdania mogą zlewać się im w blok, utrudniając śledzenie. Spełnienie tego kryterium oznacza, że strona nie „rozpadnie się” ani nic nie zniknie, gdy użytkownik narzuci własne style zwiększające te odstępy. Dla niedowidzących przekłada się to na możliwość poprawy czytelności tekstu poprzez luźniejszy skład, co bywa pomocne przy czytaniu dłuższych partii tekstu[49][31].
Poprawne zastosowanie (przykłady):
– Elastyczny design tekstu: Deweloper upewnił się, że jeśli użytkownik zastosuje w przeglądarce własny arkusz stylów zwiększający line-height, letter-spacing itp. do wyznaczonych wartości, to żaden element tekstowy nie zostanie obcięty ani zasłonięty. Np. pola tekstowe mają na tyle duże wysokości (height) lub zastosowano w CSS line-height w jednostkach względnych, że dodatkowe odstępy mieszczą się w nich bez ucinania liter. Dzięki temu osoba słabowidząca, która za pomocą rozszerzenia przeglądarki zwiększa sobie odstępy między linijkami do 1,5, widzi cały tekst akapitu nadal w całości – nic na siebie nie nachodzi ani nie wypada poza box[30][31].
– Opcja zmiany interlinii na stronie: Niektóre serwisy (np. czytniki e-booków online, blogi) wprost udostępniają użytkownikowi kontrolę nad interlinią i wielkością czcionki. Przy zaimplementowaniu tej funkcji autorzy pilnują, by interfejs poprawnie reagował – np. kontener z tekstem się rozszerza, dodatkowa przestrzeń nie powoduje zanikania przycisków czy obrazków osadzonych między akapitami. Użytkownik słabowidzący może jednym kliknięciem ustawić większy odstęp między liniami, co ułatwia mu czytanie (mniejsze ryzyko przeskoczenia wzrokiem do złej linii).
Typowe błędy:
– Tekst nachodzący na siebie po zwiększeniu odstępów: Jeśli strona nie została przetestowana pod tym kątem, zwiększenie odstępu między wierszami do 1.5 może skutkować tym, że dolna część liter z wyższej linii zachodzi na górną część liter niższej linii (albo elementy są ucinane). Często dotyczy to np. przycisków o określonej stałej wysokości – dodatkowy odstęp powoduje, że napis się nie mieści. Jest to niezgodne z kryterium 1.4.12, bo treść staje się nieczytelna lub obcięta po takiej modyfikacji.
– Wykorzystywanie zbyt ciasnego składu jako nośnika informacji: Niekiedy projekt przewiduje np. ujemne kerningi lub bardzo specyficzne złamania linii, które przy zmianie odstępów tracą sens. Jeśli np. ikony emoji w tekście są celowo umieszczone bez spacji dla efektu graficznego, to dodanie odstępu między słowami może je „rozsypać”. Takie praktyki są ryzykowne, bo mogą utrudnić korzystanie ze strony tym, którzy potrzebują dostosować odstępy dla czytelności. W myśl kryterium – autor nie ma obowiązku sam ustawiać dużych odstępów wszędzie, ale musi zapewnić, że nic nie przeszkodzi użytkownikowi w nadpisaniu stylu odstępów na własne potrzeby[50][30].
1.4.13 Treść spod kursora lub fokusu (AA)
Cel i istota: Kryterium to dotyczy dodatkowej treści, która pojawia się przy najechaniu kursorem lub ustawieniu fokusu na element (np. podpowiedzi, wyskakujące opisy, menu rozwijane na hover). Wymaga się, by taka treść była: możliwa do zamknięcia (dismissible) bez przesuwania kursora, hoverowalna (użytkownik może najechać na nią kursorem bez jej znikania) oraz utrzymywana (persistent) – pozostaje widoczna tak długo, jak fokus lub kursor są na elemencie, a znika dopiero po ich usunięciu, ewentualnie po dłuższym czasie[51]. Dla osób niedowidzących ma to istotne znaczenie, ponieważ często potrzebują więcej czasu, by odczytać pojawiające się informacje. Jeśli np. wskazówka narzędzia (tooltip) zniknie po 5 sekundach, osoba słabowidząca może nie zdążyć jej przeczytać. Podobnie, gdy dodatkowa treść jest niestabilna – próba jej powiększenia lub najechania lupą powoduje zniknięcie. Kryterium 1.4.13 zapewnia, że użytkownik niedowidzący będzie mógł spokojnie przenieść powiększony widok na pojawiającą się treść i ją przeczytać, bez obawy że zniknie mu sprzed oczu.
Poprawne zastosowanie (przykłady):
– Trwałe podpowiedzi na fokus: Pola formularza posiadają ikony „?” z podpowiedziami. Po wybraniu pola fokus (lub kliknięciu ikony) wyświetla się dymek z instrukcją. Dymek ten nie znika automatycznie po krótkim czasie – pozostaje aż do zamknięcia przez użytkownika (np. kliknięcia przycisku „x”) albo do przeniesienia fokusu poza pole[51]. Dzięki temu osoba słabowidząca może powiększyć stronę i przeczytać wskazówkę we własnym tempie, a także najechać kursorem na dymek, by np. skopiować z niego tekst – dymek nie zniknie przy takiej interakcji.
– Menu rozwijane dostępne dla lupy: Strona ma menu nawigacyjne rozwijane po najechaniu myszą. Zgodnie z kryterium, takie menu nie znika natychmiast, gdy kursor zjedzie z przycisku – użytkownik może na nie wjechać kursorem (hover) i spokojnie wybrać pozycję, bez „chowania się” menu[51]. Ponadto menu można też zamknąć klawiszem Esc (dismiss), nie wymagając precyzyjnego trafienia kursorem. To pozwala osobie niedowidzącej, korzystającej z powiększenia ekranu, bez stresu obsłużyć rozwijaną nawigację.
Typowe błędy:
– Znikająca treść na hover: Tooltip lub panel, który pokazuje się po najechaniu, znika od razu, gdy tylko kursor nieco się przesunie (np. trzeba idealnie trafić kursorem w jego obszar, inaczej zniknie). Użytkownik niedowidzący, próbując przesunąć powiększony widok lub kursor, przypadkowo schowa taką treść i nie zdoła jej przeczytać. Taki mechanizm jest niezgodny z kryterium – treść powinna być „hoverowalna”, czyli dostępna pod kursorem bez natychmiastowego zamknięcia.
– Limit czasowy na dodatkową treść: Część stron ustawia timeout, po którym podpowiedź znika (np. po 5 sek.). Dla wielu użytkowników to zbyt krótko. Osoba słabowidząca może nie zdążyć przeskanować wzrokiem całej informacji nim ta zniknie. To również narusza zasady 1.4.13, które wymagają, by treść utrzymywała się co najmniej tak długo, jak jest w fokusie/hover (a najlepiej aż do aktywnego zamknięcia przez użytkownika).
– Brak możliwości zamknięcia: Niekiedy dodatkowa treść pojawia się i zasłania część ekranu, a jedynym sposobem jej usunięcia jest wykonanie jakiejś akcji, która może być trudna do znalezienia. Kryterium wymaga prostego mechanizmu zamknięcia (np. klawisz Esc). Jego brak utrudnia osobom słabowidzącym powrót do głównej treści – mogą one utknąć z nakładką na ekranie nie wiedząc, jak ją schować.
Funkcjonalność (Operable)
Zasada Funkcjonalność oznacza, że interfejs i nawigacja muszą być dostępne niezależnie od sposobu ich obsługi. Osoby niedowidzące często posługują się standardowymi metodami (mysz, touchpad), ale czasem także klawiaturą lub technologiami asystującymi. Ważne jest, aby elementy interaktywne były łatwe do zlokalizowania wzrokiem, a strona nie stwarzała dodatkowych utrudnień w obsłudze (np. zbyt krótkie limity czasu, migotanie). Poniżej przedstawiono kryteria operacyjne kluczowe z punktu widzenia użytkowników słabowidzących.
2.2.1 Dostosowanie czasu (A)
Cel i istota: Kryterium to wymaga, by użytkownicy mieli możliwość wydłużenia lub wyłączenia limitów czasowych wszędzie tam, gdzie czas nie jest elementem istoty danej funkcjonalności. Osoby niedowidzące często potrzebują więcej czasu na przeczytanie i zrozumienie treści lub wypełnienie formularzy, gdyż robią to wolniej (np. z powodu konieczności przewijania powiększonego ekranu)[52][53]. Zbyt krótki czas na reakcję może uniemożliwić im ukończenie zadania. Zapewnienie mechanizmów dostosowania czasu (np. „przedłuż sesję”, „więcej czasu”) sprawia, że niedowidzący użytkownik nie zostanie nagle wylogowany lub pozbawiony możliwości dokończenia czynności tylko dlatego, że czytał coś dłużej[52][54]. Krótko mówiąc – każdy powinien mieć wystarczająco czasu, by wykonać interakcję, a osoby słabowidzące potrzebują go często więcej niż standardowo przewidziano.
Poprawne zastosowanie (przykłady):
– Formularz online posiada informację o limicie czasu (np. 10 minut bezczynności) oraz przycisk „Przedłuż czas”, który pojawia się na minutę przed upływem. Użytkownik niedowidzący, który wolno wprowadza dane (bo np. musi powiększać i przesuwać ekran dla każdego pola), otrzyma ostrzeżenie i może bez stresu przedłużyć sesję, aby dokończyć wypełnianie formularza[52][55].
– Aplikacja nie zakłada sztywnych okien czasowych tam, gdzie to niekonieczne. Przykładowo quiz wiedzy ma co prawda licznik czasu, ale w trybie dla użytkowników z niepełnosprawnościami (lub po zaznaczeniu opcji) można go wyłączyć, dając tyle czasu, ile potrzeba. Osoba słabowidząca może wtedy spokojnie przeczytać każde pytanie powiększając tekst, nie martwiąc się, że minie czas zanim doczyta do końca.
– Strona z aktualizującymi się danymi (np. wyniki sportowe) oferuje możliwość pauzy automatycznego odświeżania. Dzięki temu słabowidzący użytkownik może zatrzymać przewijający się ticker wyników i przeczytać go we własnym tempie, a następnie wznowić aktualizacje.
Typowe błędy:
– Brak opcji przedłużenia czasu: Użytkownik jest automatycznie wylogowywany po X minutach, bez ostrzeżenia ani możliwości wydłużenia. Osoba niedowidząca może nie zdążyć w porę zareagować i traci efekty swojej pracy (np. wypełniany formularz)[53][56]. Taki design narusza kryterium – należy dać wyraźne ostrzeżenie i łatwy sposób na uzyskanie dodatkowego czasu.
– Szybko znikające komunikaty lub elementy: Strona pokazuje ważny komunikat (np. toast o nowej wiadomości) tylko przez parę sekund, po czym znika on na zawsze. Użytkownik słabowidzący może go w ogóle nie zdążyć przeczytać, co czyni funkcjonalność niedostępną. Zgodnie z WCAG w takich sytuacjach powinno istnieć inne źródło informacji (np. lista powiadomień) albo możliwość przywrócenia komunikatu[57][58].
– Automatyczne przenoszenie lub zmiana strony po czasie: Np. strona wyników wyszukiwania, która sama przekierowuje na inną stronę po 5 sekundach. Niedowidzący użytkownik może nie zdążyć przeczytać wyników zanim nastąpi przekierowanie. Jeżeli taka zmiana jest niezbędna, to należy dać opcję zatrzymania odliczania.
(Uwaga: Na poziomie AAA istnieje powiązane kryterium 2.2.3 „Bez ograniczeń czasowych”, które sugeruje eliminację wszelkich limitów czasu tam, gdzie to możliwe. Przestrzeganie go oznacza maksymalną przyjazność dla użytkowników potrzebujących dużo czasu – w tym wielu słabowidzących – ale nie zawsze jest wykonalne, np. w aplikacjach transakcyjnych z powodów bezpieczeństwa.)
2.2.2 Pauza, zatrzymanie, ukrycie (A)
Cel i istota: Kryterium to dotyczy treści ruchomych, migających lub automatycznie aktualizujących się. Wymaga, aby użytkownik miał możliwość wstrzymania, zatrzymania lub ukrycia takiej treści, jeśli trwa ona dłużej niż 5 sekund[59][60]. Dla osób niedowidzących wszelkie animacje, przesuwające się teksty czy zmieniające się dynamicznie sekcje mogą stanowić ogromne rozproszenie uwagi. Czytanie powiększonego, przewijającego się tekstu jest bardzo trudne – zanim słabowidzący przeniesie wzrok, treść może już zniknąć. Ruch na stronie może również utrudniać skupienie wzroku na innych elementach. Dlatego istotne jest umożliwienie zatrzymania animacji czy karuzeli treści, by użytkownik mógł spokojnie przeczytać zawartość statycznie[61][62]. Reguła „5 sekund” sprawia, że krótkie, jednorazowe animacje nie muszą mieć kontroli, ale wszystko co dłuższe lub stale poruszające się – już tak.
Poprawne zastosowanie (przykłady):
– Karuzela banerów z kontrolkami: Na stronie głównej obracają się co kilka sekund slajdy promocyjne. Implementacja zgodna z WCAG daje użytkownikowi widoczne kontrolki „pauza / odtwarzaj” oraz strzałki do ręcznego przewijania. Dzięki temu osoba niedowidząca może kliknąć „pauza” i zatrzymać pokaz slajdów, aby spokojnie przeczytać tekst na aktualnym banerze[63][64].
– Migający element z opcją wyłączenia: Jeśli strona ma dynamiczny ticker (np. przesuwające się na pasku newsy), obok znajduje się przycisk „Stop przewijanie”, który zatrzyma tekst. Alternatywnie możliwe jest przełączenie tickera w tryb statycznej listy. Osoba słabowidząca, którą ruchomy tekst dekoncentruje, może łatwo go wyłączyć, by móc czytać newsy we własnym tempie.
– Automatyczne aktualizacje z kontrolą częstotliwości: W przypadku danych odświeżających się (np. kursy giełdowe) interfejs pozwala ustawić, jak często następuje odświeżenie lub całkowicie je wstrzymać[65][62]. Użytkownik może np. zatrzymać aktualizacje, przeanalizować wyświetlone dane, a potem wznowić je. Nie traci przy tym informacji – aplikacja może wyświetlić powiadomienie „wstrzymano aktualizację” i pozwolić jednym kliknięciem pobrać nowe dane.
Typowe błędy:
– Brak możliwości zatrzymania animacji: Np. tło strony jest animowane (poruszające się obrazy) i użytkownik nie ma jak go zatrzymać. Dla osoby niedowidzącej korzystającej z powiększenia takie ruchome tło może być wyjątkowo rozpraszające, a brak opcji wyłączenia narusza to kryterium.
– Automatyczne przewijanie tekstu bez pauzy: Marquee lub slider tekstowy, który stale przewija treść (np. wyniki meczów) i nie zatrzymuje się po najechaniu kursorem ani nie ma przycisku pauzy. Taka implementacja uniemożliwia wolniejsze przeczytanie – użytkownik musi gonić wzrokiem tekst. Według WCAG, jeśli coś się porusza równolegle z inną treścią, musi być opcja to zatrzymać[59][61].
– Migające banery reklamowe bez „X”: Część stron zawiera migotliwe lub przewijające się reklamy, których nie da się zamknąć (brak widocznego „X” lub linku „zatrzymaj animację”). Migotanie nie tylko może wywołać ataki padaczki (to kryterium 2.3.1), ale dla niedowidzącego jest też męczące i odciąga uwagę od treści właściwej. To podwójnie problematyczne, a z punktu widzenia tego kryterium – powinno być rozwiązane przez umożliwienie ukrycia takiej reklamy lub zapauzowania animacji.
2.4.7 Widoczny fokus (AA)
Cel i istota: Kryterium to wymaga, aby wszystkie interaktywne elementy (linki, przyciski, pola itp.) posiadały widoczny wskaźnik fokusu podczas nawigacji za pomocą klawiatury[66][67]. Oznacza to, że gdy dana kontrolka otrzymuje fokus (np. poprzez naciśnięcie klawisza Tab), musi być to wyraźnie zaznaczone wizualnie. Dla osób niedowidzących, które czasem posługują się klawiaturą (np. tabulator, strzałki) zamiast myszy, widoczność fokusu jest krytyczna – stanowi odpowiednik wskaźnika myszy dla nawigacji klawiaturowej[68][69]. Bez tego użytkownik nie wie, który element jest aktualnie aktywny, co uniemożliwia efektywne poruszanie się po stronie[66][67]. Nawet ci słabowidzący, którzy korzystają z myszy, mogą skorzystać na wyraźnych stylach fokusu – np. gdy klikną element i potem obsługują klawiaturą, dobrze widoczny fokus pomaga zachować orientację.
Poprawne zastosowanie (przykłady):
– Domyślne obramowanie lub własny styl: Strona nie usuwa domyślnych stylów fokusu przeglądarki (np. nie stosuje outline: none w CSS), dzięki czemu elementy zaznaczone klawiaturą mają wyraźną ramkę lub poświatę. Możliwe też, że deweloper zdefiniował własny styl – np. grube podkreślenie linku lub zmiana tła przycisku na ciemniejsze – ale zachował wysoką widoczność tego efektu[70][71]. Dzięki temu osoba słabowidząca widzi, gdzie znajduje się fokus.
– Fokus wyróżniający się od otoczenia: Przy aktywnym elemencie styl fokusu zapewnia kontrast co najmniej 3:1 względem otaczających kolorów (zgodnie z kryterium 1.4.11) oraz ma odpowiednią grubość/rozmiar. Np. link otrzymuje niebieską obwódkę o grubości 2px na jasnym tle, co jest bardzo czytelne. Takie praktyki spełniają dodatkowo zalecenia wyższego poziomu (AAA) co do jakości wskaźnika fokusa[72][73]. Niedowidzący użytkownik nie przeoczy fokusu, bo jest on zaprojektowany jak wyraźny podświetlony „kursor klawiatury” na stronie.
Typowe błędy:
– Usuwanie/wszystanie wskaźnika fokusu: Popularny, ale skrajnie niekorzystny błąd – autor strony ustawia w CSS :focus { outline: none; } bez zastąpienia go innym widocznym stylem. W efekcie element w fokusie nie ma żadnego wyróżnienia[74][75]. Użytkownik poruszający się Tabem „zgaduje”, gdzie jest – co dla słabowidzącego jest praktycznie niemożliwe. Taka strona nie spełnia kryterium 2.4.7 i jest nieoperacyjna z klawiatury dla osób z ubytkiem wzroku.
– Zbyt słabo widoczny fokus: Fokus niby jest, ale zaprojektowany niedbale – np. cienka linia w kolorze mało odróżniającym się od tła (blado-niebieska przerywana obwódka na szarym tle). Taki wskaźnik może zostać przeoczony, szczególnie przy słabym wzroku lub na słabym ekranie[71][72]. Choć formalnie styl fokusu istnieje, to nie spełnia swojej roli. Jest to przeciwieństwo idei tego kryterium, które ma pomóc wzrokowo śledzić nawigację klawiaturą[66][67].
– Fokus ginący pod innymi elementami: Niekiedy błąd polega na tym, że element w fokusie zostaje przykryty przez jakiś overlay lub jest poza kadrem i strona go nie scrolluje. Użytkownik naciska Tab, ale nie widzi fokusu, bo np. jest on poza widocznym obszarem (i brak automatycznego przewinięcia) lub został schowany pod stałym nagłówkiem. W rezultacie fokus nie jest realnie widoczny. To również narusza zasadę – fokus powinien być zawsze częściowo widoczny w oknie[76][77].
(Uwaga: W WCAG 2.2 dodano dodatkowe kryteria AAA związane z fokusem – „Fokus niezakryty (minimum)”, „Fokus niezakryty (ulepszony)” oraz „Wygląd fokusu”. Omówiono je poniżej, ponieważ wprost odnoszą się do potrzeb osób słabowidzących.)
2.4.11 Fokus niezakryty (minimum) (AA)
Cel i istota: Kryterium to (nowe w WCAG 2.2) rozszerza wymóg widoczności fokusu o sytuacje złożonych układów. Nakazuje, by element z fokusem nie był całkowicie zasłonięty przez inne treści stworzone przez autora strony[78][79]. Innymi słowy – gdy przemieszczamy fokus klawiaturą, aktywny element musi być przynajmniej częściowo widoczny dla użytkownika. To istotne m.in. w przypadku tzw. sticky header/footer (przyklejonych nagłówków lub pasków na dole). Dla osoby niedowidzącej, która i tak widzi tylko fragment ekranu, sytuacja, w której fokus „schowa się” za banerem lub modalem, jest bardzo myląca – może odnieść wrażenie, że nawigacja utknęła lub strona się zepsuła[76][77]. Dzięki temu kryterium autorzy muszą dbać, by żaden stały element nie przykrywał punktu fokusu (np. poprzez odpowiednie marginesy lub przewijanie strony w momencie focus).
Poprawne zastosowanie (przykłady):
– Odskrolowanie za sticky header: Strona ma stały nagłówek u góry. Programista zadbał, by skrypty przewijające fokus (lub fragmenty id) uwzględniały wysokość nagłówka – np. stosując CSS scroll-padding-top. Dzięki temu, gdy fokus przechodzi do sekcji tuż pod nagłówkiem, strona przewija nieco więcej treści, tak aby aktywny element nie krył się pod paskiem[80][81]. Osoba słabowidząca widzi cały element z fokusem lub przynajmniej jego znaczną część.
– Modale i bannery modalne: Jeśli pojawia się baner (np. zgoda na cookies) lub okienko modalne, które mogłoby zakryć elementy na stronie, to nawigacja klawiaturą jest tak zorganizowana, że fokus nie przejdzie za ukryty obszar. Np. dopóki baner cookie nie jest zamknięty, fokus krąży tylko w jego obrębie (co spełnia zasadę „modalność”). Gdyby jednak jakimś sposobem fokus znalazł się pod banerem, to autor stylów zapewnił, że element z fokusem jest częściowo widoczny (np. baner jest półprzezroczysty lub nie zajmuje 100% ekranu). Zgodnie z kryterium minimum, fokus musi być choć trochę widoczny nawet w takich okolicznościach[82][80].
Typowe błędy:
– Fokus za banerem cookie: Po akceptacji cookies, baner zostaje na stronie jako niewidoczny element lub wciąż zajmuje miejsce, a focus przechodzi „pod spód”. Jeśli baner miał wysokość np. 100px, to może zakrywać aktywny link, który akurat znalazł się w tej strefie. Użytkownik niedowidzący nie widzi fokusa – bo jest na zasłoniętym elemencie – i nie wie, gdzie się znajduje[82][80]. To jest dokładnie scenariusz, któremu to kryterium ma zapobiegać.
– Przewijanie fokusowe bez marginesu: Programowo ustawiany fokus (np. po zamknięciu okna modalnego fokus wraca do wywołującego przycisku) jest przewijany tak, że element z focusem ląduje na krawędzi ekranu, częściowo zasłonięty przez stały nagłówek. Błąd polega na braku scroll-padding – w efekcie użytkownik widzi tylko połowę obiektu z fokusem, reszta ginie pod nagłówkiem. Dla słabowidzącego oznacza to niepełną widoczność punktu interakcji, co narusza zasadę, że powinien on być zawsze w polu widzenia[76][77].
2.4.12 Fokus niezakryty (ulepszony) (AAA)
Cel i istota: Jest to zaostrzenie kryterium 2.4.11 – na poziomie AAA wymaga, by element z fokusem był w pełni widoczny, nie tylko częściowo. Oznacza to, że żaden fragment aktywnego elementu nie może być przykryty przez inne treści strony. To kryterium jest adresowane do zapewnienia maksymalnej czytelności fokusu, co szczególnie doceniają użytkownicy słabowidzący i korzystający z dużych powiększeń. Przy spełnieniu tego wymogu, osoba niedowidząca zawsze zobaczy cały obszar aktualnie zaznaczonego elementu, co ułatwia jej zrozumienie kontekstu (np. pełnej etykiety przycisku). Kryterium „ulepszone” zachęca autorów, by projektowali interfejs tak, aby focus nigdy nie wpadał pod inne elementy – np. poprzez unikanie nakładających się warstw lub dynamiczne przesuwanie przeszkadzających paneli.
Poprawne zastosowanie (przykłady):
– Automatyczne przewijanie z nadmiarem: Strona przy przeskoku fokusu przewija zawartość tak, że element z fokusem znajduje się zawsze w pewnej odległości od krawędzi (np. 20px marginesu). Dzięki temu nawet jeśli jest stały element interfejsu, fokus nie zbliża się do niego na tyle, by być przysłoniętym. Użytkownik słabowidzący widzi cały podświetlony element plus trochę przestrzeni wokół, co ułatwia koncentrację wzroku.
– Kompaktowe nagłówki sticky: Projektanci decydują się, by stałe nagłówki lub stopki automatycznie się chowały lub zmniejszały, gdy użytkownik zaczyna nawigować klawiaturą po treści poniżej. To zapewnia, że w momencie przechodzenia fokusem, te elementy nie kolidują z widokiem fokusa. W efekcie element z fokusem zawsze będzie w całości widoczny, bo żadne sticky UI mu nie przeszkodzi – spełniając tym samym AAA.
Typowe błędy:
– Błędy tutaj to właściwie wszystko, co dopuszcza tylko częściową widoczność fokusa, co już omówiono przy poziomie AA. Brak dodatkowych rozwiązań sprawiających, że element w fokusie ma margines wolnej przestrzeni, oznacza niespełnienie ulepszonego kryterium AAA. Np. fokus stykający się krawędzią z nagłówkiem (choć niezasłonięty, ale tuż pod nim) – to już nie spełnia AAA, bo element nie jest w pełni odsłonięty (jego górna krawędź dotyka nakładki). Osoba o bardzo słabym wzroku mogłaby nie zauważyć fragmentu, jeśli zlewa się z krawędzią. AAA wymaga bardziej rygorystycznego podejścia – by takie sytuacje nie występowały.
2.4.13 Wygląd fokusu (AAA)
Cel i istota: Kryterium to (również wprowadzone w WCAG 2.2) definiuje jakościowe wymagania co do samego stylu wskaźnika fokusu. Określa m.in., że obszar zaznaczenia fokusu musi mieć wielkość co najmniej równoważną obrysowi 2px dookoła elementu oraz kontrast przynajmniej 3:1 względem stanu bez fokusu[83]. W praktyce oznacza to, że fokus powinien być gruby i kontrastowy, by był wyraźnie dostrzegalny. Dla osób niedowidzących jest to niezwykle ważne – cienkie obwódki mogą umykać ich uwadze, podobnie jak subtelne zmiany kolorów. Dzięki temu kryterium na poziomie AAA strona ma naprawdę dobrze widoczny fokus, co przekłada się na jeszcze wygodniejszą nawigację klawiaturą. Wskaźnik fokusu staje się łatwo zauważalny nawet przy peryferyjnym spojrzeniu czy na ekranie o słabych parametrach.
Poprawne zastosowanie (przykłady):
– Gruby kontrastowy outline: Projektant ustawił styl :focus np. jako 3px obramowanie w kolorze, który mocno odcina się od tła i samego elementu. Dla przycisku o niebieskim tle, fokus to gruba biała obwódka (kontrast >3:1 względem niebieskiego) plus dodatkowy cień, co sprawia, że całość jest bardzo wyraźna na każdej powierzchni. Taki wygląd spełnia warunki AAA – powierzchnia fokusa jest duża, a różnica wizualna dobrze zauważalna[72][84].
– Zmiana tła lub tekstu przy fokusie: Zamiast obwódki, developer przewidział zmianę stylu całego elementu – np. link w fokusie staje się z negatywu (jasny tekst na ciemnym prostokątnym tle). Powierzchnia zmiany to co najmniej tak duży obszar jak 2px obramowanie wokół linku, a kontrast nowego tła do starego jest silny. W efekcie fokus „bije po oczach”, nie sposób go przegapić. Taki kreatywny styl również spełnia kryterium Wyglądu fokusu.
Typowe błędy:
– Zbyt mały lub cienki wskaźnik: Jeśli wskaźnik fokusu ma powierzchnię mniejszą niż wymagane minimum (np. tylko 1px obramowania), to nie spełnia tego kryterium AAA. Dla użytkownika niedowidzącego taki fokus może być niewystarczająco widoczny, zwłaszcza na dużym monitorze czy w nietypowych warunkach oświetleniowych.
– Niewystarczający kontrast wskaźnika: Jeżeli fokus pojawia się jako zmiana koloru, ale ten nowy kolor nie odróżnia się wyraźnie od stanu normalnego (kontrast <3:1), to również jest to błąd według AAA[83]. Przykładowo, zmiana odcienia obramowania z jasnoszarego na ciemnoszary (gdy tło elementu jest białe) – różnica może być ledwie dostrzegalna. Osoba słabowidząca może takiej subtelności nie zauważyć, więc kryterium wymaga mocniejszego kontrastu.
– Fokus widoczny, ale tylko wokół części elementu: Spotyka się czasem stylistykę, gdzie fokus to np. niewielki znacznik (jakby zakreślenie tylko dolnej krawędzi). Jeśli obszar tego znacznika nie odpowiada co najmniej obwodowi 2px wokół całego elementu, nie spełnia to wymagań. Niedowidzący może przegapić tak fragmentaryczny wskaźnik. AAA preferuje ciągły, wyraźny obrys lub inne zaznaczenie o wystarczającej powierzchni.
Zrozumiałość (Understandable)
Zasada Zrozumiałość oznacza, że zawartość i sterowanie interfejsem powinny być intuicyjne i klarowne. Choć większość kryteriów w tej kategorii dotyczy języka i spójności z punktu widzenia wszystkich użytkowników (w tym np. osób z dysfunkcjami poznawczymi), kilka aspektów ma znaczenie także dla osób niedowidzących. Słabowidzący często polegają na stałych miejscach elementów i klarownych etykietach, aby szybko odnaleźć potrzebne informacje przy ograniczonym polu widzenia lub powiększeniu. Poniżej omówiono te kryteria, które przekładają się na lepszą orientację i zrozumiałość interfejsu dla osób z uszkodzonym wzrokiem.
3.2.3 Spójna nawigacja (AA)
Cel i istota: Kryterium to wymaga, by powtarzalne elementy nawigacyjne (menu, linki, sekcje) były prezentowane w stałej kolejności i miejscu na wszystkich stronach serwisu[85][86]. Dla użytkownika niedowidzącego ma to duże znaczenie: przy korzystaniu z powiększenia widzi on jednorazowo mały wycinek strony, więc orientuje się często poprzez pamięć układu. Jeśli menu zawsze jest w tym samym miejscu i w takiej samej kolejności, łatwiej jest je odnaleźć i nawigować nawet przy dużym zoomie[85][87]. Osoby słabowidzące używają wskazówek wzrokowych i granic elementów do szybkiego lokalizowania znanych fragmentów – spójność nawigacji im to umożliwia[85][87].
Poprawne zastosowanie (przykłady):
– Menu główne niezmienne na każdej stronie: Każda podstrona serwisu zawiera identyczny pasek nawigacyjny (np. u góry) w tej samej kolejności: Home, O nas, Produkty, Kontakt. Osoba niedowidząca po kilku wizytach pamięta, gdzie szukać danego odnośnika – np. wie, że „Kontakt” jest ostatnią pozycją w menu u góry. Nawet przy powiększeniu szybko odnajduje ten link, bo układ jest spójny na każdej stronie[88][89].
– Elementy interfejsu w stałych miejscach: Przykładowo pole wyszukiwania zawsze znajduje się w prawym górnym rogu strony. Nawet jeśli na niektórych podstronach jest mniej elementów, pole to nie zmienia położenia względem krawędzi. Użytkownik słabowidzący z góry kieruje wzrok (lub kursor) w ten róg ekranu po wejściu na stronę, by skorzystać z wyszukiwarki – nie musi jej za każdym razem szukać od nowa[85][90].
– Przewidywalna kolejność treści: Jeśli każda strona artykułu ma na dole te same linki (np. „Powrót do góry”, „Następny artykuł”), i zawsze w tej samej kolejności, to osoba niedowidząca łatwo nauczy się, że po skończeniu czytania może przewinąć do końca i tam znajdzie np. link do kolejnego tekstu. Spójność kolejności pomaga jej nie błądzić wzrokiem po ekranie – wie dokładnie, gdzie spodziewać się danej opcji[86][90].
Typowe błędy:
– Niespójne menu na różnych stronach: Np. na stronie głównej menu ma kolejność A-B-C, a na podstronie kolejność zmienia się na A-C-B. Osoba niedowidząca może pogubić się, próbując znaleźć pozycję B – w miejscu, gdzie spodziewała się jej zobaczyć, jest już coś innego. To zaburza nawyki nawigacyjne i obniża dostępność. WCAG uznaje takie przypadki za niewłaściwe[88][89].
– Przemieszczanie się stałych elementów: Jeśli np. panel logowania raz jest po prawej stronie, a na innej stronie został przeniesiony do lewego menu – użytkownik słabowidzący musi na nowo przeszukać interfejs, co zabiera czas i energię. Brak spójności utrudnia mu korzystanie z serwisu, bo nie może polegać na pamięci układu.
– Nieprzewidywalne zmiany kolejności po rozwinięciu menu: Czasem w wersji desktop menu jest poziome A | B | C, a w mobilnej (czy przy bardzo dużym powiększeniu) zmienia się w inny układ, np. C | A | B. To bywa pomyłką przy implementacji. Dla niedowidzącego (który może korzystać z responsywnego trybu) to dezorientujące – kolejność powinna być zachowana nawet po przekształceniu do menu hamburgerowego. Nieprzestrzeganie tego to typowy błąd spójności.
3.3.2 Etykiety lub instrukcje (A)
Cel i istota: Kryterium to wymaga, aby formularze i interaktywne pola miały jasno zidentyfikowane etykiety lub zawierały instrukcje dla użytkownika[91][92]. Z perspektywy osób niedowidzących oznacza to, że każde pole czy przycisk powinny być opisane w sposób czytelny wizualnie – tak, by nie trzeba było się domyślać ich funkcji. Jest to ważne, ponieważ przy dużym powiększeniu pola formularza mogą być widoczne oddzielnie od podpisów, jeśli te podpisy nie są poprawnie ulokowane (albo co gorsza brakuje ich i jest tylko placeholder). Osoba niedowidząca może np. zobaczyć pusty biały prostokąt i nie wiedzieć, co tam wpisać, dopóki nie przewinie do przodu, by znaleźć ewentualną wskazówkę. Wyraźne etykiety obok pól eliminują ten problem – użytkownik łatwo skojarzy, jakie dane ma wprowadzić, nawet jeśli widzi tylko fragment formularza na ekranie.
Poprawne zastosowanie (przykłady):
– Widoczne etykiety przy polach formularza: Każde pole tekstowe ma obok (lub nad) siebie krótki opis, np. „Imię:”, „Email:”. Tekst etykiety jest wystarczająco duży i kontrastowy, by osoba słabowidząca go odczytała. Dzięki temu nawet przy powiększeniu na tyle dużym, że na ekranie mieści się tylko pole i etykieta, użytkownik wie, czego to pole dotyczy[93][92]. Nie musi zgadywać, co wpisać.
– Instrukcje do złożonego inputu: Jeśli wymagany jest specyficzny format danych (np. „RRRR-MM-DD” przy dacie), obok pola podana jest krótka instrukcja. Jest ona zawsze widoczna – np. jako podpowiedź nad polem lub etykieta ze wskazówką. Osoba niedowidząca dostrzeże ją, bo jest w stałej pozycji. Nie polega się wyłącznie na placeholderze wewnątrz pola, który znika po fokuse – instrukcja jest dostępna na stałe, by użytkownik mógł w każdej chwili sprawdzić wymagany format.
– Etykiety powiązane z kontrolkami: Nawet elementy jak checkbox czy radio mają obok siebie czytelnie napisane opcje. Dzięki temu słabowidzący nie musi celować lupą w maleńki kwadracik, by wiedzieć co oznacza – może skierować wzrok na etykietę tekstową, a kliknięcie w nią zaznacza kontrolkę (co jest także ułatwieniem).
Typowe błędy:
– Pole bez etykiety (tylko placeholder): Częsty błąd designu – zamiast etykiety, w polu przed wpisaniem jest np. szary napis „Wpisz email”. Po kliknięciu napis znika. Użytkownik niedowidzący powiększa stronę, widzi może tylko część pola, wpisuje coś i… już nie wie, jakie było pytanie, bo placeholder zniknął, a brak prawdziwej etykiety. To dezorientujące – musi pomniejszać widok, szukać kontekstu. WCAG zaleca unikać takiej sytuacji, zapewniając zawsze osobną etykietę lub utrzymując widoczny opis[92][94].
– Etykieta oddalona od pola: Np. opis grupy pól umieszczony jako nagłówek formularza, daleko od właściwego pola, może nie być oczywisty przy dużym zoomie. Osoba słabowidząca widzi np. pole z napisem „cm” (jednostka), ale dopiero wyżej jest informacja, że chodzi o „Wzrost”. Jeśli odległość jest spora, użytkownik może nie powiązać etykiety z polem. Dlatego lepiej każdorazowo powtarzać etykietę przy polu albo zapewnić programatyczne powiązanie (atrybut label for), co też często skutkuje lepszym rozmieszczeniem wizualnym.
– Brak instrukcji dla nietypowych wymagań: Gdy pole ma wymagany format (np. hasło musi zawierać znak specjalny) ale nigdzie nie jest to napisane obok, użytkownik niedowidzący może kilkukrotnie wpisywać dane błędnie, zanim zauważy komunikat błędu. Lepsze są jasne instrukcje od razu widoczne. Ich brak utrudnia zrozumienie interakcji.
Solidność (Robustness)
Zasada Solidność oznacza, że treść powinna być dostarczona w sposób zgodny ze standardami i kompatybilny z różnymi narzędziami użytkowników – przeglądarkami, czytnikami ekranu, programami powiększającymi itp. Dla osób niedowidzących solidność oznacza, że strona będzie poprawnie działać z ich ewentualnymi technologiami wspomagającymi (jak czytnik ekranu używany dodatkowo, lupy ekranowe, tryby wysokiego kontrastu), a także że nie wystąpią błędy techniczne utrudniające wyświetlanie zawartości.
4.1.1 Poprawność kodu (A)
Cel i istota: Kryterium to wymaga, by kod strony był syntaktycznie poprawny (zgodny z formalnymi zasadami HTML/XML). Dzięki temu user agents i technologie asystujące mogą jednoznacznie interpretować zawartość. Dla osób niedowidzących ma to pośrednie znaczenie – poprawny kod to mniejsze ryzyko, że jakaś część strony nie wyświetli się lub zadziała nieprawidłowo w ich konfiguracji sprzętowo-programowej. Przykładowo, brak zamykającego znacznika </div> może skutkować rozlaniem się layoutu, co przy powiększeniu może kompletnie zaburzyć kolejność treści. Solidny kod gwarantuje, że strona zachowa przewidywalny układ nawet przy nietypowych ustawieniach. Ponadto, poprawność ułatwia działanie narzędzi takich jak czytniki – choć niedowidzący korzystają głównie ze wzroku, część z nich używa np. funkcji odczytu pojedynczych elementów (i tu poprawny kod zapewnia, że czytnik odnajdzie elementy we właściwej kolejności).
Poprawne zastosowanie (przykłady):
– Walidacja HTML/CSS: Strona została przetestowana walidatorami – nie zawiera błędów typu niezamknięte tagi, duplikaty id, itp. Dla użytkownika niedowidzącego oznacza to stabilniejszą prezentację: nic nie znika lub nie pojawia się w złym miejscu z powodu błędu w kodzie. Na przykład wszystkie nagłówki są poprawnie zagnieżdżone, więc strona w trybie stylów użytkownika (np. wysokokontrastowych) nadal zachowuje logiczny porządek.
– Unikanie eksperymentalnych, nieobsługiwanych znaczników: Autor korzysta z semantycznego, standardowego HTML. Dzięki temu np. tryb wysokiego kontrastu w Windows potrafi prawidłowo rozpoznać przyciski i pola i zmienić im kolory (bo są prawdziwymi elementami <button>, <input>). Gdyby użyto niestandardowych kontrolek bez poprawnej semantyki, system mógłby ich nie rozpoznać i np. nie zmienić koloru tekstu, czyniąc je niewidocznymi dla osoby słabowidzącej. Poprawny i semantyczny kod temu zapobiega.
Typowe błędy:
– Błędy HTML psujące układ: np. zapomniany </table> sprawia, że pozostała część strony renderuje się wewnątrz tabeli. Osoba niedowidząca, powiększając, widzi chaotyczny układ – kolumny rozjechane, tekst nie tam gdzie trzeba. To może uniemożliwić zrozumienie treści, choć przyczyną jest stricte błąd kodu.
– Niezamknięte tagi lub duplikaty wpływające na AT: Przykładowo dwa elementy z tym samym id mogą zmylić skrypty lub asystujące technologie. Czytnik ekranu używany okazjonalnie przez niedowidzącego (np. do odczytania obrazka) może pobrać niewłaściwy tekst, jeśli struktura DOM jest zaburzona. Błędy kodu obniżają niezawodność strony w nietypowych sytuacjach.
– Ogólna niestabilność przez błędy: Strona z wieloma błędami walidacji może działać w jednej przeglądarce, a w innej już nie. Osoba słabowidząca może używać np. starszej wersji przeglądarki (ze względu na kompatybilność z lupą ekranową) – tam błędy mogą się ujawnić. Solidny, zgodny kod minimalizuje te problemy.
4.1.2 Nazwa, rola, wartość (A)
Cel i istota: Kryterium 4.1.2 dotyczy poprawnego oznaczania komponentów interfejsu – każdy element interaktywny powinien mieć określoną programistycznie nazwę (label), rolę (typ elementu) i wartość (stan). Zapewnia to, że technologie asystujące mogą z nimi poprawnie działać[95][96]. Dla osób niedowidzących jest to ważne, gdy korzystają np. z czytników ekranu (niektórzy słabowidzący wspomagają się także głosowym odczytem fragmentów tekstu) lub z trybu wysokiego kontrastu systemu. Przykładowo, jeżeli przycisk nie jest prawdziwym <button> ani ma atrybutu roli, to w trybie wysokiego kontrastu może nie zmienić wyglądu (system go nie wykryje) – przez co może być niewidoczny dla użytkownika. Albo jeśli kontrolka nie ma etykiety (nazwa), czytnik ekranu nie odczyta jej opisu – co utrudnia niedowidzącym korzystającym z TTS (text-to-speech) części interfejsu. Spełnienie tego kryterium gwarantuje, że niestandardowe elementy są dostępne: np. własny kontroler suwaka ma odpowiednią rolę i wartości, więc asystent powiększenia/odczytu będzie wiedział, jak go obsłużyć.
Poprawne zastosowanie (przykłady):
– Wykorzystanie natywnych elementów HTML: Formularze używają <label> powiązanych z <input>, przyciski są <button>, itp. W efekcie przeglądarka i system automatycznie wiedzą, jaka jest rola tych elementów (pole tekstowe, przycisk) oraz jakie mają etykiety (tekst <label>). Osoba niedowidząca korzystająca z czytnika ekranu (np. NVDA, by odsłuchać zawartość) usłyszy poprawny komunikat: „Pole edycji: Imię”. Jeśli włączy tryb wysokiego kontrastu, system prawidłowo podkreśli fokus na przycisku, bo to prawdziwy przycisk.
– Aria-labelle i role dla niestandardowych widgetów: Gdy developer musiał użyć własnego elementu (np. <div> stylowanego na rozwijane menu), zadbał o dodanie atrybutów ARIA: role=”combobox”, aria-label=”Wybierz kraj”, oraz dynamiczne aktualizowanie aria-expanded itp. Dzięki temu czytnik lub inne narzędzie wie, że ten <div> to lista wyboru o nazwie „Wybierz kraj” i czy jest rozwinięta. Osoba słabowidząca może nie korzysta z pełnego czytnika, ale np. z funkcji odczytu fokusu – te informacje zostaną przekazane i ułatwią jej obsługę.
– Komunikaty o stanie poprzez role ARIA: Na stronie pojawiają się dynamicznie komunikaty (np. „dodano do koszyka”). Developer oznaczył je role=”status” lub użył ARIA live region. Jeśli użytkownik słabowidzący akurat używa narratora (np. głosowe potwierdzenie akcji), komunikat zostanie odczytany automatycznie[97][98]. To pomaga – nawet jeśli coś umknie wzrokowi, głos to zasygnalizuje.
Typowe błędy:
– Niestandardowy element bez roli: Np. klikany <span> udający checkbox nie ma roli checkbox ani aria-checked. Czytnik traktuje go jako zwykły tekst. W trybie wysokiego kontrastu system może go nie wyróżnić jako zaznaczalny element. Niedowidzący użytkownik może w ogóle nie zdawać sobie sprawy, że to interaktywny checkbox, a nie zwykła ikonka.
– Brak nazw dla przycisków ikonowych: Ikona kosza jako przycisk do usunięcia, zrealizowana np. jako <button><img src=”kosz.png”></button> bez atrybutu alt ani aria-label. Osoba słabowidząca korzystająca z narratora usłyszy „Przycisk nieoznaczony”, co nic jej nie mówi. Powinna być nazwa, np. aria-label=”Usuń”. Brak opisu sprawia, że funkcja jest nieczytelna, jeśli nie można polegać na samej ikonie (a przy słabym wzroku i powiększeniu może być trudno rozpoznawalna).
– Nieaktualizowanie stanu ARIA: Np. rozwijane menu ma aria-expanded=”false”, ale po rozwinięciu skrypt tego nie zmienia. Czytnik stale komunikuje „zwinięte”, co wprowadza w błąd. Użytkownik niedowidzący może być zdezorientowany sprzecznymi bodźcami (widzi listę opcji, ale asystent mówi „zwinięte”). To obniża zaufanie do interfejsu.
Podsumowanie: Stosowanie powyższych zasad WCAG znacząco ułatwia osobom niedowidzącym korzystanie z serwisów internetowych. Zapewnienie odpowiedniego kontrastu, elastyczności w skalowaniu i prezentacji treści, widocznych fokusów i spójnej nawigacji sprawia, że użytkownik z ograniczonym wzrokiem może skutecznie percepować i obsługiwać stronę. Z kolei solidna technicznie realizacja (poprawny kod i semantyka) gwarantuje współdziałanie z narzędziami powiększającymi i ewentualnymi czytnikami, z jakich taki użytkownik może korzystać. Dzięki wdrożeniu opisanych kryteriów sukcesu na poziomach A, AA, a nawet AAA, interfejs staje się bardziej przyjazny i dostępny – co przekłada się na samodzielność i komfort osób słabowidzących w świecie cyfrowym.
Źródła: Wszystkie informacje i przykłady oparto na wytycznych WCAG (w tym oficjalnym tłumaczeniu na język polski) oraz materiałach uzupełniających W3C, jak również na wynikach analiz dostępności dla użytkowników niewidomych i niedowidzących. Powyższe treści odwołują się do konkretnych fragmentów dokumentacji WCAG i związanych opracowań (oznaczonych w tekście), m.in. dotyczących uzasadnienia wymogów kontrastu[9], potrzeb osób niedowidzących w kontekście czasu[56] i nawigacji[85], a także przykładów dobrych i złych praktyk opisywanych przez ekspertów ds. dostępności, np. z Fundacji Widzialni[99]. Wszystko to ma na celu zilustrowanie praktycznego znaczenia poszczególnych kryteriów sukcesu WCAG dla poprawy dostępności stron dla osób niedowidzących.
[1] [2] [3] [4] Understanding Success Criterion 1.3.4: Orientation | WAI | W3C
https://www.w3.org/WAI/WCAG22/Understanding/orientation.html
[5] [6] [7] [8] Understanding Success Criterion 1.4.1: Use of Color | WAI | W3C
https://www.w3.org/WAI/WCAG21/Understanding/use-of-color.html
[9] [10] [13] [14] [22] Understanding Success Criterion 1.4.3: Contrast (Minimum) | WAI | W3C
https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html
[11] [12] [99] WCAG 2.0 – Niedowidzący
https://wcag20.widzialni.org/niedowidzacy,m,mg,152
[15] [16] [17] [18] [19] [20] [21] Understanding Success Criterion 1.4.4: Resize Text | WAI | W3C
https://www.w3.org/WAI/WCAG21/Understanding/resize-text.html
[23] [24] [25] [26] [27] [28] [29] Understanding Success Criterion 1.4.8: Visual Presentation | WAI | W3C
https://www.w3.org/WAI/WCAG21/Understanding/visual-presentation.html
[30] [31] [47] [48] [49] [50] Understanding Success Criterion 1.4.12: Text Spacing | WAI | W3C
https://www.w3.org/WAI/WCAG22/Understanding/text-spacing.html
[32] [33] [34] [35] [36] Understanding Success Criterion 1.4.10: Reflow | WAI | W3C
https://www.w3.org/WAI/WCAG21/Understanding/reflow.html
[37] [38] [39] [40] [41] [42] [43] [44] [45] [46] Understanding Success Criterion 1.4.11: Non-text Contrast | WAI | W3C
https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html
[51] UNF: ADA Web Accessibility
https://www.unf.edu/adacompliance/web/accessibility.html
[52] [53] [54] [55] [56] [57] [58] Understanding Success Criterion 2.2.1: Timing Adjustable | WAI | W3C
https://www.w3.org/WAI/WCAG21/Understanding/timing-adjustable.html
[59] [60] [61] [62] [65] 2.2.2 Pause, Stop, Hide – NYU Accessibility Testing Standards
https://digitalaccessibility.nyu.edu/testing/sc222.html
[63] 2.2.2 Pause, Stop, Hide (Level A) – WCAG
https://www.wcag.com/designers/2-2-2-pause-stop-hide/
[64] WCAG 2.2.2: Pause, stop, hide (Level A) – Silktide
https://silktide.com/accessibility-guide/the-wcag-standard/2-2/enough-time/2-2-2-pause-stop-hide/
[66] [67] Understanding Success Criterion 2.4.7: Focus Visible | WAI | W3C
https://www.w3.org/WAI/WCAG22/Understanding/focus-visible.html
[68] [69] [70] [71] [72] [73] [74] [75] [83] [84] A guide to designing accessible, WCAG-conformant focus indicators
https://www.sarasoueidan.com/blog/focus-indicators/
[76] [77] [78] [79] [80] [81] [82] Understanding Success Criterion 2.4.11: Focus Not Obscured (Minimum) | WAI | W3C
https://www.w3.org/WAI/WCAG22/Understanding/focus-not-obscured-minimum.html
[85] [86] [87] [88] [89] [90] Understanding Success Criterion 3.2.3: Consistent Navigation | WAI | W3C
https://www.w3.org/WAI/WCAG22/Understanding/consistent-navigation.html
[91] Labeling Controls | Web Accessibility Initiative (WAI) – W3C
https://www.w3.org/WAI/tutorials/forms/labels/
[92] [93] Labels or instructions are provided when content requires user input
[94] 2.4.6 Headings and Labels – AAArdvark
https://aaardvarkaccessibility.com/wcag-plain-english/2-4-6-headings-and-labels/
[95] [96] [97] [98] Standard WCAG, a przeciwdziałanie wykluczeniu w narzędziach BI | NDLS