Dokumentacja Wytyczne WCAG Kryteria sukcesu WCAG WCAG 1.3.3: Cechy sensoryczne

WCAG 1.3.3: Cechy sensoryczne

Kryterium sukcesu WCAG 1.3.3 Cechy sensoryczne dotyczy sposobu przekazywania informacji na stronach internetowych i w aplikacjach. Jego głównym celem jest zapewnienie, że żadna informacja nie będzie przekazywana wyłącznie za pomocą cech sensorycznych, takich jak kształt, rozmiar, położenie wizualne, orientacja lub dźwięk. Zamiast tego, muszą być dostępne alternatywne sposoby zrozumienia tej informacji, zazwyczaj poprzez tekst lub programowe określenie.

Kryterium to jest częścią Wytycznej 1.3: Adaptable (Adaptowalność), która z kolei jest częścią Zasady 1: Perceivable (Postrzegalność). Oznacza to, że użytkownicy muszą mieć możliwość dostosowania prezentacji treści, aby mogli ją postrzegać w sposób, który najlepiej odpowiada ich potrzebom i preferencjom, niezależnie od ich ograniczeń.

Dlaczego to ważne? (Wpływ na dostępność)

Informacje przekazywane wyłącznie za pomocą cech sensorycznych mogą być niezrozumiałe lub niedostępne dla wielu grup użytkowników. Niespełnienie tego kryterium tworzy bariery dla:

Osób niewidomych lub słabowidzących: Użytkownicy polegający na czytnikach ekranu nie otrzymają informacji, jeśli jest ona przekazywana tylko kolorem, kształtem, rozmiarem czy położeniem wizualnym. Czytniki ekranu nie interpretują takich wizualnych atrybutów automatycznie.
Osób z dysfunkcjami poznawczymi lub trudnościami w uczeniu się: Mogą mieć trudności z zapamiętywaniem lub interpretacją informacji opartych wyłącznie na położeniu wizualnym, złożonych kształtach lub orientacji. Potrzebują jasnych, tekstowych instrukcji.
Osób niesłyszących lub słabosłyszących: Informacje przekazywane wyłącznie dźwiękiem są dla nich niedostępne. Konieczne są alternatywy tekstowe (np. transkrypcje, napisy).
Osób z trudnościami w postrzeganiu kolorów (daltonizm): Jeśli kolor jest jedynym sposobem rozróżnienia informacji (np. czerwony = błąd, zielony = sukces), osoby te mogą nie być w stanie poprawnie zinterpretować znaczenia.
Osób korzystających z powiększenia ekranu: Przy dużym powiększeniu, położenie wizualne elementów może stać się mylące lub niemożliwe do śledzenia w kontekście całej strony.

Zapewnienie alternatywnych, nietekstowych lub programowych sposobów przekazywania informacji pozwala na elastyczne i adaptowalne dostarczanie treści, co jest fundamentem dostępności.

Kryteria sukcesu i wymagania

WCAG 1.3.3 Cechy sensoryczne (poziom A): Instrukcje dostarczone do zrozumienia treści nie mogą opierać się wyłącznie na cechach sensorycznych komponentów, takich jak kształt, rozmiar, położenie wizualne, orientacja lub dźwięk.

Kluczowe jest słowo „wyłącznie”. Oznacza to, że używanie tych cech jest dozwolone, a nawet często pożądane, pod warunkiem, że zawsze istnieje dodatkowa, nietekstowa lub programowo dostępna alternatywa, która przekazuje tę samą informację. Ta alternatywa może być tekstem, ikoną z etykietą tekstową, czy też informacją przekazaną za pomocą atrybutów ARIA.

Praktyczne wskazówki dotyczące zgodności

Kolor: Nigdy nie używaj koloru jako jedynego środka do przekazania informacji. Zawsze dodaj element tekstowy, ikonę, wzór lub symbol, aby informacja była dostępna dla osób z daltonizmem lub korzystających z czytników ekranu.
Kształt i rozmiar: Jeśli interaktywne elementy różnią się tylko kształtem lub rozmiarem, dodaj do nich etykiety tekstowe lub dostępne dla czytników ekranu nazwy. Unikaj instrukcji typu „kliknij duży okrągły przycisk” bez dalszego kontekstu.
Położenie wizualne i orientacja: Unikaj instrukcji typu „kliknij na prawy przycisk”, „zobacz tabelę po lewej stronie” lub „instrukcje są w górnym rogu strony”. Zamiast tego, odwołuj się do konkretnych etykiet tekstowych lub elementów nawigacyjnych, np. „kliknij przycisk 'Zapisz’”, „zobacz tabelę 'Stan zamówienia’”, „instrukcje znajdziesz w sekcji 'Pomoc’”.
Dźwięk: Jeśli dźwięk przekazuje istotną informację (np. alert o błędzie, powiadomienie), zawsze zapewnij wizualny (tekstowy) odpowiednik, taki jak komunikat na ekranie, wibracja lub zmiana stanu interfejsu.

Przykłady implementacji

1. Kolor i tekst

Nieprawidłowa implementacja: Informacja przekazana tylko kolorem.

<style>
  .error { color: red; }
  .success { color: green; }
</style>
<p class="error">Wystąpił błąd.</p>
<p class="success">Operacja zakończona sukcesem.</p>

Problem: Osoby z daltonizmem lub niewidome nie otrzymają informacji o typie komunikatu.

Prawidłowa implementacja: Kolor jest uzupełniony tekstem lub ikoną.

<style>
  .error { color: red; font-weight: bold; }
  .success { color: green; font-weight: bold; }
</style>
<p class="error"><span role="img" aria-label="Błąd:">❌</span> Wystąpił błąd.</p>
<p class="success"><span role="img" aria-label="Sukces:">✅</span> Operacja zakończona sukcesem.</p>
<!-- LUB -->
<p>Status: <span style="color: red;">Błąd</span></p>

2. Instrukcje dla pól formularza

Nieprawidłowa implementacja: Poleganie na wizualnym położeniu i kolorze.

<label for="email">E-mail:</label>
<input type="email" id="email">
<p style="color: red;">Proszę podać poprawny adres e-mail.</p>

Problem: Komunikat błędu jest wizualnie związany z polem, ale nie jest programowo powiązany. Brak alternatyw dla koloru.

Prawidłowa implementacja: Użycie aria-describedby i dodatkowego symbolu.

<style>
  .error-message {
    color: red;
    font-weight: bold;
    margin-top: 5px;
  }
  .visually-hidden {
    position: absolute;
    width: 1px;
    height: 1px;
    margin: -1px;
    border: 0;
    padding: 0;
    white-space: nowrap;
    overflow: hidden;
    clip: rect(0 0 0 0);
  }
</style>

<label for="email">E-mail <span class="required" aria-hidden="true">*</span>:</label>
<input type="email" id="email" aria-invalid="true" aria-describedby="email-error">
<p id="email-error" class="error-message" role="alert">
  <span class="visually-hidden">Błąd: </span>Proszę podać poprawny adres e-mail.
</p>

3. Instrukcje nawigacyjne

Nieprawidłowa implementacja: Poleganie na położeniu wizualnym.

<p>Aby przejść do koszyka, kliknij ikonę w prawym górnym rogu strony.</p>
<img src="cart-icon.png" alt="" style="float: right;">

Problem: Użytkownicy czytników ekranu lub osoby z trudnościami w postrzeganiu wzrokowym nie znajdą „ikony w prawym górnym rogu”. Atrybut alt="" dla obrazka czyni go ignorowanym.

Prawidłowa implementacja: Konkretne odwołanie tekstowe.

<p>Aby przejść do koszyka, kliknij ikonę <strong>"Mój koszyk"</strong>.</p>
<a href="/cart">
  <img src="cart-icon.png" alt="Mój koszyk">
  <span class="visually-hidden">Mój koszyk</span>
</a>
<!-- LUB prostsze, używając przycisku z etykietą -->
<button type="button" onclick="location.href='/cart'">
  <img src="cart-icon.png" alt=""> Mój koszyk
</button>

4. Alert dźwiękowy

Nieprawidłowa implementacja: Tylko dźwięk informuje o zdarzeniu.

<script>
  function playAlertSound() {
    new Audio('alert.mp3').play();
  }
  // Funkcja playAlertSound() wywoływana jest np. po upływie sesji użytkownika
</script>

Problem: Osoby niesłyszące lub słabosłyszące przegapią alert. Użytkownicy wyłączający dźwięk również.

Prawidłowa implementacja: Dźwięk jest uzupełniony wizualnym komunikatem.

<div id="status-message" role="alert" aria-live="assertive" style="display: none; padding: 10px; background-color: yellow; color: black;"></div>

<script>
  function showAlert(message) {
    const statusMessage = document.getElementById('status-message');
    statusMessage.textContent = message;
    statusMessage.style.display = 'block';
    // Dodatkowo odtwórz dźwięk
    new Audio('alert.mp3').play();
    // Można również dodać focus, aby czytnik ekranu natychmiast odczytał komunikat
    statusMessage.focus();
  }

  // Przykładowe wywołanie
  // showAlert('Twoja sesja wygasła. Zaloguj się ponownie.');
</script>

Najlepsze praktyki i typowe pułapki

Najlepsze praktyki:

Redundancja informacji: Zawsze dostarczaj informacje na więcej niż jeden sposób. Kolor może być używany do wzmocnienia przekazu, ale nigdy jako jedyny sposób.
Używaj semantycznego HTML: Poprawne użycie elementów <label>, <button>, <a>, <input> automatycznie pomaga w dostępności.
Atrybuty ARIA: W sytuacjach, gdy standardowy HTML jest niewystarczający, używaj atrybutów ARIA (np. aria-describedby, aria-label, role="alert") do programowego wzmocnienia informacji.
Testowanie: Regularnie testuj swoją stronę za pomocą czytników ekranu i innych technologii wspomagających. Symuluj różne formy niepełnosprawności, aby upewnić się, że wszystkie informacje są dostępne.
Jasne i konkretne instrukcje: Zamiast „kliknij tutaj”, użyj „kliknij przycisk 'Dodaj do koszyka’”.

Typowe pułapki:

Poleganie na ikonach bez etykiet: Same ikony mogą być niezrozumiałe, jeśli nie mają towarzyszącego tekstu lub atrybutu aria-label.
Instrukcje nawigacyjne oparte na pozycji: „Szukaj menu po lewej stronie” jest problematyczne; lepiej „Szukaj menu nawigacyjnego”.
CAPTCHA oparte wyłącznie na obrazie/dźwięku: Zawsze zapewnij wiele metod weryfikacji, np. tekstowe CAPTCHA, dźwiękowe CAPTCHA z transkrypcją, alternatywy oparte na zadaniach lub reCAPTCHA.
Brak tekstowych odpowiedników dla mediów: Filmy bez napisów lub audiodeskrypcji, podcasty bez transkrypcji.

Zgodność z WCAG 1.3.3 wymaga świadomego projektowania i kodowania, które stawia na pierwszym miejscu możliwość postrzegania treści przez wszystkich użytkowników, niezależnie od ich indywidualnych cech sensorycznych.