> For the complete documentation index, see [llms.txt](https://overleaf-pro.ayaka.space/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://overleaf-pro.ayaka.space/latex/nl/meer-onderwerpen/04-an-introduction-to-tagged-pdf-files-internals-and-the-challenges-of-accessibility.md). # Een inleiding tot getagde PDF-bestanden: internals en de uitdagingen van toegankelijkheid ## Update: januari 2026 Zie [de instructies van Overleaf voor het maken van getagde PDF's](https://docs.overleaf.com/writing-and-editing/creating-accessible-pdfs). De [LaTeX-team](https://latex-project.org/) heeft nieuwe functies uitgebracht die automatische PDF-tagging mogelijk maken, de centrale vereiste voor PDF-toegankelijkheid. Deze nieuwe functies zijn beschikbaar in Overleaf in [TeX Live 2025](http://\(https//www.overleaf.com/blog/tex-live-2025-is-now-available), met recentere updates beschikbaar in de rollende TeX Live-release via [Overleaf Labs](https://www.overleaf.com/labs/participate). Het is nu mogelijk om een getagde PDF uit LaTeX-bron te produceren die voldoet aan WCAG 2.1-niveau AA door te volgen [onze gebruikersdocumentatie](https://docs.overleaf.com/writing-and-editing/creating-accessible-pdfs) met behulp van TeX Live-releases die beschikbaar zijn in Overleaf. Het onderstaande artikel uit 2020 is weliswaar niet bijgewerkt met de nieuwste informatie over LaTeX-toegankelijkheid, maar kan nog steeds worden gelezen uit interesse en voor achtergrondinformatie over PDF-tagging. *** ## Waar gaat dit artikel over? Het doel van dit artikel is om een inleiding te geven tot getagde PDF, samen met een overzicht van enkele technische uitdagingen waarmee software te maken heeft, waaronder TeX-engines en LaTeX, die tot doel hebben getagde en toegankelijke PDF-bestanden te produceren. Toegankelijkheid, met name van PDF's, is een breed en complex onderwerp, dat ook technische uitdagingen kent waarvoor niet altijd één universele, algemeen aanvaarde of geaccepteerde oplossing bestaat — zoals hoe complexe wiskunde binnen PDF's op een toegankelijke manier kan worden weergegeven: met MathML of LaTeX-code? Hoewel we niet op elk onderwerp diep kunnen ingaan, en veel details moeten vereenvoudigen, kunnen we in PDF's kijken om te laten zien wat het taggen van een PDF nu eigenlijk inhoudt. Overleaf hoopt dat dit artikel als een nuttige inleiding zal dienen, met voldoende achtergrond om lezers in staat te stellen de technische uitdagingen beter te begrijpen en hun verdere lezen en verkenning van getagde PDF en toegankelijkheid te ondersteunen. Hulpbronnen in dit artikel zijn onder meer: * [een video van 8 minuten](#video-showing-the-logical-structure-of-a-tagged-pdf) waarin een door LaTeX geproduceerde getagde PDF wordt verkend; * [een Overleaf-project](#using-luatex-an-example-in-the-overleaf-gallery) om het gebruik van spaties in LuaTeX te verkennen; * [geluidsopnamen](#tagged-yes-but-the-reading-order-is-incorrect) die toegankelijkheidsproblemen met PDF demonstreren. ## Inleiding Het waarborgen van de toegankelijkheid van digitale content wordt terecht erkend als een belangrijk aspect van het produceren en verspreiden van content. Bovendien voeren overheden, waaronder het [Verenigd Koninkrijk](https://www.gov.uk/guidance/accessibility-requirements-for-public-sector-websites-and-apps) en de [Verenigde Staten](https://www.hhs.gov/sites/default/files/Intro%20to%20Accessibility%20and%20508.pdf), wetten in die vereisen dat content die onder hun jurisdictie wordt geproduceerd, voldoet aan vastgestelde toegankelijkheidscriteria. Voldoen via verspreiding van content in HTML is niet buitensporig belastend, maar het waarborgen van het vereiste niveau van toegankelijkheid voor documenten die in PDF-formaat worden verspreid, kan een aanzienlijke technische uitdaging zijn — afhankelijk van de software die wordt gebruikt om content te maken die als PDF-bestand moet worden uitgevoerd. PDF ontstond begin jaren 1990 als oplossing voor problemen rond betrouwbare documentoverdracht en de geschiedenis heeft aangetoond dat het enorm succesvol is. PDF is echter ook een complex bestandsformaat dat ontstond vóórdat de noodzaak om de toegankelijkheid van documentinhoud te vergemakkelijken wijdverbreid werd erkend en geaccepteerd. Niettemin is de PDF-specificatie in de loop der tijd geëvolueerd om functies te bieden die de productie van toegankelijke PDF-documenten mogelijk maken en ondersteunen met een ‘gestileerde’ variant van PDF die Adobe noemt *getagde PDF*. In de praktijk brengt de productie van getagde—*en volledig toegankelijke*—PDF-bestanden aanzienlijke extra technische vereisten met zich mee voor software die PDF uitvoert — en daaronder vallen TeX-engines en het LaTeX-ecosysteem van macro's en aanvullende LaTeX-pakketten. ## Ontstaansgeschiedenis van PDF als digitale eindvorm van papier De [ontstaansgeschiedenis van Portable Document Format (PDF)](https://theblog.adobe.com/evolution-digital-document-celebrating-adobe-acrobats-25th-anniversary/) stamt uit een tijdperk waarin het overbrengen van documenten tussen computers gepaard ging met moeilijkheden, vaak veroorzaakt door bestandsconversies die leidden tot herflow van pagina's en andere afwijkingen, verergerd door incompatibele lettertypen en tekencoderingen die op verschillende besturingssystemen werden gebruikt (met name Windows en Macintosh). De auteur van dit document werkte destijds in de uitgeverij en heeft levendige herinneringen aan het omgaan met die uitdagingen! PDF was ontworpen om problemen met het delen van bestanden aan te pakken door de introductie van een universeel, in de eindvorm (niet-bewerkbaar) digitaal papier, waardoor het naadloos overdragen van op zichzelf staande documenten mogelijk werd die de lettertypen bevatten die nodig zijn om ze weer te geven. Gebruikers konden eindelijk allerlei documenten met redelijke zekerheid overdragen dat ontvangers, ongeacht het computerplatform, ze konden openen en lezen — de getrouwheid van het document bleef behouden en rommelige herflows van pagina's, compatibiliteit/beschikbaarheid van lettertypen behoorden tot het verleden. ### Digitaal papier: goed voor alle gebruikers? De afstamming van PDF, als vorm van digitaal papier, ging er vanzelfsprekend van uit dat gedrukte paginanummers, typografie of ontwerpelementen werden gebruikt als aanwijzingen voor visuele navigatie door de inhoud — op het scherm of op papier. Die visuele aanwijzingen/mechanismen zijn voor mensen met ernstige visuele beperkingen uiteraard betekenisloos. Tegenwoordig wordt de verbeterde toegankelijkheid van digitale content terecht erkend als een belangrijk aspect van het produceren en verspreiden van content. De uitdaging voor PDF was mechanismen te bieden die niet-visuele toegang tot inhoud vergemakkelijken die opgesloten zit in een ‘container’ die oorspronkelijk was ontworpen om het visuele medium van de gedrukte pagina na te bootsen. De eerste versie van de PDF-specificatie (PDF 1.0) werd [officieel uitgebracht op 15 juni 1993](https://theblog.adobe.com/evolution-digital-document-celebrating-adobe-acrobats-25th-anniversary/) gevolgd door nieuwe versies met updates die in 2001 (PDF 1.4) de introductie van ‘tagged PDF’ omvatten, wat [‘...gebruikers van hulpmiddelen voor toegankelijkheid in staat stelde’](https://www.adobe.com/accessibility/pdf.html). Latere versies van de PDF-specificatie hebben de functies van PDF uitgebreid en verbeterd, met als hoogtepunt de nieuwste release (PDF 2.0) die, op basis van [rapporten](https://www.pdfa.org/tagged-pdf-2-0/), de toegankelijkheidsfuncties aanzienlijk heeft vernieuwd — hoewel PDF 2.0 nog niet goed wordt ondersteund door TeX-engines. ## Inhoud binnen PDF's Om de betrokken kwesties te begrijpen, is het de moeite waard te bekijken hoe PDF-bestanden de pagina-inhoud die ze bevatten daadwerkelijk weergeven. Diep in een PDF-bestand bevindt de inhoud van elke pagina zich in de *contentstream*: een reeks PDF-operators (“opdrachten”) die tekst of grafische elementen op een bepaalde paginapositie plaatsen voor weergave (display) door software die wordt gebruikt om de PDF te *bekijken* De contentstream biedt in feite een grafische beschrijving of ‘recept’ dat PDF-bekijkapplicaties vertelt hoe ze elke pagina moeten ‘tekenen’ — en definieert wat op de pagina moet worden weergegeven en waar. Uiteraard bevat die reeks operators instructies om bepaalde lettertypen op een specifieke grootte te kiezen, kleuren te selecteren, lijnbreedten te definiëren, lijnen, krommen enzovoort te tekenen — alles wat nodig is om een volledige grafische beschrijving te geven voor de visuele presentatie van een pagina. Om de bestandsgrootte te verkleinen, worden PDF-contentstreams gecomprimeerd en opgeslagen in een compact binair formaat, maar als je toegang hebt tot geschikte software, zoals Adobe Acrobat Pro DC, kun je die gebruiken om een ‘gedecomprimeerde’ tekstversie van pagina-contentstreams te bekijken. Laten we eens bekijken hoe PDF-operators een tabel zouden kunnen ‘tekenen’: de PDF-contentstream zou een passende reeks operators bevatten om horizontale/verticale lijnen te produceren, verschillende lettertypen te selecteren en tekst uit te voeren op verschillende paginalocaties om de inhoud van de tabel te creëren. Om dit te demonstreren, bekijken we een heel eenvoudig niet-getagd PDF-document dat niets meer bevat dan een basistabel met wat tekst — gemaakt in Microsoft Word om redenen die later in het artikel duidelijk zullen worden. Hier is een schermafbeelding van onze eenvoudige PDF: ![Een tabel gemaakt in Microsoft Word](/files/851b8029e87da6c5b894d3bbc82865a9abc4fb3a) Als we de (gedecomprimeerde) contentstream voor deze pagina extraheren en de eerste paar regels in een teksteditor plakken, kunnen we enkele van de PDF-operators samenvatten om een ‘smaakje’ te krijgen van hoe PDF-bestanden de inhoud ‘beschrijven’ die op deze pagina wordt weergegeven. ![Afbeelding van een contentstream in een PDF-bestand](/files/0d580643cf001f9cfb760828563d4faa9491b99e) Als je toegang hebt tot Adobe Acrobat Pro DC, kun je het gebruiken om de operators op te sommen die in een PDF-pagina-contentstream staan. Hier is Acrobat's *Interne PDF-structuur* weergave van dezelfde PDF, die behulpzaam een eendelige beschrijving geeft van elke operator die wordt gebruikt om onze enkele pagina met een basistabel ‘te tekenen’ — let op: deze korte beschrijvingen worden geleverd door Adobe Acrobat Pro DC en zijn *niet* aanwezig in het PDF-bestand zelf: ![Afbeelding van een PDF-contentstream bekeken in Adobe Acrobat Pro DC](/files/6d7511ef0f67c01e8c383ebf8d634a934c3d55df) Let echter op dat geen van die tekeninstructies (operators) enige ‘betekenis’ of ‘beschrijving’ opslaat van wat ze daadwerkelijk produceren: het zijn slechts een reeks grafische operators die resulteren in de constructie van wat een *oplettende waarnemer herkent* als een tabel. Voor mensen met ernstige visuele beperkingen is het duidelijk geen haalbare methode om via de grafische operators in de contentstream van de PDF de tabel die daaruit voortkomt weer te geven en zo toegang te krijgen tot die inhoud. Wat nodig is, is een mechanisme waarmee PDF-bestanden een geschikte niet-visuele (machineleesbare) beschrijving van die tabel bevatten — en natuurlijk van alle andere inhoud die zich in de pagina's binnen een PDF-bestand bevindt. Om niet-visuele toegang tot inhoud mogelijk te maken, moeten PDF-bestanden extra gegevens bevatten die ‘betekenis’ of semantiek koppelen aan verzamelingen of groepen operators die worden gebruikt om een bepaald stuk inhoud ‘te tekenen’. Noodzakelijkerwijs moet dit principe van het toekennen of verschaffen van ‘betekenis’ zich uitstrekken tot alle vormen van inhoud in een PDF: dat mechanisme bestaat en heet *tagging* van de PDF om een ‘variant’ van PDF te produceren, niet verrassend genaamd *getagde PDF*. ## Invoering van getagde PDF Getagde PDF is de naam voor een specifiek type PDF-bestand dat extra gegevens (en gegevensstructuren) bevat die niet aanwezig zijn in niet-getagde PDF-bestanden. Hoewel de principes/ideeën achter getagde PDF zich goed lenen voor een beknopte beschrijving, zijn de volledige details complex en beslaan ze vele pagina's in de formele PDF-specificatie. Adobe ontwierp getagde PDF om een aantal doelstellingen te bereiken, waaronder het toegankelijk maken van inhoud voor gebruikers met visuele beperkingen, maar het omvat ook de volgende lijst uit sectie 10.7 van [Adobe's PDF 1.7-specificatie](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf): * eenvoudig extraheren van tekst en grafische elementen om in andere toepassingen te plakken; * automatisch herflowen van tekst en bijbehorende grafische elementen zodat ze passen op een pagina van een andere grootte dan die voor de oorspronkelijke lay-out werd verondersteld; * tekst verwerken voor doeleinden zoals zoeken, indexeren en spellingscontrole; * conversie naar andere gangbare bestandsformaten (zoals HTML, XML en RTF) met behoud van documentstructuur en basisopmaakinformatie. Bovendien vereist getagde PDF ook: * dat tekst binnen PDF-inhoud wordt weergegeven in een vorm die naar Unicode kan worden omgezet; * woordafbrekingen moeten expliciet worden weergegeven — let op: TeX-engines gebruiken geen spaties om woorden van elkaar te scheiden; ze gebruiken TeX's flexibele spatiëring, glue genaamd (zie hieronder); * echte (‘reële’) inhoud wordt onderscheiden van artefacten van lay-out en paginering. Onder getagde PDF liggen twee kernconcepten die we zullen doornemen: * het definiëren van de logische structuur van inhoud in een PDF-bestand; * markering (tagging) van PDF-inhoud met een set standaardinhoudstypen. ## Logische structuur Binnen langere documenten wordt inhoud meestal onderverdeeld in een reeks kleinere inhoudsonderdelen; zo worden boeken doorgaans opgedeeld in hoofdstukken, die zelf weer worden verdeeld in secties en subsecties met alinea's, tabellen, figuren/grafieken, opsommingen of genummerde lijsten, voetnoten en referenties enzovoort. De structuur en organisatie van inhoud in zo'n boek, of in elk ander documenttype, wordt aangeduid als de *logische structuur*. Het begrip logische structuur van een document speelt een belangrijke rol in de toegankelijkheid van PDF's, maar als concept kan logische structuur wat vaag en lastig te begrijpen lijken. De volgende definitie uit de [Encyclopedie van databasesystemen](https://link.springer.com/referenceworkentry/10.1007%2F978-0-387-39940-9_213) biedt nuttig inzicht: > “Logische structuur verwijst naar de manier waarop informatie in een document is georganiseerd; ze definieert de hiërarchie van informatie en de relatie tussen verschillende delen van het document. Logische structuur geeft aan hoe een document is opgebouwd, in tegenstelling tot wat een document bevat.” Merk op dat deze definitie van logische structuur geen verwijzing bevat naar precies *hoe* waar die structurele informatie fysiek wordt opgeslagen; alleen dat ze een weergave biedt van de structuur en organisatie van een document. De precieze details van hoe de logische structuur van een document wordt opgeslagen of weergegeven, hangen af van de implementatie: een functie van de software die wordt gebruikt om die te genereren en te verwerken. ### Logische structuur in PDF's De PDF-specificatie biedt mechanismen waarmee de logische structuur van een document in een PDF-bestand kan worden vastgelegd — voor gebruik door software die bijvoorbeeld de inhoud van de PDF misschien wil exporteren naar andere formaten zoals XML, HTML of Microsoft Word. Die exportprocessen moeten een correct gestructureerd tekstdocument opleveren dat voldoet aan de regels van het doelformaat voor exportbestanden — dat kan het best worden bereikt wanneer het exportproces wordt geleid door informatie over de logische structuur die in de PDF is opgenomen. Daarnaast is de logische structuur van een PDF-bestand essentieel voor toegankelijkheidssoftware die bijvoorbeeld tekst-naar-spraakbewerkingen wil uitvoeren en de inhoud hardop wil voorlezen aan iemand met een visuele beperking. Het tekst-naar-spraakproces moet ervoor zorgen dat de inhoud in de juiste volgorde/opeenvolging hardop wordt voorgelezen; anders zouden er onzinnige resultaten ontstaan. Merk ook op dat het concept van een pagina op zich mogelijk geen betekenis heeft voor toegankelijkheidstoepassingen die alleen geïnteresseerd zijn in de inhoud en structuur van de PDF van het document, niet in de visuele verdeling en presentatie in paginagrote brokken. #### Inhoudsitems benoemen Het vastleggen (opslaan) van de logische structuur van een PDF-document vereist een reeks betekenisvolle namen die worden toegekend aan de verschillende *typen* inhoudsitem die waarschijnlijk onderdeel zijn van een typisch PDF-document — waarbij secties van inhoud worden geïdentificeerd die koppen, alinea's, tabellen, lijsten enzovoort vertegenwoordigen. Bovendien hebben sommige inhoudsitems, zoals inhoudsopgaven, genummerde/opsommingslijsten en tabelmateriaal, hun eigen vrij complexe structuren, dus er zijn ook richtlijnen/regels nodig om aan te geven hoe die complexere inhoudsitems zijn opgebouwd — hun substructuur. Een verdere vereiste is om duidelijk alle PDF-inhoud te identificeren die genegeerd moet worden door hulpsoftware die de PDF verwerkt; zo zijn paginahoofden en -voeten bijvoorbeeld pagineringsartefacten met tekst die overbodig is voor mensen met ernstige visuele beperkingen: die inhoud moet genegeerd worden. De mechanismen die PDF gebruikt om de logische structuur van een document te definiëren zijn ontworpen om flexibel te zijn, dus in principe zouden verschillende toepassingen die PDF-bestanden genereren en verwerken namen voor inhoudstypen kunnen gebruiken volgens elke conventie van hun keuze. Om de documentuitwisseling echter te maximaliseren en verschillende PDF-verwerkingsapplicaties consistente resultaten te laten geven, definieerde Adobe een set standaardnamen voor typen inhoudsitems waaraan PDF-generatiesoftware zich zou moeten houden. Binnen de PDF-specificatie worden die standaardnamen tags genoemd, wat leidt tot het begrip *getagde* PDF. ### Markering van PDF-inhoud: een kijkje ‘onder de motorkap’ Om de discussie wat minder abstract te maken, werpen we een korte blik op de interne werking van getagde PDF-bestanden — hoewel we niet alle details kunnen behandelen omdat getagde PDF zo'n groot, complex onderwerp is. #### Gemarkeerde inhoudsreeksen: bouwstenen voor getagde PDF Op het laagste niveau begint het proces van het vastleggen van de betekenis van inhoud in een PDF-pagina (d.w\.z. binnen zijn contentstream) met *gemarkeerde inhoudsreeksen* die worden gebruikt om clusters of groepen PDF-operators te identificeren (en ‘betekenis’ te geven). Aan gemarkeerde inhoudsreeksen wordt een numerieke identificatie toegewezen die haar `MCID` (*gemarkeerde inhoudsidentifier*) genoemd wordt, een geheel getal dat op elke pagina oploopt van 0 tot een maximum N. Die `MCID` waarden bieden een manier om reeksen operators binnen de contentstream van een specifieke pagina uniek te identificeren. Ter verduidelijking: voor elke pagina beginnen de `MCID` identifiers bij 0 en nemen ze sequentieel toe tot een maximale waarde die afhangt van hoeveel gemarkeerde inhoudsreeksen in de contentstream van een bepaalde pagina voorkomen. Gemarkeerde inhoudsreeksen zijn in feite fundamentele ‘bouwstenen’ die worden gebruikt om structuren op hoger niveau samen te stellen die *structuurelementen*heten. Die structuurelementen bevatten een tag, de naam die wordt gebruikt om aan te geven welk type inhoudsitem zij vertegenwoordigen. #### Voorbeeld van structuurelementen We springen hier iets vooruit, maar het is de moeite waard om een voorbeeld te bekijken. Stel dat je 3 kleine tekstfragmenten van paginainhoud hebt en dat elk daarvan in de contentstream wordt geïdentificeerd door een andere gemarkeerde inhoudsreeks. Elk van die 3 tekstfragmenten kan in zijn eigen structuurelement worden verpakt, met een tag, en alle drie kunnen met behulp van een ander structuurelement ‘aan elkaar worden gekoppeld’ om een inhoudsitem op hoger niveau voor te stellen, zoals een regel in een inhoudsopgave. ![Afbeelding die structuurelementen en gemarkeerde inhoudsreeksen uitlegt](/files/129f9ba9e88bc11d3ac51154c9502739a2c082b0) Via een vorm van ouder-kindgegevensrelatie worden verzamelingen structuurelementen gecombineerd om gekoppelde datastructuren te creëren die complexere gegevensitems vertegenwoordigen zoals genummerde en opsommingslijsten, tabellen, wiskunde enzovoort. Uiteindelijk worden alle structuurelementen in het hele PDF-bestand verder aan elkaar gekoppeld en gecombineerd om de logische structuur van het PDF-document te creëren — we komen hier later in het artikel op terug. ### Wat is een gemarkeerde inhoudsreeks? In de bovenstaande bespreking gebruikten we een eenvoudig niet-getagd PDF-document met een tabel (gemaakt in Microsoft Word), maar als we Word instrueren een getagde PDF te maken, kunnen we zien dat er wat extra markering is verschenen in de contentstream van de pagina. Hier bekijken we slechts de eerste paar regels van de contentstream (er zijn honderden regels), maar let op de aanwezigheid van extra operators zoals `/P <> BDC` en `EMC` die worden gebruikt om een gemarkeerde inhoudsreeks te identificeren. We zullen de volledige syntaxis van gemarkeerde inhoudsreeksen niet verkennen, maar verwijzen de lezer naar pagina 862 van [Adobe's officiële PDF 1.7-specificatie](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf). ![Afbeelding die gemarkeerde inhoudsreeksen in een getagde PDF-contentstream toont](/files/923297316977e77ecab82af80f0f5b7e9b800cc0) Voor de duidelijkheid tonen we opnieuw de niet-getagde versie: ![Afbeelding die PDF-contentstream toont](/files/0d580643cf001f9cfb760828563d4faa9491b99e) In de *niet-getagde* PDF, operators zoals `/P <> BDC` en `EMC` ontbreken, maar de overige operators zijn onveranderd: de niet-getagde PDF mist de extra markering die wordt gebruikt om bepaalde reeksen/verzamelingen operators te identificeren. Opnieuw kunnen we ook Adobe Acrobat's *Interne PDF-structuur* functie gebruiken om de gemarkeerde inhoudsreeksen binnen een contentstream te bekijken — hier hebben we ze gemarkeerd met een groene rand: ![Afbeelding die gemarkeerde inhoudsreeksen in een getagde PDF-contentstream toont, bekeken in Adobe Acrobat Pro DC](/files/180aecd35bc46acc5f86a6e85d748dd807c1b21b) Merk op dat sommige inhoudsfragmenten zijn gemarkeerd met `/Artifact` dat materiaal op de PDF-pagina identificeert dat *genegeerd* moet worden door hulpsoftwaretoepassingen, zoals die welke hardop voorlezen aan mensen met een visuele beperking. De volgende schermafbeelding toont een uitgebreide weergave van de eerste gemarkeerde inhoudsreeks — die met `MCID` de waarde `0`. Het einde van de gemarkeerde inhoudsreeks wordt geïdentificeerd door de PDF-operator `EMC`. ![Afbeelding die details toont van de operators die omvat worden door een gemarkeerde inhoudsstream](/files/58eb61da02c9ecea638410f27d4026b7243ec132) ### De logische structuur opslaan Zoals opgemerkt moet een toegankelijke PDF, naast het bieden van een beschrijving van afzonderlijke inhoudsitems (alinea's, lijsten, tabellen enz.), ook een weergave bevatten van het hele document in de vorm van zijn logische structuur. Afzonderlijke stukken toegankelijke inhoud moeten aan elkaar worden gekoppeld om een volledig, navigeerbaar en toegankelijk document te creëren — vergelijkbaar met hoe een enkel HTML-document wordt opgebouwd uit alinea's, afbeeldingen en tabellen om een webpagina te vormen. Bovendien is het essentieel dat de logische structuur van een PDF-document ervoor zorgt dat alle inhoud in de juiste *leesvolgorde*kan worden genavigeerd, onafhankelijk van de volgorde waarin de paginainhoud naar de contentstreams van de PDF-pagina werd weggeschreven. We zullen leesvolgorde hieronder uitgebreider verkennen. #### Logische structuur: een ‘boom’ van structuurelementen We merkten op dat PDF's iets gebruiken dat een *structuurelement* wordt genoemd om afzonderlijke inhoudsitems weer te geven, en dat een structuurelement een tag bevat om te identificeren welk inhoudstype het vertegenwoordigt. Om een weergave van de logische structuur van het document te bieden, worden alle structuurelementen met elkaar verbonden via ouder-kindrelaties en georganiseerd in een ‘structuurboom’. Intern bevatten getagde PDF-bestanden een object genaamd de `StructTreeRoot` dat de structuurelementen bevat (eraan verwijst) die dienen als beginpunt of ‘wortel’ van de logische structuurboom van het document. Gewoonlijk begint de ‘wortel’ van de structuurboom met één enkel structuurelement dat getagd is als `Document` dat talrijke *kind* structuurelementen bevat die samen de volledige inhoud van het document vertegenwoordigen. Elke software die ontworpen is om toegankelijke PDF's via tagging te produceren, moet deze zeer complexe datastructuur (en andere!) bouwen — en daaronder vallen ook TeX-engines en LaTeX. Een voorbeeld van zo'n documentstructuurboom (`StructTreeRoot`) wordt getoond in de volgende schermafbeelding van een getagde PDF geopend in Adobe Acrobat Pro DC: ![Afbeelding die de StructTreeRoot in een getagde PDF toont](/files/bc2b07aa2eeef97a2c4b2d2696aac5167f56a287) Vergelijk bovenstaande structuur met de niet-getagde PDF-versie: ![Afbeelding die het ontbreken van StructTreeRoot in een niet-getagde PDF toont](/files/f13e5d564e477e278e80913e1af824044ead8a31) ### De logische structuur van PDF's verkennen We beginnen met enkele afbeeldingen om samen te vatten wat we hebben behandeld en sluiten af met een video die Adobe Acrobat Pro DC gebruikt om meer details van de logische structuur van een getagd PDF-bestand te tonen. Eerst beginnen we met een schema om de algemene principes te tonen: een PDF-pagina met zijn contentstream gemarkeerd met gemarkeerde inhoudsreeksen (MCS). ![Grafiek die het concept van gemarkeerde inhoudsreeksen in PDF-documentpagina's toont](/files/049e6f021c87ebb292975ffd786c2ceb7ad0c592) Die MCS worden vervolgens gecombineerd tot *structuurelementen* die de basis vormen voor grotere inhoudstypen die zelf weer verder aan elkaar gekoppeld worden om de logische structuur van de PDF op te slaan binnen een object genaamd `StructTreeRoot`. ![Grafiek die de logische structuur van een getagd PDF-bestand toont](/files/3c0bed52de405b85f2a862a897228ac54c289492) #### Video die de logische structuur van een getagde PDF toont De volgende video (8 minuten) gebruikt Adobe Acrobat Pro DC om je mee te nemen op een ‘rondleiding’ en de details van de logische structuur van een getagd PDF-bestand dat met LaTeX is geproduceerd te verkennen. Het in de video gebruikte getagde PDF-bestand heet `tagpdf.pdf`, wat een uitstekend voorbeeld is met documentatie voor het experimentele LaTeX-pakket [`tagpdf`](https://ctan.org/pkg/tagpdf?lang=en). Het doel van het `tagpdf` pakket is ‘hulpmiddelen te bieden om te experimenteren met tagging en toegankelijkheid met pdfLaTeX en LuaTeX’. {% embed url="" %} ### Een opmerking over tagging en flexibiliteit De HTML-specificatie biedt een groot aantal vooraf gedefinieerde tags voor gebruik bij het opbouwen van webpagina's, maar laat ook flexibiliteit toe in hoe je ze combineert om het door jou gekozen HTML-document te maken. Evenzo biedt Adobe's specificatie voor getagde PDF een set vooraf gedefinieerde tagnamen, maar legt ze zeer weinig beperkingen op aan hoe je die tags combineert om complexe inhoudsitems binnen een PDF weer te geven — van nature is er veel flexibiliteit. Bovendien is het, met elke specificatie die zo groot en complex is als PDF, onvermijdelijk dat er enige dubbelzinnigheden of onduidelijkheden in de geschreven specificatie sluipen. Softwareontwikkelaars die zo'n complexe specificatie moeten implementeren, kunnen bij het interpreteren ervan ‘oordeelgesprekken’ moeten voeren, omdat zij geschreven beschrijvingen moeten omzetten in werkende code. De inherente flexibiliteit van getagde PDF, samen met de interpretatie van specificaties (of toegankelijkheidsnormen), heeft uiteraard gevolgen voor ontwikkelaars van toepassingen voor documentcreatie: welke combinaties van tags moeten worden gebruikt om door de gebruiker gemaakte inhoud weer te geven wanneer deze wordt uitgevoerd naar een getagd PDF-bestand? Als je daarbij de onbeperkte mogelijkheid van gebruikers betrekt om allerlei inhoud te maken door gebruik te maken van functies van de software voor documentcreatie, dan zie je dat de geautomatiseerde productie van toegankelijke getagde PDF's nogal een uitdaging is! Misschien als weerspiegeling van de onvermijdelijke complexiteit van het produceren van getagde PDF's die volledig voldoen aan toegankelijkheidsnormen, staat het web vol met ‘hoe doe je dat’-instructies, ‘tips’ en advies over ‘best practices’ voor het maken van getagde PDF's via software zoals Adobe InDesign of Microsoft Word. Daarnaast heeft de PDF Association een nuttig document gemaakt met de titel [Tagged PDF Best Practice Guide](https://www.pdfa.org/wp-content/uploads/2015/12/StructureElementsBestPracticeGuide_2016-01-19.pdf) geschreven om ontwikkelaars te helpen die worden geconfronteerd met de uitdagingen van het implementeren van getagde PDF en PDF/UA. ## Heb je een PDF, maar is hij toegankelijk? Om te bepalen of een bepaald PDF-bestand voldoet aan vereiste toegankelijkheidsnormen zoals PDF/A of PDF/UA (zie hieronder), moet het *worden gevalideerd* met behulp van een overeengekomen validatieproces of softwaretool. Validatie vindt echter meestal plaats nadat het document voltooid is, maar dat proces wordt mogelijk niet uitgevoerd door de auteur van het document, maar door toegankelijkheidsspecialisten binnen de organisatie of instantie die conformiteit heeft gevraagd. Als de PDF niet slaagt voor de validatie, kan het zijn dat er deskundige handmatige tussenkomst via Adobe Acrobat Pro DC nodig is om de tagging te herstellen (indien mogelijk). Als alternatief moet het misschien terug naar de auteur om hun oorspronkelijke document aan te passen, mogelijk door gebruik te vermijden van de functies van de auteurssoftware die de problemen hebben veroorzaakt — iets wat extreem moeilijk te realiseren kan zijn omdat het buiten de controle van de auteur kan liggen. ### Leesvolgorde en inhoudsvolgorde Zoals opgemerkt stelt de productie van werkelijk toegankelijke PDF's extra technische eisen aan de auteurssoftware en, mogelijk, ook aan documentauteurs door ‘auteursdiscipline’ af te dwingen in hoe zij functies van de auteurssoftware gebruiken/toepassen. Hoewel getagde PDF het mechanisme is dat *mogelijk maakt* de productie van volledig toegankelijke PDF's, betekent het feit dat een PDF getagd is nog *niet* niet automatisch dat hij volledig toegankelijk is, zoals we in een voorbeeld hieronder zullen zien. Om volledig toegankelijke PDF's te produceren, moeten alle inhoudsitems in de PDF worden getagd om een logische structuur te creëren die ervoor zorgt dat inhoud in de juiste volgorde kan worden benaderd en gelezen — de *leesvolgorde*leesvolgorde *leesvolgorde* van: 1. tekst 2. table 3. grafische Wanneer software een contentstream voor die pagina naar een PDF wegschrijft, kan zij beginnen met operators om de tabel te tekenen, vervolgens operators uitvoeren om de grafiek te produceren, gevolgd door operators voor de tekst, wat in de contentstream een *inhoudsvolgorde* van: 1. table 2. grafische 3. tekst Natuurlijk wordt alles op de juiste positie geplaatst wanneer die pagina wordt bekeken. Voor een volledig ziende lezer is de volgorde waarin die items binnen de contentstream van de pagina zijn opgeslagen niet interessant: zij ervaren een volledig gerenderde pagina met alles op de juiste plaats. Als hulpsoftware echter zou moeten vertrouwen op de volgorde van items in een contentstream (de inhoudsvolgorde), dan zou zij problemen ondervinden als de inhoudsvolgorde anders was dan de natuurlijke leesvolgorde; hulpmiddelen voor hardop lezen zouden materiaal bijvoorbeeld in de verkeerde volgorde voorlezen. Gelukkig kan hulpsoftware de logische volgorde (structuur) van een getagde PDF gebruiken, die zo moet worden georganiseerd dat ze de volgorde weerspiegelt waarin inhoud moet worden gelezen. Om deze redenen wordt data die de logische structuur van het document weergeeft, afzonderlijk opgeslagen van de daadwerkelijke inhoud die op de zichtbare pagina's wordt weergegeven, zodat > ‘...de ordening en nesting van logische inhoudselementen volledig onafhankelijk kunnen zijn van de volgorde en locatie van grafische objecten op de pagina's van het document.’ (pagina 856 van [The PDF Reference, zesde editie, november 2006](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf)) In de praktijk is het veel lastiger dan het lijkt om een logische volgorde te garanderen die de leesvolgorde behoudt, dus laten we een eenvoudig, zij het verzonnen, voorbeeld gebruiken dat een indicatie geeft van de betrokken problemen. #### Onjuiste leesvolgorde: een voorbeeld met Microsoft Word De auteur van een document kan de functies van zijn of haar gekozen auteurssoftware gebruiken om een specifiek visueel effect te bereiken — bijvoorbeeld door tabellen te gebruiken om een bepaalde tekstlay-out te maken. De volgende schermafbeelding toont bijvoorbeeld het Microsoft Word-document dat in eerdere voorbeelden is gebruikt. Het bevat een tabel die is gebruikt om een reeks genummerde alinea's naast elkaar te maken. Maar als het gaat om het taggen van deze inhoud, hoe moet deze dan worden behandeld: getagd als een tabel of als een genummerde lijst? Beide inhoudstypen vereisen een complexe taggingstructuur om ze correct weer te geven. Let in de volgende afbeelding op de volgorde waarin de genummerde alinea's bedoeld zijn om te worden gelezen: kolom voor kolom, niet rij voor rij. ![Afbeelding van een tabel gemaakt in Microsoft Word](/files/8e1df2bad593fec7c2d6afc1c9cdd42c066c597c) Als we Word vragen dit document op te slaan als een PDF met behulp van de ingebouwde exportfunctie — niet de Acrobat PDFMaker-plug-in — kunnen we aangeven dat het een getagde PDF moet maken: ![Optiedialoogvenster van het exportproces van Microsoft Word](/files/edea71e29de057991934376e0890043ac72345b2) Dus, hoe tagt Word deze lay-out? In de volgende zeer korte video (14 seconden) gebruiken we Adobe Acrobat Pro DC om de tagstructuur te inspecteren die door Microsoft Word is geproduceerd. {% embed url="" %} Voor dit document heeft Word een getagd PDF-document gemaakt dat een `Table` tag gebruikt met twee sub-tags: `THead` voor de rijgroep van de tabelkop en en `TBody` om de groep rijen voor de tabelinhoud weer te geven. `THead` en `TBody` beide bevatten `TR` tags om afzonderlijke rijen inhoud weer te geven. De `TR` tags bevatten verdere tags om het genummerde lijstitem weer te geven dat in elke cel aanwezig is. De volgende schermafbeelding toont de diep geneste tagstructuur en de overeenkomstig complexe logische structuur die nodig is om zelfs dit uiterst eenvoudige document weer te geven! ![Afbeelding die de diep geneste tagstructuur en logische structuur van een eenvoudige tabel toont die in Microsoft Word is gemaakt](/files/3f075a1b851e6d9f96d25253d568f22781ddb514) Vergeleken met PDF’s gegenereerd door TeX en LaTeX is dit Word-voorbeeld een uiterst eenvoudig document, maar het vereist nog steeds een complexe logische structuur om het weer te geven. Stel je het niveau van tagcomplexiteit voor dat nodig is om door LaTeX gegenereerde PDF’s weer te geven die complexe wiskunde en tabellen bevatten! #### Getagd, ja, maar de leesvolgorde is onjuist Hoewel Word wel een [getagde PDF](https://assets.ctfassets.net/nrgyaltdicpt/3vcgZmG5mkCPYUPTjV30CF/4c34ae919212fa19e979e4cf852e66c1/ReadAloud.pdf) maakt, laat het een van de fundamentele uitdagingen zien waarmee elke applicatie wordt geconfronteerd die volledig toegankelijke PDF’s probeert te produceren: het correct weergeven van de beoogde leesvolgorde van de inhoud. Tijdens het maken van de getagde PDF besloten Word’s interne processen de overeenkomstige contentstream te schrijven door de tabel rij voor rij uit te voeren, niet kolom voor kolom. Voor een volledig ziende lezer die de PDF bekijkt, maken deze details op laag niveau geen verschil: de tabel wordt correct weergegeven. Voor mensen met een visuele beperking produceert Word’s logische documentstructuur echter het verkeerde resultaat omdat de gewenste leesvolgorde (kolom voor kolom) niet behouden blijft: de inhoud wordt in de verkeerde volgorde voorgelezen. De volgende audio-opname is gemaakt met behulp van de functie “Read Out Loud” van Adobe Reader DC. Zoals duidelijk is, wordt de tekst in de verkeerde volgorde voorgelezen: rij voor rij, niet kolom voor kolom: ![Een tabel gemaakt in Microsoft Word](/files/0b711777d99a2bbcd92914319916df798411ad42) Zoals hierboven opgemerkt is dit voorbeeld enigszins geconstrueerd, maar het laat wel zien hoe eenvoudig het is om combinaties van softwarefuncties toe te passen die toegankelijkheidsproblemen veroorzaken — maar hoe kan de auteur van het document dit vooraf weten? Waarschijnlijk zou dit probleem alleen worden ontdekt als de resulterende PDF praktische toegankelijkheidstests zou ondergaan, bijvoorbeeld met behulp van ondersteunende software. Mogelijk zouden dergelijke documenten PDF/A-nalevings-/validatietests doorstaan maar in “de echte wereld” falen. Het garanderen van de juiste leesvolgorde van een PDF-bestand zoals dit zou vaardige handmatige interventie vereisen met geavanceerde PDF-bewerkingstools zoals Adobe Acrobat Pro DC: een tijdrovend en duur proces. Als alternatief zou de auteur van het document kunnen afzien van deze specifieke vorm van inhoudsweergave of lay-out — maar alleen als hij of zij wist dat het problematisch was! ### Spatietekens gebruiken om woorden te scheiden Wanneer je tekst typt in tekstverwerkers of teksteditors gebruik je het spatieteken om het einde van het ene woord en het begin van het volgende aan te geven. Als je vervolgens een PDF van zo’n document maakt, zullen de door jou getypte spatietekens uiteraard worden uitgevoerd en deel uitmaken van de tekst die in de PDF wordt opgeslagen. TeX-engines gebruiken echter geen spatietekens om woorden in gezet tekst te scheiden; in plaats daarvan zetten ze spatietekens om in een vorm van flexibele spatiëring genaamd glue (zie dit [Overleaf-artikel](/latex/nl/diepgaande-artikelen/11-boxes-and-glue-a-brief-but-visual-introduction-using-luatex.md) voor meer informatie over TeX-boxen en glue). Binnen de contentstream van PDF-pagina’s die door TeX-engines zijn gemaakt, wordt de scheiding van afzonderlijke woorden bereikt door naar een andere positie op de pagina te gaan en de tekst voor het volgende woord te beginnen — in plaats van een spatieteken uit te voeren om die afstand te creëren. Bovendien varieert de hoeveelheid ruimte tussen woorden in alinea’s tekst die door TeX-engines zijn gezet van regel tot regel vanwege TeX’ regelafbrekingsalgoritme. Die variatie wordt weerspiegeld in de positioneringsgegevens die naar de contentstream van PDF-pagina’s worden geschreven. Dit aspect van TeX’s zetwerk heeft gevolgen voor kopiëren/plakken van tekst uit zijn PDF’s en voor ondersteunende software die de gezette tekst in PDF’s die door TeX-engines zijn geproduceerd hardop probeert voor te lezen. Ondersteunende software moet de contentstream van een PDF-pagina ontleden om de tekst te extraheren die ze moet verwerken. Duidelijk heeft dergelijke software een mechanisme nodig om het begin en einde van woorden te detecteren — de meest voor de hand liggende oplossing is het gebruik van een spatieteken. Met dat in gedachten vereisen toegankelijkheidsstandaarden dat afzonderlijke woorden duidelijk worden beëindigd (bijvoorbeeld door spatietekens), wat problematisch is voor TeX-engines vanwege hun gebruik van interwoord-glue. #### Maar alles is nog niet verloren! In 2014 introduceerde pdfTeX 2 nieuwe primitieve commando’s om de ondersteuning voor toegankelijkheid te verbeteren door het gebruik van spatietekens tussen woorden in de door het programma uitgevoerde PDF’s mogelijk te maken: * `\pdfinterwordspaceon` * `\pdfinterwordspaceoff` Deze commando’s maken gebruik van een “dummyfont” die alleen een spatieteken bevat. Details en een voorbeeld zijn te vinden op pagina 29 van de [pdfTeX User Manual](http://texdoc.net/texmf-dist/doc/pdftex/manual/pdftex-a.pdf). #### Using LuaTeX: een voorbeeld in de Overleaf-galerij LuaTeX ondersteunt die pdfTeX-primitieven niet, maar het kan geprogrammeerd worden om resultaten te bereiken die zeer vergelijkbaar zijn met pdfTeX, met gebruik van LuaTeX’s zogenaamde callback-mechanisme. Een Overleaf-project om glue om te zetten in spatietekens is beschikbaar in de Overleaf-galerij onder de titel [Using LuaTeX to convert interword glue to spaces and kerns](https://www.overleaf.com/latex/examples/using-luatex-to-convert-interword-glue-to-spaces-and-kerns/sfdkdkybrvkv). Als je je LaTeX-code zet met LuaTeX (dus de compileroptie LuaLaTeX op Overleaf), dan kun je met Lua-code een gezette alinea nabewerken om eventuele interwoord-glue te vinden en deze te vervangen door een spatieteken plus een geschikte kern. De spatiëring die wordt geleverd door de breedte van het spatieteken kan worden toegevoegd aan (of verminderd door) een passende kernwaarde te berekenen om de hoeveelheid ruimte te behouden die door de interwoord-glue wordt geleverd, waardoor er visueel geen verschil is in het gezette resultaat. Om het verschil te begrijpen dat dit maakt voor gebruikers van toegankelijkheidssoftware, luister naar deze geluidsopname die is vastgelegd met de functie *Read Out Loud* van Adobe Reader DC. Het registreert dat de twee regels tekst in dat project hardop worden voorgelezen, vóór en na het omzetten van glue naar spaties. Let op hoe de tweede lezing van de regel, die spaties gebruikt, snel en vloeiend wordt voorgelezen vergeleken met de regel die interwoord-glue gebruikt. Het Overleaf-project is een gewoon TeX-bestand dat met LuaTeX wordt gecompileerd en uitsluitend voor experimenteel gebruik wordt aangeboden; het is niet bedoeld als volledige oplossing van productiekwaliteit. Het is in de eerste plaats ontworpen om te helpen bij het begrijpen van technische kwesties met betrekking tot toegankelijke PDF’s. De Lua-code die in dat project wordt gebruikt is gebaseerd op werk in een veel eerder Overleaf-artikel [Boxen en lijm: een korte, maar visuele, introductie met LuaTeX](/latex/nl/diepgaande-artikelen/11-boxes-and-glue-a-brief-but-visual-introduction-using-luatex.md). Opmerking: Voor de eenvoud gebruikt het project zijn eigen zeer minimale OpenType-lettertype-lader, afgeleid van deze code: . ### Andere toegankelijkheidsproblemen en getagde PDF Hoewel tagging identificatie mogelijk maakt van inhoudselementen binnen een PDF, vereisen sommige soorten inhoud, zoals grafieken of complexe wiskunde, aanvullende gegevens of informatie als ze toegankelijk moeten worden gemaakt via software die is ontworpen om mensen met een visuele beperking te ondersteunen. Om toegankelijkheid voor een breed scala aan inhoudstypen te bieden en te ondersteunen, biedt de PDF-specificatie de mogelijkheid om “Alternate Descriptions” of “ActualText” aan inhoudselementen te koppelen, zodat geschikte tekstuele beschrijvingen of andere machineleesbare representaties worden geleverd. MathML is bijvoorbeeld in de PDF 2.0-specificatie voor dit doel aangewezen. #### Is het “echte inhoud” of gewoon een artefact? Voor mensen met een visuele beperking heeft het opdelen en weergeven van inhoud in rechthoekige, paginagrote blokken ongewenste neveneffecten, zoals woordafbreking. Bovendien zijn aspecten van paginavormgeving of lay-out die worden gebruikt om de visuele presentatie te verbeteren, volstrekt zinloos voor degenen die dit niet kunnen zien. Om deze redenen moet het taggen van PDF-inhoud erkennen dat sommige inhoud binnen een PDF moet worden behandeld als een *artefact* van visuele presentatie of paginering. Bijvoorbeeld paginanummers, kop- en voetteksten, gekleurde achtergronden of andere ontwerpelementen moeten worden geïdentificeerd zodat toegankelijkheidssoftware die de inhoud verwerkt weet dat deze genegeerd moeten worden. ## Overzicht van de PDF/A-standaarden Verzoeken om toegankelijke PDF’s te produceren verwijzen meestal naar een ISO-standaard genaamd [ISO 19005](https://www.iso.org/standard/38920.html) , beter bekend als PDF/A. Omdat PDF/A echter een *familie* van standaarden is, specificeert alleen “PDF/A-conformiteit” vragen mogelijk niet volledig de werkelijke vereisten. Om te zien waarom, beginnen we met een korte schets van PDF/A van de [website van de PDF Association](https://www.pdfa.org/resource/iso-19005-pdfa/) (geraadpleegd op 21 mei 2020), die ISO 19005 (PDF/A) als volgt beschrijft: > “Het primaire doel van ISO 19005 is het definiëren van een bestandsformaat gebaseerd op PDF, bekend als PDF/A, dat een mechanisme biedt voor het weergeven van elektronische documenten op een manier die hun statische visuele uiterlijk in de loop van de tijd behoudt, onafhankelijk van de tools en systemen die worden gebruikt voor het maken, opslaan of weergeven van de bestanden. > > Een secundair doel van ISO 19005 is het definiëren van een raamwerk voor het weergeven van de logische structuur en andere semantische informatie van elektronische documenten binnen conformerende bestanden. > > Een ander doel van ISO 19005 is het bieden van een raamwerk voor het vastleggen van de context en geschiedenis van elektronische documenten in metadata binnen conformerende bestanden.” Duidelijk heeft PDF/A verschillende kerndoelstellingen. ### Evolutie en groei van PDF De [PDF 1.0-specificatie](https://web.archive.org/web/20150617123515/http://acroeng.adobe.com/PDFReference/PDF%20Reference%201.0.pdf) werd gepubliceerd in 1993 en telde slechts 230 pagina’s. Maar 13 jaar later was de specificatie voor [Adobe’s PDF-versie 1.7](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf) ruim meer dan 1000 pagina’s! In de loop van de tijd zijn de omvang en complexiteit van de PDF-specificatie gegroeid door uitbreiding van de ondersteunde functieset: met nieuwe technologieën en de vereisten van steeds geavanceerdere op PDF gebaseerde workflows en gebruiksscenario’s binnen verschillende markten en gemeenschappen. Het is echter waarschijnlijk dat geen enkele gebruiker, of groep gebruikers, ooit alle mogelijkheden benut: PDF moet “alle basissen afdekken” om zeker te zijn dat het de behoeften van de grootst mogelijke markt kan dienen. Zo zijn veel PDF-functies die zijn ontworpen om high-end commerciële drukwerkproductie te ondersteunen niet nodig voor typisch dagelijks kantoorgebruik als formaat voor het opslaan of delen van documentatie. ### PDF/A: “terug naar de basis” voor PDF De kerndoelstelling van PDF/A is ervoor te zorgen dat conformerende PDF’s geschikt zijn voor langetermijnarchivering of inhoud bevatten die toegankelijk is voor mensen die verschillende hulpmiddelen gebruiken om deze PDF’s te “consumeren”. Om deze doelen te bereiken beperkt PDF/A de set PDF-functies die zijn toegestaan in conforme PDF-bestanden, en verbiedt het gebruik van functies die de archiverings- of toegankelijkheidswaarde zouden kunnen ondermijnen. Je kunt PDF/A zien als een set standaarden die specificeren hoe conforme PDF-bestanden een *subset* van de volledige PDF-specificatie gebruiken om bestanden te produceren die geschikt zijn voor langetermijnarchivering of om te garanderen dat hun inhoud toegankelijk is. De beperkingen van PDF/A maken het mogelijk PDF’s te gebruiken als een “archivisch digitaal papier” dat onafhankelijk is van de technologie om PDF’s te lezen en van de computeromgeving die wordt gebruikt om hun inhoud te openen. Conforme PDF’s mogen niets bevatten waarvan het gedrag “implementatie-afhankelijk” is — d.w\.z. afhankelijk van de specifieke software of besturingssystemen die worden gebruikt om ze te bekijken of te verwerken. PDF’s moeten ook *volledig*zijn: belangrijke documentbronnen moeten in het bestand zijn ingebed — zoals lettertypen of kleurprofielen. ### PDF/A-versies en conformiteitsniveaus Er zijn verschillende *versies* van de PDF/A-standaard, die elk een specifieke versie van de formele PDF-specificatie weerspiegelen (PDF 1.4, 1.7 en 2.0). Daarnaast zijn er verschillende *conformiteitsniveaus* die aangeven aan welk(e) aspect(en) van de PDF/A-standaard een PDF-bestand voldoet. Wanneer je dus “PDF/A-conformiteit” claimt of eist, kun je denken aan PDF-bestanden die voldoen aan **PDF/A-** Bijvoorbeeld * PDF/A-1a: betekent PDF/A-versie 1, conformiteitsniveau a * PDF/A-2b: betekent PDF/A-versie 2, conformiteitsniveau b We verkennen deze iets gedetailleerder. #### PDF/A-versies De PDF/A-standaard valt onder de auspiciën van de ISO en wordt gepubliceerd als een standaard genaamd ISO 19005. Zoals opgemerkt heeft de PDF-specificatie zich in de loop van de tijd ontwikkeld en dat vereiste op zijn beurt updates van ISO 19005, wat resulteerde in de onderstaande tabel: | | | | | ---------------- | ----------------- | --------------------------- | | **PDF/A-versie** | **ISO-standaard** | **Gebaseerd op PDF-versie** | | PDF/A-1 | ISO 19005-1:2005 | PDF 1.4 | | PDF/A-2 | ISO 19005-2:2011 | PDF 1.7 | | PDF/A-3 | ISO 19005-3:2012 | IS0 32000-1 (PDF 1.7) | Ten tijde van het schrijven (april/mei 2020) is een bijgewerkte PDF/A-4 (ISO 19005-4) [in voorbereiding](https://www.iso.org/standard/71832.html). #### PDF/A-conformiteitsniveaus Naast drie PDF/A-versies (PDF/A-1, PDF/A-2 en PDF/A-3) zijn er drie *conformiteitsniveaus*: * Niveau A (toegankelijk) voor toegankelijkheid (omvat de archiveringsvereisten van Niveau B) * Niveau B (basis) voor archivering * Niveau U (Unicode) (= archivering plus het gebruik van Unicode voor tekst) Hier volgt een korte beschrijving van deze conformiteitsniveaus: * **Niveau B (basis)** is de minimale vereiste voor conformiteit onder PDF/A. Het definieert vereisten om ervoor te zorgen dat conforme PDF-documenten geschikt zijn voor langetermijnarchivering — dat ze altijd betrouwbaar kunnen worden bekeken of afgedrukt, onafhankelijk van specifieke software, tools of besturingssystemen. * **Niveau A (toegankelijkheid)** omvat de vereisten van Niveau B-conformiteit, maar vereist daarnaast het gebruik van getagde PDF om logische structuur- en leesvolgorde-informatie te bieden, samen met het gebruik van Unicode om toegang tot de tekst van het document mogelijk te maken. * **Niveau U (Unicode)** conformiteit was een niveau dat aan PDF/A-2 werd toegevoegd en bouwt voort op Niveau B door daarnaast het gebruik van Unicode voor documenttekst te eisen, maar gaat niet zo ver als Niveau A door het afdwingen van structuurinformatie. PDF/A-versies en conformiteitsniveaus kunnen in een tabel worden samengevat: | | | | | | ----------------------- | ---------------------------------- | -------- | -------- | | **Conformiteitsniveau** | **PDF/A-** | | | | Niveau A (toegankelijk) | PDF/A-1a | PDF/A-2a | PDF/A-3a | | Niveau B (basis) | PDF/A-1b | PDF/A-2b | PDF/A-3b | | Niveau U (Unicode) | n.v.t. (bestond niet voor PDF/A-1) | PDF/A-2u | PDF/A-3u | ### PDF/UA (“Universele Toegankelijkheid”) Hoewel naleving van Niveau A van de PDF/A-standaard een deel van de vereisten voor toegankelijke PDF’s definieert, gaat een andere ISO-standaard genaamd [ISO 14289](https://www.iso.org/standard/64599.html) , aangeduid als PDF/UA, verder. PDF/UA versterkt de toegankelijkheidsvereisten en verduidelijkt de richtlijnen in de PDF/A-standaarden en is de voorkeursstandaard voor toegankelijke PDF’s geworden. #### Matterhorn-protocol Lezers met een grote belangstelling om meer te weten te komen over PDF/UA-conformiteit kunnen interesse hebben in het [Matterhorn Protocol](https://www.pdfa.org/resource/the-matterhorn-protocol-1-02/) dat “een lijst is van alle mogelijke manieren om PDF/UA-conformiteit te laten mislukken”. ### Validatiesoftware Om te controleren of een PDF-bestand voldoet aan een bepaalde standaard moet het worden *worden gevalideerd* met conformiteitssoftware die de PDF doorzoekt om te controleren of de inhoud en structuur voldoen aan de vereisten van die standaard — zoals PDF/UA of PDF/A-*x*a (waar *x* = 1, 2 of 3). Merk op dat validatie van PDF’s — het verwerken ervan met een voorkeurvalidatietool — diagnostische berichten of waarschuwingen kan opleveren die voor de niet-expert redelijk cryptisch kunnen zijn — misschien vanwege een bepaalde PDF-gegevensstructuur op laag niveau (of structuur) die niet voldoet aan de relevante standaard. Voor veel auteurs kan het interpreteren van die waarschuwingen en deze omzetten in een uitvoerbare oplossing voor hun document(en) een behoorlijke uitdaging zijn. #### Gratis validatiesoftware * [veraPDF](https://verapdf.org/) die, om hun website te citeren (geraadpleegd op 28 mei 2020), een “speciaal gebouwde, open-source bestandsformaatvalidator is die alle PDF/A-onderdelen en conformiteitsniveaus ondersteunt”. * (alleen Windows) [PDF Accessibility Checker (PAC 2024)](https://pac.pdf-accessibility.org/en/download) die een “...gratis tool voor het controleren van PDF-toegankelijkheid is die sinds 2010 is geprobeerd en getest”. #### Commerciële validatiesoftware * [Adobe Acrobat](https://acrobat.adobe.com/uk/en/acrobat/pricing.html) biedt een reeks PDF-validatietests samen met tools om tags in niet-conforme PDF-bestanden te bewerken en te herstellen. ### PDF Association: een geweldige informatiebron De [PDF Association](https://www.pdfa.org/) produceert veel *uitstekende* bronnen over PDF/A, PDF/UA en vele andere PDF-gerelateerde onderwerpen — waaronder video’s op hun [YouTube-kanaal](https://www.youtube.com/user/ThePDFAssociation/playlists) samen met artikelen en gratis technische publicaties op hun website. Een dergelijke publicatie is [PDF/UA in a Nutshell](https://www.pdfa.org/resource/pdfua-in-a-nutshell/) die een onschatbare inleiding geeft tot de PDF/UA-standaard en de vereisten ervan. ## Toegankelijke PDF’s van TeX-engines en LaTeX Hopelijk hebben de voorgaande besprekingen aangegeven dat het produceren van volledig toegankelijke en correct getagde PDF-bestanden een veeleisende technische uitdaging is. Bovendien toonde zelfs het eenvoudige Microsoft Word-voorbeeld aan dat auteurs heel gemakkelijk combinaties van softwarefuncties kunnen gebruiken die resulteren in getagde PDF-documenten die niet aan toegankelijkheidscriteria voldoen. Als auteurstool biedt LaTeX auteurs vrijwel onbeperkte flexibiliteit in het scala en de complexiteit van documenten die je kunt maken — wat misschien juist de reden is om het in de eerste plaats te kiezen. LaTeX ondersteunt ook uitbreidbaarheid via duizenden add-onpakketten die auteurs als onderdeel van hun documenten kunnen gebruiken. Bovendien hebben auteurs de vrijheid om nieuwe TeX- of LaTeX-macro’s te schrijven of bestaande te herdefiniëren om specifieke effecten te bereiken. Toch heeft deze vrijheid en flexibiliteit misschien een prijs, omdat de inhoud die wordt geproduceerd door de talloze interacties van al die LaTeX-pakketten en macro’s “op de een of andere manier” georkestreerd moet worden als LaTeX automatisch correct getagde en toegankelijke PDF-uitvoer moet genereren. In de praktijk vormen de uitbreidbaarheid, kracht, veelzijdigheid en auteurvrijheid die LaTeX biedt technische uitdagingen voor het naadloos en transparant (“automatisch”) produceren van volledig toegankelijke getagde PDF-documenten die voldoen aan de PDF/UA- of PDF/A-{1|2|3}a-standaarden. De bredere TeX- en LaTeX-gemeenschap doet veel moeite om die uitdagingen aan te pakken en The TeX User Group (TUG) coördineert onderzoeks- en ontwikkelingsinspanningen via de PDF accessibility and PDF standards [werkgroep](https://www.tug.org/twg/accessibility/). Er is een [discussielijst](https://tug.org/mailman/listinfo/accessibility) die belangstellenden een manier biedt om de productie van getagde PDF-bestanden met TeX en LaTeX te bespreken. Bij deze discussies is het de moeite waard te onthouden dat LaTeX eigenlijk geen uitvoerbaar zetprogramma is, maar een grote verzameling geavanceerde macro’s (commando’s) geschreven in een taal op lager niveau die TeX heet. Tussen je zorgvuldig vervaardigde LaTeX-document en de uiteindelijke gezette PDF bevindt zich software die een TeX-engine heet, waarvan de taak is om de verzameling LaTeX-commando’s (d.w\.z. macro’s) die zijn gebruikt om je document te schrijven en op te bouwen “uit te voeren” — en ze om te zetten in de gezette representatie van je document, opgeslagen als een PDF-bestand. Degenen die nieuw zijn in het TeX/LaTeX-ecosysteem worden vaak, en begrijpelijkerwijs, overdonderd door de overvloed aan cryptisch klinkende namen die worden gebruikt voor de tools die ze tegenkomen: TeX, LaTeX, pdfTeX, pdfLaTeX, XeTeX, XeLaTeX, LuaTeX en LuaLaTeX. Als je je hetzelfde voelt, is er hulp beschikbaar in het Overleaf-artikel [Wat zit er in een naam: een gids voor de vele smaken van TeX](/latex/nl/diepgaande-artikelen/55-what-s-in-a-name-a-guide-to-the-many-flavours-of-tex.md) dat de oorsprong en betekenis van al die termen uitlegt. TeX-engines zoals pdfTeX, XeTeX of LuaTeX zijn een klasse software die wordt genoemd *documentcompilers*: ze nemen je LaTeX-code en compileren deze naar de gezette vorm door LaTeX-macro’s (commando’s) te “vertalen” naar hun instructies in de onderliggende TeX-taal, die worden “uitgevoerd” om het gezette resultaat te produceren. Op TeX gebaseerde zetystemen zijn in staat uitzonderlijk complexe inhoud te produceren — waaronder geavanceerde wiskunde, muzieknotatie, chemische structuren, grafieken en geavanceerde meertalige gezette tekst. Om ervoor te zorgen dat die complexe documenten voldoen aan toegankelijkheidsnormen en -voorschriften, moeten TeX-engines, samen met de LaTeX-macroverzameling en LaTeX-pakketten, passend getagde PDF-bestanden genereren door veel aanvullende gegevens in de PDF-bestanden die ze genereren in te sluiten. Hoewel TeX-engines extreem complexe PDF-bestanden kunnen genereren, hebben hun interne processen, algoritmen en functies niet *ingebouwde* functies *speciaal ontworpen* om de productie van getagde en toegankelijke PDF’s te ondersteunen. In plaats daarvan moet ondersteuning voor tagging en toegankelijkheid worden bereikt via complexe macroprogrammering die extra gegevens “injecteert” in de PDF’s die door TeX-engines worden gegenereerd — waarbij de gemarkeerde contentsequenties, structuur-elementen en logische datastructuren worden aangemaakt die zijn opgeslagen in `StructTreeRoot`. En hier komt die “orkestratie” scherp in beeld: code binnen de kern (kernel) van LaTeX samen met code in duizenden pakketten en ontelbare door auteurs gemaakte macro’s zou zeer zorgvuldig moeten samenwerken om ervoor te zorgen dat uitvoering van macro’s correcte tagging van de inhoud van de resulterende documenten oplevert. Die “orkestratie” zou betrouwbaar moeten zijn — ongeacht hoe auteurs de functies, commando’s en functionaliteit van LaTeX, het pakketsysteem en de kracht van TeX-macro’s kiezen te combineren en te gebruiken. ### De behoeften van auteurs Voor de meeste mensen is LaTeX gewoon een hulpmiddel waarmee je prachtig gezette documenten kunt maken, met de vrijheid om pakketten te kiezen die je daarbij helpen. De overgrote meerderheid van LaTeX-auteurs wil simpelweg dat hun documenten “werken”: zonder fouten zetten zodat ze hun scriptie, artikel, rapport kunnen indienen of dat langverwachte boek kunnen afmaken. Niet onredelijk verwachten gebruikers van LaTeX dat hun gekozen verzameling LaTeX-pakketten vreedzaam naast elkaar bestaan en naadloos en transparant samenwerken om de commando’s en functies te leveren die nodig zijn om hun documenten te produceren. Diezelfde wensen zullen waarschijnlijk ook gelden wanneer men geconfronteerd wordt met de eis om getagde PDF uit LaTeX te produceren: het zou “gewoon moeten werken”, transparant en met minimale tussenkomst van de auteur. Helaas zijn we nog ver verwijderd van de ervaring van “Tada! tagging gebeurt gewoon, ongeacht welke rare dingen ik doe”. Het koppelen van de technische vereisten van toegankelijkheid plus getagde PDF aan LaTeX en auteursvrijheid is inherent complex en misschien is het onvermijdelijk dat een vorm van “auteursdiscipline” nodig kan zijn als de technische uitdagingen praktisch implementeerbaar en oplosbaar moeten worden. Een apart, maar verwant, probleem is dat onjuiste tagging mogelijk geen visuele impact heeft op de uiteindelijke PDF: visueel kan het er perfect uitzien en het zal waarschijnlijk ook probleemloos afdrukken, maar onbekend voor de auteur kan de tagging “kapot” zijn, pas ontdekt door daaropvolgende mislukking van PDF/A-conformiteits-/validatiecontroles en/of verder praktisch testen via toegankelijkheidssoftware zoals schermlezers. ### PDF-bestanden geproduceerd op Overleaf Overleaf biedt zijn gebruikersgemeenschap een browsergebaseerde LaTeX-editor samen met project- en documentbeheertools die gezamenlijk auteurschap vergemakkelijken — allemaal gebouwd bovenop een standaard TeX Live-installatie. In feite stelt Overleaf gebruikers in staat om LaTeX op afstand uit te voeren via een webbrowser, waardoor een laag van bescherming wordt geboden tegen de complexiteit van het beheren en onderhouden van een volledig TeX Live-systeem. Een gevolg van Overleaf’s gebruik van een standaard TeX/LaTeX-installatie is dat PDF’s die worden geproduceerd uit LaTeX-code geschreven in Overleaf’s editor worden gemaakt met exact dezelfde technologieën die aanwezig zijn in elke andere TeX Live-installatie van dezelfde versie — inclusief opstellingen die gebruikers op hun lokale apparaten hebben geïnstalleerd. Het enige verschil is dat de TeX-engines die Overleaf’s LaTeX-code compileren en verwerken op externe servers draaien, niet op lokale machines. Overleaf lineariseert de door TeX gegenereerde PDF wel voor efficiënte download/weergave in een browser, maar dat proces staat los van de toegankelijkheid van de PDF-inhoud zelf. Het produceren van toegankelijke PDF’s via Overleaf is afhankelijk van de mogelijkheden en functies die zijn ingebouwd in standaard TeX-engines, samen met de beschikbaarheid van geschikte LaTeX-macro-pakketten die gebruikers als onderdeel van hun document kunnen inzetten. LaTeX-documenten die met Overleaf worden gemaakt, moeten compatibel blijven met andere TeX- en LaTeX-installaties omdat gebruikers hun LaTeX-project vaak van Overleaf moeten exporteren voor indiening bij een breed scala aan uitgevers- en journalsystemen. Het introduceren van Overleaf-specifieke functies in de LaTeX-documenten of de onderliggende TeX-engines zou de vrijheid van gebruikers om hun werk elders te gebruiken ernstig belemmeren. Overleaf erkent en ondersteunt de behoefte aan volledig toegankelijke PDF’s die worden gegenereerd vanuit TeX/LaTeX-auteursystemen: we investeren tijd in het onderzoeken van toegankelijkheidsproblemen, het verkennen van de nieuwste ontwikkelingen in TeX-engines en experimentele LaTeX-pakketten die getagde PDF ondersteunen. Uiteindelijk is er, ten tijde van het schrijven, geen kant-en-klare oplossing die LaTeX-auteurs kunnen gebruiken (via `\usepackage`) om naadloos en transparant volledig toegankelijke en PDF/UA-conforme PDF’s te genereren uit generieke LaTeX-documenten. Wanneer die oplossingen beschikbaar komen via TeX Live-updates, zullen ze uiteraard beschikbaar worden voor de Overleaf-gebruikersgemeenschap. ### Enkele LaTeX-pakketten om tagging en toegankelijkheid te verkennen Voor veel mensen, [tex.stackexchange](https://tex.stackexchange.com/) is het eerste aanspreekpunt voor hulp met TeX, LaTeX of ConTeXt. Het is een geweldige bron en bevat veel vragen over het onderwerp [toegankelijkheid](https://tex.stackexchange.com/questions/tagged/accessibility?tab=Newest) en de productie van toegankelijke PDF’s via LaTeX. Als je deze vragen leest en doorbladert, en de daaropvolgende stroom van antwoorden en opmerkingen, is slechts één conclusie onvermijdelijk: op dit moment is er geen volledige, productieniveau-oplossing om automatisch volledig toegankelijke, standaardconforme, getagde PDF’s te maken uit elk type LaTeX-document. Er zijn echter enkele pakketten die tagging ondersteunen — zij het misschien binnen een beperkt scala aan gebruiksscenario’s en documenttypen. De volgende lijst is bedoeld voor lezers die LaTeX-gebaseerde PDF-tagging willen verkennen: * [`tagpdf` pakket](https://ctan.org/pkg/tagpdf) (Ulrike Fischer): zeer capabel pakket ontworpen om te experimenteren met PDF-tagging. Ondersteunt pdfTeX en LuaTeX en biedt uiterst nuttige en interessante documentatie met uitstekende notities over de technische uitdagingen van het maken van getagde PDF’s via TeX-engines; het is sterk aanbevolen leesvoer voor iedereen die de betrokken problemen beter wil begrijpen. Verwachte toekomstige richting ligt waarschijnlijk bij LuaTeX. * [`axessibility` pakket](https://ctan.org/pkg/axessibility?lang=en) (Boris Doubrov en Universiteit van Turijn): biedt toegang tot formules in PDF-bestanden via ondersteunende technologieën. * [`toegankelijkheid` pakket](https://ctan.org/pkg/accessibility) (Andy Clifton): maakt getagde en gestructureerde PDF-bestanden. De CTAN-notities vermelden dat dit pakket is “gericht op gebruikers van de KOMA-Script-documentklassen”. * [`accsupp` pakket](https://ctan.org/pkg/accsupp) (Heiko Oberdiek): experimenteel pakket om betere ondersteuning voor toegankelijkheid van PDF-bestanden te bieden. Een verdere opmerkelijke referentie is een paper uit 2018 [Implementing PDF standards for Mathematical Publishing](http://web.science.mq.edu.au/~ross/TaggedPDF/PDF-standards-v2.pdf) van dr. Ross Moore van de afdeling Wiskunde, Macquarie University. In dat artikel geeft dr. Moore een korte schets van de uitdagingen van het taggen van PDF’s in LaTeX: > “De belangrijkste bron van moeilijkheid ligt in de manier waarop verschillende omgevingen met elkaar kunnen interageren. Er zijn veel situaties in LaTeX waarin de ene omgeving of structuur niet echt voltooid is totdat de volgende is begonnen. Het gaat dus niet alleen om het omringen van elk stuk aangeleverde inhoud met begin- en eindtags. In plaats daarvan moet men de subtiliteiten begrijpen van hoe verschillende omgevingen en andere structuren feitelijk beginnen en eindigen, binnen de context die door het omringende materiaal is vastgesteld.” Dr. Moore is ook de huidige onderhoudsverantwoordelijke van het [`pdfx`](https://ctan.org/pkg/pdfx) pakket en een expert en pionier van getagde PDF met behulp van TeX/LaTeX. Zijn werk is zeker de moeite waard om op te zoeken — inclusief deze video op YouTube die interessante inzichten biedt: {% embed url="" %} #### Opmerking over het pdfx-pakket De [`pdfx`](https://ctan.org/pkg/pdfx) pakket (Ross Moore et al.) biedt uitstekende ondersteuning voor PDF/A-1|2|3b (archivering), en andere opties, maar produceert nog geen getagde PDF. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://overleaf-pro.ayaka.space/latex/nl/meer-onderwerpen/04-an-introduction-to-tagged-pdf-files-internals-and-the-challenges-of-accessibility.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.