WCAG 5.2.4: Tylko sposoby korzystania z technologii wspierające dostępność

Tylko sposoby korzystania z technologii wspierające dostępność

Wprowadzenie

Zasada używania "technologii wspierających dostępność" jest fundamentalnym elementem spełnienia wymagań WCAG (Wytyczne dla Dostępności Treści Internetowych). Nie jest to pojedyncze kryterium sukcesu, lecz kluczowy wymóg zgodności, który stanowi podstawę dla wszystkich innych kryteriów. Oznacza to, że aby treści internetowe mogły być uznane za zgodne z WCAG, muszą być stworzone przy użyciu technologii, które są obsługiwane i interpretowane w przewidywalny sposób przez technologie wspomagające (AT) użytkowników oraz funkcje dostępności przeglądarek i systemów operacyjnych.

Krótko mówiąc, nawet najlepiej zaprojektowane elementy interfejsu mogą stać się niedostępne, jeśli technologia, na której się opierają, nie jest rozumiana przez narzędzia, których używają osoby z niepełnosprawnościami. Celem tego wymogu jest zapewnienie, że wysiłki włożone w tworzenie dostępnych treści faktycznie przełożą się na pozytywne doświadczenia użytkowników końcowych.

Czym jest technologia wspierająca dostępność?

Zgodnie z definicją WCAG, technologia (lub sposób jej użycia) jest wspierająca dostępność, jeśli:

• jest obsługiwana przez technologie wspomagające użytkownika (AT) (np. czytniki ekranu, oprogramowanie do rozpoznawania mowy, lupy ekranowe) oraz funkcje dostępności w przeglądarkach i systemach operacyjnych;
• jest szeroko dostępna dla użytkowników.

W praktyce oznacza to, że standardowe technologie internetowe, takie jak HTML, CSS i JavaScript, są ogólnie uważane za wspierające dostępność, pod warunkiem że są używane zgodnie z najlepszymi praktykami dostępności (np. semantyczny HTML, poprawne użycie ARIA, obsługa klawiatury). Problemem nie jest często sama technologia, lecz jej implementacja, która może pomijać aspekty dostępności.

Dlaczego to jest ważne?

Znaczenie korzystania z technologii wspierających dostępność jest kluczowe dla zapewnienia prawdziwie uniwersalnego dostępu do treści cyfrowych. Niespełnienie tego wymogu może prowadzić do całkowitej blokady dostępu dla wielu grup użytkowników.

Wpływ na dostępność

• Brak interakcji z technologiami wspomagającymi: Gdy strona używa technologii, której czytnik ekranu nie potrafi zinterpretować, informacje stają się niewidoczne, a interakcje niemożliwe. Użytkownik nie wie, że element istnieje lub jak z nim współdziałać.
• Brak obsługi standardowych funkcji dostępności: Niektóre technologie mogą ignorować wbudowane funkcje dostępności przeglądarek, takie jak powiększanie tekstu, tryb wysokiego kontrastu czy nawigacja za pomocą klawiatury, co utrudnia lub uniemożliwia korzystanie z nich osobom o różnych potrzebach.
• Fragmentacja doświadczenia: Użycie wielu różnych, słabo wspieranych technologii na jednej stronie może prowadzić do niespójnego i frustrującego doświadczenia, gdzie niektóre części strony działają, a inne nie.

Grupy użytkowników, których dotyczy problem

• Osoby niewidome i niedowidzące: Osoby niewidome i niedowidzące: Korzystają z czytników ekranu, lup ekranowych i innych technologii wspomagających. Brak odpowiedniego wsparcia uniemożliwia im korzystanie z treści.
• Osoby z niepełnosprawnością ruchową: Często korzystają z klawiatury, specjalistycznych myszy, przełączników lub sterowania głosowego. Technologie niewspierające dostępności mogą blokować nawigację lub interakcję.
• Osoby z niepełnosprawnością poznawczą: Potrzebują spójnych i przewidywalnych interfejsów, które działają zgodnie ze standardami. Niespójne zachowanie może prowadzić do dezorientacji.
• Wszyscy użytkownicy: Stosowanie technologii wspierających dostępność sprawia, że strony są bardziej niezawodne, zgodne ze standardami i łatwiejsze w utrzymaniu, co poprawia ogólne doświadczenie użytkownika.

Wymagania i Kryteria Sukcesu

Jak wspomniano, "Tylko sposoby korzystania z technologii wspierające dostępność" nie jest jednym z numerowanych Kryteriów Sukcesu WCAG 2.0 lub 2.1, ale kluczowym wymogiem zgodności (ang. Conformance Requirement). Jest to drugi z pięciu wymogów zgodności, określony w sekcji 5.2 Zgodność (Conformance) (otwiera nową kartę), zatytułowany "Accessibility-Supported Only" (Tylko technologia wspierająca dostępność).

Wymóg ten stwierdza:

Technologie wspierające dostępność. Cała informacja i funkcjonalność na stronie internetowej, która jest niezbędna do spełnienia kryteriów sukcesu, musi być dostarczana w sposób wykorzystujący technologie wspierające dostępność. (Jeśli technologia niewspierająca dostępności jest używana, musi być dostępna alternatywa wspierająca dostępność.)

Oznacza to, że jeśli jakaś część treści lub funkcjonalności Twojej strony jest niezbędna do spełnienia kryterium sukcesu (np. tekst alternatywny dla obrazu, etykieta formularza, nawigacja klawiaturowa), to musi być ona dostarczona przy użyciu technologii, która jest obsługiwana przez technologie wspomagające.

Jeśli korzystasz z technologii niedostępnej dla wszystkich użytkowników (np. przestarzałego apletu Java czy niestandardowego odtwarzacza wideo bez dostępnych kontrolerów), należy zapewnić alternatywną wersję tej samej informacji lub funkcjonalności, która będzie w pełni dostępna.alternatywną wersję tej samej informacji lub funkcjonalności, która jest dostępna i wspierająca dostępność.

Praktyczne wskazówki dla zachowania zgodności

Aby upewnić się, że Twoje treści spełniają wymóg korzystania z technologii wspierających dostępność, zastosuj poniższe praktyki:

• Preferuj standardowe technologie sieciowe: Używaj HTML, CSS i JavaScript, ponieważ są one najszerzej wspierane przez przeglądarki i technologie wspomagające.
• Używaj semantycznego HTML: Wykorzystuj odpowiednie elementy HTML (np. <button> zamiast <div role="button">, <h1>-<h6> dla nagłówków, <nav> dla nawigacji, <form> i <label> dla formularzy). Semantyka jest kluczowa dla AT.
• Właściwie stosuj WAI-ARIA: Jeśli tworzysz niestandardowe komponenty UI, które nie mają natywnego odpowiednika w HTML, używaj atrybutów WAI-ARIA (np. role, aria-label, aria-labelledby, aria-describedby, aria-haspopup, aria-expanded) zgodnie z wytycznymi WAI-ARIA Authoring Practices Guide (otwiera nową kartę).
• Zapewnij pełną obsługę klawiatury: Wszystkie interaktywne elementy muszą być dostępne i obsługiwane wyłącznie za pomocą klawiatury.
• Testuj z technologiami wspomagającymi: Regularnie testuj swoją stronę z różnymi czytnikami ekranu (np. NVDA, JAWS, VoiceOver), powiększalnikami ekranu i innymi AT, aby upewnić się, że wszystko działa zgodnie z oczekiwaniami.
• Unikaj przestarzałych lub egzotycznych technologii: Staraj się nie polegać na wtyczkach (np. Flash, Silverlight) lub niestandardowych frameworkach, które mają ograniczone wsparcie dla dostępności lub nie są szeroko rozpowszechnione.
• Zapewnij alternatywy: Jeśli musisz użyć technologii niedostępnej dla wszystkich użytkowników, zawsze udostępniaj równoważną treść lub funkcjonalność w formie dostępnej (np. transkrypcję wideo, dokument PDF zamiast interaktywnej animacji).

Przykłady implementacji

Poniższe przykłady ilustrują różnicę między użyciem technologii wspierających i niewspierających dostępność.

Przykład poprawny: Semantyczny HTML i dostępne komponenty

Użycie standardowych elementów HTML i JavaScript do dodawania funkcjonalności jest najlepszym sposobem na zapewnienie wsparcia dla dostępności.

<!-- Poprawny przycisk używający natywnego elementu HTML -->
<button type="button" onclick="alert('Przycisk kliknięty!')">
  Kliknij mnie
</button>

<!-- Poprawny formularz z etykietami -->
<form>
  <label for="username">Nazwa użytkownika:</label>
  <input type="text" id="username" name="username" aria-required="true">

  <label for="password">Hasło:</label>
  <input type="password" id="password" name="password">

  <button type="submit">Zaloguj</button>
</form>

<!-- Rozwijane menu z użyciem ARIA -->
<nav>
  <button type="button" aria-expanded="false" aria-controls="menu-list" id="menu-button">Menu</button>
  <ul id="menu-list" role="menu" aria-labelledby="menu-button" hidden>
    <li role="none"><a href="#" role="menuitem">Link 1</a></li>
    <li role="none"><a href="#" role="menuitem">Link 2</a></li>
  </ul>
</nav>
<script>
  const menuButton = document.getElementById('menu-button');
  const menuList = document.getElementById('menu-list');

  menuButton.addEventListener('click', () => {
    const expanded = menuButton.getAttribute('aria-expanded') === 'true';
    menuButton.setAttribute('aria-expanded', !expanded);
    menuList.hidden = expanded;
  });

  // Dodatkowo, obsługa klawiatury dla nawigacji w menu.
  // W pełnej implementacji powinna być uwzględniona.
</script>
Skopiuj tekst

Przykład niepoprawny: Niewspierane technologie lub niepoprawne użycie

Unikaj tych wzorców, ponieważ mogą one sprawić, że treść będzie niedostępna.

<!-- Niewłaściwy "przycisk" bez semantyki, ról ARIA i obsługi klawiatury -->
<div onclick="alert('Kliknięto!')" style="cursor: pointer; padding: 10px; border: 1px solid #ccc;">
  Kliknij mnie
</div>

<!-- Formularz bez etykiet, polegający na placeholderach -->
<form>
  <input type="text" placeholder="Nazwa użytkownika">
  <input type="password" placeholder="Hasło">
  <div onclick="submitForm()">Zaloguj</div>
</form>

<!-- Niestandardowy odtwarzacz wideo bez dostępnych kontrolerów -->
<object data="video.swf" type="application/x-shockwave-flash" width="400" height="300">
  <!-- Brak alternatywnego tekstu lub dostępnego odtwarzacza HTML5 -->
</object>
Skopiuj tekst

Najlepsze praktyki i typowe pułapki

Najlepsze praktyki

• Zawsze zaczynaj od semantycznego HTML: To najsilniejszy fundament dostępności. Natywne elementy HTML mają wbudowane role, stany i właściwości, które są automatycznie interpretowane przez technologie wspomagające.
• Stosuj progresywne ulepszanie: Twórz podstawową funkcjonalność za pomocą czystego HTML, a następnie dodawaj CSS i JavaScript w celu wzbogacenia doświadczenia, upewniając się, że podstawowa funkcjonalność pozostaje dostępna.
• Korzystaj z WAI-ARIA tylko wtedy, gdy jest to absolutnie konieczne: "Pierwszą zasadą ARIA" jest: "Jeśli możesz użyć natywnego elementu HTML lub atrybutu o wymaganej semantyce i zachowaniu, zamiast duplikować tę semantykę i zachowanie za pomocą ARIA, zrób to."
• Przeprowadzaj testy z różnymi przeglądarkami i AT: Dostępność może różnić się w zależności od kombinacji przeglądarki i technologii wspomagającej. Testowanie jest kluczowe.
• Monitoruj wsparcie dla nowych technologii: Przed wdrożeniem nowych frameworków, bibliotek JavaScript lub funkcji przeglądarki, sprawdź ich stan wsparcia dla dostępności.

Typowe pułapki

• Używanie divów i spanów zamiast semantycznych elementów: Tworzenie niestandardowych kontrolek bez odpowiednich ról ARIA i obsługi klawiatury (np. <div> jako przycisk, <span> jako link).
• Nadmierne poleganie na ARIA: Nieprawidłowe lub nadmierne użycie ARIA może faktycznie pogorszyć dostępność, zamiast ją poprawić. ARIA powinna być używana jako uzupełnienie, a nie zamiennik dla semantycznego HTML.
• Brak obsługi klawiatury: Tworzenie interaktywnych elementów, które można obsługiwać tylko myszką, całkowicie blokuje dostęp dla osób niekorzystających z myszy.
• Używanie przestarzałych wtyczek bez alternatyw: Wtyczki takie jak Flash lub Silverlight są często niedostępne i wymagają zapewnienia w pełni funkcjonalnych, dostępnych alternatyw.
• Ignorowanie dynamicznie generowanej treści: Treść ładowana dynamicznie przez JavaScript musi być również zaimplementowana w sposób wspierający dostępność i ogłoszona dla czytników ekranu (np. za pomocą aria-live).

Dodatkowe zasoby

• WCAG 2.1: Zrozumienie Zgodności (Conformance) (otwiera nową kartę)
• WAI-ARIA Authoring Practices Guide (APG) (otwiera nową kartę)
• WCAG 2.1: Definicja "Accessibility Supported" (w j. angielskim) (otwiera nową kartę)