PDF-toegankelijkheidsgids: tags & PDF/UA

PDF’s zijn het stille toegankelijkheidsprobleem binnen vrijwel elke organisatie. Websites worden geaudit, opnieuw ontworpen en getest met schermlezers — maar het jaarverslag, het beleidsdocument, het uitkeringsoverzicht en het aanvraagformulier die achter een downloadlink leven, worden maar al te vaak precies zo verstuurd als ze uit het exportvenster kwamen. Voor een ziende lezer zien ze er verzorgd uit. Voor iemand die een schermlezer, een vergrotingsprogramma of alleen het toetsenbord gebruikt, kan datzelfde bestand een ondoordringbare muur zijn: geen koppen om tussen te springen, afbeeldingen zonder beschrijving, tabellen die als een betekenisloze stroom getallen worden voorgelezen, en formuliervelden die helemaal niet kunnen worden ingevuld.

Deze gids legt uit waarom PDF’s zo vaak ontoegankelijk zijn en wat een PDF werkelijk bruikbaar maakt voor hulptechnologie. Hij behandelt de structurele bouwstenen — tags, leesvolgorde, alternatieve tekst, tabellen, formulieren en metadata — en de standaarden die ze regelen: WCAG 2.2 en PDF/UA, de ISO 14289-specificatie voor toegankelijke getagde PDF’s. Het doel is steeds hetzelfde dat QualiBooth toepast op elk document dat we aanraken: een bestand dat in de praktijk werkt, bevestigd met echte hulptechnologie, niet alleen goedgekeurd door een geautomatiseerde checker.

Waarom PDF’s zo vaak ontoegankelijk zijn

Een PDF is in de kern een beschrijving van hoe markeringen op een pagina moeten worden geschilderd. Het formaat is ontworpen om visuele getrouwheid te behouden — om een document er identiek uit te laten zien op elk scherm of elke printer. Precies dat ontwerpdoel maakt toegankelijkheid moeilijk. Visuele getrouwheid zegt niets over betekenis. Een regel vetgedrukte tekst van 18 punt ziet er voor het menselijk oog uit als een kop, maar tenzij het bestand expliciet vastlegt “dit is een kop”, heeft hulptechnologie geen manier om te weten dat het iets anders is dan wat grotere lettertekens.

De meeste PDF’s in omloop zijn niet getagd. Ze bevatten de visuele inhoud maar geen van de onderliggende structuur — geen informatie over wat een kop, een paragraaf, een lijst, een tabel of een afbeelding is. Een schermlezer die wordt geconfronteerd met een niet-getagde PDF weigert deze ofwel zinvol voor te lezen, of valt terug op giswerk en leidt een leesvolgorde af uit de positie van markeringen op de pagina. De resultaten variëren van onhandig tot onbruikbaar: een nieuwsbrief in twee kolommen die dwars over beide kolommen wordt voorgelezen, een bijschrift dat vóór de paragraaf wordt voorgelezen waar het bij hoort, of voetnoten die midden in een zin verschijnen.

Verschillende veelvoorkomende productiegewoonten maken het erger:

Gescande documenten. Een scan is slechts een afbeelding van een pagina. Zonder optische tekenherkenning (OCR) is er helemaal geen echte tekst — niets om te lezen, te doorzoeken of te selecteren.
Exports die structuur weggooien. Veel “Opslaan als PDF”- en “Afdrukken naar PDF”-routes gooien de kop- en lijststructuur weg die in het brondocument bestond.
Lay-outs uit ontwerptools. Bestanden gemaakt in opmaaksoftware kunnen visueel correcte pagina’s hebben waarvan de onderliggende objectvolgorde geen enkele relatie heeft met de bedoelde leesvolgorde.
Decoratieve rommel. Achtergrondafbeeldingen, lijnen en versieringen worden blootgesteld aan hulptechnologie en aangekondigd alsof ze betekenis droegen.

Niets hiervan is zichtbaar op het scherm, en juist daarom blijft het probleem bestaan. De oplossing is om de structurele laag toe te voegen die het formaat optioneel laat — het werk van PDF-remediatie.

Tags en documentstructuur

Tags zijn de basis van een toegankelijke PDF. Een getagde PDF draagt een verborgen hiërarchie — de structuurboom — die naast de visuele inhoud staat en beschrijft wat elk onderdeel van de pagina werkelijk is. Dit is direct vergelijkbaar met de semantische HTML achter een goed gebouwde webpagina: waar HTML <h1>, <p>, <ul> en <table> gebruikt, gebruikt een getagde PDF structuurelementen zoals <H1>, <P>, <L> (lijst) en <Table>.

De tagboom is wat hulptechnologie iets geeft om door te navigeren. Met die boom op zijn plaats kan een schermlezer de dingen doen waar de gebruikers op vertrouwen:

Springen per kop. Gebruikers bewegen door een lang document van kop naar kop in plaats van naar elk woord op volgorde te luisteren. Dit vereist echte koptags (<H1> tot en met <H6>) toegepast in een logische, geneste volgorde — nooit niveaus overslaan, nooit een kop nabootsen door een paragraaf vet te maken.
Lijsten begrijpen. Een <L>-tag met de <LI>-items vertelt de schermlezer “dit is een lijst van vijf items”, zodat de gebruiker weet waar hij is en hoeveel er nog over is.
Inhoud onderscheiden van decoratie. Echte inhoud wordt getagd; puur decoratieve markeringen worden aangewezen als artefacten zodat ze volledig worden overgeslagen.

Een correcte, logisch geneste kopstructuur is het enige met de grootste impact dat je goed kunt krijgen in een PDF, omdat het een lineaire luisterervaring verandert in een navigeerbare. Het verkeerd doen — of weglaten — is een van de veelvoorkomende toegankelijkheidsproblemen die keer op keer opduiken in documentaudits.

Leesvolgorde

Tags zeggen wat elk element is. Leesvolgorde zegt in welke volgorde die elementen worden gepresenteerd aan iemand die de pagina niet kan zien. De twee zijn gerelateerd maar onderscheiden, en leesvolgorde is waar veel overigens goed getagde PDF’s de mist in gaan.

Een schermlezer kondigt inhoud aan in de volgorde die door de structuur van het document is gedefinieerd, niet in de volgorde waarin de markeringen toevallig in het bestand staan. In een document met één kolom komen de twee meestal overeen. In iets ingewikkelders — lay-outs met meerdere kolommen, zijbalken, citaten, bijschriften, tekst die om een afbeelding heen loopt — lopen ze vaak uiteen. Het ziende oog herordent inhoud moeiteloos; hulptechnologie volgt de volgorde die het krijgt, en als die volgorde verkeerd is, stort de betekenis in.

Een goede leesvolgorde betekent dat de inhoud wordt aangekondigd in de volgorde die een ziende lezer van nature zou volgen: de kop vóór de hoofdtekst, de inleiding vóór de zijbalk, een bijschrift na de afbeelding die het beschrijft. Het correct instellen is een handmatig oordeel over hoe het document bedoeld is om gelezen te worden, en daarom kunnen geautomatiseerde tools alleen het niet garanderen. Het is een van de kernopleveringen van professionele PDF-remediatie, en een van de eerste dingen die ervaren testers controleren.

Alternatieve tekst voor afbeeldingen

Elke afbeelding die informatie draagt heeft een tekstequivalent nodig zodat deze kan worden beschreven aan mensen die haar niet kunnen zien. De principes zijn dezelfde als voor het web, toegepast via PDF-tags.

Informatieve afbeeldingen — grafieken, diagrammen, foto’s die betekenis overbrengen, infographics — hebben beknopte, accurate alternatieve tekst nodig die dezelfde informatie communiceert als de afbeelding. Voor een grafiek betekent dat vaak het samenvatten van de kernboodschap (“De omzet groeide 12% jaar op jaar”) in plaats van het visuele te beschrijven (“een staafdiagram in blauw”).
Complexe afbeeldingen — een gedetailleerd processchema of een gegevensrijke figuur — hebben mogelijk zowel korte alt-tekst als een langere beschrijving nodig, of de onderliggende gegevens elders in het document in een toegankelijke vorm gepresenteerd.
Decoratieve afbeeldingen — randen, achtergrondtexturen, sierscheidingen, een logo dat herhaald wordt in een voettekst — moeten worden gemarkeerd als artefacten zodat hulptechnologie ze overslaat. Een schermlezer dwingen “afbeelding, afbeelding, afbeelding” aan te kondigen voor decoratie is op zichzelf een toegankelijkheidsfalen.
Tekst binnen afbeeldingen — een grafische weergave van een citaat, een gescand briefhoofd, een knopafbeelding met een label — moet die tekst vastleggen, ofwel als alt-tekst of, beter, als echte selecteerbare tekst.

Het schrijven van goede alt-tekst is een inhoudelijke taak, geen technische. Het vereist begrip van waar de afbeelding voor is in haar context — dezelfde vaardigheid die ons team voor toegankelijkheidsadvies inbrengt bij webinhoud.

Toegankelijke tabellen

Tabellen zijn waar PDF-toegankelijkheid echt moeilijk wordt, en waar geautomatiseerde exports het vaakst falen. Een gegevenstabel communiceert betekenis via de relatie tussen een cel en de bijbehorende rij- en kolomkoppen. Ziende lezers reconstrueren die relaties visueel door omhoog en naar links te kijken. Een schermlezergebruiker kan dat niet — die is afhankelijk van de opmaak van de tabel zodat de kopassociaties expliciet zijn.

Een toegankelijke PDF-tabel heeft nodig:

Een juiste <Table>-structuur met <TR> (rijen), <TH> (kopcellen) en <TD> (gegevenscellen), in plaats van een los raster van tekst dat zo is gepositioneerd dat het eruitziet als een tabel.
Kopcellen die correct zijn geïdentificeerd, met bereik (rij of kolom) waar de tabelopmaak dat vereist, zodat terwijl een gebruiker door de gegevens beweegt de relevante koppen opnieuw worden aangekondigd (“Q3, Omzet, 1,2 miljoen”).
Een verstandige verwerking van samengevoegde of overspannen cellen, die de kopelrelaties compliceren en geautomatiseerde tooling vaak in verwarring brengen.

Een veelvoorkomend anti-patroon is de lay-outtabel — een raster dat puur wordt gebruikt om inhoud visueel te positioneren, zonder echte gegevensrelaties. Lay-outtabellen mogen helemaal niet als tabellen worden getagd, omdat dit hulptechnologie dwingt fantoomrijen en -kolommen aan te kondigen. Het onderscheiden van een gegevenstabel van een lay-outartefact, en vervolgens de juiste relaties coderen, is gedetailleerd handmatig werk dat enorm profiteert van beoordeling door mensen die zelf elke dag schermlezers gebruiken.

Toegankelijke PDF-formulieren

Formulieren zijn de documenten met de hoogste inzet die een organisatie publiceert, omdat ze transactioneel zijn: een aanvraag, een claim, een toestemming, een registratie. Als een PDF-formulier niet met hulptechnologie kan worden ingevuld, wordt de persoon niet slechts ongemak bezorgd — die wordt uitgesloten van een dienst.

Een toegankelijk PDF-formulier vereist:

Gelabelde velden. Elk veld — tekstinvoer, selectievakje, keuzerondje, vervolgkeuzelijst — heeft een toegankelijke naam nodig (een tooltip/label in PDF-termen) zodat een schermlezer aankondigt waar het veld voor dient, niet alleen “tekst bewerken”.
Logische tabvolgorde. Toetsenbordgebruikers bewegen met Tab door velden. De tabvolgorde moet de visuele en logische stroom van het formulier volgen, niet de volgorde waarin de velden in de editor zijn toegevoegd.
Gegroepeerde besturingselementen. Gerelateerde keuzerondjes en selectievakjes moeten worden gegroepeerd zodat hun gedeelde vraag eenmaal wordt aangekondigd en de opties als een geheel worden begrepen.
Verplichte velden en instructies. Verplichte velden, opmaakvereisten en foutbegeleiding moeten in tekst worden overgebracht, niet alleen via kleur of visuele aanwijzingen.
Volledige toetsenbordbediening. Elk veld moet bereikbaar en bedienbaar zijn zonder muis.

Formulieren bevinden zich op het snijpunt van structuur, interactie en inhoud, wat ze het onderdeel van PDF-werk maakt waar het correct doen het meest telt. Dezelfde discipline geldt voor andere transactionele documenten — het is nauw verwant aan de zorg die nodig is voor toegankelijke e-mail, waar structuur en labeling bepalen of een bericht daadwerkelijk kan worden gebruikt.

Taal, titel en metadata

Sommige van de meest impactvolle PDF-oplossingen zijn ook de kleinste. Een handvol eigenschappen op documentniveau verandert wezenlijk hoe hulptechnologie een bestand verwerkt.

Documenttaal. De PDF moet zijn primaire taal aangeven (bijvoorbeeld en-GB) zodat een schermlezer de juiste uitspraakregels gebruikt. Een Franse paragraaf gelezen met Engelse fonetiek, of omgekeerd, is nauwelijks verstaanbaar. Passages in een andere taal dan het hoofddocument moeten hun eigen taalmarkeringen dragen.
Documenttitel. PDF-metadata moet een betekenisvolle titel bevatten, en de viewer moet zo zijn ingesteld dat die titel wordt weergegeven in plaats van de bestandsnaam. “Jaarverslag Toegankelijkheid 2026” wordt aangekondigd en getoond; “definitief_v3_VOORWEB.pdf” niet.
Navigatie via tabs en bladwijzers. Bladwijzers (de documentstructuur) geven alle gebruikers — en vooral degenen die niet-visueel navigeren — een manier om naar belangrijke secties van een lang document te springen.
Vlaggen voor getagde PDF en schone metadata. Het bestand moet worden gemarkeerd als een getagde PDF en consistente, accurate metadata dragen.

Deze eigenschappen kosten minuten om in te stellen en zijn vereist voor conformiteit, en toch worden ze overgeslagen in de overgrote meerderheid van gepubliceerde PDF’s.

WCAG 2.2 en PDF/UA (ISO 14289)

Twee standaarden regelen toegankelijke PDF’s, en ze werken samen in plaats van te concurreren.

WCAG 2.2 is de technologieonafhankelijke basislijn voor digitale toegankelijkheid. De succescriteria — tekstalternatieven, info en relaties, betekenisvolle volgorde, contrast, toetsenbordbediening en de rest — gelden voor PDF’s net zoals ze gelden voor webpagina’s. WCAG 2.2 is de standaard waar de meeste wetten naar verwijzen, en het W3C publiceert specifieke technieken om aan WCAG te voldoen met PDF-functies (koppen taggen, alt-tekst leveren, leesvolgorde definiëren, enzovoort). Als je werkt aan algemene conformiteit, zijn onze gids over content WCAG-conform maken en het WCAG-conformiteit-overzicht beide direct van toepassing op documenten.

PDF/UA — formeel ISO 14289 — is de technische specificatie voor toegankelijke PDF. Waar WCAG uitkomsten beschrijft (“lever tekstalternatieven”), schrijft PDF/UA precies voor hoe een PDF moet worden geconstrueerd om een correct getagd, machineleesbaar, toegankelijk document te zijn: welke structuurtypen te gebruiken, hoe de tagboom moet worden gevormd, hoe artefacten moeten worden gemarkeerd, en hoe formulieren en tabellen moeten worden gecodeerd. De twee zijn complementair — de meest robuuste aanpak is om te remediëren tegen de technische vereisten van PDF/UA terwijl je de gebruikersgerichte uitkomsten valideert tegen WCAG 2.2.

Conformiteit aan deze standaarden is wat juridische verplichtingen in verschillende rechtsgebieden onderbouwt. PDF’s gepubliceerd door betrokken organisaties vallen onmiskenbaar binnen de European Accessibility Act, de ADA en Section 508, die allemaal downloadbare documenten behandelen als onderdeel van de digitale ervaring die toegankelijk moet zijn.

Bestaande PDF’s remediëren versus toegankelijke PDF’s maken

Er zijn twee routes naar toegankelijke PDF’s, en de meeste organisaties hebben beide nodig.

Bestaande PDF’s remediëren betekent een afgerond bestand nemen — een rapport, een achterstand aan overzichten, een gescand formulier — en de toegankelijkheidslaag toevoegen of corrigeren: OCR uitvoeren waar nodig, de tagboom bouwen, leesvolgorde instellen, alt-tekst schrijven, tabellen repareren en formuliervelden labelen. Remediatie is essentieel wanneer de bronbestanden weg zijn, wanneer documenten door derden zijn geproduceerd, of wanneer je een gepubliceerd archief hebt dat in conformiteit moet worden gebracht. Cruciaal is dat remediatie de onderliggende structuur verandert, niet het visuele ontwerp — het document ziet er identiek uit en wordt bruikbaar voor iedereen. Dit is de kern van QualiBooth’s PDF-remediatie-dienst, die batches afbakent op belang en bereik en de documenten die er het meest toe doen als eerste prioriteert.

Toegankelijke PDF’s maken betekent toegankelijkheid inbouwen in het productieproces zodat documenten toegankelijk worden geboren. Dat houdt in: echte kopstijlen, lijststijlen en alt-tekst gebruiken in de bronapplicatie; tabellen ontwerpen als gegevenstabellen; taal en titel instellen; en een exportroute kiezen die de tagboom behoudt. Toegankelijk maken is dramatisch goedkoper dan hetzelfde document later repareren, en het is het enige duurzame antwoord voor organisaties die continu PDF’s publiceren.

De twee benaderingen zijn geen of-of. Het praktische patroon is om de documenten die al in omloop zijn te remediëren terwijl je het upstream-proces repareert zodat nieuwe documenten het probleem niet opnieuw creëren. Het verankeren van die verandering is precies wat verbetering van het toegankelijkheidsproces aanpakt — het omzetten van toegankelijk publiceren van een eenmalig project naar de standaardmanier waarop je team werkt. Een breder beeld van waar document- en webwerk samenkomen, wordt uiteengezet in ons overzicht van toegankelijkheidsdiensten.

Valideren met schermlezers — en waarom overlays niet helpen

Een PDF is alleen toegankelijk als deze daadwerkelijk werkt voor de mensen die ervan afhankelijk zijn. Daarom kan validatie niet stoppen bij een geautomatiseerde checker. Tools die een PDF scannen tegen PDF/UA-regels zijn waardevol — ze vangen ontbrekende tags, ongedefinieerde talen en structurele fouten op schaal op — maar ze verifiëren de aanwezigheid van structuur, niet de kwaliteit ervan. Een geautomatiseerde tool kan bevestigen dat een afbeelding alt-tekst heeft; hij kan je niet vertellen dat de alt-tekst verkeerd is. Hij kan bevestigen dat een kop bestaat; hij kan je niet vertellen dat hij op het verkeerde niveau is genest.

Echte validatie combineert beide:

Geautomatiseerd controleren om structurele en metadatafouten breed en consistent op te vangen. Software zoals het QualiBooth toegankelijkheidsscanplatform blinkt uit in het markeren van machinaal detecteerbare problemen over grote volumes.
Handmatig testen met hulptechnologie — door het document navigeren met een schermlezer, per kop bewegen, tabellen lezen, door een formulier tabben — om te bevestigen dat de ervaring samenhangend is. Dit is de enige manier om leesvolgorde, alt-tekstkwaliteit en formulierbruikbaarheid te verifiëren. Onze methodologie voor handmatige audits legt uit waarom menselijk testen onvervangbaar is, en audits uitgevoerd door mensen met een beperking brengen problemen aan het licht die geen enkele checker en geen enkele ziende tester ooit zou opmerken.

Een woord van waarschuwing over kortere wegen. Toegankelijkheidsoverlays — scripts of widgets van derden die beweren toegankelijkheid automatisch op te lossen — lossen PDF-toegankelijkheid niet op, en QualiBooth onderschrijft ze niet. Ze kunnen geen correcte tagboom maken, geen leesvolgorde beoordelen of betekenisvolle alt-tekst schrijven, omdat die taken begrip vereisen van de inhoud en intentie van het document. Er is geen geautomatiseerd substituut voor goede remediatie. Echte PDF-toegankelijkheid komt voort uit correcte structuur plus menselijke verificatie — de aanpak achter ons PDF-remediatie-werk.

Veelgestelde vragen

Is een niet-getagde PDF ooit acceptabel? Nee. Een niet-getagde PDF is per definitie ontoegankelijk voor hulptechnologie en voldoet niet aan WCAG 2.2 noch aan PDF/UA. Elke PDF die je publiceert voor het publiek of voor werknemers moet getagd zijn.

Verandert het toegankelijk maken van een PDF hoe deze eruitziet? Nee. Remediatie voegt de verborgen structurele laag toe en corrigeert deze — tags, leesvolgorde, metadata — zonder het visuele ontwerp te wijzigen. De pagina ziet er identiek uit.

Moet ik gewoon een HTML-versie leveren in plaats van een toegankelijke PDF? Een toegankelijk HTML-alternatief is vaak de betere ervaring en is het aanbieden waard. Maar als je de PDF publiceert, moet de PDF zelf toegankelijk zijn — een HTML-alternatief stelt het document niet vrij van conformiteitsvereisten.

Kunnen gescande documenten toegankelijk worden gemaakt? Ja, maar ze moeten eerst worden ge-OCR’d om echte tekst te creëren, waarna de normale remediatiestappen — taggen, leesvolgorde, alt-tekst, tabellen — van toepassing zijn.

Hoe houd ik nieuwe PDF’s toegankelijk zonder elk afzonderlijk te remediëren? Repareer het maakproces: gebruik echte stijlen en alt-tekst in de bron, ontwerp goede gegevenstabellen, stel taal en titel in, en exporteer via een route die tags behoudt. Het koppelen van remediatie aan procesverbetering maakt toegankelijke documenten de standaard.

Conclusie

PDF-toegankelijkheid is geen optionele afwerkingsstap — het is het verschil tussen een document dat iedereen kan gebruiken en een dat stilletjes de mensen uitsluit die op hulptechnologie vertrouwen. Het werk is concreet en goed begrepen: tag de structuur, stel een correcte leesvolgorde in, beschrijf afbeeldingen, codeer tabellen en formulieren correct, geef taal en titel aan, en valideer het resultaat tegen WCAG 2.2 en PDF/UA met echte schermlezers én geautomatiseerde tools. Remedieer de documenten die je al publiceert, repareer het proces dat nieuwe produceert, en sla de overlay-kortere wegen over die toegankelijkheid beloven zonder die te leveren.

Als je rapporten, overzichten, brochures of formulieren nooit zijn gecontroleerd, is dat de plek om te beginnen. Je kunt starten met een gratis toegankelijkheidsscan, een demo aanvragen van het QualiBooth-platform, of met ons team praten over PDF-remediatie voor één kritiek document of een heel archief.