Case Study (2025)

Audyt WCAG 2.2

Choć WCAG kojarzone jest z ułatwieniami dla osób niewidomych, słabowidzących, niesłyszących w rzeczywistości obejmuje znacznie szerszy kontekst. Dostępność cyfrowa to fundament projektowania treści w sposób uniwersalny, przewidywalny i logiczny tak, aby były zrozumiałe nie tylko dla ludzi, lecz także dla maszyn. W praktyce oznacza to, tworzenie środowiska przyjaznego również dla AI i LLM.

Spis treści
  1. WCAG Wstęp
  2. Narzędzia i zasoby
  3. Wybór wzorca ARIA
  4. WCAG w HTML
  5. Rezultat testów

WCAG Wstęp

WCAG (Web Content Accessibility Guidelines) to zbiór wytycznych, które pomagają tworzyć strony i aplikacje dostępne dla szerokiego spektrum użytkowników. Przedewszystkim dla tych z niepełnosprawnościami (np. osoby niewidome, słabowidzące, poruszające się tylko za pomocą klawiatury). Współcześnie dotyczy to niemal wszystkich aplikacji podlegających walidacji jakości dlatego dobrą praktyką jest dodanie WCAG do konwencji programistycznych oraz zasad obowiązujących w zespole. W rezultacie umożliwi to nam wcześniejsze wychwycenie błędów.

  • Konwencje programistyczne to zbiór ustaleń dotyczących stylu kodu, struktury plików, testowania, narzędzi linterskich i innych standardów. WCAG jako część konwencji pokazuje, że dostępność nie jest "opcją", tylko integralna część developmentu.

    1. Ustalenie zakresu audytu.

    • Określenie testowanych widoków, komponentów i scenariuszy.
    • Ustalenie poziomu zgodności (np. WCAG 2.2 poziom AA).

    2. Przegląd projektu i technologii.

    • Analiza frameworka (Angular, React).

    3. Przygotowanie środowiska testowego.

    • Konfiguracja narzędzi: axe, WAVE, Lighthouse, NVDA.
    • Ustalenie przeglądarek, systemu i czytników ekranu.

    4. Wybór i przypisanie wzorców ARIA (ARIA Patterns).

    • Określenie dla każdego komponentu wzorca z ARIA Authoring Practices.
    • Sprawdzenie zgodności ze strukturą ról i zachowań (np. dialog, tablist, combobox).

    5. Testy

    • Testowanie interakcji klawiaturą (Tab, Shift+Tab, Enter, Esc, fokus).
    • Sprawdzenie tytułów stron, kontrastu, struktury nagłówków.
    • Ocena alternatywnych tekstów, ról ARIA i etykiet (aria-label, role, aria-hidden).
    • Uruchomienie lintersów (axe-linter, eslint-plugin-jsx-a11y).
    • Skany z użyciem WAVE, axe DevTools, Lighthouse.
    • Sprawdzenie kolejności czytania, dostępnych opisów, widoczności elementów (czytnik ekranu).
    • Symulacja typowych scenariuszy użytkowników niewidomych i słabowidzących (czytnik ekranu).

    6. Raportowanie i kategoryzacja błędów

    • Opis każdego defektu z odniesieniem do kryterium WCAG (np. 1.1.1, 2.4.3).
    • Rekomendacje w odniesieniem do WCAG

    7. Sumaryczny raport

    • Lista defektów wg priorytetu.
    • Przekazanie dokumentacji.

Narzędzia i zasoby

Poniższa lista narzędzi opiera się na doświadczeniu w audycie relizowanym w projekcie opartym na Angular. Dla innych frameworków mogą obowiązywać inne dobre praktyki, konfiguracje lub dedykowane narzędzia. Warto korzystać z dokumentacji odpowiedniej dla danego stosu technologicznego.

Dokumentacja WCAG (WAI - Web Accessibility Initiative (W3C))

Wybór wzorca dostępności (ARIA Pattern) dla projektu

Podczas wdrażania dostępności zgodnej z WCAG 2.2 warto już na etapie projektowania interfejsu zaplanować, które komponenty będą zgodne ze wzorcami dostępności (ARIA patterns). Wzorce dostępności to gotowe zalecenia struktury HTML, ról i atrybutów ARIA dla komponentów takich jak: modal, dialog, menu, akordeon, tabs i tak dalej. Są opisane w oficjalnej dokumentacji ARIA Authoring Practices Guide (APG), przygotowanej przez W3C.


W projekcie zastosowano wzorzec Dialog (Modal) Pattern, który określa:

  • jak zarządzać fokusem wewnątrz modala,
  • jak ukrywać tło (aria-hidden lub aria-modal),
  • jakie role i atrybuty powinien mieć modal (role="dialog" lub alertdialog).

Wzorzec korzysta z atrybutu aria-modal="true" (został wprowadzony w specyfikacji ARIA 1.1), który informuje czytniki ekranu, że poza modalem nie ma aktywnej treści. Dzięki temu nie trzeba ręcznie stosować aria-hidden="true" na tle. Nie wszystkie czytniki jednak wspierają aria-modal dlatego w projektach wymagających pełnej zgodności można rozważyć dodatkowe zabezpieczenia (np. ręczne ukrywanie tła za pomocą aria-hidden).

WCAG w HTML (przykłady wskazówek)



Niektóre czytniki ekranowe (np. NVDA) wykorzystują strukturę nagłówków <h1> <h6> do szybkiego poruszania się po stronie za pomocą skrótów klawiszowych. Pominięcie poziomu nagłówka może sugerować, że kolejny nieistnieje.


Poziom nagłówka nie powinien być używany do zmiany wielkości tekstu do tego używamy klas CSS:

<h1>Zaplanowane płatności</h1>
<h2 class="h3">Przelewy z datą przyszłą</h2>
<h2 class="h3">Przelewy z karty</h2>

Google Lighthouse traktuje nieprawidłową kolejność nagłówków jako błąd, który może obniżyć wynik jakości strony (accessibility score).

Treści graficzne

Każdy element graficzny powinien mieć alternatywny opis taki by użytkownicy korzystający z czytników ekranu mogli zrozumieć, co dana grafika przedstawia.


Klasyczne obrazy <img> użycie alt

<img src="assets/creditcards.png" alt="Logo reklamowe dla Credit Cards">

Zastosowanie role="img" i aria-label W przypadku złożonych elementów SVG, które są dekoracyjne lub ikonograficzne, należy:

  • użyć role="img" - by czytnik wiedział, że to element graficzny,
  • dodać aria-label - by zapewnić opis w drzewie dostępności.
<svg role="img" aria-label="Opis grafiki SVG">
  <!-- zawartość SVG -->
</svg>

Dzięki temu czytnik ekranu odczyta cały obrazek jako jeden spójny element, zamiast analizować każdy fragment SVG z osobna.


Jeśli grafika nie wnosi treści (czysto dekoracyjna).
Można użyć role="presentation" to usuwa grafikę z accessibility tree. Należy jednak stosować to świadomie, aby nie ograbiać uzytkowników z treści.

<img src="assets/just-a-graphic-line-without-content.png" role="presentation">


Rezultat testów

Zakres czasu: 3 miesiące
Technologia: Angular
Zakres testów: Zgodność z WCAG 2.2 na poziomie AA (dostępność komponentów Angular w tym DOM, routing, formularze, modale, role ARIA, kontrast kolorów oraz nawigację klawiaturą w kontekście komponentów interfejsu użytkownika)

Statystyki:
  • Liczba zgłoszonych błędów: 650+
  • Liczba komponentów przetestowanych: brak danych
  • Rodzaj testów: manualne, półautomatyczne (axe, Wave), lintersy, testy screen readerem (NVDA)
Przykładowe błędy:

Obserwacje ogólne:

W większości analizowanych aplikacji warstwa UI (kontrast kolorów, rozmiary czcionek, minimalna klikalna powierzchnia itp.) jest dziś na ogół zgodna z podstawowymi wymaganiami WCAG. Wynika to z rosnącej świadomości projektowej i angażowania doświadczonych zespołów UX/UI w SDLC. W efekcie liczba błędów widocznych na pierwszy rzut oka była stosunkowo niewielka.


Najwięcej problemów dostępnościowych wynikało z ukrytych elementów struktury HTML. Najczęściej powtarzające się to:

  • brak semantycznych ról,
  • nieprawidłowe wykorzystanie atrybutów ARIA,
  • brak obsługi klawiatury,
  • błędne zarządzanie fokusem,
  • nieczytelne tytuły stron,
  • dekoracyjne obrazy nieoznakowane prawidłowo.

To pokazuje, że prawdziwe wyzwania w zakresie dostępności rzadko widoczne są gołym okiem i właśnie dlatego testy dostępności pod kontem WCAG 2.2 stanowia wyzwanie.

Extra references