Dlaczego większość PDF-ów jest niedostępna?
Format PDF ma przewrotną właściwość: dokument może wyglądać świetnie na ekranie, a jednocześnie być całkowicie bezużyteczny dla czytnika ekranu. Nagłówki, tabele, kolumny – to wszystko to wizualny układ, który sam w sobie nic nie mówi oprogramowaniu wspomagającemu. Żeby czytnik ekranu wiedział, co jest nagłówkiem, a co przypisem, plik musi zawierać tagi opisujące strukturę. I tu zaczyna się problem, bo tagowanie jest niewidoczne, nie następuje automatycznie, a większość narzędzi do tworzenia PDF-ów albo tego nie robi, albo robi źle.
Problem z narzędziami do naprawy jest taki, że większość z nich zakłada, że użytkownik rozumie, czym jest „drzewo struktury dokumentu”. Adobe Acrobat Pro obsługuje naprawę dostępności sprawnie, ale żeby z niego skorzystać, trzeba wiedzieć, czego się szuka. Dla kogoś, kto po raz pierwszy styka się z tematem, to za wysoki próg wejścia.
Narzędzie PAVE
PAVE zadebiutowało w 2014 roku na Politechnice w Zurychu (ZHAW) jako próba odpowiedzi na ten problem. Pomysłem było stworzenie webowego narzędzia, które samo zrobi co może, a resztę wyjaśni krok po kroku, dodatkowo nie wymagając instalacji, płatności ani zrozumienia specyfikacji PDF/UA.
Aktualizacja narzędzia nosi nazwę PAVE 2.0, a zmiany, które przyniosła, to nowy interfejs i automatyczne wykrywanie nagłówków oraz sekcji, a także skróty klawiaturowe. Ta wersja działa do dziś pod adresem pave-pdf.org i nadal jest użyteczna dla prostych dokumentów.
Możliwości PAVE 2.0
Proces wygląda następująco: wgrywasz plik, PAVE wykonuje automatyczne korekty, ty poprawiasz to, czego automat nie ogarnie, pobierasz gotowy dokument. Plik zostaje na serwerze przez trzy tygodnie, potem jest usuwany.
Narzędzie prowadzi przez kilka kroków. Najpierw definiowanie regionów – każdy element strony dostaje etykietę (akapit, nagłówek, lista, grafika). Potem kolejność odczytu, czyli informacja dla czytnika ekranu, w jakiej kolejności ma czytać treść. Dalej nagłówki, tabele, listy, grafiki z tekstami alternatywnymi, wzory matematyczne. Na końcu metadane dokumentu i pobieranie.
Dostępność plików PDF w testowaniu
Dostępność PDF-ów rzadko pojawia się w rozmowach o testowaniu i trochę niesłusznie.
Raporty z testów, specyfikacje wymagań, dokumentacja akceptacyjna – to wszystko pliki, które zespoły QA produkują regularnie. Jeśli organizacja działa w sektorze publicznym, ochronie zdrowia, finansach albo edukacji, dostępność tych dokumentów może być wymogiem wynikającym z European Accessibility Act. Ustawa obowiązuje od 2019 roku i nakłada konkretne obowiązki na firmy dostarczające produkty i usługi cyfrowe w Europie.
Jeśli w zespole ktoś odpowiada za testy dostępności, to PAVE 2.0 daje mu praktyczne narzędzie do szybkiej weryfikacji dokumentów bez potrzeby stawiania całego środowiska testowego, bo narzędzie działa w przeglądarce.
PAVE 2.0. Praktyka
Żeby nie było, że to tylko teoria – sprawdziliśmy, jak PAVE 2.0 radzi sobie z prawdziwym dokumentem. Jako królik doświadczalny posłużyły nam Release Notes do ISTQB® CTFL v4.0 – PDF, który spora część testerów już zna. Cały proces liczy 8 kroków; poniżej opisujemy tylko te, które najlepiej pokazują, co narzędzie potrafi i gdzie się potyka. Zachęcamy Was do samodzielnego przetestowania narzędzia.
Krok 1: Zdefiniuj regiony
Po wgraniu pliku PAVE pokazał nam od razu skalę problemu. Strona pierwsza, 188 elementów, zero otagowanych. Cały dokument podświetlony na czerwono.

Jedno kliknięcie przycisku „Detect Regions” i obraz się zmienił. Każdy element dostał ramkę i etykietę: Paragraph, Heading, List, Figure. Licznik spadł do zera nieprzypisanych elementów. Automat poradził sobie z całą treścią w kilka sekund.

Nie wszystko wyszło idealnie. Stopka strony dostała etykietę „Headingraph” zamiast czegoś sensownego. To drobny defekt detekcji, który trzeba poprawić ręcznie.
Krok 2: Zdefiniuj kolejność czytania
Tu zaczęło robić się ciekawie. PAVE automatycznie przypisał numery do regionów i narysował strzałki pokazujące, w jakiej kolejności czytnik ekranu przeczyta dokument. Pierwsza automatyczna detekcja dała nam wynik chaotyczny – nagłówek z tytułem dokumentu wylądował na pozycji 10, logo ISTQB® na 5, a strzałki przecinały się przez całą stronę.

Kliknięcie „Detect Reading Order” poprawiło najbardziej oczywisty defekt: nagłówek przeskoczył na pozycję 1. Stopka nadal wymagała ręcznej korekty.

To dobra ilustracja granicy możliwości narzędzia: geometryczne wykrywanie kolejności działa dobrze dla prostych, jednokolumnowych dokumentów. Przy stopkach, nagłówkach firmowych i elementach graficznych automat potrzebuje pomocy.
Krok 6: Edytuj tekst alternatywny
PAVE wyciągnął logo ISTQB® jako osobną figurę do opisania i wyświetlił je powiększone w panelu. Pole na alternatywny tekst mamy puste, narzędzie nie wygenerowało opisu automatycznie, bo to logo, nie wykres. Czeka na człowieka. Mimo wszystko dostępny jest przycisk „Recognize Chart”, na wypadek, gdyby grafika była jednak wykresem danych, i możliwy do zaznaczenia checkbox „is decorative” dla elementów, które czytnik ekranu powinien pominąć. Limit opisu to 50 słów.

Na podglądzie dokumentu po prawej stronie różowe podświetlenia z wcześniejszych kroków zniknęły – strona wygląda normalnie. PAVE nie zmienia wizualnego układu, pracuje wyłącznie na niewidocznej warstwie struktury.
Krok 8: Sprawdź informacje meta i wyniki końcowe
Ostatni krok to metadane i pobieranie. PAVE wyciągnął z pliku tytuł, autora, język i słowo kluczowe „CTFL”. Pole Subject pozostało puste – w oryginale go nie było. Oczywiście wszystkie informacje można edytować przed pobraniem.
Na podglądzie końcowym pojawiły się zielone ramki i numeracja od 1 do 13 – dokument jest gotowy do pobrania jako dostępny PDF. Błąd w stopce („Headingraph” przy pozycji 13) przetrwał cały proces nienaprawiony (pominęliśmy go celowo).

Całość procesu zajęła nam kilka minut.
Czego PAVE nie zrobi
Limit pliku to 5 MB. Wystarczy dla prostych raportów, ale dla rozbudowanej dokumentacji technicznej może to być za mało. Skanowane dokumenty bez OCR są poza zasięgiem narzędzia, co znaczy, że jeśli tekst na stronie to zdjęcie, żadne tagowanie nie pomoże.
Złożone układy wielokolumnowe i zagnieżdżone tabele wciąż sprawiają narzędziu problemy – co zresztą widać już na przykładzie stopki w naszym teście.
I rzecz najważniejsza: żadne narzędzie automatyczne nie zastąpi ręcznego testu z czytnikiem ekranu. PAVE sprawdza, czy tagi istnieją, nie sprawdza, czy mają sens. Tekst alternatywny „rysunek1.png” technicznie rzecz biorąc jest tekstem alternatywnym, ale nikomu nie pomaga.
Podsumowanie
PAVE 2.0 znajdziecie pod adresem pave-pdf.org. Nie rozwiązuje ono problemu dostępności PDF-ów w całości – żadne narzędzie tego nie robi. Obniża jednak próg wejścia na tyle, żeby osoba bez specjalistycznej wiedzy mogła zrobić coś sensownego z dokumentem, który inaczej byłby nieczytelny dla czytnika ekranu. Jest bezpłatne, działa w przeglądarce i nie wymaga instalacji. Dla większości zastosowań – raportów, dokumentacji, materiałów szkoleniowych – to wystarczający punkt startowy.
Redakcja testerzy.pl

