Kryteria

Wszystkie elementy treści nietekstowej  (Obrazy (informacyjne, dekoracyjne, funkcjonalne, jako CAPTCHA), Grafiki, Wykresy, Przyciski graficzne (zamiast tekstu), Pliki audio/video (jeśli są jedyną treścią), Mapy) muszą mieć tekstowy odpowiednik (alternatywę) służący temu samemu celowi, chyba że treść nietekstowa jest czystą dekoracją, jest ukryta lub została wyłączona z wymogu.

Szczegóły i wyjątki:

• Cel funkcjonalny: Jeśli obrazek jest elementem sterującym (np. przycisk z ikoną lupy), jego odpowiednik tekstowy musi opisywać funkcję lub cel (np. „Szukaj”).
• Wprowadzanie danych: Jeśli treść nietekstowa to wejście do danych (np. obrazek CAPTCHA), musi być dostępna alternatywna forma dostępu do informacji (np. CAPTCHA dźwiękowe lub inne metody weryfikacji).
• Dekoracje/Ukryte: Jeśli obraz jest czysto dekoracyjny lub jest ukryty przed technologiami asystującymi (np. CSS background, aria-hidden="true"), nie wymaga odpowiednika tekstowego (pusty atrybut alt="" lub nie jest w ogóle używany w przypadku CSS).
• Media czasowe: Treść nietekstowa prezentująca media czasowe (wideo, audio) musi mieć poprawną alternatywę tekstową (opis) lub być odpowiednio oznaczona jako medium czasowe, a całe medium musi spełniać kryteria (np. napisy, audiodeskrypcja).
• Testy i sztuka: Wyjątek dotyczy sytuacji, gdy wygląd jest kluczowy dla zrozumienia (np. wyniki testu wzrokowego, fragment sztuki audiowizualnej), wówczas krótka alternatywa tekstowa musi identyfikować treść nietekstową, a pełny opis musi być podany w tekście.

Dla treści nagranej, która jest wyłącznie audio lub wyłącznie wideo, musi być dostępna alternatywa dla mediów czasowych, która przedstawia wszystkie informacje i zapewnia interakcję.

Szczegóły i wyjątki:

• Tylko audio (nagrane): Musi być dostępny tekstowy zapis (transkrypcja), który zawiera wszystkie dialogi i znaczące dźwięki (np. „szczekanie psa”, „dzwonek do drzwi”).
• Tylko wideo (nagrane): Musi być dostępna albo:
  • Ścieżka dźwiękowa (audiodeskrypcja) zawierająca wszystkie informacje wizualne lub…
  • Tekstowy zapis (transkrypcja) lub nagranie audio, które opisuje wszystkie kluczowe elementy wizualne.
• Wyjątek:
  • Media jako alternatywa: Kryterium nie obowiązuje, jeśli audio lub wideo jest alternatywą dla tekstu i jest to wyraźnie oznaczone (np. wideo na temat produktu w karcie produktu, gdzie informacje są już w pełni podane w tekście towarzyszącym).

Dla wszystkich nagranych wcześniej materiałów wideo, które zawierają ścieżkę dźwiękową, muszą być dostępne napisy rozszerzone. Kryterium to nie dotyczy samodzielnych plików audio (np. podcastów).

Szczegóły i wyjątki:

• Synchronizacja: Napisy muszą być zsynchronizowane z treścią wizualną i dźwiękową.
• Pełna treść: Napisy muszą zawierać nie tylko dialogi, ale również znaczące dźwięki (np. [Muzyka dramatyczna], [Dzwonek telefonu], [Śmiech]).
• Technologia: Napisy powinny być realizowane jako napisy zamknięte (umożliwiające włączanie/wyłączanie przez użytkownika) lub otwarte (trwale wtopione w obraz), przy czym preferowane są zamknięte.
• Wyjątek:
  • Media jako alternatywa: Kryterium nie obowiązuje, jeśli materiał wideo jest wyłącznie alternatywną formą prezentacji treści tekstowej znajdującej się już na stronie i został wyraźnie oznaczony (np. film, na którym lektor wyłącznie odczytuje opublikowany obok artykuł).

Dla wszystkich nagranych treści wideo ze ścieżką dźwiękową (audio), musi być dostępna albo audiodeskrypcja, albo alternatywa dla mediów czasowych (np. pełny tekstowy zapis), która przedstawia wszystkie informacje wizualne.

Szczegóły i wyjątki:

• Wideo z audio: Jeśli wideo zawiera ścieżkę dźwiękową, ale występują w nim wizualne informacje, które nie są przekazane na ścieżce dźwiękowej (np. demonstracje wizualne, tekst na ekranie), konieczne jest dodanie:
  • Audiodeskrypcji: Dodatkowa ścieżka audio opisująca te wizualne szczegóły.
  • Alternatywy dla mediów: Pełny tekstowy zapis zawierający wszystkie dialogi oraz wszystkie wizualne informacje wideo.
• Wideo bez audio: Jeśli wideo jest wyłącznie wizualne i nie ma ścieżki dźwiękowej (jak w 1.2.1), audiodeskrypcja jest obowiązkowa (lub alternatywa dla mediów).
• Wyjątek:
  • Media jako alternatywa: Kryterium nie obowiązuje, jeśli media czasowe są alternatywą dla treści tekstowej i są wyraźnie oznaczone (np. wideo będące wizualizacją już wyświetlonego tekstu).

Dla wszystkich mediów czasowych na żywo, które zawierają ścieżkę dźwiękową (audio), muszą być dostępne napisy (Captions) na żywo.

Szczegóły i wyjątki:

• Synchronizacja: Napisy muszą być dostarczone w czasie rzeczywistym i być zsynchronizowane z dźwiękiem, tak by były pomocne dla osób głuchych lub niedosłyszących.
• Pełna treść: Napisy muszą zawierać wszystkie dialogi i znaczące dźwięki (o ile jest to technicznie wykonalne na żywo).
• Wymogi technologiczne: Wymagane jest użycie technologii, która umożliwia szybkie i dokładne generowanie napisów na żywo.
• Wyjątek:
  • Media jako alternatywa: Kryterium nie obowiązuje, jeśli media czasowe na żywo są alternatywą dla treści tekstowej i są wyraźnie oznaczone.

Dla wszystkich nagranych treści wideo, które zawierają wizualne informacje nieprzekazane na ścieżce dźwiękowej, musi być dostępna audiodeskrypcja.

Szczegóły i wyjątki:

• Cel: Audiodeskrypcja (AD) musi opisywać istotne dla zrozumienia informacje wizualne (np. zmiany scenerii, gesty, tekst na ekranie), które nie są wystarczająco opisane przez główną ścieżkę audio.
• Synchronizacja: Audiodeskrypcja musi być zsynchronizowana z treścią wideo, tzn. wstawiona w naturalne pauzy dialogowe.
• Wymóg minimalny: To kryterium jest bardziej rygorystyczne niż 1.2.3, ponieważ wymaga dostarczenia audiodeskrypcji (a nie jedynie tekstowej alternatywy dla mediów).
• Wyjątki: Wymóg nie obowiązuje, jeśli:
  • Wszystkie istotne informacje wizualne są już w pełni zawarte w głównej ścieżce audio.
  • Media czasowe są alternatywą dla treści tekstowej i są wyraźnie oznaczone.

Informacje, struktura i relacje elementów, które są przekazywane wizualnie, muszą być również przekazane programowo (w kodzie) lub być dostępne w postaci tekstu.

Szczegóły i wyjątki:

• Struktura nagłówków: Hierarchia nagłówków (H1-H6) musi być logiczna i poprawnie oznaczona w kodzie (<h1>, <h2>, itd.).
• Listy: Listy (uporządkowane i nieuporządkowane) muszą być oznaczone odpowiednimi elementami HTML (<ul>, <ol>).
• Formularze: Etykiety muszą być programowo powiązane ze swoimi polami formularza (<label for="id_pola">).
• Tabelaryczne dane: Dane w tabelach muszą mieć programowo powiązane nagłówki kolumn i/lub wierszy (<th>, atrybuty scope, id/headers).
• Relacje: Powiązania logiczne między treścią (np. kroki w procesie, sekcje) muszą być zachowane w kodzie (np. za pomocą elementów semantycznych, atrybutów WAI-ARIA).
• Wyjątek:
  • Elementy prezentacyjne: Elementy, które są czysto prezentacyjne (np. wizualne obramowanie, cień), nie wymagają programowego określenia relacji.

Jeśli kolejność prezentacji treści wpływa na jej znaczenie, to kolejność ta musi być programowo określona (w kodzie) i logiczna. Treść musi być przedstawiona w takiej kolejności, aby użytkownicy technologii asystujących (np. czytników ekranu) i ci, którzy polegają na kolejności tabulacji (nawigacji klawiaturowej), zrozumieli jej sens.

Szczegóły i wyjątki:

• Kolejność czytania: Dotyczy to, na przykład, kolejności czytania tekstu w kolumnach, instrukcji „krok po kroku”, pól formularza (np. Imię, Nazwisko, Adres) oraz powiązanych etykiet i komunikatów.
• Kolejność tabulacji: Elementy interaktywne muszą być osiągane za pomocą klawiatury w logicznej i przewidywalnej kolejności.
• Wizualna a programowa: Kolejność odczytu przez czytnik ekranu musi odpowiadać kolejności wizualnej (zgodnej z zasadami języka — od lewej do prawej, od góry do dołu) lub logicznej (jeśli wizualna kolejność nie jest jedynym czynnikiem).
• Wyjątek: Kryterium nie określa wyjątków. Dotyczy to każdego przypadku, w którym zaburzona kolejność odczytu mogłaby zmienić lub unieważnić znaczenie treści.

Instrukcje, które są dostarczane użytkownikowi w celu zrozumienia i obsługi treści, nie mogą polegać wyłącznie na cechach sensorycznych komponentów, takich jak kształt, kolor, rozmiar, położenie wizualne, orientacja czy dźwięk.

Szczegóły i wyjątki:

• Unikaj wyłączności: Nie można polegać wyłącznie na:
  • Kształcie:
    • Błąd: „Kliknij ikonę, która wygląda jak trójkąt (znak odtwarzania)”.
    • Poprawne: Obok ikony musi znajdować się etykieta tekstowa („Odtwórz”) lub ikona musi mieć dostępną programowo nazwę (np. atrybut aria-label="Odtwórz").
  • Rozmiarze:
    • Błąd: „Wybierz większą ikonę”.
    • Poprawne: Wymagana jest alternatywa tekstowa lub inny wskaźnik (np. „Wybierz ikonę koszyka”, lub dodanie tekstu „Usuń” pod większą ikoną).
  • Wizualnej lokalizacji:
    • Błąd: „Zobacz politykę prywatności, klikając link w stopce po lewej stronie„.
    • Poprawne: Link musi mieć zrozumiały tekst („Polityka prywatności”), który identyfikuje cel, niezależnie od tego, gdzie jest umieszczony na ekranie.
  • Dźwięku:
    • Błąd: System informuje o nowej wiadomości tylko krótkim dźwiękiem „ding”.
    • Poprawne: Oprócz dźwięku, musi pojawić się wizualne powiadomienie (np. dymek, dzwonek z licznikiem, komunikat tekstowy), które użytkownik czytnika ekranu może odczytać.
• Alternatywy tekstowe: Informacje muszą być dostępne w sposób tekstowy lub programowo określony. Zamiast „Kliknij niebieski przycisk”, użyj „Kliknij przycisk 'Dalej'”.
• Wyjątek: Kryterium nie określa wyjątków. Dotyczy wszystkich instrukcji na stronie.

Treść i funkcjonalność strony internetowej nie mogą być ograniczone do wyświetlania w pojedynczej orientacji (pionowej lub poziomej), chyba że określona orientacja jest niezbędna.

Szczegóły i wyjątki:

• Kierunki orientacji: Strona musi działać i wyglądać poprawnie zarówno w orientacji pionowej (portrait), jak i poziomej (landscape).
• Brak zablokowania: Niedopuszczalne jest programowe blokowanie orientacji ekranu urządzenia (np. CSS orientation: landscape lub blokada w aplikacji mobilnej/widoku webowym).
• Utrzymanie funkcjonalności: Przy zmianie orientacji:
  • Cała treść musi być nadal widoczna bez konieczności przewijania w dwóch kierunkach (w miarę możliwości).
  • Wszystkie elementy interaktywne muszą pozostać dostępne i funkcjonalne.
• Wyjątek:
  • Niezbędna orientacja: Wymóg nie obowiązuje, jeśli określona orientacja jest niezbędna dla poprawnego działania lub zrozumienia treści.
    • Przykłady: Obsługa czeku bankowego, aplikacja fortepianowa (klawisze), slajdy do projektora/telewizora lub treści VR (gdzie orientacja może być dowolna, ale nie jest sztywno pozioma/pionowa).

Cel każdego pola formularza do zbierania informacji o użytkowniku musi być programowo określony (np. za pomocą atrybutu autocomplete), aby umożliwić przeglądarkom i technologiom asystującym automatyczne wypełnianie formularzy.

Szczegóły i wyjątki:

• Zakres: Kryterium dotyczy pól formularza, które zbierają dane o użytkowniku, np.: imię, nazwisko, adres, dane karty płatniczej, login, hasło, telefon, email.
• Implementacja techniczna: Pole powinno wykorzystywać atrybut autocomplete z odpowiednią wartością (np. name, email, tel, street-address).
• Wyjątki:
  • Brak zdefiniowanego celu: Wymóg nie obowiązuje, jeśli pole nie zbiera danych o użytkowniku lub jego przeznaczenie nie jest zdefiniowane na liście wartości autocomplete (np. specjalne ID transakcji, unikatowe kody promocyjne).
  • Bezpieczeństwo i poufność: Wymóg nie obowiązuje, jeśli programowe określenie celu zagroziłoby bezpieczeństwu lub naruszyłoby poufność informacji (np. tajne kody jednorazowe, hasła tymczasowe).

Kolor nie może być używany jako jedyny wizualny środek przekazywania informacji, wskazywania działania, zachęcania do reakcji ani wyróżniania elementu.

Szczegóły i wyjątki:

• Podwójne kodowanie: Informacje przekazywane kolorem muszą być zawsze zdublowane w inny sposób – tekstowo, symbolicznie (ikoną, wzorem, kształtem) lub programowo.
  • Błąd: Wymagane pola w formularzu są oznaczone tylko kolorem czerwonym.
  • Poprawnie: Wymagane pola są oznaczone kolorem czerwonym i gwiazdką (*) i mają etykietę tekstową „(wymagane)”.
• Wizualna zmiana stanu: Zmiana stanu interaktywnego elementu (np. po najechaniu myszą – hover, lub po otrzymaniu focusu klawiatury – fokus) nie może polegać wyłącznie na zmianie koloru. Musi wystąpić również inny wskaźnik (np. podkreślenie, pogrubienie, zmiana kształtu, zmiana obramowania).
  • Błąd: Link w tekście jest wyróżniony wyłącznie czerwonym kolorem. Po najechaniu myszką, kolor się nie zmienia i nie ma dodatkowego innego wskaźniku.
  • Poprawnie: Link w tekście jest wyróżniony podkreśleniem. Po najechaniu myszką, do link traci podkreślenie i zmienia swój kolor na niebieski. (Brak podkreślenia – dodatkowy wskaźnik wizualny, zmiana koloru – wzmocnienie).
• Kolor jako wzmacnianie (kontekst): Kolor jest dozwolony i jest bardzo pomocny, o ile jest używany jako wzmocnienie i uzupełnienie, a nie jako jedyny sposób przekazania informacji.
• Wyjątek:
  • Wizualizacje: Kryterium nie obowiązuje, jeśli użycie koloru jest niezbędne do zrozumienia informacji.
    • Przykład: Obraz termiczny, mapa cieplna (heatmap) lub wykresy, gdzie różnice w kolorze bezpośrednio reprezentują mierzone wartości (np. temperaturę, natężenie ruchu) i nie da się ich logicznie zastąpić tekstem. W takim przypadku wymagana jest legenda lub etykiety jednoznacznie opisujące znaczenie poszczególnych kolorów.

Jeśli dowolny zasób dźwiękowy (audio) na stronie odtwarza się automatycznie przez dłużej niż 3 sekundy, musi być dostępny mechanizm umożliwiający zatrzymanie (stop) lub wyciszenie (mute) tego dźwięku.

Szczegóły i wyjątki:

• Trzy opcje spełnienia: Wystarczy, że strona zapewnia jedno z trzech rozwiązań:
  1. Stop/Pause: Mechanizm do całkowitego zatrzymania lub wstrzymania audio.
  2. Wyciszenie: Mechanizm do całkowitego wyciszenia audio.
  3. Kontrola głośności: Mechanizm do regulacji głośności audio niezależnie od głównej głośności systemu operacyjnego.
• Kontrola: Mechanizm kontroli musi być dostępny natychmiast i znajdować się na początku strony internetowej lub w miejscu widocznym bez przewijania.
• Zakres: Kryterium dotyczy całej zawartości strony, ponieważ niekontrolowany dźwięk może zakłócać działanie technologii asystujących i uniemożliwiać korzystanie z całej strony (jest to wymóg „niezakłócania”).
• Wyjątki: Kryterium nie określa wyjątków. Obowiązuje dla wszystkich automatycznie odtwarzanych dźwięków przekraczających próg 3 sekund.

Wizualna prezentacja tekstu i obrazów zawierających tekst musi posiadać odpowiedni współczynnik kontrastu względem tła, aby zapewnić czytelność dla wszystkich użytkowników.

Szczegóły i wyjątki:

• Wymagany kontrast: Tekst podstawowy (mniejszy niż 18pt [24px] lub 14pt [18.5px] pogrubiony/bold) musi mieć stosunek kontrastu co najmniej 4.5:1.
• Duży tekst: Tekst w dużym rozmiarze (równy lub większy niż 18pt [24px] lub 14pt [18.5px] pogrubiony/bold) wymagają kontrastu co najmniej 3:1.
• Tekst będący częścią obrazu: Tekst, który jest integralną częścią obrazu (np. etykiety na zdjęciu produktu), musi spełniać wymóg 4.5:1 lub 3:1, chyba że jest to obraz na żywo (np. z kamery internetowej).
• Wyjątki: Wymóg kontrastu nie dotyczy:
  • tekstu w nieaktywnych komponentach interfejsu (disabled),
  • tekstu czysto dekoracyjnego,
  • tekstu który nie jest widoczny (np. display: none),
  • tekstu będącego częścią większego obrazu o istotnej treści wizualnej,
  • tekstu będącego częścią logo lub nazwy marki.

Tekst (z wyjątkiem napisów rozszerzonych i obrazów tekstu) może zostać powiększony do 200% bez użycia technologii asystujących, przy zachowaniu pełnej funkcjonalności i treści.

Szczegóły i wyjątki:

• Metoda powiększania: Sprawdzenie odbywa się poprzez funkcję zmiany rozmiaru czcionki w ustawieniach przeglądarki, a nie poprzez skalowanie całej strony (zoom całego widoku).
• Brak utraty treści i funkcjonalności: Po powiększeniu do 200%:
  • Żaden tekst nie może zostać ucięty (clipping) ani nakładać się na inne elementy (overlapping).
  • Wszystkie przyciski, linki i pola formularzy muszą nadal działać poprawnie.
  • Układ strony może ulec zmianie (np. reflow), ale informacja musi być dostępna.
• Wyjątek:
  • Obrazy tekstu: Tekst będący integralną częścią obrazu (np. logotyp, wykresy z tekstem) jest zwolniony z tego wymogu. Tekst ten musi spełniać kryterium 1.1.1 (alternatywa tekstowa).

Jeśli dostępne technologie mogą osiągnąć pożądaną prezentację wizualną, do przekazywania informacji należy używać tekstu zamiast obrazów zawierających tekst.

Szczegóły i wyjątki:

• Priorytet: Zawsze należy używać tekstu zakodowanego w HTML/CSS, aby zapewnić skalowalność, elastyczność i możliwość dostosowania przez użytkownika.
• Obrazy tekstu: Kryterium wymaga minimalizowania użycia obrazów zawierających tekst (np. tekstu zapisanego w pliku .jpg lub .png).
• Wyjątki: Użycie obrazów tekstu jest dopuszczalne tylko w dwóch sytuacjach:
  1. Możliwość dostosowania: Obraz tekstu może zostać wizualnie dostosowany do wymagań użytkownika (np. poprzez CSS, które nadpisuje obraz, lub jeśli jest skalowalny bez utraty jakości).
  2. Kluczowe znaczenie: Określona prezentacja tekstu jest niezbędna dla przekazywanej informacji (np. jest to zdjęcie dyplomu, mapa, której etykiet nie można zmienić, logotypy i nazwy marek, dane w diagramach lub wykresach,).

Treść musi być prezentowana bez utraty informacji lub funkcjonalności i bez konieczności przewijania w dwóch wymiarach (poziomo i pionowo jednocześnie) po powiększeniu.

Szczegóły i wyjątki:

• Wymóg pionowy (dla treści przewijanych w pionie): Treść musi się „przelewać” przy szerokości odpowiadającej 320 pikselom CSS.
  • Weryfikacja: 320px CSS jest równoważne powiększeniu 400% dla standardowej szerokości 1280px CSS.
• Wymóg poziomy (dla treści przewijanych w poziomie): Treść musi się „przelewać” przy wysokości odpowiadającej 256 pikselom CSS.
• Zakres: Użytkownik, który powiększy stronę nie może być zmuszony do przewijania w lewo lub w prawo, aby odczytać linię tekstu lub uzyskać dostęp do komponentów. Przewijanie w pionie (góra/dół) jest dozwolone.
• Zachowanie układu: Układ strony musi się dynamicznie dostosować (np. kolumny przechodzą w układ pionowy, elementy stają się pełnowymiarowe), ale kolejność czytania musi być zachowana (patrz 1.3.2).
• Wyjątki (wymagany układ dwuwymiarowy):
  • Niezbędne funkcje: Wymóg nie obowiązuje, jeśli poziome przewijanie jest niezbędne dla dwuwymiarowego układu używanego do zrozumienia lub funkcji (Tabele danych, mapy, wykresy, diagramy z dużą ilością szczegółów lub interfejsy do edycji (np. panele do edycji wideo, edytory kodu), gdzie zmiana układu naruszyłaby funkcjonalność.)
  • Wymiary obiektu: Wymóg nie obowiązuje dla treści, której układ jest określony przez sam obiekt (np. duże obrazy rastrowe, wideo, prezentacje slajdów, komponenty, których nie można zmodyfikować, np. widgety bankowe).

Wizualna prezentacja kluczowych elementów interfejsu użytkownika i graficznych obiektów musi mieć stosunek kontrastu wynoszący co najmniej 3:1 względem sąsiadujących kolorów.

Szczegóły i wyjątki:

• Komponenty interfejsu: Wymóg 3:1 dotyczy wizualnej granicy komponentu (np. cienka ramka wokół pola tekstowego), która wskazuje jego obszar klikalny/interaktywny, a także wskaźników stanu (np. focus, selection, checked).
  • Przykład: Ramka pola formularza musi kontrastować z tłem w stosunku 3:1. Wskaźnik focusu (np. zewnętrzna niebieska obwódka) musi kontrastować z sąsiadującym kolorem (np. tłem lub granicą pola) w stosunku 3:1.
• Elementy graficzne (Graphics): Obejmuje to grafiki, które są kluczowe do zrozumienia informacji (np. ikony na wykresach, strzałki wskazujące kierunek).
  • Przykład: Linia na wykresie słupkowym lub krawędzie wycinka na wykresie kołowym muszą kontrastować z tłem wykresu w stosunku 3:1.
• Wyjątki:
  • Brak wizualnej granicy: Wymóg nie obowiązuje, jeśli komponent interfejsu jest wizualnie zdefiniowany wyłącznie przez treść (np. link w tekście, którego granica nie jest widoczna, dopóki nie zostanie aktywowany stan hover/focus).
  • Wymagania przeglądarki/UA: Wymóg nie obowiązuje dla wizualnych aspektów komponentów, których wygląd jest całkowicie określany przez przeglądarkę (User Agent) i których nie można dostosować za pomocą stylów autora (np. domyślny wygląd pól wyboru bez jakiegokolwiek niestandardowego CSS).
  • Niezbędne (Essential): Wymóg nie obowiązuje, jeśli konkretny kontrast jest niezbędny do przekazania informacji (np. obraz termiczny, gdzie brak kontrastu jest celowy).
  • Logotypy/Obrazy osób: Wymóg nie obowiązuje dla logotypów lub grafik, w których kontrast jest ustalony ze względu na wygląd rzeczywistych osób lub innych materiałów fotograficznych.

W treści zaimplementowanej przy użyciu języków znaczników (np. HTML/CSS) nie może dojść do utraty treści ani funkcjonalności po nadpisaniu standardowych właściwości odstępów w tekście za pomocą arkuszy stylów, bez konieczności przewijania w poziomie (patrz 1.4.10).

Szczegóły i wyjątki:

• Nadpisywane właściwości (CSS): strona musi zachować pełną funkcjonalność i zawartość, gdy style CSS zostaną nadpisane na:
  • Wysokość linii (line height/leading): co najmniej 1.5 razy rozmiar czcionki.
  • Odstęp po akapitach: co najmniej 2 razy rozmiar czcionki.
  • Odstępy między literami (letter spacing/tracking): co najmniej 0.12 razy rozmiar czcionki.
  • Odstępy między słowami (word spacing): co najmniej 0.16 razy rozmiar czcionki.
• Wyjątki:
  • Język i skrypt: wymóg nie obowiązuje, jeśli zmiana odstępów uniemożliwiłaby funkcjonowanie (np. tekst w tekście ASCII-Art, notacji muzycznej, notacji matematycznej, czy w polach gdzie długość jest limitowana, np. kod weryfikacyjny).
  • Media czasowe: wymóg nie obowiązuje dla napisów rozszerzonych i napisów (captions), które mają stałe odstępy.

W przypadku, gdy wskazanie myszą (hover) lub ustawienie fokusu klawiatury (focus) wyzwala wyświetlenie, a następnie ukrycie dodatkowej treści (np. podpowiedzi, tooltipy, wyskakujące menu), muszą być spełnione trzy następujące warunki:

• Możliwość zamykania – usuwalna/zbywalna (dismissable): Musi istnieć mechanizm, aby ją zamknąć bez konieczności przenoszenia fokusu klawiatury lub wskaźnika myszy (np. klawisz Esc).
• Możliwość wskazania – utrzymywalna (hoverable): Jeśli wskaźnik myszy wyzwala dodatkową treść, musi być możliwe przesunięcie kursora nad tę dodatkową treść bez jej zniknięcia.
• Możliwość zachowania – trwała (persistent): Treść musi pozostawać widoczna, dopóki nie zostanie zamknięta przez użytkownika lub dopóki fokus klawiatury/wskaźnik myszy nie zostanie przeniesiony poza nią i poza element wyzwalający.

Wyjątki:

• Wymagane przez User Agent: Kryterium nie obowiązuje dla treści, których wygląd i działanie są kontrolowane przez przeglądarkę i nie są modyfikowane przez autora (np. domyślny tooltip przeglądarki dla atrybutu title).
• Błędy wprowadzania danych: Komunikaty o błędach w formularzu (np. „Wprowadź poprawny email”) są zwolnione, ponieważ ich pojawienie się jest reakcją na wprowadzenie błędu.
• Nie wymaga interakcji: Wymóg nie obowiązuje, jeśli treść (np. wyskakujące menu) jest używana do wyświetlania dodatkowej informacji, a wszystkie funkcje są dostępne w inny sposób bez konieczności aktywowania elementu.

Cała funkcjonalność treści musi być obsługiwana za pomocą wyłącznie interfejsu klawiatury, a sposób obsługi nie może wymagać precyzyjnego czasu wciśnięcia klawiszy.

Szczegóły i wyjątki:

• Pełna obsługa klawiaturą: Użytkownik musi mieć możliwość uzyskania dostępu do każdego elementu interaktywnego (link, przycisk, pole formularza, widżet) i aktywowania go za pomocą klawiatury (klawiszy takich jak Tab, Enter, Spacja, klawisze strzałek).
• Brak czasu: Obsługa funkcji nie może wymagać, aby użytkownik naciskał klawisze w określonym tempie lub czasie.
• Wyjątki:
  • Zależność od Ścieżki Ruchu: Obsługa klawiaturą nie jest wymagana tam, gdzie podstawowa funkcja wymaga danych wejściowych, które są zależne od ścieżki ruchu użytkownika i nie da się logicznie obsłużyć klawiszami. (np. Rysowanie odręczne, podpisywanie dokumentu, operacje precyzyjnego przeciągania elementów)
  • Wymóg Czasu: Wymóg, że obsługa nie może wymagać precyzyjnego czasu wciśnięcia klawiszy, ma zastosowanie, chyba że funkcja jest z natury czasowa (np. granie na wirtualnym instrumencie muzycznym, symulator).

Jeśli fokus klawiatury można przenieść do elementu na stronie za pomocą klawiatury, to fokus ten musi być również możliwy do opuszczenia za pomocą standardowych metod klawiaturowych (np. klawisz Tab), bez konieczności odświeżania strony.

Szczegóły i wyjątki:

• Typowe pułapki:
  • Użytkownik wejdzie do elementu (np. iframe, odtwarzacza wideo, widżetu autocomplete) i nie może przenieść fokusu klawiatury poza niego, używając klawisza Tab lub Shift+Tab.
  • Pojawia się okno modalne, które nie pozwala na zamknięcie za pomocą klawisza Esc lub naciśnięcia widocznego przycisku zamykającego.
• Wymóg wyjścia: Musi być zapewniona prosta metoda wyjścia (np. klawisz Tab lub Esc).
• Instrukcja dla użytkownika: Jeśli opuszczenie komponentu wymaga użycia klawiszy innych niż standardowe (np. kombinacja Shift + F6), użytkownik musi zostać poinformowany o tej metodzie.
• Wyjątki: Kryterium nie określa wyjątków. Obowiązuje dla wszystkich interaktywnych elementów na stronie.

Jeśli na stronie używane są jednoklawiszowe skróty klawiszowe używające wyłącznie klawiszy będących znakami (litery, cyfry, interpunkcja lub symbole), muszą one spełniać jeden z następujących warunków:

1. Wyłączalność (turn off): Musi istnieć mechanizm, aby wyłączyć ten skrót.
2. Modyfikowalność (remap): Musi istnieć mechanizm, aby zmienić skrót na co najmniej dwuklawiszowy (np. Ctrl + X, Alt + Y ).
3. Aktywność fokusu (active only on focus): Skrót jest aktywny tylko wtedy, gdy komponent, do którego jest przypisany, otrzymuje focus klawiatury.

Szczegóły i wyjątki:

• Preferowane rozwiązanie: Najlepszym rozwiązaniem jest stosowanie skrótów tylko wtedy, gdy mają focus (punkt 3) lub używanie wieloklawiszowych skrótów (np. Alt + P).
• Wyjątki: Kryterium nie określa wyjątków dla funkcji, ale zapewnia trzy równoważne metody spełnienia wymogu.

Jeśli na stronie internetowej występuje limit czasowy na wykonanie jakiegoś zadania (np. czas trwania sesji, czas na wypełnienie formularza), musi być spełniony co najmniej jeden z poniższych warunków:

• Wyłączenie (turn off): Musi istnieć mechanizm, aby wyłączyć limit czasowy przed jego osiągnięciem.
• Dostosowanie (adjust): Musi istnieć mechanizm, aby dostosować limit czasowy (co najmniej 10-krotnie więcej niż standardowy czas).
• Wydłużenie (extend): Użytkownik musi zostać ostrzeżony o zbliżającym się końcu i mieć możliwość łatwego przedłużenia limitu czasowego o co najmniej 20 sekund.

Szczegóły i wyjątki:

• Cel kryterium: Zapewnienie użytkownikom z niepełnosprawnościami poznawczymi, powolnym pisaniem lub tym, którzy używają technologii asystujących, wystarczającej ilości czasu na interakcję i ukończenie zadania.
• Wyjątki (Gdy limitu nie trzeba zmieniać): Limit czasowy jest dopuszczalny bez możliwości zmiany, gdy:
  • Czas rzeczywisty: Limit czasowy jest wymaganą częścią zdarzenia w czasie rzeczywistym (np. licytacja na aukcji) i nie ma dla niego alternatywy.
  • Kluczowe znaczenie: Limit jest niezbędny, a jego wydłużenie unieważniłoby działanie (np. test bezpieczeństwa lub limit czasowy na wpisanie hasła).
  • Długi limit: Limit czasowy jest dłuższy niż 20 godzin.

W przypadku ruchomej, migającej, przewijanej lub automatycznie aktualizowanej treści, która:

• startuje automatycznie i trwa dłużej niż 5 sekund lub
• jest prezentowana równolegle z inną treścią lub
• wydaje się być częścią reszty treści (tj. nie jest przekazywana do technologii asystujących jako oddzielny komponent)

musi być dostępny mechanizm, który umożliwia użytkownikowi zatrzymanie, wstrzymanie (pauzowanie) lub ukrycie tej treści.

Szczegóły i wyjątki:

• Ruchoma/przewijana treść (np. karuzele, paski przewijania wiadomości): Jeśli treści elementy sekcji automatycznie się poruszają i trwają dłużej niż 5 sekund, użytkownik musi mieć możliwość ich zatrzymania lub wstrzymania (pause/stop).
• Migająca/mrugająca treść: Jeśli treść miga lub mruga w tle, użytkownik musi mieć możliwość jej ukrycia (hide).
• Automatyczne aktualizacje (np. czaty na żywo, kursy walut): Jeśli treść zmienia się automatycznie, użytkownik musi mieć możliwość jej zatrzymania lub dostosowania częstotliwości aktualizacji, chyba że jest to istotne dla aktywności i występuje co 3 sekundy lub rzadziej.
• Wyjątki:
  • Niezbędna animacja/ruch: Wymóg nie obowiązuje, jeśli ruch lub automatyczna aktualizacja jest niezbędna do przekazania informacji lub jest integralną częścią zadania, a jej zatrzymanie zniekształciłoby jej sens. [np. Animacje ładowania/loader, elementy wyświetlające ruch biologiczny/fizyczny (np. animacja burzy na mapie pogody)].
  • Media czasowe: Wymóg nie obowiązuje dla mediów czasowych (wideo, audio), które mają własne elementy sterujące (patrz grupa kryteriów WCAG 1.2).

Treść nie może zawierać elementów, które migają lub błyskają więcej niż trzy razy w ciągu dowolnej sekundy, lub muszą utrzymywać błysk poniżej ogólnych progów dla błysków.

Szczegóły i wyjątki:

• Limit Błysków: Cała treść nie może zawierać elementów błyskających z częstotliwością większą niż 3 błyski na sekundę (3 Hz).
• Ogólny próg migotania (General Flash Threshold): Zgodnie z wytycznymi, migotanie jest bezpieczne, jeśli:
  • Miga tylko mały obszar na ekranie (o wielkości mniejszej niż 10 stopni pola widzenia);
  • Jasność migających elementów nie jest zbyt wysoka.
• Próg Czerwonego Migotania (Red Flash Threshold): Migotanie zawierające znaczną część intensywnej czerwieni jest szczególnie niebezpieczne i musi spełniać jeszcze bardziej rygorystyczne kryteria jasności i rozmiaru.
• Wideo i Animacje: Wideo i animacje, które mogą zawierać sekwencje błysków, muszą zostać przetestowane. Jeśli testy wykażą niebezpieczne sekwencje, muszą zostać usunięte lub poddane obróbce.
• Wyjątki: Kryterium nie określa wyjątków. Obowiązuje dla wszystkich migających lub błyskających treści.

Musi być dostępny mechanizm umożliwiający ominięcie bloków treści powtarzających się na wielu stronach internetowych. Szczegóły i wyjątki:

• Mechanizm skip link: Najczęściej jest to ukryty link, który staje się widoczny po otrzymaniu fokusu (czyli po pierwszym naciśnięciu klawisza Tab po załadowaniu strony). Link ten musi przenosić fokus bezpośrednio do zadeklarowanego bloku treści (np. „Przejdź do treści głównej” to link elementu z główną treścią).
• Elementy semantyczne: Użycie semantycznych elementów HTML5 (np. <header>, <nav>, <main>, <footer>, <aside>) oraz ról WAI-ARIA (np. role="main", role="navigation") jest akceptowalne, ponieważ technologie asystujące często używają ich do nawigacji po sekcjach.
• Bloki treści: Elementy, które powtarzają się na wielu stronach i stanowią bloki treści to m.in.:
  • Globalna i lokalna nawigacja.
  • Logo i baner nagłówkowy.
  • Stopka strony.
  • Powtarzające się panele boczne lub reklamy.
• Wyjątki: Kryterium nie określa wyjątków. Obowiązuje dla wszystkich powtarzalnych bloków treści.

Wszystkie strony internetowe muszą posiadać tytuły, które w sposób opisowy przekazują temat lub cel danej strony.

Szczegóły i wyjątki:

• Wymóg techniczny: Tytuł musi być zawarty w elemencie <title> w sekcji <head> dokumentu HTML.
• Unikalność i Opisowość:
  • Tytuł musi być unikalny w obrębie serwisu dla każdej różniącej się treści.
  • Tytuł musi krótko i konkretnie opisywać cel lub treść strony (np. „Konto – Zmiana hasła | Nazwa Serwisu”, a nie tylko „Strona”).
• Wyjątek: Wymóg nie obowiązuje w rzadkich przypadkach, gdy strona jest tylko częścią większego procesu i nie jest widoczna w pasku tytułu przeglądarki (np. dynamicznie ładowane fragmenty treści za pomocą AJAX, które nie aktualizują <title>). W takich przypadkach stosuje się mechanizmy ARIA.

Jeśli nawigowanie po treści za pomocą klawiatury wpływa na jej znaczenie lub obsługę, to elementy otrzymujące fokus muszą być w porządku, który zachowuje znaczenie i funkcjonalność.

Szczegóły i wyjątki:

• Zgodność z wizualnym porządkiem oraz kodem: Kolejność fokusu powinna być spójna z kolejnością logiczną w kodzie źródłowym (DOM order) oraz z kolejnością wizualną, aby uniknąć dezorientacji.
• Elementy, których dotyczy: Wszystkie elementy interaktywne, które mogą otrzymać focus (np. linki, przyciski, pola formularzy, kontrolki widżetów).
• Elementy programowo ukryte: Elementy, które są wizualnie niewidoczne i ukryte programowo (np. display: none lub visibility: hidden), nie mogą otrzymywać fokusu.
• Wyjątek: Kryterium nie ma zastosowania do elementów, które nie wpływają na znaczenie lub obsługę (np. elementy czysto dekoracyjne, do których fokus klawiatury nie powinien docierać).

Cel każdego łącza musi być zrozumiały z samej treści łącza lub z treści łącza powiązanej z jego kontekstem (np. zdaniem, w którym się znajduje).

Szczegóły i wyjątki:

• Autonomiczność tekstu: Tekst linku (np. Więcej informacji o produkcie X) musi być na tyle opisowy, by użytkownik wiedział, dokąd zostanie przekierowany.
• Samopisujące się linki (Preferowane): Najlepiej, aby sam tekst linku był opisowy.
  • Poprawnie: Więcej o [naszej polityce prywatności]
  • Błąd: Więcej [kliknij tutaj]
• Link w kontekście: Jeśli tekst linku jest ogólny (np. „więcej”), kontekst otaczającego zdania musi wyjaśniać jego cel, np. Wszystkie szczegóły znajdziesz [tutaj].
• Elementy nie-linkowe: Jeśli element jest wizualnie linkiem (np. ikona strzałki „Dalej”), jego tekstowy odpowiednik (np. atrybut aria-label="Następna strona") musi opisywać jego cel.
• Wyjątki:
  • Mechanizm ogólny: Wymóg nie dotyczy linków, których cel jest ogólny dla całego serwisu i powszechnie rozpoznawalny. (np. Linki Strona główna, Kontakt, Mapa serwisu, Szukaj)
  • Linki, których cel jest nieznany: Wymóg nie dotyczy linków, których przeznaczenie jest celowo ukryte przed użytkownikiem (np. test pamięci, gdzie kliknięcie ujawnia ukryty tekst).
  • Linki dla czytników: Elementy, które są wyłącznie dekoracyjne lub są ukryte przed czytnikiem ekranu (aria-hidden="true", alt=""), nie są wliczane do tego kryterium.

Musi być dostępny więcej niż jeden sposób na zlokalizowanie danej strony internetowej w ramach zestawu stron (całej witryny), chyba że dana strona jest wynikiem lub jednym krokiem w procesie (sekcji).

Szczegóły i wyjątki:

• Wymagane sposoby: Witryna musi oferować co najmniej dwie z poniższych metod:
  • Linki nawigacyjne/Globalna nawigacja (Menu): Globalne paski menu, listy linków.
  • Mapa strony (Site Map): Strona zawierająca hierarchiczną listę wszystkich stron.
  • Wyszukiwanie (Search function): Funkcja wyszukiwania na stronie, umożliwiająca znalezienie treści po słowach kluczowych.
  • Spis treści: Hierarchiczna nawigacja po strukturze serwisu.
• Wyjątek:
  • Wynik Procesu/Krok: Wymóg nie obowiązuje dla stron, które stanowią etap w procesie sekwencyjnym (np. kroki koszyka zakupowego, rejestracja użytkownika) lub są wynikiem wykonanej akcji (np. strona z wynikami wyszukiwania, strona potwierdzenia transakcji).

Nagłówki (headings) oraz etykiety (labels) muszą w sposób opisowy przekazywać temat lub cel sekcji, której dotyczą, lub pola, które opisują.

Szczegóły i wyjątki:

• Nagłówki (headings):
  • Muszą być opisowe: Treść nagłówka musi informować o tym, co zawiera sekcja pod nim.
    • Błąd: Nagłówek o treści Sekcja 3.
    • Poprawnie: Nagłówek o treści Szczegóły wysyłki i dostawy.
  • Muszą być poprawnie oznaczone programowo: Należy używać elementów <h1> do <h6> w odpowiedniej kolejności (patrz 1.3.1).
• Etykiety (labels):
  • Muszą być opisowe: Etykieta musi jasno identyfikować cel pola formularza, do którego jest przypisana.
    • Błąd: Pole z etykietą Wprowadź dane.
    • Poprawnie: Pole z etykietą Adres e-mail.
  • Muszą być programowo powiązane: Wizualna etykieta musi być programowo powiązana z polem formularza, do którego się odnosi (najczęściej za pomocą znacznika <label> i atrybutu for="ID_pola").
• Wyjątki: Kryterium nie określa wyjątków. Obowiązuje dla wszystkich nagłówków i etykiet.

Każdy element interfejsu użytkownika, który może otrzymać fokus klawiatury (np. po naciśnięciu klawisza Tab), musi mieć wizualny wskaźnik fokusu (np. ramka, obwódka, zmiana koloru tła), który jest widoczny, wyraźny i zrozumiały.

Szczegóły i wyjątki:

• Konkretny fokus: Jeśli standardowa ramka przeglądarki (domyślny wskaźnik) zostanie usunięta za pomocą CSS (outline: none), autor strony musi dostarczyć własny, odpowiednio widoczny i kontrastowy wskaźnik.
• Wymagania kontrastu/rozmiaru: Chociaż to kryterium nie ma sztywno zdefiniowanego minimalnego kontrastu/rozmiaru, nowsze standardy i dobre praktyki sugerują, że wskaźnik fokusu musi być:
  • Wystarczająco duży: Powinien być na tyle duży, aby był łatwo zauważalny.
  • Wystarczająco kontrastowy: Musi kontrastować z tłem elementu w stosunku co najmniej 3:1 (patrz 1.4.11 Kontrast elementów nietekstowych).
• Wyjątki: Kryterium nie określa wyjątków.

Gdy element interfejsu otrzyma fokus klawiatury, musi być on całkowicie widoczny (żadna jego część nie może być ukryta) przez inną treść na stronie.

Szczegóły i wyjątki:

• Wymóg minimalny: Fokusowany element musi być co najmniej częściowo widoczny po otrzymaniu fokusu.
• Problem zasłaniania (Obscuring): Naruszenie występuje, gdy:
  • Przyklejony nagłówek/stopka (position: fixed lub sticky): Zasłania element, który otrzymał fokus.
  • Wyskakujące menu/widżety: Dynamicznie pojawiający się element (np. okno czatu, baner cookie) przesuwa się na pozycję, gdzie aktualnie znajduje się fokus.
• Wyjątki:
  • Interfejsy konfigurowalne: Jeśli użytkownik może sam zmieniać położenie elementów (np. w interfejsie typu drag-and-drop), testowanie i zgodność dotyczą tylko początkowego położenia tych ruchomych elementów.
  • Treść otwarta przez użytkownika: Treść, którą sam użytkownik otworzył, a która zasłania fokus (np. duże menu kontekstowe), jest dopuszczalna, pod warunkiem że użytkownik może odkryć fokusowany komponent bez zmieniania fokusu (np. za pomocą przycisku esc).

Cała funkcjonalność, która może być obsługiwana za pomocą skomplikowanych gestów wskaźnika (np. dwupalcowy ścisk, ścieżki przeciągania, pociągnięcia), musi być również dostępna za pomocą pojedynczego kliknięcia lub pojedynczego stuknięcia.

Szczegóły i wyjątki:

• Wymagana alternatywa: Dla każdej funkcji opartej na złożonym geście musi istnieć alternatywa wykorzystująca:
  • Pojedynczy punkt styku: (np. kliknięcie myszą, stuknięcie palcem)
  • Bez wymogu ścieżki: (np. kliknięcie w ikonę, która zmienia wartość suwaka, zamiast przeciągania suwaka).
  • Przykład: Zamiast przeciągać element (drag-and-drop), należy udostępnić przyciski „Przenieś w górę” lub „Przenieś w dół”.
• Wyjątek:
  • Niezbędne gesty: Wymóg nie obowiązuje, jeśli złożony gest jest niezbędny do przekazania informacji lub operacji. (np. Rysowanie odręczne w edytorze graficznym, podpisywanie dokumentu, interfejsy do gier, które z natury wymagają ścieżek ruchu)

W przypadku wszelkich działań obsługiwanych za pomocą pojedynczego wskaźnika (np. kliknięcie myszą, dotknięcie ekranu), funkcja musi być aktywowana na zdarzeniu UP (zwolnienie przycisku/palca), a nie na zdarzeniu DOWN (wciśnięcie przycisku/dotknięcie), chyba że:

• użytkownik ma możliwość cofnięcia (anulowania) akcji przed zakończeniem (przed zwolnieniem) lub
• wykonanie funkcji na zdarzeniu DOWN jest niezbędne do jej obsługi (np. wirtualne klawiatury, gry zręcznościowe).

Dla wszystkich komponentów interfejsu użytkownika, które mają etykiety wizualne, etykiety te muszą być zawarte w ich dostępnej nazwie programowej (Accessible Name).

Szczegóły i wyjątki:

• Wizualna etykieta (Visual label): Tekst, który jest wyświetlany graficznie użytkownikowi (np. „Wyszukaj”, „Dalej”, „Koszyk”).
• Dostępna nazwa (Accessible name): Jest to nazwa, którą technologia asystująca ogłasza użytkownikowi. Jest ona tworzona na podstawie tekstu wizualnej etykiety, atrybutu aria-label, atrybutu title lub tekstu alternatywnego.
• Zasada zawierania: Dostępna nazwa nie musi być identyczna z wizualną etykietą, ale musi zawierać ten sam tekst.
  • Poprawnie: Przycisk posiada wizualną etykietę (tekst) „Koszyk”. Dostępna nazwa to „Koszyk (5 produktów)”. (Wizualna etykieta jest zawarta w dostępnej nazwie).
  • Błąd: Przycisk posiada wizualną etykietę (tekst) „Szukaj”. Dostępna nazwa to tylko „Lupa”. (Tekst „Szukaj” nie jest zawarty w nazwie).
• Wyjątek:
  • Tekst nie ma znaczenia: Wymóg nie obowiązuje dla tekstu, który jest czysto dekoracyjny lub jest częścią wizualizacji, a nie właściwą etykietą funkcjonalną (np. małe litery na ikonie, których celem jest wyłącznie styl, a nie identyfikacja działania).

Funkcjonalność, którą można obsługiwać za pomocą ruchu urządzenia (np. potrząśnięcie) lub ruchu użytkownika (np. gesty głowy), musi być również możliwa do obsłużenia za pomocą komponentów interfejsu (np. przycisków), a reagowanie na ruch musi być możliwe do wyłączenia, aby zapobiec przypadkowej aktywacji.

Wyjątek: Wymóg nie obowiązuje, jeśli ruch jest niezbędny do przekazania informacji lub operacji. (np. Interfejsy do gier, w których ruch jest naturalnym i kluczowym elementem rozgrywki (symulatory lotu, gry z czujnikami ruchu), interfejsy do pomiaru ruchu (krokomierze, aplikacje fitness)).

Cała funkcjonalność, która wymaga ruchu przeciągania (dragging) – czyli złożonego gestu wskaźnika, który wymaga precyzyjnego pozycjonowania i ścieżki (np. drag-and-drop, suwaki, które muszą być precyzyjnie przeciągane) – musi być również dostępna za pomocą pojedynczego kliknięcia lub pojedynczego stuknięcia.

Szczegóły i Wyjątki:

• Alternatywa dla przeciągania: Musi być zapewniona prosta, alternatywna metoda obsługi, która nie wymaga utrzymywania naciśniętego przycisku myszy podczas przesuwania.
  • Przykład: Zamiast przeciągać suwak do precyzyjnego ustawienia wartości, należy udostępnić pola tekstowe lub przyciski „plus/minus” obok suwaka.
• Zgodność z innymi kryteriami: To kryterium jest ściśle powiązane z 2.5.1 Gesty wskaźnika.
• Wyjątek:
  • Niezbędne przeciąganie: Wymóg nie obowiązuje, jeśli funkcjonalność, która wymaga ciągłego ruchu, jest niezbędna do przekazania informacji lub operacji (np. rysowanie, malowanie, tworzenie wykresów, edycja ścieżek w edytorach graficznych (gdzie sam proces przeciągania jest istotą funkcji).

Rozmiar celu (obszar interaktywny) dla wprowadzania wskaźnikiem (mysz, dotyk) musi wynosić co najmniej 24 na 24 piksele CSS.

Szczegóły i wyjątki:

• Obszar interaktywny: Wymagany minimalny rozmiar 24 na 24 CSS px dotyczy obszaru reagującego na kliknięcie/dotknięcie, a nie wizualnego elementu (np. ikona posiada rozmiar wizualny 16 na 16px z 4 px paddingu dookoła, daje to efektywne 24 na 24 px).
• Wyjątki:
  • W linii (Inline): Cel (np. link w środku akapitu) znajduje się w tekście lub jego rozmiar jest naturalnie ograniczony przez wysokość linii tekstu.
  • Kontrola przeglądarki (User Agent Control): Rozmiar celu jest określany przez przeglądarkę i nie został zmodyfikowany przez autora strony.
  • Równoważność (Equivalent): Funkcja może być osiągnięta za pomocą innego komponentu interfejsu na tej samej stronie, który spełnia wymóg minimalnego rozmiaru (24 x 24 px CSS).
  • Kluczowe znaczenie (Essential): Określona prezentacja celu jest kluczowa lub wymagana prawnie dla przekazywanej informacji.
  • Odstępy (Spacing): Mniejsze cele są dozwolone, jeśli są rozmieszczone w taki sposób, że krąg o średnicy 24 pikseli CSS, wyśrodkowany na każdym z celów, nie zachodzi na sąsiednie cele.

Domyślny język każdej strony internetowej musi być określony programowo w głównym elemencie za pomocą atrybutu lang (np. <html lang="pl">).

Szczegóły i wyjątki:

• Kod języka: Wartość atrybutu lang musi być poprawnym kodem języka, zgodnie z wybranym standardem:
  • ISO 639-1 (np. pl dla polskiego, en dla angielskiego, de dla niemieckiego).
  • IETF BCP 47 language tag (rozszerzone kody BCP 47) (np. en-US dla angielskiego w USA, pl-PL dla polskiego w Polsce).
• Wyjątki: Kryterium nie określa wyjątków. Obowiązuje dla wszystkich stron internetowych.

Domyślny język każdego fragmentu treści, który różni się od domyślnego języka całej strony, musi być programowo określony za pomocą atrybutu lang (np. <span lang="en">hello world</span>).

Szczegóły i wyjątki:

• Kod języka: Wartość atrybutu lang musi być poprawnym kodem języka, zgodnie z wybranym standardem:
  • ISO 639-1 (np. pl dla polskiego, en dla angielskiego, de dla niemieckiego).
  • IETF BCP 47 language tag (rozszerzone kody BCP 47) (np. en-US dla angielskiego w USA, pl-PL dla polskiego w Polsce).
• Wyjątki:
  • Nazwy własne: Dla nazw własnych (np. nazwisk, nazw firm, imion) wymóg nie obowiązuje.
  • Zwroty ugruntowane: Wymóg nie obowiązuje w przypadku słów i zwrotów, które zostały już ugruntowane w języku domyślnym i są powszechnie używane (np. „e-mail”, „laptop”, „rendez-vous” w języku polskim, które są zazwyczaj wymawiane z polską intonacją).

Kiedy jakikolwiek komponent interfejsu użytkownika (np. link, pole formularza, przycisk) otrzymuje fokus klawiatury, nie może on automatycznie inicjować zmiany kontekstu.

Szczegóły i wyjątki:

• Zmiana kontekstu: Zmiana kontekstu to nagła, znacząca zmiana postrzeganej treści strony (np. przejście do innej strony, automatyczne przesłanie formularza, przeskoczenie do innego dużego fragmentu strony, otworzenie nowego okna, zmianę układu, lub znaczącą zmianę treści).
• Wyjątek:
  • Ostrzeżenie i zgoda: Kryterium nie ma zastosowania, jeśli użytkownik został ostrzeżony o automatycznej zmianie kontekstu i wyraził na nią zgodę przed interakcją.

Zmiana ustawienia jakiegokolwiek komponentu interfejsu użytkownika (np. przełączenie pola wyboru, wybranie opcji z listy rozwijanej) nie może automatycznie powodować zmiany kontekstu, chyba że użytkownik został wcześniej ostrzeżony o takim zachowaniu.

Szczegóły i wyjątki:

• Zmiana kontekstu: Zmiana kontekstu to nagła, znacząca zmiana postrzeganej treści strony (np. przejście do innej strony, automatyczne przesłanie formularza, przeskoczenie do innego dużego fragmentu strony, otworzenie nowego okna, zmianę układu, lub znaczącą zmianę treści).
• Akceptowalne zmiany: Dozwolone są zmiany, które nie dezorientują użytkownika ani nie stanowią istotnej zmiany kontekstu (np. dynamiczna aktualizacja listy produktów po wybraniu filtra (jeśli lista jest w tej samej sekcji), zmiana zdjęcia na podglądzie produktu po wybraniu koloru, wyświetlenie komunikatu o błędzie).
• Wyjątek:
  • Ostrzeżenie i zgoda: Kryterium nie ma zastosowania, jeśli użytkownik został ostrzeżony o automatycznej zmianie kontekstu i wyraził na nią zgodę przed interakcją.

Mechanizmy nawigacyjne (np. linki w menu głównym), które powtarzają się na wielu stronach w obrębie całej witryny, muszą występować za każdym razem w tej samej kolejności względnej (Relative Order), chyba że użytkownik dokonał zmiany w tej kolejności.

Wyjątki:

• Responsywność: Dozwolona jest zmiana położenia wizualnego (np. menu w widoku mobilnym staje się rozwijane lub przenosi się na dół), o ile ich programowa kolejność pozostaje taka sama.
• Zmiana inicjowana przez użytkownika: Dopuszczalna jest zmiana kolejności, jeśli jest ona bezpośrednim wynikiem działania użytkownika (np. użytkownik zmienia język, co skutkuje dodaniem nowych linków, lub personalizuje widok).

Komponenty, które mają tę samą funkcjonalność w ramach całej witryny internetowej, muszą być identyfikowane w sposób spójny (czyli mieć te same etykiety, nazwy, opisy, wygląd).

Szczegóły i wyjątki:

• Spójność funkcjonalności: Oznacza, że komponenty wykonują to samo zadanie i prowadzą do tego samego rezultatu.
• Spójność wizualna:
  • Wizualna tożsamość: Użycie tej samej ikony, kształtu lub stylu dla danej funkcji (np. zawsze używaj ikony lupy dla wyszukiwania).
  • Tekstowa tożsamość: Użycie tej samej etykiety tekstowej dla danej funkcji (np. zawsze używaj „Wyloguj”, a nie raz „Wyloguj”, a raz „Zakończ sesję”).
• Wyjątek:
  • Zmiana przez użytkownika: Wymóg nie obowiązuje, jeśli użytkownik świadomie zmienił wizualną reprezentację lub etykietę komponentów (np. użytkownik spersonalizował nazwy zakładek w ramach dostosowywania interfejsu).

Jeśli strona zawiera mechanizmy pomocy (np. link do wsparcia, FAQ, czat na żywo), które powtarzają się na wielu stronach w całej witrynie, muszą one występować w tej samej kolejności względnej w stosunku do innej treści strony, chyba że zmiana została zainicjowana przez użytkownika.

Szczegóły i wyjątki:

• Mechanizmy pomocy: Obejmuje to wszelkie opcje, które mają pomóc użytkownikowi w obsłudze lub zrozumieniu treści:
  • Szczegóły kontaktu z człowiekiem (np. numer telefonu, adres e-mail).
  • Mechanizm kontaktu z człowiekiem (np. link do czatu na żywo).
  • Opcja samoobsługi (np. link do bazy wiedzy, FAQ).
  • W pełni zautomatyzowany mechanizm kontaktu (np. chatbot).
• Kolejność względna: Dotyczy to kolejności w kodzie (DOM order). Jeśli np. „FAQ” jest programowo przed „Telefonem Kontaktowym” w stopce na jednej stronie, musi tak być również na innych.
• Wyjątek:
  • Zmiana przez użytkownika: Wymóg nie obowiązuje, jeśli użytkownik świadomie zmienił kolejność (np. użytkownik spersonalizował kolejność w ramach dostosowywania interfejsu).

Jeśli wystąpi błąd wprowadzania danych (input error), błąd ten musi być automatycznie zidentyfikowany i opisany użytkownikowi w postaci tekstu.

Szczegóły i wyjątki:

• Automatyczne wykrywanie: Wymóg dotyczy błędów, które system automatycznie rozpoznaje (np. brak wypełnienia wymaganego pola, niepoprawny format adresu e-mail).
• Identyfikacja elementu: Użytkownik musi wiedzieć, które pole zawiera błąd. Często osiąga się to poprzez ramkę lub ikonę błędu wizualnie wskazującą pole
  • Wymóg programowy: Pole musi być również zidentyfikowane programowo (np. za pomocą atrybutów ARIA, które informują czytnik ekranu o stanie błędu).
• Opis tekstowy: Sama wizualna wskazówka (np. czerwona ramka) nie wystarcza. Konieczne jest dostarczenie opisu błędu w formie tekstu
  • Poprawnie: Komunikat: „To pole jest wymagane” lub „Wprowadzony adres e-mail jest nieprawidłowy”.
  • Błąd: Pole jest tylko podświetlone na czerwono lub obok niego pojawia się tylko ikona wykrzyknika bez towarzyszącego tekstu.
• Lokalizacja: Komunikat o błędzie musi być umieszczony w pobliżu pola, którego dotyczy, lub na szczycie formularza z wyraźnym linkiem do danego pola.
• Wyjątek:
  • Naruszenie bezpieczeństwa: Wymóg nie obowiązuje w przypadku, gdy identyfikacja błędu mogłaby naruszyć bezpieczeństwo lub naruszyć cel treści.
  • Przykład: W przypadku nieprawidłowego logowania, ujawnienie, czy błąd dotyczy nazwy użytkownika, czy hasła, może naruszyć bezpieczeństwo systemu
    • Poprawnie: „Nieprawidłowa nazwa użytkownika lub hasło”.
    • Błąd: „Wprowadzona nazwa użytkownika jest niepoprawna.”, „Wprowadzone hasło jest niepoprawne.”

Jeśli treść wymaga wprowadzenia danych przez użytkownika, muszą być dostarczone etykiety (labels) lub instrukcje (instructions).

Szczegóły i wyjątki:

• Etykiety (Labels): Każde pole formularza musi posiadać wizualną etykietę, która jest programowo powiązana z polem (np. za pomocą <label for="ID">). Etykieta ta jasno identyfikuje cel pola (patrz 2.4.6 Nagłówki i etykiety).
• Instrukcje: Jeśli format wprowadzanych danych jest krytyczny lub nietypowy, należy dostarczyć dodatkowe instrukcje lub przykłady.
  • Przykłady: Instrukcje dla hasła („Minimum 8 znaków, w tym jedna wielka litera i cyfra”), informacja o wymaganym formacie daty („DD/MM/RRRR”).
• Położenie: Etykiety i instrukcje powinny być umieszczone w bezpośrednim sąsiedztwie pola formularza lub być dostępne programowo (np. poprzez aria-describedby).
• Wyjątek:
  • Zrozumiałe bez instrukcji: Wymóg dostarczenia dodatkowych instrukcji nie obowiązuje dla pól, których cel jest powszechnie zrozumiały i nie wymaga szczególnego formatu. (np. Pole „Imię”, „Nazwisko”, „Adres e-mail” (jeśli format jest walidowany ogólnie, a nie w specyficzny sposób)).

Jeśli wystąpi błąd we wprowadzaniu danych i istnieją znane sugestie dotyczące poprawnego wprowadzenia, sugestie te muszą być automatycznie dostarczone użytkownikowi, chyba że naruszyłoby to bezpieczeństwo lub cel treści.

Szczegóły i wyjątki:

• Sugestie: Dotyczy to sytuacji, gdy system może logicznie i z dużym prawdopodobieństwem zaproponować, co użytkownik miał na myśli.
  • Przykłady:
    • Literówki: Użytkownik wpisał [email protected]. System sugeruje: „Czy chodziło Ci o: [email protected]?”
    • Powszechne błędy formatowania: Użytkownik wpisał kod pocztowy w złym formacie  w formacie 41000. System sugeruje: „Wpisz kod pocztowy w formacie XX-XXX.”
• Wyjątek:
  • Bezpieczeństwo i cel: Wymóg nie obowiązuje, jeśli podanie sugestii mogłoby naruszyć bezpieczeństwo lub cel treści.
    • Przykład dla bezpieczeństwa: Sugerowanie prawidłowej nazwy użytkownika po błędzie logowania jest niedozwolone, ponieważ narusza bezpieczeństwo (patrz 3.3.1). W tym wypadku system nie powinien sugerować poprawy.
    • Przykład dla celu: W teście pisowni sugerowanie poprawnej pisowni słowa jest niedozwolone, ponieważ celem formularza jest ocena wiedzy użytkownika, a nie poprawianie go.

W przypadku stron internetowych, które powodują konsekwencje prawne, transakcje finansowe, lub które modyfikują/usuwają dane kontrolowane przez użytkownika, musi być dostępny co najmniej jeden z następujących mechanizmów, aby zapobiec poważnym błędom:

1. Odwracalne (reversible): Przesłane dane są odwracalne (np. istnieje możliwość anulowania transakcji po jej wykonaniu).
2. Sprawdzone (checked): Dane wprowadzone przez użytkownika są sprawdzane pod kątem błędów we wprowadzaniu, a użytkownikowi daje się możliwość ich poprawy (np. system wskazuje błędne pola i prosi o korektę).
3. Potwierdzone (confirmed): Dostępny jest mechanizm do przeglądania, potwierdzania i poprawiania informacji przed ostatecznym przesłaniem (np. strona podsumowująca, na której można edytować dane przed ich akceptacją).

Wyjątek:

• Krytyczna i natychmiastowa akcja: Kryterium nie obowiązuje, jeśli cel treści wymaga natychmiastowej i nieodwracalnej akcji, a zastosowanie mechanizmów cofnięcia lub potwierdzenia mogłoby naruszyć bezpieczeństwo lub całkowicie zniweczyć cel usługi. (np. przycisk „zablokuj dostęp natychmiast” w systemie zarządzania kryzysowego, który nie ma dodatkowego potwierdzenia, ponieważ późniłoby to krytyczną akcję i naraziłoby system na poważne szkody)

Informacje, które zostały wcześniej wprowadzone przez użytkownika lub dostarczone mu i są wymagane do ponownego wprowadzenia w ramach tego samego procesu, muszą być albo automatycznie uzupełnione, albo dostępne do wyboru przez użytkownika.

Szczegóły i wyjątki:

• Wymóg (musi być spełniony co najmniej jeden): System musi spełnić co najmniej jeden:
  • Automatyczne uzupełnianie (auto-populated): Pole formularza jest automatycznie wypełnione wcześniej wprowadzonymi danymi (np. w kroku „Wysyłka” i „Płatność”).
  • Dostępne do wyboru (available for selection): Użytkownik może wybrać wcześniej wprowadzone dane z listy (np. adres rozliczeniowy jako opcja do wyboru dla adresu wysyłki).
• Wyjątki (gdy ponowne wprowadzenie jest dopuszczalne):
  • Konieczne ponowne wprowadzenie (essential): Ponowne wprowadzenie informacji jest kluczowe (niezbędne) dla celu danej aktywności (np. system wymaga powtórzenia hasła w celu weryfikacji).
  • Bezpieczeństwo (security): Informacje są wymagane do zapewnienia bezpieczeństwa treści (np. ponowne wprowadzenie hasła lub kodu weryfikacyjnego).
  • Nieważne dane (no longer valid): Wcześniej wprowadzone informacje są już nieaktualne lub niewłaściwe dla bieżącego kontekstu.

Proces uwierzytelniania (logowania) nie może polegać wyłącznie na testach zdolności poznawczych (cognitive function test), chyba że:

• Alternatywa: Dostępna jest inna metoda uwierzytelniania, która nie opiera się na teście funkcji poznawczych (np. użycie klucza bezpieczeństwa FIDO, logowanie biometryczne, link magiczny wysłany e-mailem).
• Mechanizm: Dostępny jest mechanizm pomagający użytkownikowi w ukończeniu testu funkcji poznawczych.
  • Przykłady mechanizmów: Wsparcie dla menedżerów haseł (np. przez atrybut autocomplete), możliwość kopiowania/wklejania hasła w celu zmniejszenia obciążenia związanego z ponownym wpisywaniem.
• Rozpoznawanie obiektów: Test funkcji poznawczych polega na rozpoznawaniu obiektów (np. CAPTCHA, w którym należy wybrać obrazy samochodów).
• Treść osobista: Test funkcji poznawczych polega na identyfikacji treści nietekstowej, którą użytkownik sam dostarczył wcześniej do witryny (np. identyfikacja jednego z własnych zdjęć profilowych).

Szczegóły i wyjątki:

• Test funkcji poznawczych (cognitive function test): Obejmuje wszelkie zadania, które wymagają zapamiętywania lub skomplikowanego przetwarzania informacji (np. konieczność ręcznego wpisywania skomplikowanego hasła, rozwiązywanie nieoznaczonych graficznie CAPTCHA).
• Wyjątek:
  • Niezbędne: Wymóg nie obowiązuje, jeśli test zdolności poznawczych jest niezbędny dla celu danego elementu (np. strona do testowania pamięci lub gra, której celem jest właśnie przypomnienie sobie ciągu znaków).

Dla wszystkich komponentów interfejsu użytkownika (UI Components) – w tym elementów formularzy, linków, widżetów i ich stanów – informacje programowe (kod) muszą umożliwiać technologiom asystującym (AT) poprawne określenie:

• Nazwy (Name): Jaka jest dostępna nazwa dla elementu (np. „Przycisk Wyślij”) – nazwa zazwyczaj pochodzi z wizualnej etykiety (<label>), tekstu wewnętrznego lub atrybutu ARIA (aria-label).
• Roli (Role): Jaki jest typ elementu – rola jest domyślnie określana przez semantyczne elementy HTML (np. <a> = link, <button> = przycisk) lub jest nadawana za pomocą atrybutów ARIA (np. role="navigation").
• Wartości/Stanów (Value/State): Jaki jest aktualny stan elementu (np. zaznaczony checked , rozwinięty aria-expanded="true" , nieaktywny aria-disabled="true") lub jego wartość (np. tekst wpisany w pole <input type="text">).

Komunikaty o statusie (Status Messages) muszą być prezentowane użytkownikowi za pomocą technologii asystujących (AT) bez konieczności otrzymywania fokusu.

Szczegóły i wyjątki:

• Komunikat o statusie: Informacja, która przekazuje użytkownikowi zmianę stanu strony bez przerywania jego pracy (np. „Produkt dodano do koszyka”, „Błąd zapisu”, „Trwa aktualizacja wyników wyszukiwania”).

• Wymagana implementacja (ARIA Live Regions): Najbardziej akceptowaną i skuteczną metodą spełnienia tego kryterium jest użycie regionów na żywo WAI-ARIA (ARIA Live Regions). System musi dynamicznie wstawić komunikat do obszaru oznaczonego odpowiednią rolą:

  • role="status": Ogólny status, który jest czytany bez przerywania aktualnego zadania użytkownika (np. „Produkty zostały zaktualizowane”).

  • aria-live="polite": Najczęściej używany, informuje o zmianie statusu w momencie, gdy czytnik ekranu zakończy odczytywanie aktualnej sekwencji.

• Wyjątek:

  • Błędy i wyskakujące okna: Kryterium nie ma zastosowania do:

    • Komunikatów o błędach (patrz 3.3.1) – są krytyczne i wymagają natychmiastowej reakcji użytkownika najczęściej z przeniesieniem fokusu.

    • Okien dialogowych/modalnych – najczęściej wymagają, aby fokus został do nich przeniesiony (patrz 2.1.2).