WCAG 1.3.3: Cechy sensoryczne

Co Oznacza Ta Zasada

Kryterium sukcesu WCAG 1.3.3 — Cechy sensoryczne (poziom A) stanowi, że instrukcje służące do zrozumienia i obsługi treści nie mogą opierać się wyłącznie na cechach sensorycznych komponentów, takich jak kształt, rozmiar, położenie wizualne, orientacja czy dźwięk. Innymi słowy, jeśli interfejs mówi użytkownikowi, aby wchodził w interakcję z elementem, odwołując się tylko do tego, jak on wygląda, gdzie pojawia się na ekranie lub jak brzmi, taka instrukcja będzie bez znaczenia dla użytkowników, którzy nie mogą postrzegać tych konkretnych właściwości sensorycznych.

Kluczowym słowem jest tutaj wyłącznie. Kryterium nie zabrania używania odniesień sensorycznych — zabrania uczynienia z nich jedynych środków identyfikacji. Instrukcja typu „kliknij okrągły zielony przycisk po lewej” zawodzi, gdy użytkownik nie rozróżnia koloru zielonego, nie widzi kształtu przycisku lub nie jest w stanie określić lewo–prawo z powodu przeformatowania układu. Natomiast „kliknij przycisk Submit (okrągły zielony przycisk po lewej)” spełnia wymagania, ponieważ etykieta tekstowa „Submit” zapewnia niesensoryczny identyfikator, który działa niezależnie od koloru, kształtu i położenia.

Instrukcje objęte tym kryterium obejmują wszelkie treści tekstowe, dźwiękowe lub wizualne, które nakierowują użytkowników na wykonanie działania lub zlokalizowanie informacji. Typowe wzorce niezgodne z wymaganiami obejmują:

• „Kliknij przycisk po prawej, aby kontynuować” — opiera się wyłącznie na położeniu wizualnym.
• „Wybierz kwadratową ikonę, aby otworzyć ustawienia” — opiera się wyłącznie na kształcie.
• „Pola wymagane są pokazane na czerwono” — opiera się wyłącznie na kolorze.
• „Gdy usłyszysz dzwonek, przejdź do następnego kroku” — opiera się wyłącznie na dźwięku.
• „Stuknij duży kafelek, aby rozwinąć sekcję” — opiera się wyłącznie na rozmiarze.

Instrukcja spełniająca wymagania zawsze zawiera co najmniej jeden niesensoryczny identyfikator — zazwyczaj etykietę tekstową, nazwę programistyczną lub nagłówek — tak aby użytkownicy polegający na technologiach asystujących lub działający w warunkach, w których wskazówki sensoryczne są niedostępne, nadal mogli podążać za instrukcjami. Należy zauważyć, że to kryterium dotyczy konkretnie instrukcji; nie wymaga ono przeprojektowania każdego elementu interfejsu, ale wymaga, aby wszelkie wskazówki tekstowe lub mówione dotyczące tych elementów były postrzegalne bez rozróżniania cech sensorycznych.

W samym 1.3.3 nie zdefiniowano oficjalnych wyjątków, choć dokument Understanding wyjaśnia, że treści, które używają cech sensorycznych oprócz niesensorycznych identyfikatorów, są w pełni zgodne. Kryterium to uzupełnia, ale różni się od 1.4.1 (Użycie koloru), które dotyczy wyłącznie koloru; 1.3.3 ma szerszy zakres, obejmujący wszystkie modalności sensoryczne.

Dlaczego To Ma Znaczenie

Instrukcje oparte wyłącznie na cechach sensorycznych tworzą poważne bariery dla szerokiej grupy użytkowników. Rozważmy każdą z dotkniętych grup:

Osoby niewidome i słabowidzące polegają na czytnikach ekranu lub oprogramowaniu powiększającym. Gdy instrukcja mówi „kliknij ikonę w prawym górnym rogu”, użytkownik czytnika ekranu nawigujący według kolejności tabulacji lub struktury nagłówków nie ma pojęcia o „prawym górnym rogu” w układzie wizualnym. Podobnie, użytkownik z poważną wadą wzroku, który powiększył widok do 400%, może widzieć jedynie niewielką część ekranu naraz, co sprawia, że odniesienia do położenia, takie jak „lewy panel” czy „dolna sekcja”, są całkowicie niewiarygodne. Według Światowej Organizacji Zdrowia około 2,2 miliarda osób na świecie ma jakąś formę upośledzenia wzroku, co czyni tę grupę jedną z największych.

Osoby z daltonizmem — dotyczy to około 1 na 12 mężczyzn i 1 na 200 kobiet — nie rozróżniają pewnych par kolorów. Instrukcja „pola podświetlone na czerwono są obowiązkowe” jest niewidoczna jako wyróżniająca wskazówka dla osoby z daltonizmem czerwono–zielonym. Podczas gdy 1.4.1 odnosi się do tego w kontekście samego elementu interfejsu, 1.3.3 zapewnia, że tekst instrukcji również dostarcza alternatywy.

Osoby głuche i niedosłyszące są dotknięte wskazówkami opartymi wyłącznie na dźwięku. Jeśli platforma e-learningowa instruuje użytkowników, aby „przeszli dalej, gdy usłyszą dzwonek”, osoby, które nie słyszą dzwonka, są wykluczone. Taki wzorzec pojawia się w interaktywnych prezentacjach, samouczkach wideo i testach na czas.

Osoby z niepełnosprawnościami poznawczymi i trudnościami w uczeniu się mogą mieć trudności z językiem kierunkowym, zwłaszcza gdy ich technologia asystująca renderuje treść w formie zlinearyzowanej, która usuwa pozycjonowanie wizualne. Osoba korzystająca z urządzenia przełącznikowego lub systemu śledzenia wzroku również nawiguję sekwencyjnie, w sposób, który może nie mieć żadnego związku z dwuwymiarowym układem przestrzennym, jaki wyobraził sobie widzący projektant.

Rozważmy konkretny scenariusz z życia: turecki rządowy portal e-usług instruuje obywateli, aby „wypełnili pola obramowane na niebiesko, a następnie naciśnęli trójkątny przycisk, aby przesłać wniosek”. Niewidomy użytkownik nawigujący po polach formularza słyszy etykiety pól przez czytnik ekranu, ale nie ma możliwości dowiedzieć się, które pola są obramowane na niebiesko, ani zidentyfikować przycisku po jego trójkątnym kształcie. Proces składania wniosku jest w praktyce zablokowany. Dodanie rzeczywistych etykiet pól (np. „Imię i nazwisko, numer ID i data urodzenia są wymagane”) oraz etykiety tekstowej przycisku („Submit Application”) natychmiast usuwa barierę.

Poza dostępnością, usunięcie instrukcji opartych wyłącznie na cechach sensorycznych poprawia użyteczność dla wszystkich. Projekty responsywne przeformatowują treść, przez co odniesienia do położenia stają się nieprecyzyjne na urządzeniach mobilnych. Tryb ciemny lub motywy o wysokim kontraście zmieniają sposób renderowania kolorów. Asystenci głosowi odczytujący instrukcje na stronie usuwają cały kontekst wizualny. Budowanie instrukcji wokół stabilnych, programistycznych etykiet zamiast ulotnych właściwości sensorycznych sprawia, że treść jest bardziej odporna we wszystkich urządzeniach i kontekstach — co stanowi również bezpośrednią korzyść dla SEO i utrzymania.

Powiązane Zasady Axe-core

WCAG 1.3.3 wymaga testów manualnych, ponieważ narzędzia automatyczne nie są w stanie wiarygodnie zinterpretować znaczenia ani intencji instrukcji w języku naturalnym. Silnik analizy statycznej może wykryć, że istnieje przycisk lub że użyto koloru, ale nie potrafi przeczytać akapitu tekstu instruktażowego, zrozumieć, że odnosi się on do przycisku, a następnie ustalić, czy to odniesienie jest wyłącznie sensoryczne. Jest to osąd semantyczny i kontekstowy, który wymaga przeglądu przez człowieka.

• Wymagana recenzja manualna — nie istnieje dedykowana zasada axe-core dla 1.3.3. Zasady axe-core, takie jak color-contrast i label, mogą ujawniać powiązane problemy (na przykład przycisk bez dostępnej nazwy), ale dotyczą innych kryteriów. W przypadku 1.3.3 tester musi ręcznie przeczytać każde zdanie instruktażowe na stronie, zidentyfikować wszelkie odniesienia sensoryczne (kształt, kolor, rozmiar, położenie, orientacja, dźwięk) i zweryfikować, że każdemu odniesieniu towarzyszy co najmniej jeden niesensoryczny identyfikator. Narzędzia automatyczne nie oznaczą zdania typu „kliknij zielony przycisk poniżej” jako naruszenia, ponieważ analiza intencji w języku naturalnym wykracza poza możliwości obecnej automatyzacji opartej na regułach.
• Dlaczego automatyzacja tu zawodzi: Rozważmy, że „kliknij duży przycisk” zawiera słowo „przycisk”, które narzędzie automatyczne mogłoby zinterpretować jako odniesienie do roli dostępności. Jednak instrukcja nadal opiera się wyłącznie na rozmiarze („duży”), aby odróżnić ten przycisk od innych. Narzędzia automatyczne nie są w stanie ustalić, czy „duży” jest jedyną cechą wyróżniającą, ani czy na stronie jest tylko jeden przycisk (co czyni „duży” zbędnym, ale nieszkodliwym). Ludzki osąd jest niezbędny do oceny tych niuansów w kontekście.
• Komplementarne zasady axe do uruchomienia równolegle z recenzją manualną: Uruchomienie kontroli color-contrast, label, button-name i aria-label pomoże upewnić się, że elementy interfejsu, do których odnoszą się instrukcje, faktycznie mają nazwy programistyczne — co jest warunkiem wstępnym do pisania niesensorycznych instrukcji. Jeśli przycisk nie ma dostępnej nazwy, żadna instrukcja nie może sensownie się do niego odwołać bez uciekania się do wskazówek sensorycznych.

Jak Testować

1. Najpierw uruchom skan automatyczny (axe DevTools lub Lighthouse): Otwórz stronę w Chrome, włącz rozszerzenie axe DevTools i uruchom skan całej strony. Choć żadna reguła nie mapuje się bezpośrednio na 1.3.3, przejrzyj wszystkie zgłoszone problemy w kategoriach „color”, „label” i „name”. Wyniki te stanowią punkt wyjścia — jeśli elementom interfejsu brakuje dostępnych nazw, tekst instrukcji odnoszący się do nich niemal na pewno opiera się na wskazówkach sensorycznych. Wyeksportuj wyniki i zanotuj wszystkie elementy interaktywne bez etykiet programistycznych.
2. Ręcznie zidentyfikuj cały tekst instruktażowy: Przeczytaj każde zdanie na stronie, które nakierowuje użytkownika na wykonanie działania lub zlokalizowanie informacji. Obejmuje to tekst pomocy, podpowiedzi formularzy, dymki podpowiedzi, nakładki samouczków, komunikaty o błędach i ścieżki wdrożeniowe (onboarding). Utwórz listę każdej instrukcji i wyróżnij wszelkie odniesienia sensoryczne: słowa dotyczące koloru (czerwony, niebieski, zielony), kształtu (okrągły, kwadratowy, trójkątny), rozmiaru (duży, mały, wielki), położenia (lewy, prawy, górny, dolny, powyżej, poniżej, róg), orientacji (poziomy, pionowy) oraz dźwięku (dzwonek, piknięcie, dźwięk alertu).
3. Oceń każde odniesienie sensoryczne pod kątem dodatkowych niesensorycznych identyfikatorów: Dla każdego odniesienia sensorycznego ustal, czy występuje również niesensoryczny identyfikator. Niesensoryczny identyfikator obejmuje etykietę tekstową odpowiadającą widocznej etykiecie elementu lub jego dostępnej nazwie, nagłówek, numerowany krok, unikalną rolę programistyczną lub etykietę ARIA. Jeśli jedynym sposobem zidentyfikowania danego elementu jest percepcja sensoryczna, instrukcja nie spełnia 1.3.3.
4. Przetestuj z czytnikiem ekranu (NVDA + Firefox): Nawiguj po stronie wyłącznie za pomocą klawiatury i NVDA. Przechodź klawiszem Tab przez wszystkie elementy interaktywne i słuchaj, jak NVDA je ogłasza. Następnie przeczytaj tekst instruktażowy na stronie i zadaj sobie pytanie: czy użytkownik słyszący tylko te komunikaty mógłby podążać za instrukcjami? Jeśli instrukcja mówi „kliknij ikonę po prawej”, ale NVDA ogłasza element jako „Settings, button”, wówczas odniesienie do położenia jest zbędne, ale etykieta sprawia, że instrukcja jest nawigowalna. Jeśli NVDA ogłasza element jako „button” bez nazwy, instrukcja opierająca się na położeniu wizualnym całkowicie zawodzi.
5. Przetestuj z VoiceOver + Safari (macOS/iOS): Włącz VoiceOver i nawiguj po stronie. Użyj rotor, aby przeglądać przyciski, linki i kontrolki formularzy. Zweryfikuj, że każdy element, do którego odnosi się instrukcja, jest osiągalny i identyfikowalny wyłącznie po ogłaszanej nazwie, bez polegania na jego położeniu w układzie wizualnym.
6. Przetestuj z JAWS + Chrome: Otwórz stronę w Chrome z aktywnym JAWS. Użyj trybu Forms Mode, aby nawigować po polach i słuchać ogłaszania pól. Porównaj to z instrukcjami na poziomie formularza, które używają koloru lub położenia do wskazania pól wymaganych.
7. Przetestuj w trybach wysokiego kontrastu i ciemnym: Przełącz system operacyjny w tryb wysokiego kontrastu i przeładuj stronę. Instrukcje zakodowane kolorami, które odnoszą się do konkretnych kolorów, mogą stać się niejednoznaczne lub niewidoczne, gdy sposób renderowania kolorów się zmienia. Pomaga to ujawnić ukryte poleganie na kolorze jako jedynym wskaźniku sensorycznym.
8. Przetestuj w widoku mobilnym z powiększeniem lub przeformatowaniem: Zmień rozmiar okna przeglądarki do szerokości 320px lub użyj urządzenia mobilnego. Instrukcje używające języka położenia, takie jak „lewy pasek boczny” czy „górna nawigacja”, powinny nadal być sensowne, gdy układ zostanie przeformatowany do pojedynczej kolumny.

Jak Naprawić

Instrukcje pól formularza oparte wyłącznie na kolorze — Niepoprawne

<p>Fields shown in red are required.</p>
<label for='email'>Email Address</label>
<input type='email' id='email' style='border-color: red;' />
<label for='phone'>Phone Number</label>
<input type='tel' id='phone' />

Instrukcje pól formularza oparte wyłącznie na kolorze — Poprawne

<!-- The instruction now uses a text marker AND color, not color alone.
     The asterisk and the word "required" provide non-sensory identification. -->
<p>Fields marked with an asterisk (*) are required.</p>
<label for='email'>Email Address <span aria-hidden='true'>*</span></label>
<input type='email' id='email' aria-required='true' />
<label for='phone'>Phone Number</label>
<input type='tel' id='phone' />

Odniesienie do przycisku oparte wyłącznie na położeniu — Niepoprawne

<p>To save your work, click the button on the right side of the toolbar.</p>
<div class='toolbar'>
  <button type='button'>Undo</button>
  <button type='button'>Redo</button>
  <button type='button'>Save</button>
</div>

Odniesienie do przycisku oparte wyłącznie na położeniu — Poprawne

<!-- The instruction now references the button by its visible text label "Save",
     which matches the button's accessible name. Position is still mentioned
     but is no longer the sole identifier. -->
<p>To save your work, click the <strong>Save</strong> button (located on the right side of the toolbar).</p>
<div class='toolbar'>
  <button type='button'>Undo</button>
  <button type='button'>Redo</button>
  <button type='button'>Save</button>
</div>

Nawigacja ikoną oparta wyłącznie na kształcie — Niepoprawne

<p>Tap the circular icon to return to the home screen.</p>
<nav>
  <button type='button' class='icon-home'>
    <img src='home-circle.svg' alt='' />
  </button>
</nav>

Nawigacja ikoną oparta wyłącznie na kształcie — Poprawne

<!-- The button now has an accessible name via aria-label.
     The instruction references "Home" by name, not just by shape. -->
<p>Tap the <strong>Home</strong> button (the circular icon) to return to the home screen.</p>
<nav>
  <button type='button' class='icon-home' aria-label='Home'>
    <img src='home-circle.svg' alt='' />
  </button>
</nav>

Wskazówka postępu oparta wyłącznie na dźwięku — Niepoprawne

<p>Listen for the beep to know when the upload is complete.</p>
<button type='button' id='upload-btn'>Upload File</button>
<audio id='complete-chime' src='chime.mp3'></audio>

Wskazówka postępu oparta wyłącznie na dźwięku — Poprawne

<!-- A visible and screen-reader-accessible status message supplements the audio cue.
     Deaf users and users in silent environments now receive the same information. -->
<p>When the upload is complete, you will hear a chime and a <strong>"Upload Complete"</strong> message will appear below.</p>
<button type='button' id='upload-btn'>Upload File</button>
<div role='status' aria-live='polite' id='upload-status'></div>
<audio id='complete-chime' src='chime.mp3'></audio>
<!-- JavaScript sets #upload-status text to "Upload Complete" on success -->

Typowe Błędy

• Zapisywanie „czerwony przycisk” lub „zielone pole” jako jedynego identyfikatora w instrukcjach formularza lub tekście pomocy, bez podania widocznej etykiety przycisku lub nazwy pola — narusza to zarówno 1.3.3, jak i 1.4.1.
• Używanie zwrotów pozycyjnych, takich jak „menu po lewej” lub „panel u góry” w dokumentacji pomocy lub ścieżkach wdrożeniowych bez nazwania menu lub panelu, co sprawia, że instrukcje stają się bezużyteczne po przeformatowaniu responsywnym układu do pojedynczej kolumny.
• Opisywanie ikon wyłącznie przez kształt („kliknij trójkątny przycisk odtwarzania”) zamiast używania dostępnej nazwy lub etykiety ikony, którą użytkownik czytnika ekranu mógłby faktycznie zlokalizować za pomocą nawigacji klawiaturą.
• Wskazywanie wymaganych pól formularza wyłącznie poprzez kolor obramowania lub tła w instrukcjach wbudowanych („pola pomarańczowe muszą być wypełnione”) bez symbolu, sufiksu etykiety lub atrybutu aria-required='true', który przekazywałby tę samą informację programistycznie.
• Umieszczanie informacji zwrotnej opartej wyłącznie na dźwięku dla procesów interaktywnych (przesyłanie plików, wysyłanie formularzy, upływ czasu) bez odpowiadającej jej widocznej aktualizacji statusu tekstowego z użyciem role='status' lub aria-live='polite'.
• Używanie rozmiaru jako jedynej wskazówki wyróżniającej — instrukcje typu „kliknij duży kafelek, aby rozwinąć” zawodzą, gdy użytkownik powiększa widok, gdy kafelki renderują się w identycznym rozmiarze na mniejszych viewportach lub gdy użytkownik czytnika ekranu nie ma pojęcia o względnych rozmiarach kafelków w DOM.
• Poleganie na wskazówkach dotyczących orientacji, takich jak „przesuń poziomo, aby nawigować”, bez zapewnienia alternatywnej metody interakcji i niesensorycznej etykiety dla opisywanego karuzela lub suwaka.
• Zapominanie, że komunikaty o błędach również są instrukcjami — błąd mówiący „poniższe wyróżnione pola zawierają błędy” opiera się na wizualnym wyróżnieniu i bliskości położenia, i będzie bezużyteczny dla użytkownika czytnika ekranu, chyba że każde błędne pole zostanie również nazwane wprost w komunikacie o błędzie.
• Zakładanie, że dodanie tekstu alternatywnego ikonie rozwiązuje problem instrukcji — jeśli tekst instrukcji nadal mówi tylko „kliknij okrągłą ikonę”, fakt, że ikona ma tekst alternatywny w elemencie obrazu, nie sprawia, że sama instrukcja jest zgodna; tekst instrukcji musi zawierać niesensoryczny identyfikator.
• Pomijanie dynamicznie wstrzykiwanych instrukcji w aplikacjach jednostronicowych — dymki podpowiedzi, okna modalne i kroki kreatorów wstrzykiwane przez JavaScript często zawierają wskazówki oparte wyłącznie na cechach sensorycznych, które umykają kontroli QA, ponieważ nie są widoczne w statycznym audycie strony.

Związek z Tureckimi Regulacjami Dotyczącymi Dostępności

Prezydencki okólnik Turcji 2025/10, opublikowany w Dzienniku Urzędowym nr 32933 w dniu 21 czerwca 2025 r., ustanawia obowiązkowe wymagania dotyczące dostępności stron internetowych dla szerokiego zakresu podmiotów publicznych i prywatnych działających w Turcji. Okólnik nakazuje zgodność z WCAG 2.1 na poziomie AA jako standardem bazowym, a WCAG 1.3.3 — jako kryterium poziomu A — jest zatem w pełni obowiązkowe dla wszystkich objętych podmiotów.

Podmioty objęte okólnikiem obejmują instytucje i agencje publiczne, platformy e-commerce, banki i instytucje finansowe, szpitale i świadczeniodawców opieki zdrowotnej, firmy telekomunikacyjne z 200,000 lub większą liczbą abonentów, biura podróży, prywatne firmy transportowe oraz szkoły prywatne upoważnione przez Ministerstwo Edukacji Narodowej (MoNE). Instytucje publiczne muszą osiągnąć pełną zgodność w ciągu roku od daty publikacji okólnika, podczas gdy podmiotom sektora prywatnego przyznano dwuletnie okno czasowe.

WCAG 1.3.3 ma szczególne znaczenie dla tureckich usług cyfrowych, biorąc pod uwagę powszechne stosowanie kolorowych wskazówek w formularzach i nawigacji opartej wyłącznie na ikonach w tureckich portalach e-administracji, aplikacjach bankowych i przepływach realizacji zamówień w e-commerce. Na przykład formularz wniosku online instytucji publicznej, który instruuje obywateli, aby „wypełnili pola oznaczone na czerwono” i wysłali wniosek, „naciskając przycisk w prawym dolnym rogu”, byłby w bezpośrednim naruszeniu 1.3.3 i stanowiłby brak zgodności z prezydenckim okólnikiem. Podobnie, mobilny interfejs webowy banku, który prowadzi użytkowników przez wieloetapowe transakcje, używając wyłącznie wskazówek dotyczących położenia i koloru, musiałby zostać zmieniony przed upływem dwuletniego terminu dla sektora prywatnego.

Brak zgodności wiąże się z ryzykiem reputacyjnym i prawnym, w miarę jak środowisko regulacyjne Turcji w zakresie dostępności cyfrowej dojrzewa. Podmioty objęte przepisami powinny traktować zgodność z 1.3.3 nie jako drobną poprawkę redakcyjną, lecz jako systemowy przegląd całej treści instruktażowej — w tym tekstów pomocy, komunikatów o błędach, ścieżek wdrożeniowych i dokumentacji wsparcia — aby zapewnić, że odniesieniom sensorycznym zawsze towarzyszą stabilne, programistyczne, tekstowe identyfikatory. Nakładkowy SDK Accsible może pomóc w ujawnianiu i naprawianiu wielu powiązanych problemów, choć manualny przegląd treści wymagany przez 1.3.3 musi ostatecznie zostać przeprowadzony przez wykwalifikowanego audytora–człowieka współpracującego z narzędziami automatycznymi.