De beslissing die elke latere stap bepaalt, is de schrijfomgeving. Een PDF gegenereerd vanuit een correct gestructureerd InDesign-document waarop de Make Accessible-actie is toegepast, bevat 80 procent van zijn toegankelijkheidsmetadata voordat iemand Acrobat opent. Een PDF geëxporteerd vanuit een Word-document waarbij koppen werden nagebootst met vet-en-groter-tekst, bevat bijna niets, en geen hoeveelheid downstream-herstel kan dat volledig redden. De keuze van schrijftool is met andere woorden niet esthetisch. Het is structureel.

Drie productiepaden domineren institutionele publicatie in 2026. Adobe InDesign met de Make Accessible-actie is de standaard voor opgemaakte documenten — jaarverslagen, leerboeken, regulatoire indieningen — waarbij de opmaak vast is en het bestand het ontwerpteam slechts eenmaal verlaat. Microsoft Word met Opslaan als toegankelijke PDF is het werkpaard voor kantoorstukken — beleidsregels, contracten, brieven — waarbij de bron continu wordt bewerkt en de PDF een weergave is in plaats van een eindbestemming. LibreOffice met de PDF Accessibility Checker-overdracht is het open-sourcepad dat door overheden en universiteiten wordt gebruikt die beleidsmatige redenen hebben om Microsoft- en Adobe-stacks te vermijden.

Onder elke toegankelijke PDF bevindt zich een parallelle logische structuur — de tagboom — die niets te maken heeft met de visuele opmaak. De zichtbare PDF is een coördinaat-geadresseerde verfinstucctieset. De tagboom is een apart hiërarchisch documentobjectmodel dat zegt: deze verfbewerking is de eerste kop, die is het derde punt van de tweede lijst, deze afbeelding is decoratief, die andere afbeelding heeft alternatieve tekst “Kwartaalomzet per segment, FY24”. Een schermlezer leest de tagboom, niet de verf.

Zes tagcategorieën dragen het meeste van de betekenis in real-world documenten: koppen (H1 tot H6) vormen de navigeerbare structuur; alinea’s (P) zijn de prosastromen; lijsten (L, LI, Lbl, LBody) zijn de geordende of ongeordende opsommingen; tabellen (Table, TR, TH, TD) zijn de datarasters met kolom- en rijkoppen blootgesteld via het Scope-attribuut; figuren (Figure) dragen de alternatieve tekst op hun Alt- of ActualText-attribuut; en de leesvolgorde, dat de diepte-eerste doorloop van de boom zelf is, bepaalt de volgorde waarin een schermlezer het document uitspreekt. Een pagina die er visueel goed uitziet in twee kolommen kan in de verkeerde volgorde worden gelezen als de tagboom de rechterkolom vóór de linkerkolom plaatst.

Twee meer attributen zijn van belang bij elke tag in een correct geproduceerd bestand. Het taalattribuut (Lang) vertelt de schermlezer welk uitspraakwoordenboek te gebruiken — Frans geciteerd in een Engelse alinea heeft zijn eigen Lang-attribuut nodig op een Span-tag, anders wordt het met Engelse klanken uitgesproken. En de artefactmarkering onderscheidt decoratieve inhoud van structurele inhoud; kopteksten, voetteksten, paginanummers en decoratieve regels moeten allemaal als artefacten worden gemarkeerd zodat de schermlezer ze overslaat.

PDF/UA is de internationale standaard voor toegankelijke PDF’s, gepubliceerd als ISO 14289-1 in 2014 en bijgewerkt in 2024. Waar WCAG technologieneutraal en platformneutraal is, is PDF/UA PDF-specifiek — het is het contract tussen documentproducentsoftware, documentconsumentsoftware en hulptechnologie dat zegt: de tagboom, metadata en structuur van dit bestand voldoen aan een verifieerbare set condities, zodat een conforme lezer erop kan vertrouwen.

De standaard wordt geoperationaliseerd via het Matterhorn Protocol, onderhouden door de PDF Association, dat PDF/UA opsplitst in 31 genummerde faalcondities met zowel machinaal controleerbare als door mensen controleerbare varianten. Machinaal controleerbare fouten omvatten het ontbreken van een documenttitel in metadata, de aanwezigheid van figuren zonder Alt of ActualText, lijsten buiten L/LI-tags, en ontbrekende taalattributen op het document of op taalwisselende passages. Door mensen controleerbare fouten dekken wat software zelf niet kan verifiëren — of de alternatieve tekst bij een Figure de figuur daadwerkelijk beschrijft, of de leesvolgorde overeenkomt met de logische volgorde, of koppen logisch zijn genest in plaats van niveaus overslaan.

De update van 2024 stemde PDF/UA af op de WCAG 2.2-succescriteria en verduidelijkte de behandeling van digitale handtekeningen en formulieren — toegankelijke PDF-formulieren moeten veldlabels, veldtooltips en tabvolgorde blootstellen, en ondertekende PDF’s mogen de schermlezertoegang tot de onderliggende tagboom na ondertekening niet blokkeren.

Wanneer een PDF binnenkomt zonder bruikbare tagboom — en de meeste verouderde PDF’s hebben dat — versmalt de keuze van de engineer tot vier herstelomgevingen. Elk heeft een andere combinatie van sterke punten in tagboombeheer, OCR voor gescande originelen, batchverwerking en PDF/UA-rapportage. De matrix hieronder brengt capaciteiten in kaart per tool.

Een correct getagde PDF is slechts de helft van de productketen. De andere helft is de schermlezer, en de vier lezers die gebruikers het meest inzetten, behandelen hetzelfde bestand op subtiel verschillende manieren. De verschillen zijn van belang omdat een document dat in JAWS soepel wordt gelezen, kan stotteren in NVDA, en een bestand dat werkt in VoiceOver op macOS zich anders kan gedragen wanneer hetzelfde bestand wordt geopend door ChromeVox in de ingebouwde PDF-viewer van Chrome.

JAWS heeft de diepste, oudste PDF-ondersteuning van alle commerciële schermlezers. De PDF Mode geeft getagde PDF’s weer via Acrobat of Acrobat Reader en stelt de tagboom direct bloot — koppenlijst (Insert+F6), formulierenlijst (Insert+F5), tabelcelnavigatie met de standaard JAWS-tabeltoetsen. Wanneer een PDF geen tags heeft, biedt JAWS aan structuur af te leiden, maar het afgeleide resultaat is onbetrouwbaar; engineers mogen niet valideren op basis van door JAWS afgeleide lezingen.

NVDA leest getagde PDF’s ook via Acrobat of Acrobat Reader, met browsmodus-navigatie die zijn webpagina-model weerspiegelt — H om koppen te springen, K om links te springen, T om tabellen te springen. NVDA’s PDF-ondersteuning is since 2022 merkbaar verbeterd maar loopt nog achter op JAWS bij complexe tabellen en formuliervelden. NVDA geeft eerlijker feedback voor documenten met misvormde tags: waar JAWS kan doorzoeken, valt NVDA vaak stil, wat diagnostisch nuttig is.

VoiceOver op macOS leest PDF’s via Preview en Safari met rotornavigatie (VO + U) over koppen, links, tabellen en formuliervelden. VoiceOver is de meest vergevingsgezinde van de vier — het zal een leesvolgorde reconstrueren zelfs voor slecht getagde bestanden — maar zijn vergevingsgezindheid kan echte fouten maskeren. Een document dat acceptabel leest in VoiceOver moet nog steeds worden geverifieerd met JAWS of NVDA, niet andersom.

ChromeVox op ChromeOS, en het bredere gedrag van elke schermlezer die werkt met de ingebouwde PDF-viewer van Chrome, valt in een andere categorie. De PDF-viewer van Chrome rastert en extraheert tekst opnieuw in plaats van de oorspronkelijke tagboom te renderen, zodat een PDF met een schone tagboom veel van zijn structuur kan verliezen wanneer die direct in Chrome wordt geopend. De workaround voor toegankelijkheidskritische contexten is het bestand te downloaden en te openen in Acrobat Reader, of een HTML-alternatief te bieden.

De keten samengevat: een enkele toegankelijke PDF doorloopt zes concrete stappen. Ze zijn sequentieel — het overslaan van één stap produceert een bestand dat faalt in een van de latere stappen of in de handen van de gebruiker.

Teams die PDF-toegankelijkheid behandelen als een afsluitend herstelingsprobleem betalen de rekening tweemaal — eenmaal om een bestand te herstellen dat zonder structurele intentie is geproduceerd, en opnieuw elke keer dat het bestand wordt bijgewerkt. Teams die het behandelen als een schrijfprobleem bouwen de tagboom bij de bron, genereren hem schoon bij elke revisie, en gebruiken PAC en een schermlezer als verificatie in plaats van als reparatie. Het kostenverschil tussen de twee houdingen is groot; het toegankelijkheidsverschil is groter.

De keten die hierboven is gedocumenteerd is bewust tool-agnostisch bij elke schakel. Of de upstream InDesign of LibreOffice is, de editor Acrobat of Foxit, de verificateur PAC, en de schermlezer JAWS of NVDA, de structurele logica is dezelfde: alineaopmaak wordt gekoppeld aan tags, tags voldoen aan PDF/UA, PDF/UA wordt geverifieerd door PAC, en schermlezers lezen het resultaat. Tools veranderen; de keten niet.

Voor aanbestedende en nalevingsteams is de operationele implicatie dat PDF-toegankelijkheidsverklaringen de productieketen moeten vermelden — de schrijftool, de exportactie, de verificateur — niet alleen een Acrobat-controleresultaat. Voor engineeringteams is de implicatie dat de tagboom de bron van waarheid is, en dat de tagboom upstream van elke PDF die de gebruiker ooit ziet wordt opgebouwd. Zie voor een praktische productie-doorloop die deze primer aanvult het stapsgewijze draaiboek voor PDF-toegankelijkheid.