PAVE 2.0
Weź dowolny raport z testów, specyfikację wymagań albo dokumentację techniczną zapisaną jako PDF. Z dużym prawdopodobieństwem czytnik ekranu nie da rady go odczytać. Nie ma w tym złej woli, po prostu nikt przy tworzeniu tego pliku nie zadbał o dostępność. PAVE (PDF Accessibility Validation Engine) to darmowe, webowe narzędzie, które pozwala rozwiązać ten problem bez konieczności znajomości wewnętrznej struktury plików PDF.

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. 

Infografika: 8 kroków remediacji dostępności PDF w narzędziu PAVE – od definiowania regionów i kolejności czytania, przez nagłówki, tabele i listy, po teksty alternatywne figur i formuł, aż po metadane dokumentuWidok główny PAVE 2.0 – ekran wgrywania pliku z polem przeciągnij i upuść oraz paskiem nawigacji ośmiu kroków remediacji po lewej stronie

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. 

PAVE 2.0, krok 1: podgląd pierwszej strony dokumentu ISTQB CTFL Release Notes z 188 nieotagowanymi elementami podświetlonymi na czerwono, przed uruchomieniem automatycznego wykrywania regionów
 
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. 

PAVE 2.0, krok 1 po wykryciu regionów: każdy element strony otagowany i oznaczony kolorową ramką z etykietą (Figure, Paragraph, Heading, List), licznik spada do zera nieotagowanych elementów
 
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ę. 

PAVE 2.0, krok 2: błędna kolejność czytania po automatycznej detekcji – strzałki przecinają stronę, nagłówek dokumentu na pozycji 10, logo ISTQB na pozycji 5
 
Kliknięcie „Detect Reading Order” poprawiło najbardziej oczywisty defekt: nagłówek przeskoczył na pozycję 1. Stopka nadal wymagała ręcznej korekty. 

PAVE 2.0, krok 2 po korekcie kolejności: nagłówek dokumentu na pozycji 1, strzałki prowadzą logicznie od góry strony w dół, stopka pozostaje błędnie otagowana jako Headingraph
 
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. 

PAVE 2.0, krok 6: panel edycji tekstu alternatywnego z powiększonym logo ISTQB i pustym polem na opis – narzędzie czeka na ręczne uzupełnienie przez użytkownika
 
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).

PAVE 2.0, krok 8: formularz metadanych z uzupełnionym tytułem, autorem i językiem oraz podgląd dokumentu z zielonymi ramkami i numeracją regionów 1–13 gotowego do pobrania
 
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. 

Jak oceniasz potencjał narzędzia PAVE 2.0 w kontekście swoich codziennych zadań?
Jak oceniasz potencjał narzędzia PAVE 2.0 w kontekście swoich codziennych zadań?
0 %
Brzmi świetnie – na pewno przetestuję je przy najbliższym raporcie z testów lub specyfikacji.
0 %
Wygląda ciekawie, ale ograniczenie do 5 MB i brak obsługi OCR to dla mnie za duże minusy.
0 %
Może być przydatne jako szybki, wstępny krok, ale i tak wolę tradycyjne metody weryfikacji.
0 %
Raczej z niego nie skorzystam – rzadko pracuję z plikami PDF w swojej roli.
Łącznie głosów: 0

To powinno Cię zainteresować