WCAG 2.2: Kompleksowy przewodnik po dostępności cyfrowej

Artykuł stanowi przegląd wytycznych dostępności treści internetowych WCAG 2.2. Zawiera praktyczne aspekty implementacji standardów inkluzywności cyfrowej, w tym m.in.: reguły nawigacji strukturalnej, wykorzystanie narzędzi i czytników ekranowych, a także tworzenie dostępnych dokumentów w pakiecie Microsoft Office. Szczególną uwagę zwróciłem na przykłady implementacji dostępności w kodzie HTML z wykorzystaniem specyfikacji WAI-ARIA.

Wprowadzenie

Web Content Accessibility Guidelines (WCAG) to międzynarodowy standard opracowany przez World Wide Web Consortium (W3C), który definiuje sposoby tworzenia treści internetowych dostępnych dla osób z niepełnosprawnościami.^{[1, 2]} Standard ten ewoluował przez lata, od wersji WCAG 1.0 wydanej w 1999 roku, przez WCAG 2.0 (2008), WCAG 2.1 (2018), aż do najnowszej wersji WCAG 2.2 wydanej w październiku 2023 roku.^[3–^6]

WCAG opiera się na czterech fundamentalnych zasadach, znanych jako POUR:

Perceivable (postrzegalność),
Operable (funkcjonalność),
Understandable (zrozumiałość),
Robust (solidność).^{[1, 7, 8]}

Standard definiuje trzy poziomy zgodności:

A (minimalny),
AA (akceptowalny),
AAA (optymalny).^{[3, 9]}

Ryc. 1 Wizualna reprezentacja czterech zasad WCAG – POUR

Poziom AA obejmuje podmioty publiczne, tj.: organy administracji publicznej, jednostki samorządu terytorialnego, instytucje kultury, szkoły i uczelnie publiczne oraz sądy i inne instytucje wykonujące zadania publiczne.^[10] Natomiast od 28 czerwca 2025, poziom AA obejmuje również podmioty prywatne w całej Unii Europejskiej, w tym m.in.: e-commerce, banki i dostawców usług płatniczych, producentów, importerów, dystrybutorów, usługi transportu pasażerskiego online, operatorów telefonii i komunikatorów.^{[10, 11]} Nie podlegają temu mikroprzedsiębiorstwa.^[11] Obowiązek ten wynika z implementacji Europejskiego Aktu o Dostępności (EAA), który rozszerza dostępność cyfrową na sektor prywatny obok sektora publicznego.^{[10, 11]}

Znaczenie dostępności cyfrowej stale rośnie – według Światowej Organizacji Zdrowia ponad 2,2 mld ludzi na świecie ma jakąś formę niepełnosprawności wzroku.^{[12, 13]} Natomiast ok. 36 mln ludzi jest niewidomych.^[14] W związku z tym, coraz więcej krajów wprowadza przepisy prawne wymagające zgodności z WCAG, jak na przykład nowe przepisy ADA Title II w Stanach Zjednoczonych, które wejdą w życie w 2026 roku.^{[15, 16]}

Czytniki ekranowe i skróty klawiaturowe

Czytniki ekranowe to kluczowe narzędzia asystujące, które konwertują treść cyfrową na mowę syntetyczną lub wyświetlacz brajlowski, umożliwiając osobom niewidomym i słabowidzącym nawigację po stronach internetowych i dokumentach. Najpopularniejsze czytniki ekranowe^{[17, 18]}to:

NVDA (darmowy, dla Windows),^[19]
JAWS (komercyjny, dla Windows),^[20]
TalkBack (wbudowany w Android),^[21]
VoiceOver (wbudowany w macOS).^[22]

Podstawowe zasady nawigacji

Czytniki ekranowe wykorzystują strukturę semantyczną dokumentów do nawigacji. Użytkownicy mogą poruszać się między różnymi elementami strony, używając dedykowanych skrótów klawiaturowych, które pozwalają na szybkie przechodzenie między nagłówkami, linkami, formularzami lub tabelami (więcej na ten temat znajdziesz w rozdziale: Ważniejsze skróty klawiaturowe).^{[23, 24]}

Czytniki umożliwiają również nawigowanie po landmarkach, czyli specjalnie oznaczonych, semantycznych obszarach będących punktami nawigacyjnymi. Są nimi m.in.: <header>, <nav>, <main>, <aside> i <footer>. Korzystanie z landmarków pomaga szybko przechodzić do najważniejszych sekcji witryny bez konieczności liniowego przeglądania całej treści (więcej na ten temat znajdziesz w rozdziale: Skip linki).^{[25, 26]}

Ważniejsze skróty klawiaturowe

Efektywna nawigacja za pomocą czytnika ekranowego opiera się na znajomości podstawowych skrótów klawiaturowych. Większość komend jest uniwersalna między różnymi czytnikami.^{[23, 24]} Kluczowe jest zrozumienie, że czytniki ekranowe odczytują tylko semantycznie poprawny kod HTML. Przykładowo, jeżeli nagłówki są utworzone jedynie poprzez zwiększenie rozmiaru tekstu i pogrubienie, a nie za pomocą odpowiednich znaczników od <h1> do <h6>, czytnik nie będzie w stanie ich rozpoznać jako struktury nawigacyjnej.^[27]

Skrót klawiaturowy:

F – odszukuje najbliższy/kolejny formularz.
E – pole edycji.
X – pole wyboru.
C – pole rozwijane.
R – pole opcji (radio).
B – przyciski.
H – nagłówki (w połączeniu z klawiszami 1–6 można wskazać nagłówek konkretnego poziomu).
G – grafiki.
K – linki (U – nieodwiedzone, V – odwiedzone).
L – listy (I – elementy wewnątrz danej listy).
D – landmarki.

Nawigacja bez znajomości skrótów klawiaturowych również jest możliwa. Klawisze:

Tab i Shift+Tab – pozwalają trawersować (przechodzić) po interaktywnych elementach, takich jak m.in.: kontrolki, linki i przyciski.^[28]
Strzałki ↑ / ↓ – służą do odczytywania kolejno poprzednich/następnych elementów strony.^[25]
Strzałki ← / → – odczytują pojedyncze znaki w wybranym elemencie (np. w polach edycyjnych).^[29]

Wartości kontrastów w WCAG

Kontrast kolorów jest jednym z najważniejszych aspektów dostępności wizualnej. Odpowiedni kontrast między tekstem a tłem zapewnia czytelność treści dla osób z różnymi rodzajami niepełnosprawności wzroku, w tym daltonizmem i słabowidzeniem.^{[30, 31]} Niestety, zbyt niski kontrast nadal stanowi powszechnie występujący problem.^[32] W przypadku elementów nietekstowych jakimi są np. elementy interfejsu, grafiki lub wykresy, współczynnik kontrastu oblicza się, porównując kolor badanego elementu z kolorem przylegającym do tego elementu.^[33]

Wymagania kontrastowe według poziomów WCAG

WCAG definiuje precyzyjne wymagania dotyczące współczynników kontrastu (Ryc. 2).

Ryc. 2 Wymagania WCAG dotyczące współczynnika kontrastu na różnych poziomach zgodności dla zwykłego i dużego tekstu. Tekst duży stanowi 18 pt lub 14 pt, gdy jest pogrubiony

Poziom AA (wymagany standard):

Tekst normalny: minimum 4,5:1.
Tekst duży (18 pt lub 14 pt pogrubiony): minimum 3:1.
Elementy interfejsu i grafika: minimum 3:1.

Poziom AAA (wzmocniony standard):

Tekst normalny: minimum 7:1.
Tekst duży: minimum 4,5:1.

Narzędzia do sprawdzania kontrastu

W celu analizy kontrastu można wykorzystać darmowe narzędzia tj.: Colour Contrast Analyser,^[34] WebAIM Contrast Checker,^[30] Color Contrast Checker^[35] lub wbudowane w przeglądarki narzędzia deweloperskie.^{[36, 37]} Warto zaznaczyć, że zasady kontrastu nie dotyczą elementów nieaktywnych (np. wyszarzonych przycisków) oraz logotypów.^{[31, 38]}

Dostępne dokumenty Word

Microsoft Word oferuje szereg funkcji umożliwiających tworzenie dokumentów zgodnych z WCAG. Kluczowe jest wykorzystanie wbudowanych narzędzi dostępności oraz odpowiedniej struktury dokumentu.^{[39, 40]}

Podstawowe zasady tworzenia dostępnych dokumentów Word

Sprawdzanie dostępności:

Narzędzie „Check Accessibility” w zakładce „Review” automatycznie identyfikuje problemy z dostępnością i sugeruje rozwiązania.^{[40, 41]}

Struktura dokumentu:

Używanie predefiniowanych stylów nagłówków (Heading 1–6) zamiast ręcznego formatowania.^[39–41]
Logiczny porządek nagłówków bez pomijania poziomów.^[39–41]
Jeden nagłówek główny (Heading 1) na dokument.^{[39, 41]}
Ustawienie tytułu dokumentu we właściwościach pliku (to inny tytuł niż ten z obszaru roboczego dokumentu).^[41]

Formatowanie tekstu:

Unikanie centrowania i justowania tekstu.^[39–41]
Rezygnacja z dzielenia wyrazów.^[41]
Używanie odstępów i interlinii zamiast „enterów” do tworzenia przestrzeni w pionie (puste linie są czytane przez czytniki).^[39–41]
Jeżeli treść ma być ułożona w kolumnach, należy zastosować pionową linię, która wizualnie je oddzieli.^[42]

Elementy graficzne:

Dodawanie tekstu alternatywnego do wszystkich obrazów.^[39–41]
Oznaczanie obrazów dekoracyjnych jako „decorative”.^[39–41]
Opisywanie złożonych grafik w tekście dokumentu.^{[40, 41]}

Tabele:

Definiowanie wierszy nagłówkowych (z wybraniem opcji, która umożliwia powielenie wiersza, gdy tabela przejdzie na następną stronę).^[39–41]
Unikanie łączenia i dzielenia komórek.^[40]
Dodawanie opisów dla złożonych tabel.^[43]

Nagłówki/Stopki:

Informacje zawarte w nagłówku i stopce traktowane są jako ozdobniki.
Jeżeli nagłówek/stopka zawiera ważną informację (np. dane teleadresowe), należy skopiować ją do treści dokumentu.^[39–41]

Eksport do PDF:

Podczas eksportowania należy wybrać opcje: „Właściwości dokumentu” oraz „Tagi struktury dokumentu dla ułatwień dostępu”^[44] wraz z zaznaczeniem zgodności PDF/A.^[45]

Dostępne arkusze Excel

Excel wymaga szczególnej uwagi przy tworzeniu dostępnych arkuszy kalkulacyjnych ze względu na złożoność danych i funkcji.^{[46, 47]}

Podstawowe zasady tworzenia dostępnych arkuszy Excel

Struktura arkusza:

Umieszczanie opisu lub tytułu w komórce A1.^{[46, 47]}
Nadawanie opisowych nazw arkuszom.^[46]
Usuwanie pustych arkuszy.^[46]
Ustawienie tytułu we właściwościach pliku (to inny tytuł niż ten z obszaru roboczego arkusza).^[48]

Tabele danych:

Używanie funkcji „Format as Table” zamiast ręcznego formatowania.^[46–48]
Definiowanie nagłówków kolumn.^[46–48]
Nadawanie opisowych nazw tabelom.^{[46, 48]}
Unikanie pustych wierszy i kolumn.^{[46, 48]}

Wykresy i grafika:

Dodawanie tekstu alternatywnego do wykresów z ogólnym opisem.^[46–48]
Przedstawianie szczegółowych danych w formie tabeli (alternatywny sposób prezentacji wykresu).^[46–48]
Unikanie identyfikacji informacji wyłącznie kolorem.^[46–48]
Każda dana (linia na wykresie) powinna być opatrzona etykietą z opisem zgodnym z tym w legendzie.^{[46, 48]}
Alternatywą dla etykiety może być użycie:
- znacznika – np. kwadrat lub trójkąt reprezentujący pojedynczy punkt tworzący wykres^{[46, 48]}
- lub desenia – rodzaj wypełnienia, który pozwala odróżnić poszczególne elementy wykresu za pomocą powtarzalnych wzorów, tj.: pasków, kropek lub kratek.^[48]
Zapewnienie odpowiedniego kontrastu kolorów. W celu poprawy kontrastu można np. zastosować obramowanie, aby wyróżnić daną względem tła.^[46–48]

Formuły i zakresy:

Nadawanie nazw komórkom i zakresom w celu ułatwienia nawigacji.^[46–48]
Używanie opisowych nazw dla funkcji.^[46–48]

Eksport do PDF

Analogicznie jak w części dot. Worda.

Dostępne prezentacje PowerPoint

PowerPoint oferuje specjalne funkcje ułatwiające tworzenie prezentacji dostępnych dla wszystkich użytkowników.^[49]

Podstawowe zasady tworzenia dostępnych prezentacji

Struktura slajdów:

Każdy slajd musi mieć unikalny nagłówek.^[49]
- Przejście w „Widok konspektu” pozwala wyświetlić panel z miniaturami slajdów wraz z przypisanymi do nich nagłówkami. Bezpośrednio w tym widoku można uzupełnić brakujące nagłówki.
- Jeżeli dany slajd nie zawiera treści, nagłówek takiego slajdu należy przenieść poza obszar slajdu (na obszar roboczy). Wówczas nagłówek będzie ukryty.
Używanie layoutów zamiast pustych slajdów z polami tekstowymi.^[49]
Numerowanie slajdów w celu ułatwienia nawigacji.^[49]
Ustawienie tytułu we właściwościach pliku (to inny tytuł niż ten z obszaru roboczego prezentacji).^[50]

Formatowanie tekstu:

Czcionka sans-serif (np. Arial, Verdana) w rozmiarze minimum 28 pt dla tekstu głównego.^[49]
Nagłówki w rozmiarze 30–44 pt.^[49]
Unikanie kursywy i nadmiernej ilości tekstu na slajdzie.^[49]

Kolejność odczytu:

Sprawdzanie i dostosowywanie kolejności odczytu elementów za pomocą „Reading Order Pane”.^[51]

Multimedia/Elementy graficzne:

Dodawanie tekstu alternatywnego do obrazów.^{[49, 50]}
Oznaczanie grafik dekoracyjnych.^{[49, 50]}
Dodawanie napisów do filmów.^[52]
Unikanie automatycznego odtwarzania dźwięku.^[53]

Dostępność wizualna:

Zapewnienie silnego kontrastu między tekstem a tłem.^[49–53]
Unikanie bazowania wyłącznie na kolorze przy przekazywaniu informacji.^[49]
Używanie łagodnych przejść między slajdami.^[54]

Udostępnianie:

Analogicznie jak w części dot. Worda.

WCAG w aspekcie HTML

Semantyczny HTML stanowi fundament dostępności internetowej. Odpowiednie użycie elementów HTML sprawia, że treść jest zrozumiała zarówno dla użytkowników, jak i technologii asystujących.^{[55, 56]}

Semantyczne elementy HTML5

Landmarki strukturalne:

<header> – nagłówek strony lub sekcji.
<nav> – nawigacja główna.
<main> – główna treść strony.
<aside> – treść dodatkowa/sidebar.
<footer> – stopka dokumentu.
<section> – logiczne sekcje treści.
<article> – samodzielne artykuły.

Nagłówki i struktura:

Hierarchiczne użycie <h1> do <h6>.
Jeden <h1> na stronę.
Niepomijanie poziomów nagłówków.

Responsywna typografia

Opieranie się wyłącznie na jednostkach viewport (vw/vh) może nie spełniać kryteriów WCAG dotyczących powiększania tekstu do 200% bez wykorzystania technologii asystujących. Wskazanym podejściem jest kombinacja jednostek rem i vw, która zachowuje responsywność rozmiaru tekstu względem szerokości ekranu oraz preferencje powiększenia.^[57]

Warto w tym miejscu wspomnieć, że zaleca się używanie czcionek bezszeryfowych, ponieważ ich prosta, nieozdobiona forma jest bardziej czytelna dla osób z wadami wzroku. Do takich fontów należą m.in.: Arial, Tahoma, Helvetica i Verdana.^[58]

Dostępne formularze

Formularze wymagają szczególnej uwagi ze względu na interaktywność:

Etykiety i pola z adnotacją o wymagalności:

<label for="email"> 
  Adres e-mail 
  <span class="sr-only">wymagane</span> 
  <span aria-hidden="true">*</span> 
</label> 
<input type="email" id="email" required />

.sr-only {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  overflow: hidden;
  clip: rect(0 0 0 0);
  white-space: nowrap;
  border: 0;
}

Atrybut for="email" w <label> odpowiada id="email" w <input>, umożliwiając technologiom wspomagającym skojarzyć, że etykieta „Adres e-mail” dotyczy tego konkretnego pola.
Typ pola „email” wymusza poprawny format adresu e-mail.
Pierwszy element <span> jest niewidoczny, ale jest odczytywany przez czytnik, informując o tym, że pole jest wymagane.
Drugi element <span> jest widoczny, jednak jest on ignorowany przez technologie asystujące.

Grupy pól:

<fieldset>
  <legend>Dane osobowe</legend>
  <!-- pola formularza -->
</fieldset>

<fieldset> grupuje powiązane pola formularza w logiczną całość. Z kolei, <legend> opisuje, czego dotyczy dana grupa pól.
Czytniki anonsują <legend> jako nagłówek grupy pól, dzięki czemu użytkownicy mają lepszy kontekst, do czego dane pole należy.

Komunikaty błędów:

<input type="email" id="email" required aria-describedby="error-email" />
<div role="alert" id="error-email">
  Proszę podać prawidłowy adres e-mail
</div>

role="alert" to rola ARIA (opisana szerzej w rozdziale WAI-ARIA), która powoduje automatyczne wywołanie komunikatu przez czytnik bez potrzeby interakcji użytkownika.
Komunikat „Proszę podać prawidłowy adres e-mail” jest zrozumiały i odnosi się bezpośrednio do błędu.
Tag z treścią alertu powinien być powiązany z polem wywołującym alert za pośrednictwem aria-describedby.

Autouzupełnianie dla danych osobowych:

<label for="first-name">Imię</label>
<input id="first-name" type="text" autocomplete="given-name" />

<label for="last-name">Nazwisko</label>
<input id="last-name" type="text" autocomplete="family-name" />

<label for="email">E-mail</label>
<input id="email" type="email" autocomplete="email" />

<label for="phone">Telefon</label>
<input id="phone" type="tel" autocomplete="tel" />

Atrybut autocomplete pozwala automatycznie wypełnić dane.

Informacje o formatach:

<label for="phone">
  Numer telefonu
  <span aria-hidden="true">xxx xxx xxx</span>
  <span class="sr-only">trzy cyfry spacja trzy cyfry spacja trzy cyfry</span>
</label>

Pierwszy element <span> stanowi sugestię formatu dla użytkowników widzących. Atrybut aria-hidden="true" ukrywa ten tekst przed czytnikiem.
Drugi element <span> zawiera alternatywny opis formatu przeznaczony dla użytkowników niewidomych.
Klasa „sr-only” sprawia, że tekst jest niewidoczny, ale odczytywany przez aplikacje asystujące (więcej na ten temat znajdziesz w rozdziale: Etykiety i pola z adnotacją o wymagalności).

Dostępne linki

Opisowe teksty linków:

<!-- Źle -->
<a href="raport.pdf">Kliknij tutaj</a>

<!-- Dobrze -->
<a href="raport.pdf">Pobierz roczny raport finansowy (PDF, 2MB)</a>

Opis linku jest jasny oraz informuje o formacie i rozmiarze pliku.

Informowanie o otwarciu w nowym oknie:

<a href="..." target="_blank" title="Otwarcie w nowym oknie">...</a>

Należy poinformować użytkownika, że przejście w podany link nastąpi w nowym oknie.
Nie dubluje się informacji z podlinkowanego tekstu w atrybucie title.

Skip linki

Załóżmy, że strona składa się z rozbudowanego menu, lewego panelu z wyszukiwarką oraz części centralnej zawierającej główną treść. W celu przejścia do głównej treści konieczne jest kilkudziesiętne użycie klawisza Tab. Problem ten rozwiązują skip linki.^[59] Domyślnie są one ukryte. Oznacza to, że pojawiają się dopiero w momencie użycia klawiatury i umożliwiają bezpośrednie przejście (w opisanym przypadku) do panelu lub części centralnej, pomijając rozbudowane menu.

<a href="#main-content" class="skip-link">
  Przejdź do głównej treści
</a>

Skip link jest domyślnie przesunięty poza obszar widzialny, np.: left: -999em;, position: absolute; oraz ma ustawioną pełną przezroczystość. Stan zaznaczenia (fokus) dostosowuje style w celu wyświetlenia skip linku.^[59]

Dostępne przyciski

Podstawowy przycisk:

<button type="button">Zapisz</button>

<button aria-label="Wyszukaj na stronie">Wyszukaj</button>

Etykieta tekstowa powinna być czytelna i jednoznacznie określać działanie przycisku.
Zaleca się, aby przyciski były wystarczająco duże – minimum 44×44 px – oraz oddzielone od siebie odstępem wynoszącym minimum 8 px.^[60]
Użycie aria-label sprawia, że czytnik pomija widoczną etykietę tekstową (przeczyta tylko „Wyszukaj na stronie”).
- Z tego powodu, zawartość aria-label musi zaczynać się od słowa, które jest widoczne na przycisku.

Przycisk będący linkiem:

<a href="...">
  <span class="sr-only">Czytaj</span>
  <span>Więcej</span>
  <span class="sr-only">o: Najciekawsze miejsca na świecie</span>
</a>

Jeżeli etykieta tekstowa jest mało precyzyjna, można ją wzbogacić za pomocą dodatkowych fraz widocznych tylko dla technologii asystujących.
Dla powyższego przykładu:
- widoczny będzie wyłącznie napis „Więcej”,
- natomiast czytnik wypowie „Czytaj więcej o najciekawsze miejsca na świecie”.
Klasa „sr-only” sprawia, że tekst jest niewidoczny, ale odczytywany przez aplikacje asystujące (więcej na ten temat znajdziesz w rozdziale: Etykiety i pola z adnotacją o wymagalności).

Dostępne obrazy

Obraz informacyjny:

<img src="wykres.png" alt="Sprzedaż wzrosła o 25% w 2023 roku" />

Obraz przedstawiający istotną informację musi posiadać tekst alternatywny zawierający krótkie, zrozumiałe podsumowanie prezentowanych treści.
Szczegółowe informacje (w przypadku mapy lub wykresu) należy zawrzeć pod grafiką w formie tabeli lub słownie w tekście dla prostej treści.

Obraz dekoracyjny:

<img src="dekoracja.png" alt="" role="presentation" />

Obraz, który nie wnosi żadnej istotnej informacji, należy oznaczyć jako dekoracyjny, ustawiając przynajmniej pusty atrybut alt.

<div aria-hidden="true">
  <svg>...</svg>
</div>

Elementy <svg> dobrze jest ukryć przed aplikacjami asystującymi.

Obraz będący linkiem:

<a href="...">
  <img src="..." alt="Nasz profil na YouTube" />
</a>

Obraz pełniący rolę linku (np. logo prowadzące na konkretną stronę) powinien zawierać adekwatny tekst alternatywny, który nie będzie opisywać zawartości obrazu.

Dostępne ikony

Ikona w stopce będąca linkiem:

<a href="...">
  <span class="sr-only">Nasz profil na Facebook</span>
  <i class="..." aria-hidden="true">...</i>
</a>

Ikona jest opatrzona etykietą widoczną tylko dla czytnika.
Klasa „sr-only” sprawia, że tekst jest niewidoczny, ale odczytywany przez aplikacje asystujące (więcej na ten temat znajdziesz w rozdziale: Etykiety i pola z adnotacją o wymagalności).

Dostępne tooltipy

Po umieszczeniu kursora na tooltipie, pojawia się podpowiedź w postaci „dymku” zawierającego tekst. Tooltip można uznać za dostępny:

gdy po przesunięciu kursora z tooltipa na podpowiedź, podpowiedź jest nadal wyświetlana
oraz gdy po naciśnięciu klawisza Esc, podpowiedź znika.^[61]

Dostępne slidery

Sliderem (lub karuzelą) nazywa się komponent UI, który umożliwia przeglądanie wielu zdjęć lub treści w obrębie jednego widocznego obszaru. Dostępny slider:

umożliwia przesuwanie zawartości gestem przesunięcia (swipe)
oraz posiada przyciski odpowiedzialne za przesuwanie.^[62]

Jeżeli slider posiada funkcję automatycznego przesuwania, powinna być wprowadzona możliwość zatrzymania tej funkcji.^[63]

Dostępne materiały audio

Materiały audio powinny posiadać transkrypcję tekstową (napisy) w postaci np.: osobnej podstrony lub sekcji z transkrypcją lub osobnego dokumentu.^[64]

Nie należy wprowadzać funkcji automatycznego odtwarzania, ponieważ spowoduje to nałożenie się dźwięku na syntezator mowy czytnika.^[65]

Dostępne materiały wideo

Materiały wideo powinny zawierać:

napisy rozszerzone, czyli:
- transkrypcję tekstową wraz z informacjami ważnymi dla zrozumienia fabuły
- oraz audiodeskrypcję – lektor opisuje, co się dzieje w danej chwili na ekranie
lub dokument tekstowy z audiodeskrypcją
lub transkrypcję tekstową – taką jak w przypadku materiałów audio.^[66]

Jeżeli zawartość materiału wideo została opisana w tekście (np. w artykule opisującym udostępniony materiał wideo), wówczas zapewnienie powyższych alternatyw nie jest konieczne.^[67]

Zmiana odczytywanego języka

Dla pojedynczego słowa:

<p>... używamy plików <span lang="en">cookies</span>.</p>

Zakładając, że strona ma ustawiony język polski za pomocą <html lang="pl">, słowo „cookies” zostanie przeczytane z poprawną angielską wymową. Natomiast reszta zdania – po polsku.

Dla wskazanego obszaru:

<a lang="en" href="...">
  <img alt="English version" src="..." />
</a>

<blockquote lang="en">
  <p>...</p>
</blockquote>

Podobnie jak w poprzednim przykładzie, wnętrze tagów z atrybutem lang="en" zostanie przeczytane z angielską wymową.

WAI-ARIA

WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications) to specyfikacja W3C, która rozszerza możliwości HTML o dodatkowe role, właściwości i stany, umożliwiając tworzenie bardziej dostępnych aplikacji internetowych.^{[68, 69]}

Podstawowe zasady ARIA

Pięć głównych zasad ARIA:^{[68, 69]}

Nie używaj ARIA, jeśli można osiągnąć to samo natywnym HTML.
Nie zmieniaj semantyki natywnych elementów HTML.
Wszystkie interaktywne elementy ARIA muszą być dostępne z poziomu klawiatury.
Nie ukrywaj elementów fokusowalnych.
Wszystkie interaktywne elementy muszą mieć dostępną nazwę.

Właściwość „dostępnej nazwy” można zilustrować na przykładzie przycisku „OK”. Tekst „OK” jest dostępną nazwą. Gdy na przycisku znajdzie się fokus, technologie asystujące mogą połączyć opis roli z dostępną nazwą. Wówczas czytnik ekranowy może wypowiedzieć „przycisk OK” lub „OK przycisk”. Kolejność łączenia oraz szczegóły roli są określane przez technologie asystujące.^[69]

Role, właściwości i statusy

Wybrane role ARIA:

role="alert" – rola ostrzeżenia (więcej w rozdziale: Komunikat błędu).
role="status" – rola komunikatu (więcej w rozdziale: Komunikat powodzenia).
role="button" – rola przycisku (to zapewnia użycie tagu HTML <button>).
role="checkbox" – rola checkboxa (to zapewnia użycie tagu HTML <input type="checkbox" />, więcej w rozdziale: Niestandardowy checkbox).
role="dialog" – rola okna dialogowego (więcej w rozdziale: Okno dialogowe/Modal).
role="progressbar" – rola paska postępu (więcej w rozdziale: Pasek postępu).
role="slider" – rola suwaka (to zapewnia użycie tagu HTML <input type="range" />, więcej w rozdziale: Niestandardowy suwak).
role="tablist", role="tab", role="tabpanel" – rola zakładki (więcej w rozdziale: Zakładki).
role="banner" – rola baneru (to zapewnia użycie tagu HTML <header />).
role="complementary" – rola panelu bocznego (to zapewnia użycie tagu HTML <aside />).
role="contentinfo" – rola stopki (to zapewnia użycie tagu HTML <footer />).
role="form" – rola formularza (to zapewnia użycie tagu HTML <form />).
role="main" – rola zawartości głównej (to zapewnia użycie tagu HTML <main />).
role="navigation" – rola nawigacji (to zapewnia użycie tagu HTML <nav />).
role="menu" – rola menu (więcej w rozdziale: Rozwijane menu).
role="search" – rola wyszukiwarki (więcej w rozdziale: Wyszukiwarka).
role="application" – ta rola oznacza, że w danym obszarze będą obowiązywać skróty klawiaturowe zdefiniowane przez autorów strony/aplikacji (więcej w rozdziale: Tryb aplikacji).

Wybrane właściwości ARIA:

aria-labelledby="..." – właściwość służąca do skojarzenia treści ze wskazanym elementem (więcej w rozdziale: Okno dialogowe/Modal).
aria-describedby="..." – właściwość pozwalająca na powiązanie dodatkowego opisu (więcej w rozdziale: Podpięcie informacji dotyczącej pola edycji).
aria-label="..." – właściwość dla etykiety tekstowej (więcej w rozdziale: Przycisk zamykania).
aria-haspopup="..." – właściwość informująca o tym, czy element jest rozwijany (więcej w rozdziale: Rozwijane menu).
aria-controls="..." – właściwość wskazująca, który element jest sterowany przez jaki element (więcej w rozdziale: Zakładki).
aria-atomic="..." – właściwość dotycząca sposobu ogłaszania zmian treści dynamicznej – szczególnie w kontekście aria-live (więcej w rozdziale: Dynamiczny obszar).
aria-live="..." – właściwość pozwalająca nasłuchiwać na zmianę zawartości elementu (więcej w rozdziale: Dynamiczny obszar).
aria-setsize="..." – właściwość określająca całkowitą liczbę elementów w zestawie (więcej w rozdziale: Dynamiczna lista).
aria-posinset="..." – właściwość informująca o pozycji konkretnego elementu względem całego zbioru (więcej w rozdziale: Dynamiczna lista).
aria-sort="..." – właściwość informująca o sposobie sortowania – zazwyczaj danych w kolumnie tabeli (więcej w rozdziale: Tabela sortowalna).

Wybrane stany ARIA:

W odróżnieniu od właściwości ARIA, stany mogą przyjąć wyłącznie wartości true lub false:

aria-checked="..." – stan informujący o zaznaczeniu (to zapewnia użycie tagu HTML <input type="checkbox" />).
aria-selected="..." – stan pozwalający wskazać, czy dany element w zbiorze opcji jest wybrany (więcej w rozdziale: Zakładki).
aria-expanded="..." – stan pozwalający wskazać, czy element jest aktualnie zwinięty lub rozwinięty (więcej w rozdziale: Rozwijane menu).
aria-hidden="..." – stan ukrywający element przed technologią asystującą (więcej w rozdziale: Treści dekoracyjne).
aria-invalid="..." – stan informujący, czy wartość pola formularza jest błędna lub nie przechodzi walidacji (więcej w rozdziale: Komunikat błędu).
aria-modal="..." – stan określający, czy okno dialogowe jest modalne (więcej w rozdziale: Okno dialogowe/Modal).

Przykłady użycia WAI-ARIA

W niniejszej sekcji zaprezentuję praktyczne przykłady wykorzystania atrybutów ARIA w celu poprawy dostępności dynamicznych komponentów interfejsu użytkownika.

Komunikat błędu

<div role="alert">
  Formularz zawiera błędy!
</div>

Powyższy fragment kodu dotyczy ostrzeżenia zbiorczego. Jeżeli natomiast przejście do następnego pola edycji powoduje wywołanie walidacji na polu poprzednim, warto zastosować ostrzeżenie dla pojedynczego pola edycji oraz powiązać to ostrzeżenie z odpowiednim polem za pomocą aria-describedby oraz sterować wartością atrybutu aria-invalid (kod poniżej).

<label for="email">Adres e-mail</label>
<input
  type="email"
  id="email"
  required
  aria-describedby="error email"
  aria-invalid="true"
/>
<div role="alert" id="error-email">
  Proszę podać prawidłowy adres e-mail
</div>

Komunikat powodzenia

<div role="status">
  Konto zostało założone
</div>

Treść umieszczona wewnątrz takiego elementu zostanie odczytana automatycznie, jeżeli została dodana dynamicznie po załadowaniu strony.

Okno dialogowe/Modal

<div
  ...
  tabindex="-1"
  role="dialog"
  aria-labelledby="dialog-label"
  aria-describedby="dialog-desc"
  aria-modal="true"
>
  ...
  <h2 id="dialog-label">...</h2>
  ...
  <div id="dialog-desc">...</div>
</div>

Najpierw zostanie przeczytana zawartość tagu wskazanego w aria-labelledby, a potem – z aria-describedby. Warto podkreślić, że nie należy stosować aria-describedby, jeżeli w oknie dialogowym znajduje się bardziej złożona zawartość niż tekst (np. formularz).^[70]

Atrybut aria-modal określa, czy okno jest modalne, czyli czy wymaga interakcji użytkownika, gdy ten chce wrócić do reszty interfejsu, oraz czy reszta strony jest niedostępna w czasie wyświetlania takiego okna. Dodatkowo należy zapewnić blokadę fokusu za pomocą kodu JavaScript przed przejściem „pod” okno modalne.

Pasek postępu

<!-- Wariant z sygnałami dźwiękowymi z czytnika -->
<p ... id="pb-label" role="alert"></p>
<div
  class="..."
  role="progressbar"
  aria-labelledby="pb-label"
  aria-valuenow="0"
  aria-valuemin="0"
  aria-valuemax="100"
>
  ...
</div>

Kod JavaScript powinien:

umieszczać wewnątrz paragrafu opatrzonego role="alert" treść stosowną do sytuacji, np.: (1) Trwa ładowanie, (2) Ładowanie zatrzymane, (3) Ładowanie skończone
oraz aktualizować wartość aria-valuenow, aby informować czytnik o aktualnej wartości postępu, na podstawie której czytnik będzie dobierać odpowiednią częstotliwość dźwięku.

Nie należy stosować sygnałów dźwiękowych, jeżeli pasków postępu jest więcej niż jeden, aby nie wprowadzić chaosu.

<!-- Wariant bez sygnałów dźwiękowych z czytnika -->
<p ... role="alert"></p>
<div class="...">...</div>

Niestandardowy suwak

<label id="volume-label">Głośność</label>
<div
  ...
  aria-labelledby="volume-label"
  tabindex="0"
  role="slider"
  aria-valuenow="50"
  aria-valuetext="50%"
  aria-valuemin="0"
  aria-valuemax="100"
>
  <div class="..." />
</div>

Ten niestandardowy suwak głośności implementuje atrybuty aria-value wyjaśnione na przykładzie rozdziału Pasek postępu. Ważnym atrybutem jest tutaj tabindex, który nadaje możliwość obsługi za pomocą klawiatury. Implementację standardowego suwaka zapewnia <input type="range" />.

Zakładki

<div ... role="tablist" aria-label="Sekcje produktu">
  <button ... role="tab" aria-selected="true" aria-controls="nav-desc" id="nav-desc-tab" tabindex="0">
    Opis
  </button>
  <button ... role="tab" aria-selected="false" aria-controls="nav-spec" id="nav-spec-tab" tabindex="-1">
    Specyfikacja
  </button>
</div>
<div>
  <div role="tabpanel" id="nav-desc" aria-labelledby="nav-desc-tab" tabindex="0">
    Zawartość opisu...
  </div>
  <div role="tabpanel" id="nav-spec" aria-labelledby="nav-spec-tab" tabindex="0">
    Zawartość specyfikacji...
  </div>
</div>

W strukturze HTML zakładki (role="tab") muszą być:

bezpośrednimi sąsiadami, aby czytnik mógł anonsować liczbę zakładek,
bezpośrednimi dziećmi elementu z atrybutem role="tablist".

Wartości dla tabindex oraz aria-selected są ustawiane dynamicznie.

W przypadku zakładek (role="tab"), wartość tabindex="-1" sprawia, że kolejne użycie klawisza Tab spowoduje przejście do zawartości tej zakładki (role="tabpanel") zamiast do kolejnej zakładki (role="tab").

Na poziomie kodu JavaScript należy zapewnić możliwość nawigacji pomiędzy zakładkami za pomocą klawiszy ← / → oraz Home i End.

Atrybut aria-controls wskazuje id panelu, w którym znajduje się treść dla konkretnej zakładki. Panele dla pozostałych zakładek powinny zostać ukryte (np. display: none;).

Niestandardowy checkbox

<div role="checkbox" aria-checked="true" tabindex="0">
  Zgadzam się z regulaminem
</div>

Załóżmy, że chcemy sprostać niestandardowym wymaganiom polegającym na implementacji animowanych zaznaczeń i odznaczeń na bazie pseudoelementów CSS (::before i ::after), które są nieosiągalne na natywnym elemencie <input />. Wówczas używamy autorskiego checkboxa (np. pochodzącego z biblioteki), który jest renderowany w postaci <div>…</div> (zamiast <input type="checkbox" />). W takiej sytuacji należy na nim zastosować wskazane atrybuty ARIA. Wartość atrybutu aria-checked jest dobierana dynamicznie.

Podpięcie informacji dotyczącej pola edycji

<label for="email">Adres e-mail</label>
<input id="email" aria-describedby="email-help" ... />
<small id="email-help">Nikomu nie podamy twojego e-maila.</small>

Treść zawarta w <small> dostarcza dodatkowe informacje użytkownikom korzystającym z czytników ekranu, które przeczytają zarówno etykietę (<label>), jak i dodatkowy opis.

Przycisk zamykania

<button aria-label="Zamknij okno dialogowe" class="...">
  <i class="icon-close">...</i>
</button>

Użycie atrybutu aria-label sprawia, że czytnik nie przejdzie do zawartości elementu. Alternatywny zapis jest przedstawiony poniżej (zawartość klasy „sr-only” znajdziesz w przykładzie Etykiety i pola z adnotacją o wymagalności).

<button class="...">
  <i class="icon-close" aria-hidden="true">...</i>
  <span class="sr-only">Zamknij</span>
</button>

Rozwijane menu

<button
  ...
  aria-haspopup="true"
  aria-expanded="false"
  aria-controls="dropdown-menu"
>
  Opcje
</button>

<ul id="dropdown-menu" role="menu" hidden>
  <li role="menuitem">...</li>
  <li role="menuitem">...</li>
  ...
</ul>

Atrybut role="menu" informuje czytnik, że element stanowi rozwijane menu. Widoczność menu jest odzwierciedlana za pomocą wartości aria-expanded. Natomiast atrybut aria-haspopup oznacza element otwierający menu. Z kolei aria-controls wskazuje, że przycisk steruje widocznością menu.

Dynamiczny obszar

<div aria-live="polite" aria-atomic="true">
  <div class="...">Wynik wynosi:</div>
  <span id="result">Twoja rata wyniesie: 300 zł</span>
</div>

Załóżmy, że powyższy obszar często ulega modyfikacji wskutek zmiany danej wejściowej. Obecność atrybutu aria-live sprawia, że element jest pod nasłuchem. Oznacza to, że każdorazowa zmiana zawartości zostanie odczytana przez technologię asystującą. Jeżeli wartość atrybutu stanowi:

polite – odczytanie nastąpi, gdy użytkownik przestanie wykonywać trwającą operację,
assertive – odczytanie nastąpi natychmiast.

Atrybut aria-atomic z kolei określa, czy cała zawartość ma być ogłaszana, gdy nastąpi zmiana. Jeżeli wartość atrybutu jest ustawiona na:

true – odczytana zostanie cała zawartość kontenera opatrzonego atrybutem aria-live („Wartość wynosi 300 zł”),
false – odczytana zostanie tylko informacja, która uległa zmianie („300 zł”).

Element z aria-live musi występować w DOM od początku wyrenderowania widoku. W przeciwnym razie, czytnik nie będzie nasłuchiwać na taki element.^[71]

Dynamiczna lista

<ul role="listbox">
  <li role="option" aria-posinset="1" aria-setsize="3">Zdjęcie 1</li>
  <li role="option" aria-posinset="2" aria-setsize="3">Zdjęcie 2</li>
  <li role="option" aria-posinset="3" aria-setsize="3">Zdjęcie 3</li>
</ul>

W dynamicznych interfejsach (np. wirtualne listy, lazy loading), tylko część elementów może być obecna w DOM. Jednak czytnik ekranu powinien zostać poinformowany za pomocą aria-setsize i aria-posinset kolejno o tym, jak duży jest cały zbiór oraz na którym z elementów aktualnie jesteśmy.

Tabela sortowalna

<table>
  <thead>
    <tr>
      <th scope="col" aria-sort="ascending">Nazwa</th>
      <th scope="col">Data</th>
      <th scope="col">Cena</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Produkt A</td>
      <td>2023-01-01</td>
      <td>10 zł</td>
    </tr>
    ...
  </tbody>
</table>

Atrybut aria-sort określa sposób sortowania elementu w zbiorze danych:

none – brak sortowania,
ascending – sortowanie rosnące (1–100),
descending – sortowanie malejące (100–1),
other – niestandardowe sortowanie.

Gdy użytkownik kliknie nagłówek kolumny, a sortowanie się zmienia, należy zaktualizować wartość aria-sort oraz wizualny wskaźnik sortowania (np. strzałkę).

Tryb aplikacji

<div role="application" aria-label="Kalkulator">
  <h2 ...>Kalkulator</h2>
  <div role="group" aria-labelledby="calc-label">
    <label for="input1">Liczba 1</label>
    <input id="input1" type="number" />
    <label for="input2">Liczba 2</label>
    <input id="input2" type="number" />
    <button ...>Dodaj</button>
    <div role="status" aria-live="polite" id="result"></div>
  </div>
</div>

Załóżmy, że posiadamy aplikację webową z dynamicznym interfejsem graficznym i chcemy zapewnić pełne sterowanie klawiaturą. Atrybut role="application" sprawia, że zawartość elementu jest odczytywana przez technologię asystującą w odmienny sposób, czyli:

nawigacja strukturalna jest wyłączona (ignorowanie landmarków, nagłówków itp.),
użytkownik korzysta z aplikacji jak z programu desktopowego – klawiszami strzałek, skrótami, interakcją bez czytnika.

Oznacza to, że użytkownik musi znać obsługę klawiatury danej aplikacji, ponieważ typowa nawigacja przestaje działać. To podejście wymaga bardzo dobrej implementacji ARIA.

Narzędzia do testowania dostępności

Skuteczne testowanie dostępności wymaga kombinacji narzędzi automatycznych oraz testów manualnych. Automatyczne narzędzia mogą wykryć około 30–40% problemów z dostępnością, pozostałe wymagają testów manualnych.^{[72, 73]}

Najważniejsze kategorie narzędzi:

Automatyczne skanery: WAVE,^[74] axe DevTools,^[75] Lighthouse^[76] – szybko identyfikują podstawowe problemy.
Czytniki ekranowe: NVDA^[19] lub JAWS,^[20] TalkBack,^[21] VoiceOver^[22] – niezbędne do testów manualnych.
Analizatory kontrastu: Colour Contrast Analyser,^[34] WebAIM Contrast Checker,^[30] Color Contrast Checker^[35] – sprawdzają współczynniki kontrastu.
Platformy testowe: BrowserStack Accessibility,^[77] Mabl^[78] – testowanie na wielu urządzeniach i przeglądarkach.

AI w kontekście dostępności cyfrowej

Sztuczna inteligencja może znacząco wspomóc proces zapewniania dostępności cyfrowej. ChatGPT może generować kod HTML zgodny z WCAG, tworzyć opisy alternatywne dla obrazów oraz przypadki testowe uwzględniające potrzeby użytkowników z niepełnosprawnościami.^[79–81] Należy jednak pamiętać o ograniczeniach AI i każdorazowo weryfikować uzyskiwane dane.^[81]

Technologie AI oferują również inne konkretne rozwiązania wspierające dostępność:

automatyczne generowanie napisów do filmów,
opisywanie obrazów dla osób niewidomych,
rozpoznawanie nietypowych wzorców mowy,
automatyczna transkrypcja rozmów telefonicznych,
tłumaczenie na język migowy w czasie rzeczywistym,
asystenci głosowi,
inteligentne systemy nawigacji dla osób niewidomych.^[80]

Podsumowanie

Dostępność cyfrowa zgodna z WCAG to nie tylko wymóg prawny, ale przede wszystkim kwestia równości i inkluzywności. Implementacja standardów WCAG 2.2 na poziomie AA zapewnia dostęp do treści cyfrowych dla ponad 2 miliardów osób z niepełnosprawnościami na całym świecie.

Kluczowe elementy sukcesu w implementacji dostępności to:

Semantyczny kod HTML jako fundament dostępności.
Odpowiednie kontrasty kolorów zapewniające czytelność.
Dostępne dokumenty w formatach Office z odpowiednią strukturą.
Właściwe użycie ARIA do wzbogacenia semantyki HTML.
Regularne testowanie przy użyciu zróżnicowanych narzędzi.
Edukacja zespołu w zakresie zasad dostępności.

Warto pamiętać, że dostępność to proces ciągły, a nie jednorazowe działanie. Rozwój technologii oraz nadchodzący WCAG 3.0 będą wymagać stałego aktualizowania wiedzy i praktyk. Jednak inwestycja w dostępność przynosi korzyści wszystkim użytkownikom, poprawiając ogólną jakość produktów cyfrowych.