SDC

Szkolenie: ARC Toolkit – narzędzie do analizy dostępności stron internetowych

📌 Szkolenie: ARC Toolkit – narzędzie do analizy dostępności stron internetowych

🔧 Czym jest ARC Toolkit?

  • ARC Toolkit to narzędzie do analizy dostępności stron internetowych.
  • Różni się od narzędzi takich jak:
    • WAVE (narzędzie webowe z własnym UI),
    • axe (np. jako rozszerzenie do przeglądarki).
  • ARC działa w oparciu o DevTools wbudowane w przeglądarkę Google Chrome.

🛠️ Działanie ARC Toolkit

  • Korzysta z DevTools (F12 → zakładka ARC).
  • Automatyzuje analizę strony, podając:
    • błędy (Errors),
    • ostrzeżenia (Alerts),
    • dobre praktyki (Best Practices).
  • Umożliwia ręczną oraz automatyczną analizę – najlepiej stosować łącznie.

💡 Funkcjonalności ARC Toolkit

  1. Interfejs
    • Możliwość zmiany orientacji panelu (np. na dół ekranu).
      Przejrzysty podział na sekcje (nagłówki, obrazy, linki itd.).
  2. Obrazki
    • Pokazuje, które obrazy mają brakujące atrybuty alt.
    • Wyświetla fragment kodu oraz wskazuje lokalizację na stronie.
  3. Nagłówki
    • Analiza struktury nagłówków (<h1>, <h2>, …).
    • Na przykładzie strony Kraków.pl wykryto kilka <h5> bez logicznej struktury – ocena jako „kreatywność dewelopera”.
  4. Landmarki (regiony nawigacyjne)
    • Wykrywa header, nav, footer itd.
    • Braki w oznaczeniu np. brak main lub content.
  5. Listy (<ul>)
    • Oznacza listy na stronie, wskazuje ich zawartość.
    • W Kraków.pl np. lista języków, kontrastu, zmiany fontu.
  6. Formularze
    • Wykrywa również ukryte formularze.
    • Umożliwia łatwe ich zlokalizowanie i ocenę zasadności ich istnienia.
  7. Linki
    • Rozróżnia linki wewnętrzne i zewnętrzne.
    • Czasami błędnie klasyfikuje linki jako zewnętrzne (np. wewnętrzne linki serwisowe).
  8. Aria-label, role
    • Pokazuje zastosowane atrybuty aria-* i ich wartości.
  9. Tab order
    • Kolejność przechodzenia przez elementy przy pomocy klawisza Tab.
      Wskazuje ewentualne problemy z logiką przechodzenia.
  10. Kontrast
  • Sprawdza kontrast tekstu względem tła.
  • Przykład: tekst biały na żółtym w okienku Facebooka – zły kontrast.
  1. Podświetlanie elementów
  • Po kliknięciu w wynik, podświetla element na stronie oraz w kodzie.
  • Ułatwia zlokalizowanie problemu i jego kontekstu.

📦 Integracje i możliwości techniczne

  • Możliwość integracji z procesami CI/CD:
    • Automatyczne testowanie zmian w kodzie.
    • Weryfikacja spełnienia zasad dostępności bez ręcznego sprawdzania.
  • Możliwość integracji z systemami zgłoszeniowymi:
    • Jira – do tworzenia zgłoszeń błędów (np. z opisem, zrzutem ekranu, priorytetem).
    • Redmine lub inne narzędzia do zarządzania zadaniami.

🔒 Dane i prywatność

  • ARC Toolkit działa lokalnie w przeglądarce:
    • Dane nie są przesyłane do chmury.
    • W przeciwieństwie do narzędzi typu SaaS (np. WAVE online).
    • Brak problemów z RODO lub koniecznością zakładania konta.

🖥️ Praktyczne uwagi

  • ARC uruchamia się z poziomu Chrome DevTools.
  • Działa najlepiej na większym ekranie – np. przypięty po prawej stronie.
  • Przy niektórych stronach może wyłączyć elementy lub wpłynąć na ich działanie.
  • Może służyć jako narzędzie uzupełniające inne audyty.

📊 Inne informacje

  • Niektóre strony mają zminifikowany kod (dla szybkości ładowania).
    • Trudny do odczytania, ale przeglądarka nadal go analizuje.
    • Narzędzia automatyzujące upraszczają analizę nawet takiego kodu.
  • Testowanie powinno odbywać się:
    • W różnych przeglądarkach,
    • Na różnych urządzeniach.

ARC Toolkit – przegląd i zastosowanie

🔹 Czym jest ARC Toolkit?

  • ARC Toolkit to rozszerzenie do przeglądarki Chrome (nie wymaga logowania).
  • Dostarcza raport błędów związanych z dostępnością strony zgodnych ze standardem WCAG.
  • Każdy błąd zawiera szczegóły: opis, lokalizację w kodzie i powiązane kryterium WCAG.
  • Raport generowany jest dla aktualnie otwartej strony.
  • Narzędzie nie działa dynamicznie – trzeba je uruchamiać ręcznie po każdej zmianie na stronie.

🧪 Jak używać ARC Toolkit?

  1. Zainstaluj rozszerzenie z Chrome Web Store.
  2. Otwórz interesującą stronę.
  3. Uruchom DevTools (F12 lub Ctrl+Shift+I).
  4. Przejdź do zakładki ARC Toolkit.
  5. Kliknij Run Audit – otrzymasz listę błędów i ostrzeżeń.

✅ Jak interpretować wyniki?

  • Każdy błąd zawiera:
    • Opis błędu (w jęz. angielskim),
    • Kryterium WCAG, którego dotyczy (np. 1.1.1 Non-text Content),
    • Fragment kodu, którego dotyczy błąd,
    • Opcję Highlight, która zaznacza problematyczny element na stronie.
  • Można kliknąć na ikonę < >, aby przejść do źródła błędu w zakładce Elements.
  • Raport można filtrować (np. tylko błędy krytyczne).

🧪 Accessibility panel – Chrome DevTools

🔹 Gdzie go znaleźć?

  • Otwórz Chrome DevTools.
  • Kliknij >>, a następnie wybierz zakładkę Accessibility.
  • Jeśli jej nie ma, dodaj ją w menu kontekstowym (prawy klik → „Show accessibility pane”).

🧩 Do czego służy?

  • Pokazuje strukturę dostępności (Accessibility Tree) wybranego elementu.
  • Umożliwia podejrzenie:
    • Roli elementu (role),
    • Nazwy dostępnościowej (Accessible Name),
    • Właściwości ARIA,
    • Stanu widoczności (hidden, focusable, keyboard focusable itd.).

📋 Jak używać?

  1. Zaznacz element w zakładce Elements.
  2. W zakładce Accessibility zobaczysz:
    • Jak ten element jest interpretowany przez technologie asystujące.
    • Czy ma prawidłową nazwę dostępną i rolę.
    • Czy jest widoczny, dostępny z klawiatury itd.
  3. Przykłady:
    • Jeśli element nie ma tekstu alternatywnego (alt, aria-label, aria-labelledby), pojawi się jako empty name.
    • Jeśli ma niewłaściwą rolę (np. div bez role=”button”), nie zostanie rozpoznany poprawnie.

🔄 Co można sprawdzić dodatkowo?

  • Czy element jest fokusowalny z klawiatury.
  • Czy kolejność fokusu jest logiczna.
  • Czy występują konflikty ARIA (np. aria-hidden=”true” na interaktywnym elemencie).

Ustawienia środowiska testowego

  • Uwaga na skalowanie przeglądarki i systemu: np. przy powiększeniu 125% Chrome może „rozszerzyć” breakpointy, co wpłynie na widoczność błędów lub ich brak.
  • Testowanie z wyłączonymi rozszerzeniami – mogą wpływać na wyniki (np. generowanie fałszywych ramek, zakłócanie DOM).
  • Zalecany widok: 100% zoom, brak trybu mobilnego, czysta karta incognito, test na różnych systemach i przeglądarkach (Windows, Mac, Chrome, Firefox).

📋 Formularze i ich dostępność

  • Każde pole formularza musi mieć widoczną etykietę (label) – nawet jeśli placeholder jest używany jako opis (to błąd!).
    Label musi być powiązany z polem for=”id” – ARC Toolkit to wykrywa.
  • Obowiązkowo: aria-required, aria-invalid dla komunikatów błędów (plus widoczne komunikaty tekstowe).
  • Skupienie (focus) powinno być przenoszone na komunikat o błędzie po submit – można testować np. używając Tab i Enter.

🗂️ Struktura dokumentu

  • Frame (iframe):
    • Musi zawierać title, który jednoznacznie opisuje zawartość.
    • Uwaga: niektóre narzędzia dodają ukryte iframy – sprawdzaj DOM ręcznie.
  • Język dokumentu:
    • lang w <html> (np. lang=”pl”) obowiązkowy.
    • W przypadku stron wielojęzycznych: dynamiczna zmiana lang (np. lang=”en” dla angielskich fragmentów).
  • Wersje językowe strony:
    • Oddzielne adresy URL z językiem w nazwie, np. /pl/, /en/.
    • Można testować zgodność z WCAG 3.1.1 i 3.1.2 (język strony i język części).

🖼️ Obrazki i grafiki

  • Background images – ARC Toolkit ich nie analizuje. Weryfikuj ręcznie:
    • Jeśli zawierają istotne informacje → błąd.
    • Dla dekoracyjnych → role=”presentation” lub aria-hidden=”true”.
  • Ikony jako czcionki (np. Font Awesome):
    • Potrzebują alternatywy tekstowej (np. aria-label, title, sr-only).
  • ALT-y:
    • alt=”” dla dekoracyjnych.
    • Obowiązkowe alt=”…” dla informacyjnych.
    • Unikać: alt=”image” – nieinformatywne.
    • ARC zgłasza też, gdy alt zawiera sam link/plik, np. alt=”logo.png”.

Dostosowanie języka strony i treści – WCAG 3.1

1. Ustawienie języka strony i jej wersji językowych (3.1.1 Language of Page / Język strony)

  • Każda strona musi mieć określony język główny.

Atrybut lang powinien być ustawiony w tagu <html>, np.:

<html lang=”pl”>

  • Poprawne zdefiniowanie języka:
    • pozwala technologiom wspomagającym (np. czytnikom ekranu) na odpowiednie czytanie tekstu.
    • wpływa na działanie funkcji autouzupełniania (np. nazw pól formularzy w języku polskim).

2. Zmiany języka wewnątrz treści (3.1.2 Language of Parts / Język fragmentów)

Gdy w polskojęzycznej stronie pojawia się np. angielski cytat, należy użyć:

<span lang=”en”>This is a quote in English.</span>

  • Dzięki temu czytniki ekranu zmieniają wymowę, a użytkownik nie doświadcza chaosu językowego.

Sprawdzanie poprawności językowej w ARC Toolkit

Krok po kroku:

  1. Otwórz narzędzie ARC Toolkit w Chrome DevTools.
    W zakładce „Elements” sprawdź, czy:
    • atrybut lang jest ustawiony w tagu <html>.
      występują inne znaczniki z atrybutem lang, gdy zawierają tekst w obcym języku.
  2. Jeśli język nie jest ustawiony lub ustawiono go błędnie (np. lang=”eng” zamiast lang=”en”), ARC Toolkit zgłosi błąd.

Rekomendacje audytowe:

  • Brak atrybutu lang w <html> – błąd krytyczny zgodności z WCAG 2.1 (poziom A).
    • Zalecane działanie: uzupełnić poprawny kod języka (np. pl, en, de, fr, zgodnie z ISO 639-1).
  • Niewłaściwe oznaczenie języka w fragmentach – może prowadzić do błędnej wymowy lub niezrozumienia treści.
    • Zalecane działanie: oznaczać cytaty, fragmenty tekstu, słowa kluczowe w innym języku atrybutem lang.

2. Uporządkowanie zapisu błędów kontrastu:

Zamiast:

„Błąd kontrastu w linku – tekst ma kolor #fff, tło #000, czyli OK, ale w DevTools na hover tło robi się #fff i tekst też #fff = błąd kontrastu na hoverze.”

Można zapisać:

Błąd kontrastu na hoverze linku: domyślnie tekst #fff na tle #000 (OK), ale po najechaniu tło zmienia się na #fff, przez co tekst #fff staje się niewidoczny (kontrast 1:1 – błąd dostępności).

3. Doprecyzowanie przykładów WCAG:

Jeśli chcesz, mogę pomóc w przypisaniu konkretnych kryteriów WCAG 2.1 do opisanych błędów (np. 1.4.3 dla kontrastu tekstu, 2.4.4 dla opisowych linków itp.).

4. Ujednolicenie struktur notatek:

Obecnie niektóre sekcje są zapisane jako:

  • hasła i myślniki
  • pełne zdania
  • czasami komentarze osobiste np. „widziałem to w ćwiczeniu X” itd.

Propozycja:

  • Dla wersji „roboczej” zostaw jak jest.
  • Dla wersji finalnej możesz ujednolicić układ, np.:
    • Temat: np. Błąd kontrastu
    • Opis problemu: …
    • Przykład z ćwiczenia: …
    • Odniesienie do WCAG: …

5. Drobną korektę językową:

Np.:

„czy po najechaniu myszką zmienia się wygląd linku?” → „czy link zmienia wygląd po najechaniu myszką (hover)?”

„nawigacja klawiszem tabulatora” → „nawigacja klawiszem Tab”