Uncategorised

Szczegóły

Autor: maciek

Kategoria: Uncategorised

Opublikowano: 02 czerwiec 2025

Odsłon: 10

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

11. 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)?”