Pojedyncza decyzja kształtująca każdy kolejny krok to środowisko tworzenia dokumentu. Plik PDF wygenerowany z prawidłowo ustrukturyzowanego dokumentu InDesign z zastosowaną akcją Make Accessible niesie 80 procent metadanych dostępności, zanim ktokolwiek otworzy Acrobat. Plik PDF wyeksportowany z dokumentu Word, w którym nagłówki były imitowane pogrubionym i powiększonym tekstem, nie niesie niemal żadnych, a żadna ilość remediacji na dalszym etapie go w pełni nie uratuje. Wybór narzędzia do tworzenia dokumentu nie jest więc estetyczny — jest strukturalny.

Trzy ścieżki produkcyjne dominują w wydawnictwie instytucjonalnym w 2026 roku. Adobe InDesign z akcją Make Accessible to standard dla dokumentów składanych — raportów rocznych, podręczników, wniosków regulacyjnych — gdzie układ jest stały, a plik opuszcza zespół projektowy tylko raz. Microsoft Word z opcją Zapisz jako dostępny PDF to koń roboczy dla dokumentów biurowych — zasad, umów, korespondencji — gdzie źródło jest stale edytowane, a PDF jest renderem, a nie miejscem docelowym. LibreOffice z przekazaniem do PDF Accessibility Checker to ścieżka open-source stosowana przez rządy i uczelnie, które z powodów politycznych unikają stosów Microsoft i Adobe.

Pod każdym dostępnym plikiem PDF kryje się równoległa struktura logiczna — drzewo tagów — niemająca nic wspólnego z układem wizualnym. Widoczny PDF to zestaw instrukcji rysowania zaadresowanych współrzędnymi. Drzewo tagów to osobny hierarchiczny model obiektowy dokumentu, który mówi: ta operacja rysowania to pierwszy nagłówek, ta to trzecia pozycja na drugiej liście, to zdjęcie jest dekoracyjne, a tamto ma tekst alternatywny „Przychody kwartalne według segmentu, FY24“. Czytnik ekranu odczytuje drzewo tagów, nie obraz.

Sześć kategorii tagów niesie większość znaczenia w rzeczywistych dokumentach: nagłówki (H1 do H6) tworzą nawigowany konspekt; akapity (P) to ciągi prozy; listy (L, LI, Lbl, LBody) to wyliczenia uporządkowane lub nieuporządkowane; tabele (Table, TR, TH, TD) to siatki danych z nagłówkami kolumn i wierszy udostępnianymi przez atrybut Scope; figury (Figure) niosą tekst alternatywny na atrybucie Alt lub ActualText; a kolejność czytania, będąca przeszukiwaniem drzewa w głąb, decyduje o sekwencji, w jakiej czytnik ekranu czyta dokument. Strona wyglądająca poprawnie w dwóch kolumnach może być czytana w złej kolejności, jeśli drzewo tagów umieszcza prawą kolumnę przed lewą.

Dwa kolejne atrybuty mają znaczenie w każdym tagu prawidłowo przygotowanego pliku. Atrybut języka (Lang) informuje czytnik ekranu, którego słownika wymowy użyć — francuskie cytaty wewnątrz angielskiego akapitu wymagają własnego atrybutu Lang na tagu Span, inaczej zostaną odczytane z angielską fonetyką. A znacznik artefaktu odróżnia treść dekoracyjną od strukturalnej; nagłówki, stopki, numery stron i dekoracyjne linie powinny być oznaczone jako artefakty, aby czytnik ekranu je pomijał.

PDF/UA to międzynarodowy standard dostępnych plików PDF, opublikowany jako ISO 14289-1 w 2014 roku i zaktualizowany w 2024 roku. Tam gdzie WCAG jest neutralny technologicznie i platformowo, PDF/UA jest specyficzny dla PDF — to kontrakt między oprogramowaniem produkującym dokumenty, oprogramowaniem konsumującym dokumenty i technologią wspomagającą, który stwierdza: drzewo tagów, metadane i struktura tego pliku są zgodne z weryfikowalnym zestawem warunków, tak aby zgodny czytnik mógł na nich polegać.

Standard jest operacjonalizowany przez Matterhorn Protocol, utrzymywany przez PDF Association, który rozkłada PDF/UA na 31 numerowanych warunków błędów z wariantami sprawdzalnymi maszynowo i przez człowieka. Błędy sprawdzalne maszynowo obejmują brak tytułu dokumentu w metadanych, obecność figur bez Alt lub ActualText, listy zbudowane poza tagami L/LI oraz brakujące atrybuty języka w dokumencie lub w przebiegu ze zmianą języka. Błędy sprawdzane przez człowieka dotyczą tego, czego oprogramowanie nie może zweryfikować samodzielnie — czy tekst alternatywny figury faktycznie ją opisuje, czy kolejność czytania pasuje do sekwencji logicznej, czy nagłówki są zagnieżdżone logicznie, a nie z pominięciem poziomów.

Aktualizacja z 2024 roku dostosowała PDF/UA do kryteriów sukcesu WCAG 2.2 i doprecyzowała traktowanie podpisów cyfrowych i formularzy — dostępne formularze PDF muszą udostępniać etykiety pól, podpowiedzi pól i kolejność tabulacji, a podpisane pliki PDF nie mogą blokować dostępu czytnika ekranu do bazowego drzewa tagów po podpisaniu.

Gdy plik PDF przybywa bez użytecznego drzewa tagów — a większość starszych plików PDF tak właśnie wygląda — wybór inżyniera zawęża się do czterech środowisk remediacji. Każde z nich ma inną kombinację mocnych stron w zakresie edycji drzewa tagów, OCR dla zeskanowanych oryginałów, przetwarzania wsadowego i raportowania PDF/UA. Poniższa macierz mapuje możliwości według narzędzia.

Poprawnie otagowany plik PDF to tylko połowa łańcucha po stronie producenta. Drugą połową jest czytnik ekranu, a cztery czytniki, z których faktycznie korzysta większość użytkowników, traktują ten sam plik w subtelnie różny sposób. Różnice mają znaczenie, ponieważ dokument czytany płynnie w JAWS może się potykać w NVDA, a plik działający w VoiceOver na macOS może zachowywać się inaczej, gdy ten sam plik zostanie otwarty przez ChromeVox we wbudowanej przeglądarce PDF Chrome.

JAWS ma najgłębszą i najstarszą obsługę PDF spośród wszystkich komercyjnych czytników ekranu. Jego tryb PDF renderuje otagowane pliki PDF przez Acrobat lub Acrobat Reader i udostępnia drzewo tagów bezpośrednio — lista nagłówków (Insert+F6), lista formularzy (Insert+F5), nawigacja po komórkach tabeli standardowymi klawiszami tabel JAWS. Gdy plik PDF nie ma tagów, JAWS zaproponuje wywnioskowanie struktury, ale wywnioskowany wynik jest zawodny; inżynierowie nie powinni walidować względem odczytów wywnioskowanych przez JAWS.

NVDA czyta otagowane pliki PDF przez Acrobat lub Acrobat Reader, z nawigacją w trybie przeglądania odzwierciedlającym model strony internetowej — H do skakania po nagłówkach, K po linkach, T po tabelach. Obsługa PDF przez NVDA znacznie poprawiła się od 2022 roku, ale nadal ustępuje JAWS w przypadku złożonych tabel i pól formularzy. NVDA daje bardziej uczciwy feedback dla dokumentów ze zniekształconymi tagami: tam gdzie JAWS może bronić się dalej, NVDA ma tendencję do milczenia, co jest diagnostycznie przydatne.

VoiceOver na macOS czyta pliki PDF przez Preview i Safari z nawigacją rotora (VO + U) po nagłówkach, linkach, tabelach i polach formularzy. VoiceOver jest najbardziej wyrozumiały z czterech — zrekonstruuje kolejność czytania nawet dla słabo otagowanych plików — ale ta wyrozumiałość może maskować rzeczywiste błędy. Dokument czytany akceptowalnie w VoiceOver powinien mimo to zostać zweryfikowany w JAWS lub NVDA, a nie odwrotnie.

ChromeVox na ChromeOS, i szerzej zachowanie dowolnego czytnika ekranu interagującego z wbudowaną przeglądarką PDF Chrome, należy do innej kategorii. Przeglądarka PDF Chrome rasteryzuje i ponownie wyciąga tekst zamiast renderować oryginalne drzewo tagów, więc plik PDF z czystym drzewem tagów może utracić dużą część struktury, gdy zostanie otwarty bezpośrednio w Chrome. Obejściem dla kontekstów krytycznych pod względem dostępności jest wymuszenie pobrania pliku i otwarcia go w Acrobat Reader albo udostępnienie alternatywy HTML.

Łącząc łańcuch w całość: pojedynczy dostępny plik PDF przechodzi przez sześć konkretnych kroków. Są one sekwencyjne — pominięcie któregokolwiek z nich spowoduje, że plik zawiedzie na jednym z kolejnych etapów lub w rękach użytkownika.

Zespoły traktujące dostępność PDF jako problem remediacji w ostatnim przebiegu płacą rachunek dwukrotnie — raz za remediację pliku wyprodukowanego bez strukturalnej intencji, i ponownie za każdym razem, gdy ten plik jest aktualizowany. Zespoły traktujące ją jako problem tworzenia budują drzewo tagów ze źródła, odtwarzają je czysto przy każdej rewizji i używają PAC oraz czytnika ekranu do weryfikacji, a nie naprawy. Różnica kosztów między tymi dwiema postawami jest duża; różnica dostępności jest większa.

Łańcuch udokumentowany powyżej jest celowo niezależny od narzędzi na każdym ogniwie. Niezależnie od tego, czy nadrzędne narzędzie to InDesign czy LibreOffice, edytor to Acrobat czy Foxit, weryfikatorem jest PAC, a czytnikiem ekranu JAWS lub NVDA, logika strukturalna jest ta sama: style akapitowe mapują się do tagów, tagi są zgodne z PDF/UA, PDF/UA jest weryfikowany przez PAC, a czytniki ekranu odczytują wynik. Narzędzia się zmieniają; łańcuch — nie.

Dla zespołów ds. zamówień i zgodności implikacja operacyjna polega na tym, że deklaracje dostępności PDF powinny odwoływać się do łańcucha produkcyjnego — narzędzia do tworzenia, akcji eksportu, weryfikatora — a nie tylko do wyniku checkera Acrobat. Dla zespołów inżynierskich implikacja jest taka, że drzewo tagów jest źródłem prawdy, a drzewo tagów jest budowane przed jakimkolwiek plikiem PDF, który użytkownik kiedykolwiek zobaczy. Praktyczny przewodnik produkcyjny uzupełniający niniejszy primer znajdziesz w artykule PDF accessibility step-by-step playbook.