Redakcja testerzy.pl
Narzędzia do sprawdzania dostępności PDF-ów albo naprawiają plik, albo tylko sprawdzają, co jest w nim nie tak. axesCheck i PAC należą do tej drugiej grupy. Nie dołożą ani jednego tagu, ale powiedzą, czy dokument spełnia wymagania PDF/UA i WCAG.
Oba narzędzia pochodzą od niemieckiej firmy axes4 i są darmowe, ale różnią się na tyle, że dla testera wybór między nimi bywa istotny. PAC działa od 2010 roku i jest finansowany przez niemieckie Federalne Ministerstwo Pracy i Spraw Socjalnych. axesCheck to jego webowy odpowiednik. Sprawdzamy oba na jednym dokumencie i pokazujemy, dlaczego ten sam plik daje w nich dwa różne rezultaty.
Dwa wcielenia tego samego silnika
axesCheck to wersja przeglądarkowa narzędzia. Wgrywasz plik, dostajesz wynik na stronie, limit wynosi 10 MB. Pod spodem pracuje moduł axesSense, który axes4 oferuje też do integracji z systemami CMS i DMS, gdy trzeba sprawdzać dokumenty masowo po stronie serwera.
PAC jest aplikacją desktopową, dostępną wyłącznie na system operacyjny Windows. Sprawdza plik lokalnie, bez wysyłania go gdziekolwiek. To pierwsza różnica, która ma praktyczne konsekwencje: axesCheck wymaga przesłania dokumentu na serwer axes4, PAC analizuje go na dysku użytkownika. Przy raporcie zawierającym dane klienta albo dokumentacji objętej umową o poufności decyduje to, czy w ogóle warto sięgnąć po dane narzędzie.
Co weryfikują?
Oba narzędzia sprawdzają zgodność z dwoma standardami: PDF/UA (ISO 14289-1, według Matterhorn Protocol) oraz WCAG na poziomie A i AA, z istotnym zastrzeżeniem, które axes4 podaje wprost – wyłącznie kryteria sprawdzalne maszynowo.
Oznacza to, że narzędzie potwierdza istnienie tagu, ale nie ocenia, czy ma on sens. Tekst alternatywny „rysunek1.png” przejdzie kontrolę obecności tekstu alternatywnego, choć nie niesie żadnej informacji. Dlatego PAC dokłada podgląd struktury i podgląd dla czytnika ekranu, żeby człowiek mógł wykonać tę część pracy, której automat nie wykona. Narzędzie wskazuje miejsca do sprawdzenia, ocena ich sensowności pozostaje po stronie testera.
Test na realnym pliku
Do sprawdzenia wykorzystaliśmy ten sam dokument, co przy testach PAVE – Release Notes do ISTQB® CTFL v4.0. Plik jest surowy, nieotagowany, wyeksportowany z Worda przez Ghostscript, liczy dwie strony, waży 108 kB, ma zero tagów i nie ma zdefiniowanego języka. Nie naprawialiśmy go wcześniej celowo, interesowało nas, jak wersja webowa i desktopowa zachowają się wobec dokumentu pozbawionego warstwy struktury.
axesCheck
axesCheck przerwał analizę niemal od razu. Komunikat, który otrzymaliśmy po załadowaniu pliku na serwer, brzmiał: „Basic Requirements for accessible PDFs not met. The PDF does not contain a tag structure”. Bez tagów nie ma struktury do oceny, więc narzędzie nie sprawdza nic więcej. Zamiast wyniku pojawia się propozycja przesłania pliku do axesService, czyli płatnej usługi remediacji axes4.
Logicznie trudno to zakwestionować: bez warstwy tagów rzeczywiście nie da się ocenić struktury logicznej dokumentu. Z perspektywy testera, który chce poznać skalę problemu, wersja webowa zatrzymuje się jednak dokładnie tam, gdzie zaczyna się właściwa analiza problemów.
PAC
Ten sam plik, ta sama diagnoza wyjściowa – brak tagów – a PAC przeanalizował dokument do końca i rozłożył wynik na cztery zakładki.
PDF/UA. Dokument niezgodny. PDF Syntax i Fonts bez zarzutu, ale Content z 2440 defektami i Natural language z 2404 defektami, a do tego braki w strukturze logicznej i ustawieniach dokumentu.
WCAG 2.2. Również niezgodny. Kryterium 1.3 Adaptable – 2441 defektów. 3.1 Readable – 2404 defekty, czyli ten sam brak języka dokumentu liczony według innego standardu. Kryteria 1.4 Distinguishable i 4.1 Compatible zaliczone.
Quality. Ostrzeżenia jakościowe, które nie są twardym naruszeniem standardu, ale wpływają na rzeczywistą użyteczność dokumentu, między innymi ostrzeżenie dotyczące nagłówków.
AI. Nowa zakładka w PAC 2026, do której wrócimy. Wynik dla naszego pliku: Missing structural elements – 2 zaliczone, 25 z ostrzeżeniem.
Wersja webowa odpowiedziała „nie da się sprawdzić”, wersja desktopowa na tym samym pliku wskazała konkretne miejsca z problemami. To nie kwestia tego, że jedna jest lepsza od drugiej, tylko innego progu wejścia. Dla pliku bez tagów axesCheck zamyka temat i kieruje do płatnej usługi, PAC kontynuuje analizę i podaje liczby.
Liczby wymagają interpretacji
2440 defektów w sekcji Content na dwóch stronach wygląda alarmująco. To jednak nie 2440 osobnych usterek do ręcznego poprawienia, lecz zliczenie każdego nieotagowanego fragmentu treści osobno – każdej linii, każdego elementu pozbawionego przypisanej struktury. Jeden brak, czyli zero tagów w całym pliku, rozłożony na tysiące pozycji w raporcie.
Narzędzie liczy, ale nie interpretuje. Po dołożeniu warstwy tagów większość tych pozycji zniknie jednocześnie. Tester, który potraktuje czterocyfrowy licznik jako miarę nakładu pracy, źle oszacuje zadanie, a narzędzie mu w tym nie pomoże, bo podaje surowy wynik, nie jego znaczenie.
Kontrole AI w PAC 2026
PAC 2026 dodał zakładkę z testami opartymi na AI i opisuje ją jako pierwsze na świecie narzędzie weryfikujące, które ocenia jakość semantyki PDF za pomocą AI. Deklaracje producenta warto sprawdzić u źródła, więc ustaliliśmy, co ta funkcja faktycznie robi, a czego nie.
Mechanizm porównuje tag zapisany w dokumencie z tym, co model rozpoznaje semantycznie w danym miejscu. Gdy model widzi nagłówek, a w pliku znajduje się tag akapitu, zgłasza rozbieżność – jako błąd albo jako ostrzeżenie, w zależności od pewności oceny. Stąd wynik „25 z ostrzeżeniem”, bo model wykrył miejsca, w których struktura nie zgadza się z rozpoznawaną semantyką, ale nie na tyle pewnie, by uznać to za twardy błąd.
Dwie informacje, które axes4 podaje wprost, zmieniają ocenę tej funkcji. Pierwsza: model dostarczany jest razem z PAC i działa wyłącznie lokalnie, bez dostępu do Internetu. To domyka kwestię poufności – kontrole AI nie wysyłają pliku nigdzie. Druga, która studzi oczekiwania: ta AI nie generuje ani nie ocenia tekstu alternatywnego. Do tego potrzebny byłby duży model językowy w rodzaju ChatGPT, którego PAC nie zawiera, o czym producent uczciwie pisze. AI w PAC ocenia strukturę, a nie treść opisów.
Funkcja robi więc krok w stronę tego, czego maszynowy sprawdzacz dotąd nie potrafił, tzn. zaczyna oceniać, czy tag odpowiada treści, a nie tylko czy istnieje. Pozostaje jednak weryfikacja struktury, nie sensu opisów. Granica, o której pisaliśmy przy PAVE, przesunęła się, ale nie zniknęła.
Ograniczenia narzędzi pokroju axesCheck i PAC
Najważniejsze ograniczenie jest też najprostsze: narzędzie oczywiście nie naprawi nam pliku. Zwraca listę, raport i pracę do wykonania. Remediację przeprowadza się osobno, np. ręcznie w Acrobacie, w PAVE albo w płatnym axesPDF od tego samego producenta. axesCheck dodatkowo wymaga przesłania pliku o maksymalnej wadze 10 MB na serwer. PAC działa lokalnie i bez takiego limitu, ale wyłącznie na Windowsie, więc użytkownicy macOS i Linuksa zostają z wersją webową.
Istnieje też ograniczenie wspólne dla każdego automatu. Żadne z tego typu narzędzi nie zastąpi ręcznego testu z czytnikiem ekranu. PAC sam to przyznaje i dlatego dołącza podgląd struktury oraz podgląd dla czytnika ekranu. Maszyna potwierdzi, że tag istnieje i że odpowiada treści. Czy układ czyta się sensownie, czy kolejność elementów jest poprawna i czy opis grafiki cokolwiek przekazuje – to ocena, która zostaje przy człowieku.
Podsumowanie
PAC pobierzesz ze strony pac.pdf-accessibility.org, axesCheck działa w przeglądarce pod adresem check.axes4.com. Oba są darmowe.
Przy dokumentach, których nie wolno przesyłać na zewnątrz, wybór jest jednoznaczny – PAC, lokalnie. Do szybkiego sprawdzenia pojedynczego pliku bez instalacji wystarcza axesCheck, pod warunkiem że plik ma już strukturę do oceny. Dla dokumentu całkowicie surowego wersja webowa odeśle do płatnej usługi, a desktopowa pokaże, z czym mamy do czynienia.
