Dostępnik o tym, czy audytowanie wymaga znajomości HTML

Zaczynam już słyszeć zbliżających się ludzi z widłami. Jednak bohatersko przedstawię moje stanowisko w sprawie pozornie oczywistej. Czy osoby audytujące strony internetowe muszą znać HTML, ARIA, CSS?

Kiedy słyszę, że audytor dostępności powinien znać HTML, CSS i JavaScript, mam ochotę zapytać: po co? Nie jest to pytanie prowokacyjne — naprawdę chcę zrozumieć, do czego ta wiedza ma służyć. I kiedy zaczynam drążyć, okazuje się, że odpowiedź jest bardziej skomplikowana, niż mogłoby się wydawać.

Na samym początku Szkoły Dostępności Cyfrowej pojawiały się różne trudne sytuacje. Grupy bywały duże i czasem dominowały osoby prowadzące szkolenie. W pewnej grupie sytuacja tak nabrzmiała, że pojechałem porozmawiać ze wszystkimi, żeby jakoś rozwiązać konflikt. Nie będę opowiadał całej sytuacji, ale namierzyłem 3 osoby, które bardzo silnie cisnęły trenerkę i trenera. Nie podobał się im zakres programu, a główny zarzut dotyczył tego, że za mało w programie jest HTML, ARIA, CSS i JavaScript. Te 3 osoby były informatykami, doświadczonymi w tworzeniu stron internetowych.

Próbowałem argumentować, że program nie dotyczy tworzenia stron internetowych, lecz ich oceny pod kątem dostępności, ale niewiele to dało. Było dość nieprzyjemnie, bo ludzie mi przerywali, pokrzykiwali i w ogóle było słabo. We mnie zaczynało się już gotować, ale postanowiłem się nie dać. Pozbieraliśmy uwagi i część z nich wdrożyliśmy do programu. Jednak ten temat wciąż mnie męczy i postanowiłem przedstawić tutaj moje argumenty, skoro wtedy mi się nie udało.

Dwie różne prace

Budowanie stron internetowych i audytowanie ich dostępności to dwa różne zawody. Mają część wspólną, ale nie są tym samym.

Deweloper budujący stronę musi znać HTML, CSS i JavaScript. Bez tego nie zrobi swojej roboty. Audytor oceniający dostępność strony musi wiedzieć, czym jest dostępność i jak ją sprawdzić. To są inne kompetencje.

Można być świetnym programistą i słabym audytorem. Można też być doskonałym audytorem bez umiejętności napisania linii kodu. Mylenie tych dwóch ról jest źródłem nieporozumień, które naprawdę wpływają na jakość oceny dostępności.

Klasyczny przykład: obrazek bez alternatywy tekstowej

Kryterium 1.1.1 WCAG mówi, że treści nietekstowe — w tym obrazki — muszą mieć alternatywę tekstową. To jedno z najczęściej naruszanych wymagań i świetny przykład do naszej dyskusji.

Jak się to kryterium testuje? Zazwyczaj za pomocą czytnika ekranu. Audytor przechodzi przez stronę i słyszy — albo nie słyszy — opis obrazka. Nie potrzebuje do tego HTML. Wynik jest jednoznaczny: opis jest albo go nie ma.

Można też użyć narzędzia, jak Wave, które wyświetli tekst alternatywny lub oznaczy jego brak. Najbardziej chodzi mi o to, że stwierdzenie tego naruszenia w ogóle nie wymaga znajomości HTML. To nie znaczy, że znajomość HTML, CSS i ARIA są niepotrzebne. Najmniej przydatna jest znajomość JavaScript, o czym nieco dalej.

Teraz wyobraź sobie rekomendację: „Dodaj atrybut alt do elementu <img>“.

Technicznie poprawna. Praktycznie zazwyczaj bezużyteczna. Dlaczego? Bo trafia do redaktorki treści, która zarządza stroną przez WordPressa i nigdy w życiu nie widziała znacznika <img>. Ona wgrywa zdjęcia przez panel administracyjny, gdzie jest pole „Tekst alternatywny” — i to tam powinna wpisać opis. Albo do programisty używającego komponentu React, który ma własny prop alt. Albo do autora piszącego w Markdownie, dla którego właściwa instrukcja brzmi: użyj składni . Rekomendacja „dodaj atrybut alt” zakłada, że odbiorca pisze HTML ręcznie. W 2026 roku to rzadkość. Dobra rekomendacja wynika ze znajomości kontekstu implementacji — CMS-a, frameworka, narzędzia — a nie z ogólnej wiedzy o HTML.

Ten ostatni przypadek, to znaczy pisanie treści w Markdown dotyczy właśnie mnie. Moja strona wizytówkowa stoi na systemie Hugo, czyli na generatorze stron statycznych. Konwersja Markdown do HTML odbywa się pod spodem i w zasadzie nie muszę znać HTML w ogóle, bo go nie dotykam. Mam pliki Markdown z treściami i plik konfiguracyjny w YAML.

To samo dotyczy setek innych problemów. Audytor, który widzi tylko kod, może napisać technicznie poprawną rekomendację, która nie pomoże nikomu. Co więcej - skupianie się na kodzie może sprawić, że umkną te wszystkie subtelności składające się na dostępność strony lub jej brak. Tak - spotkałem strony technicznie dostępne, ale nieużyteczne. Spotkałem też takie, gdzie można było się przyczepić do wielu rzeczy, ale generalnie nadawała się do używania.

Kryteria WCAG, które nie dotyczą kodu

Warto spojrzeć szerzej. Spora część wymagań WCAG w ogóle nie wiąże się z kodem — ani z jego pisaniem, ani z jego czytaniem.

Multimedia. Kryteria z wytycznej 1.2 dotyczą napisów, transkrypcji i audiodeskrypcji. Testerem jest tu człowiek, który oglądał wideo i ocenia: czy napisy są? Czy są rzetelne? Czy audiodeskrypcja opisuje to, co istotne? To praca recenzenta treści, nie dewelopera. Żaden atrybut HTML nie zamieni złej transkrypcji w dobrą.

Zrozumiałość tekstu. Kryteria 3.1.3–3.1.6 dotyczą poziomu czytelności, wyjaśnienia skrótów, rzadko używanych słów. Są w całości redakcyjne. Jeśli tekst jest napisany językiem urzędniczym, żaden kod tego nie naprawi.

Cechy zmysłowe. Kryterium 1.3.3 sprawdza, czy instrukcje nie opierają się wyłącznie na wyglądzie lub położeniu elementu. „Kliknij zielony przycisk po lewej stronie” — to błąd, który widać w treści, nie w kodzie.

Spójność. Kryteria 3.2.3 i 3.2.4 pytają, czy elementy służące do nawigowania są umieszczone w sposób przewidywalny. To obserwacja, nie analiza kodu.

Obsługa błędów. Kryteria 3.3.1–3.3.4 oceniają jakość komunikatów błędów i podpowiedzi. Czy użytkownik wie, co zrobił źle? Czy wie, jak to naprawić? To pytanie o projekt i treść, nie o implementację.

Kiedy znajomość kodu naprawdę pomaga

Nie chcę tworzyć wrażenia, że HTML, CSS i JavaScript są w audycie zbędne. Są przypadki, gdzie ta wiedza realnie pomaga.

Złożone błędy semantyki i ARIA — gdy coś działa wizualnie, ale struktura dokumentu jest chaotyczna — wymagają zajrzenia w kod. Dynamiczne treści ładowane przez JavaScript mogą sprawiać problemy, których nie widać bez zrozumienia, co się dzieje w DOM. Przy pisaniu rekomendacji dla deweloperów w dużym projekcie precyzyjna wiedza techniczna pozwala napisać lepszą i bardziej konkretną wskazówkę.

W tym momencie chcę wrócić do JavaScript, czyli tego języka skryptowego działającego w środowisku przeglądarki. Najczęściej jest wykorzystywany do zmiany właściwości różnych elementów interfejsu oraz wzbogacania wizualnego. O ile prosty skrypt można zrozumieć, to analizowanie gotowych, czasem bardzo obszernych bibliotek, oznacza w praktyce reverse engineering. Trzeba bowiem dociec głęboko, skąd się bierze problem, aby go wyraźnie wskazać. Tymczasem podczas audytu badamy interfejs i treści strony internetowej, a nie użyte pod spodem technologie.

To jest diagnoza przyczyny — etap następujący po audycie, nie będący jego istotą. Audyt odpowiada na pytanie: czy to działa dla użytkownika? Kod jest jedną z możliwych odpowiedzi na pytanie: dlaczego nie działa?

Co powinien wiedzieć audytor

Jeśli HTML i JavaScript nie są centrum, to co nim jest?

Przede wszystkim biegłość z technologiami asystującymi. Audytor, który codziennie używa czytnika ekranu, rozumie dostępność w sposób, którego żaden kurs HTML nie zastąpi. Słyszy, gdy kolejność treści nie ma sensu. Czuje, gdy fokus gubi się po otwarciu okna modalnego. Wie, że komunikat o błędzie musi być nie tylko obecny, ale też powiązany z polem formularza w sposób, który czytnik ekranu faktycznie ogłosi.

Dalej: głęboka znajomość WCAG jako wymagań wobec doświadczenia, nie kodu. Każde kryterium sukcesu opisuje, co musi działać dla użytkownika. Kod jest jedną z możliwych ścieżek do spełnienia tego wymagania.

I wreszcie: umiejętność pisania rekomendacji do właściwej osoby. Nie „dodaj atrybut alt“, ale „w panelu WordPress, przy każdym obrazku, wypełnij pole Tekst alternatywny opisem tego, co widać na zdjęciu”. Nie „popraw kontrast koloru” w stylu CSS, ale „tekst na tym tle jest zbyt jasny — zmień jeden z kolorów tak, żeby stosunek kontrastu wynosił co najmniej 4,5 do 1”. To jest rekomendacja, która trafia do właściwej osoby i która może coś zrobić.

Zdaję sobie sprawę, że często osoba zamawiająca audyt oczekuje wskazania bardzo konkretnego rozwiązania, wraz z kodem do przeklejenia. Tylko że osoba audytująca nie zna środowiska, w którym powstała strona, na takim poziomie, jak deweloper. Wdrożenie rekomendacji należy do dewelopera, jeżeli taki jest. A rekomendacja powinna być dopasowana do konkretnego przypadku i uwzględniać odbiorcę, środowisko (na przykład CMS) i zakres zmian. Tak jak deweloper nie musi się znać na dostępności, tak osoba badająca stronę nie musi umieć kodować w PHP, TypeScript, Pythonie lub w innym języku. Bo przy ocenie dostępności najważniejsza jest ocena interfejsu.

Dostępność nie jest kwestią kodu. Jest kwestią doświadczenia — tego, czy człowiek z niepełnosprawnością może korzystać z serwisu w sposób porównywalny do innych użytkowników. Kod jest środkiem do osiągnięcia tego celu. Znać go warto. Ale myśleć, że bez niego nie można ocenić, czy cel został osiągnięty — to poważne nieporozumienie. I wiem, że się narażę wielu osobom, ale com napisał, to napisałem.

Wieści o dostępności

Skoro już rozmawiamy o HTML — jeśli chcesz go naprawdę poznać, Wojtek Kutyła prowadzi kurs semantycznego HTML, który polecam bez zastrzeżeń. To solidna wiedza o tym, jak pisać kod dostępny od podstaw. Link afiliacyjny: Kurs semantycznego HTML – humanthing.works. A od niedawna sprzedaje kolejny kurs, tym razem o WCAG. Jeszcze się z nim nie zapoznałem, więc tym razem kupujesz na własne ryzyko. Ale mam nadzieję, że dostanę darmowy dostęp i będę mógł ocenić.

☕ AutomaticA11y 2026 odbędzie się 21 maja 2026 roku w Szkole Głównej Handlowej w Warszawie. Pieniądze zebrane od 1 lutego do 30 kwietnia w całości przeznaczę na sfinansowanie tego wydarzenia. Jeśli chcesz wesprzeć konferencję — postaw mi kawę na buycoffee.to/dostepnik. Z tego miejsca chcę podziękować darczyńcom. Niektórzy byli nadzwyczaj hojni:)

Konferencja o dostępności cyfrowej 2026 odbędzie się 21 maja w Ministerstwie Cyfryzacji w Warszawie (i online przez Zoom). Temat przewodni: „Dostępność cyfrowa: od obowiązku do standardu jakości”. Trzy bloki: sektor publiczny, usługi dla seniorów i biznes prywatny. dostepnosc.pfron.org.pl

Pierwsze postępowania na podstawie Europejskiego Aktu o Dostępności. Francja, Holandia, Szwecja, Norwegia — regulatorzy zaczęli działać już kilka miesięcy po wejściu w życie EAA. W Norwegii za niedostępną aplikację medyczną nałożono kary dzienne przekraczające 5000 dolarów. Deque zebrał to wszystko w jednym artykule. Early signs of EAA enforcement across Europe

WebAIM opublikował prognozy dla dostępności cyfrowej na 2026 rok. WCAG 2.2 jako domyślny standard w zamówieniach publicznych, powrót do semantycznego HTML, AI jako wsparcie dla audytorów — nie jako ich zastępstwo. Warto przeczytać, żeby wiedzieć, co się dzieje na świecie. 2026 Predictions – WebAIM

I to by było na tyle. Robię swoje, w tym organizuję AutomaticA11y 2026. W zeszłym tygodniu wysłałem do osób zapisanych przez formularz wiadomości organizacyjne. Jeżeli nie masz jej w skrzynce odbiorczej, to sprawdź spam. A jak tam też nie będzie - napisz do mnie bezpośrednio. Na świecie nadal pomrukują bestie wojny i nienawiści, więc czasem zakładam słuchawki z ANC, żeby mieć trochę spokoju. Czego i Tobie życzę.