Wróć do wszystkich kryteriów

1.3.3 Cechy zmysłowe (ang.) Sensory Characteristics

Specjalizacje:

  • Content Creator
  • Designer
  • Deweloper

Elementy:

  • Formularze
  • Przyciski i kontrolki
  • Tekst i treść

Poziomy:

  • A

Spis treści

    Istota i cel kryterium

    Wytyczna zapewnia, że instrukcje i informacje na stronie nie opierają się wyłącznie na zdolnościach sensorycznych użytkownika, takich jak wzrok, słuch czy ruch.

    Należy upewnić się, że instrukcje i informacje wymagane do zrozumienia treści lub obsługi komponentów interfejsu nie polegają wyłącznie na kształcie, rozmiarze, wizualnym położeniu, orientacji czy dźwięku.

    Użytkownicy niewidomi, słabowidzący, niesłyszący lub ci, którzy mają problemy poznawcze, mogą nie być w stanie dostrzec lub zinterpretować instrukcji opartych wyłącznie na tych cechach zmysłowych.

    Definicja w j. angielskim

    Definicja dostępna pod adresem (link otworzy się w nowej karcie):
    https://www.w3.org/WAI/WCAG22/quickref/#sensory-characteristics

    Definicja w j. polskim

    Definicja dostępna pod adresem (link otworzy się w nowej karcie):
    https://www.w3.org/Translations/WCAG21-pl/#w-asciwosci-zmys-owe

    Słownik pojęć

    Cechy sensoryczne/zmysłowe
    –

    Właściwości elementów, które odbieramy zmysłami, takie jak ich kolor, kształt, wielkość, położenie na stronie (np. góra/dół) czy wydawany dźwięk. Zgodnie z WCAG nie mogą być one jedynym sposobem komunikacji z użytkownikiem.

    Wpływ na dostępność (Kogo wspierasz?)

    • Użytkownicy technologii wspomagających (niewidomi i słabowidzący): Czytnik ekranu to program, który analizuje kod, a nie obraz. Dla niego informacja o tym, że przycisk jest „duży” lub „okrągły”, jest całkowicie nieistniejąca – technologia ta potrzebuje nazwy tekstowej, a nie opisu wizualnego, którego nie potrafi zinterpretować.
    • Osoby z zaburzeniami rozpoznawania barw (daltonizm): Poleganie na samym kolorze to zakładanie, że każdy widzi świat w tej samej palecie. Jeśli jedynym sygnałem błędu jest czerwona ramka, osoba z daltonizmem może go po prostu nie zauważyć, co prowadzi do dezorientacji i porzucenia zadania.
    • Osoby niesłyszące i słabosłyszące: Dźwięk bez wizualnego wsparcia staje się „cichą barierą”. Użytkownik nie dowie się o krytycznym alercie lub zakończeniu ważnego procesu (np. płatności), jeśli jedynym sygnałem o tym zdarzeniu będzie sygnał dźwiękowy.
    • Osoby z trudnościami poznawczymi: Instrukcje oparte na orientacji przestrzennej (np. „wybierz element po skosie”) wymuszają dodatkowy wysiłek intelektualny związany z orientacją w układzie strony. Prosta, tekstowa komenda „Kliknij Zapisz” eliminuje zbędne „zgadywanie”, co autor miał na myśli.
    • Użytkownicy korzystający z dużego powiększenia (lupy ekranowej): Przy powiększeniu rzędu 400% lub większym, użytkownik widzi tylko mały wycinek strony. Polecenie „zobacz menu po prawej” zmusza go do żmudnego przesuwania widoku w poszukiwaniu elementu, który znajduje się daleko poza jego aktualnym polem widzenia.
    • Osoby pracujące w specyficznych warunkach (np. wyciszony dźwięk): Informacje dźwiękowe bez wizualnego odpowiednika są pomijane przez użytkowników, którzy mają wyłączone głośniki lub przebywają w hałaśliwym miejscu, gdzie sygnały audio są niesłyszalne.

    Zasady wdrażania i wymagania techniczne

    • Zrezygnuj z instrukcji lokalizacyjnych: Zamiast pisać „kliknij przycisk po lewej”, użyj nazwy tego przycisku: „wybierz przycisk 'Dalej’”.
    • Łącz kolor z dodatkowym symbolem: Jeśli zaznaczasz błąd na czerwono, dodaj ikonę ostrzeżenia, wzór lub wyraźny napis „Błąd”. Dzięki temu informacja będzie zrozumiała dla osób z daltonizmem oraz tych, którzy nie widzą kolorów.
    • Stosuj programowe powiązania ((ang.) Programmatic association): Upewnij się, że instrukcje są powiązane z elementami w kodzie strony. Wykorzystuj atrybut aria-describedby, aby komunikat o błędzie był automatycznie odczytywany przez czytnik ekranu po wejściu w dane pole formularza.
    • Opisuj kształty i rozmiary: Jeśli elementy różnią się wyglądem, dodaj do nich etykiety tekstowe dostępne dla czytników ekranu (np. atrybuty ARIA).
    • Wizualizuj dźwięki: Każdy istotny sygnał dźwiękowy (np. powiadomienie o upływie sesji) musi mieć swój odpowiednik na ekranie, np. w formie baneru lub komunikatu tekstowego (użycie role="alert" lub aria-live).
    • Dostarczaj tekst ukryty wizualnie: W sytuacjach, gdzie ze względów estetycznych nie możesz dodać widocznego tekstu, zastosuj klasę CSS typu .visually-hidden, aby dostarczyć niezbędny kontekst wyłącznie dla użytkowników czytników ekranu.

    Wyjątki i sytuacje szczególne

    Kryterium to nie zabrania używania kolorów, kształtów czy dźwięków jako dodatkowego wsparcia. Są one wręcz pożądane jako element wzmacniający przekaz, pod warunkiem, że nie stanowią jedynej metody komunikacji z użytkownikiem.

    Przykłady implementacji

    Kolor i tekst

    Instrukcje dla pól formularza

    Instrukcje nawigacyjne

    Alert dźwiękowy

    Najczęstsze błędy

    • Podawanie instrukcji nawigacyjnych opartych tylko na pozycji elementu (np. „instrukcja znajduje się w lewej kolumnie”).
    • Używanie ikon bez tekstowych etykiet lub ukrytych nazw dostępnych dla czytników ekranu.
    • Poleganie wyłącznie na dźwięku w celu poinformowania o zakończeniu procesu lub wystąpieniu błędu.
    • Stosowanie mechanizmów (ang.) CAPTCHA, które wymagają wyłącznie rozpoznania obrazu lub dźwięku bez alternatywy tekstowej.
    • Opisywanie elementów interaktywnych wyłącznie przez ich wygląd (np. „kliknij duży, niebieski przycisk”).

    Najlepsze praktyki

    • Zasada redundancji (wielokanałowości): Zawsze przekazuj kluczowe informacje na co najmniej dwa sposoby (np. kolor + tekst, kształt + ikona, dźwięk + tekst).
    • Semantyka HTML: Stosuj poprawne znaczniki, takie jak <label> czy <button>, które naturalnie wspierają dostępność i pomagają technologiom asystującym w identyfikacji elementów.
    • Konkretne nazewnictwo: Zrezygnuj z ogólników typu „kliknij tutaj” na rzecz konkretnych wezwań do działania, np. „Dodaj do koszyka”.
    • Wzbogacanie ARIA: Wykorzystuj atrybuty takie jak aria-label czy aria-describedby, aby dostarczyć dodatkowy kontekst tam, gdzie standardowy HTML nie jest wystarczający.
    • Dostarczaj alternatywy dla mechanizmów (ang.) CAPTCHA: Jeśli musisz korzystać z weryfikacji, nigdy nie polegaj wyłącznie na jednym zmyśle (np. rozpoznawaniu tekstu z obrazka). Zawsze zapewnij opcję dźwiękową lub zadanie tekstowe, aby nie wykluczać żadnej grupy odbiorców.

    Metody testowania

    • Narzędzie deweloperskie (ang.) Developer Tools: Sprawdź w drzewie DOM, czy elementy identyfikowane wizualnie posiadają odpowiednie etykiety tekstowe i czy nie są puste (np. brak atrybutu alt).
    • NVDA: Uruchom czytnik ekranu i zweryfikuj, czy po przejściu do danej sekcji otrzymujesz wszystkie niezbędne instrukcje do jej obsługi bez patrzenia na monitor.
    • (ang.) WAVE Evaluation Tool: Użyj narzędzia do wykrycia błędów w strukturze formularzy i braku powiązań między komunikatami a polami edycyjnymi.
    • (ang.) IBM Equal Access Toolkit: Przeprowadź audyt, aby sprawdzić, czy dynamiczne zmiany (np. pojawienie się komunikatu dźwiękowego) są odnotowywane przez technologie wspomagające.
    • Testowanie manualne: Wyłącz głośniki oraz style CSS, a następnie oceń, czy treść strony i instrukcje nadal pozostają w pełni zrozumiałe i możliwe do wykonania.

    Sprawdź swoją wiedzę

    W poniżej podanym linku znajduje się 5 przykładów interfejsów. Twoim celem jest ocena, czy instrukcje lub informacje przekazywane użytkownikowi nie polegają wyłącznie na cechach zmysłowych (kształt, kolor, dźwięk, lokalizacja).

    Notatka: Zanim zajrzysz do rozwiązania, uruchom wybrane narzędzia testowe i zapisz swoje wnioski na kartce.
    Proponowane narzędzia: Narzędzie deweloperskie (ang.) Developer Tools, NVDA, (ang.) WAVE Evaluation Tool, (ang.) IBM Equal Access Toolkit, Testowanie manualne

    Link: https://pdc.ambiscale.com/training/wcag-1-3-3/

    #1 BŁĄD

    Problem: Instrukcja polega wyłącznie na kształcie („okrągły przycisk”).
    Dlaczego: Osoba niewidoma słyszy tylko „Przycisk”, nie wie, który ma jaki kształt.
    Naprawa: Opisać przycisk funkcją, np. „Kliknij przycisk 'Akceptuj'”.

    #2 DOBRZE

    Dlaczego: Informacja o sukcesie jest przekazana na trzy sposoby: kolor (zielony), ikonę (wizualnie) i tekst („Sukces:”). Nie polega tylko na kolorze.

    #3 BŁĄD

    Problem: Dostępność terminu jest oznaczona wyłącznie kolorem godziny.
    Dlaczego: Osoba z achromatopsją (nie widzi kolorów) nie odróżni terminów wolnych od zajętych.
    Naprawa: Dodać tekst, np. „10:00 (Wolny)”.

    #4 DOBRZE

    Dlaczego: Sygnałowi dźwiękowemu towarzyszy komunikat wizualny („Zapisano zmiany”), który jest również dostępny programowo (`role=”status”`). Informacja nie jest tylko dźwiękowa.

    #5 BŁĄD

    Problem: Instrukcja odwołuje się do lokalizacji wizualnej („po prawej stronie”).
    Dlaczego: Na telefonie menu spadnie na dół, a w czytniku ekranu kolejność jest liniowa. „Prawa strona” traci sens.
    Naprawa: Użyć nazwy, np. „skorzystaj z Menu Głównego”.

    Źródła

    Dodatkowe linki

    Wróć do wszystkich kryteriów