Home

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

Szczegóły
Autor: maciek
Kategoria: Uncategorised
Odsłon: 11

📌 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.:

  • „nawigacja klawiszem tabulatora” → „nawigacja klawiszem Tab”

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

 

Artykuły

Main Menu

Login Form