> 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/sv/fler-amnen/04-an-introduction-to-tagged-pdf-files-internals-and-the-challenges-of-accessibility.md). # En introduktion till taggade PDF-filer: internals och tillgänglighetsutmaningar ## Uppdatering: januari 2026 Se [Overleafs instruktioner om att skapa taggade PDF-filer](https://docs.overleaf.com/writing-and-editing/creating-accessible-pdfs). Den [LaTeX-teamet](https://latex-project.org/) har släppt nya funktioner som möjliggör automatisk PDF-taggning, det centrala kravet för PDF-tillgänglighet. Dessa nya funktioner finns tillgängliga i Overleaf i [TeX Live 2025](http://\(https//www.overleaf.com/blog/tex-live-2025-is-now-available), med mer aktuella uppdateringar tillgängliga i den rullande TeX Live-versionen som finns via [Overleaf Labs](https://www.overleaf.com/labs/participate). Det är nu möjligt att skapa en taggad PDF från LaTeX-källkod som uppfyller WCAG 2.1 nivå AA genom att följa [vår användardokumentation](https://docs.overleaf.com/writing-and-editing/creating-accessible-pdfs) med hjälp av TeX Live-versioner som finns tillgängliga i Overleaf. Artikeln nedan från 2020, även om den inte är uppdaterad med den senaste informationen om LaTeX-tillgänglighet, kan fortsatt läsas av intresse och för bakgrundsinformation om PDF-taggning. *** ## Vad handlar den här artikeln om? Syftet med den här artikeln är att ge en introduktion till taggad PDF tillsammans med en översikt över några tekniska utmaningar som programvara ställs inför, inklusive TeX-motorer och LaTeX, som strävar efter att producera taggade och tillgängliga PDF-filer. Tillgänglighet, särskilt för PDF-filer, är ett brett och komplext ämne, som också har tekniska utmaningar som inte alltid har en enda, allmänt överenskommen eller accepterad lösning—som hur komplex matematik ska representeras i PDF-filer på ett tillgängligt sätt: med MathML eller LaTeX-kod? Även om vi inte kan gå på djupet i varje ämne och måste förenkla många detaljer, kan vi titta inuti PDF-filer för att visa vad det egentligen innebär att tagga en PDF. Overleaf hoppas att den här artikeln ska fungera som en användbar introduktion och ge tillräcklig bakgrund för att hjälpa läsarna att bättre förstå de tekniska utmaningarna och stödja fortsatt läsning och utforskning av taggad PDF och tillgänglighet. Resurser i den här artikeln inkluderar: * [en 8 minuter lång video](#video-showing-the-logical-structure-of-a-tagged-pdf) som utforskar en taggad PDF som skapats med LaTeX; * [ett Overleaf-projekt](#using-luatex-an-example-in-the-overleaf-gallery) för att utforska användningen av blanktecken i LuaTeX; * [ljudinspelningar](#tagged-yes-but-the-reading-order-is-incorrect) som visar problem med PDF-tillgänglighet. ## Introduktion Att säkerställa tillgänglighet för digitalt innehåll erkänns med rätta som en viktig aspekt av innehållsproduktion och spridning. Vidare antar regeringar, inklusive [Storbritannien](https://www.gov.uk/guidance/accessibility-requirements-for-public-sector-websites-and-apps) och [USA](https://www.hhs.gov/sites/default/files/Intro%20to%20Accessibility%20and%20508.pdf), lagar som kräver att innehåll som produceras under deras jurisdiktion uppfyller definierade tillgänglighetskriterier. Efterlevnad genom spridning av innehåll i HTML är inte särskilt betungande, men att säkerställa erforderlig tillgänglighetsnivå för dokument som distribueras i PDF-format kan vara en betydande teknisk utmaning—beroende på vilken programvara som används för att skapa innehåll avsett att utmynna i en PDF-fil. PDF uppstod i början av 1990-talet som en lösning på problem kring tillförlitlig dokumentöverföring, och historien har visat att formatet varit mycket framgångsrikt. PDF är emellertid också ett komplext filformat som tillkom innan behovet av att underlätta tillgänglighet för dokumentinnehåll blev allmänt erkänt och accepterat. Ändå har PDF-specifikationen över tid utvecklats för att tillhandahålla funktioner som möjliggör och stödjer produktionen av tillgängliga PDF-dokument med hjälp av en ”stiliserad” variant av PDF som Adobe kallar *taggad PDF*. I praktiken ställer produktionen av taggade—*och fullt tillgängliga*—PDF-filer betydande ytterligare tekniska krav på programvara som genererar PDF—och det inkluderar TeX-motorer samt LaTeX-ekosystemet av makron och tilläggspaket för LaTeX. ## PDF:s uppkomst som digitalt slutformat Den [tillkomsten av Portable Document Format (PDF)](https://theblog.adobe.com/evolution-digital-document-celebrating-adobe-acrobats-25th-anniversary/) härstammar från en tid då överföring av dokument mellan datorer var förknippad med svårigheter, ofta orsakade av filkonverteringar som resulterade i sidomkastning och andra avvikelser som förvärrades av inkompatibla typsnitt och textkodningar som användes i olika operativsystem (särskilt Windows och Macintosh). Författaren till detta dokument arbetade inom förlagsbranschen vid den tiden och har livliga minnen av att hantera dessa utmaningar! PDF utformades för att lösa problem med fildelning genom att introducera ett universellt digitalt papper i slutform (ej redigerbart), vilket möjliggjorde smidig överföring av självständiga dokument som innehöll de typsnitt som krävdes för att visa dem. Användare kunde äntligen överföra alla möjliga dokument med rimlig säkerhet om att mottagarna, oavsett datorplattform, kunde öppna och läsa dem—dokuments trohet bevarades och besvärlig sidomkastning samt typsnittskompatibilitet/-tillgänglighet hörde till historien. ### Digitalt papper: bra för alla användare? PDF:s släktskap som en form av digitalt papper förutsatte naturligt användning av utskrivna sidnummer, typografi eller designelement som ledtrådar för visuell navigering av innehållet—på skärm eller på papper. Dessa visuella ledtrådar/mekanismer är förstås meningslösa för personer med svår synnedsättning. I dag erkänns förbättrad tillgänglighet för digitalt innehåll med rätta som en viktig aspekt av innehållsproduktion och spridning. Utmaningen för PDF var att tillhandahålla mekanismer som underlättar icke-visuell åtkomst till innehåll inlåst i en ”behållare” som ursprungligen var utformad för att återskapa det visuella mediet hos den tryckta sidan. Den första versionen av PDF-specifikationen (PDF 1.0) [släpptes officiellt den 15 juni 1993](https://theblog.adobe.com/evolution-digital-document-celebrating-adobe-acrobats-25th-anniversary/) följdes av nya versioner med uppdateringar som år 2001 (PDF 1.4) innefattade införandet av ”taggad PDF” som [”...gjorde det möjligt för användare av hjälpmedelsteknik”](https://www.adobe.com/accessibility/pdf.html). Efterföljande utgåvor av PDF-specifikationen har utvidgat och förbättrat PDF:s funktioner, vilket kulminerade i den senaste utgåvan (PDF 2.0) som, baserat på [rapporter](https://www.pdfa.org/tagged-pdf-2-0/), har gjort en omfattande omarbetning av tillgänglighetsfunktionerna—även om PDF 2.0 ännu inte stöds väl av TeX-motorer. ## Innehåll i PDF-filer För att förstå de problem som är inblandade är det värt att undersöka hur PDF-filer faktiskt representerar sidinnehållet de innehåller. Långt inne i en PDF-fil finns innehållet för varje sida i den sidans *innehållsström*: en sekvens av PDF-operatorer (”kommandon”) som placerar text eller grafik på en viss sidlokation för återgivning (visning) av programvaran som används för att *visa* PDF-filen. I praktiken ger innehållsströmmen en grafisk beskrivning eller ett ”recept” som talar om för PDF-visningsprogram hur de ska ”rita” varje sida—och definierar vad som ska visas på sidan och var. Naturligtvis innehåller denna serie operatorer instruktioner om att välja vissa typsnitt i en viss storlek, välja färger, definiera linjebredder, rita linjer, kurvor och så vidare—allt som krävs för att ge en komplett grafisk beskrivning för visuell presentation av en sida. För att minska filstorleken komprimeras PDF-innehållsströmmar och lagras i ett kompakt binärt format, men om du har tillgång till lämplig programvara, som Adobe Acrobat Pro DC, kan du använda den för att visa en ”dekomprimerad” ren textversion av sidinnehållsströmmar. Låt oss överväga hur PDF-operatorer kan ”rita” en tabell: PDF-innehållsströmmen skulle innehålla en lämplig sekvens av operatorer för att skapa horisontella/vertikala linjer, välja olika typsnitt och mata ut text placerad på olika sidpositioner för att skapa tabellens innehåll. För att demonstrera detta, låt oss betrakta ett mycket enkelt otaggat PDF-dokument som inte innehåller något mer än en grundläggande tabell med viss text—skapat i Microsoft Word av skäl som kommer att bli tydliga senare i artikeln. Här är en skärmdump som visar vår enkla PDF: ![En tabell skapad i Microsoft Word](/files/a7a2a973b35b3fc545066cd4959c9cf35cc37971) Om vi extraherar den (dekomprimerade) sidinnehållsströmmen för denna fil och klistrar in de första raderna i en textredigerare kan vi sammanfatta några av PDF-operatorerna för att få en ”känsla” för hur PDF-filer ”beskriver” innehållet som visas på denna sida. ![Bild av innehållsström i en PDF-fil](/files/20f3d6ca3b2f5ce88be7d5ef7b2b6cf92c8ae40b) Om du har tillgång till Adobe Acrobat Pro DC kan du använda det för att lista de operatorer som finns i en PDF-sidas innehållsström. Här är Acrobats *Intern PDF-struktur* vy av samma PDF som hjälpsamt ger en beskrivning på en rad av varje operator som används för att ”rita” vår enda sida som innehåller en grundläggande tabell—observera att dessa korta beskrivningar tillhandahålls av Adobe Acrobat Pro DC, de *inte* finns i själva PDF-filen: ![Bild av en PDF-innehållsström sedd i Adobe Acrobat Pro DC](/files/04aa8692f9e606794c765653caf261867faab5aa) Men observera att inga av dessa ritinstruktioner (operatorer) lagrar någon ”betydelse” eller ”beskrivning” av vad de faktiskt producerar: de är bara en uppsättning grafikoperatorer som resulterar i konstruktionen av det en *seende betraktare känner igen* som en tabell. För personer med svår synnedsättning är det uppenbart att det inte är en användbar metod att visa tabellen som resultatet av dessa grafiska operatorer i PDF:ens innehållsström för att komma åt innehållet. Det som krävs är en mekanism för PDF-filer att innehålla en lämplig icke-visuell (maskinläsbar) beskrivning av den tabellen—och, naturligtvis, allt annat innehåll som finns på sidorna i en PDF-fil. För att möjliggöra icke-visuell åtkomst till innehåll behöver PDF-filer innehålla ytterligare data som kopplar ”betydelse” eller semantik till samlingar eller grupper av operatorer som används för att ”rita” en viss del av innehållet. Detta principen att tilldela eller tillhandahålla ”betydelse” måste nödvändigtvis omfatta alla former av innehåll som finns i en PDF: den mekanismen finns och kallas *taggning* av PDF-filen för att skapa en ”variant” av PDF som, föga överraskande, kallas *taggad PDF*. ## Introduktion till taggad PDF Taggad PDF är benämningen på en särskild typ av PDF-fil som innehåller ytterligare data (och datastrukturer) som inte finns i otaggade PDF-filer. Även om principerna/idées bakom taggad PDF lämpar sig för en översiktlig beskrivning, är de fullständiga detaljerna komplexa och upptar många sidor i den formella PDF-specifikationen. Adobe utformade taggad PDF för att uppnå ett antal mål som inkluderade att göra innehåll tillgängligt för användare med synnedsättning, men det omfattar också följande lista hämtad från avsnitt 10.7 i [Adobes PDF 1.7-specifikation](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf): * enkel extrahering av text och grafik för att klistras in i andra program; * automatisk omsättning av text och tillhörande grafik för att passa en sida av annan storlek än den som antogs för den ursprungliga layouten; * bearbetning av text för ändamål som sökning, indexering och stavningskontroll; * konvertering till andra vanliga filformat (såsom HTML, XML och RTF) med bibehållen dokumentstruktur och grundläggande formateringsinformation. Dessutom kräver taggad PDF också: * att text inom PDF-innehållet representeras i en form som kan konverteras till Unicode; * ordavbrott måste representeras uttryckligen—observera att TeX-motorer inte använder blanktecken för att separera ord, de använder TeX:s flexibla mellanrum kallat glue (se nedan); * faktiskt (”verkligt”) innehåll särskiljs från layout- och pagineringsartefakter. Bakom taggad PDF ligger två nyckelbegrepp som vi ska gå igenom: * att definiera den logiska strukturen hos innehåll i en PDF-fil; * märkning (taggning) av PDF-innehåll med en uppsättning standardiserade innehållstyper. ## Logisk struktur I längre dokument delas innehållet vanligtvis upp i en sekvens av mindre innehållsobjekt; till exempel delas böcker vanligtvis in i kapitel som i sin tur delas in i avsnitt och underrubriker som innehåller stycken, tabeller, figurer/diagram, punktlistor eller numrerade listor, fotnoter och referenser och så vidare. Strukturen och organisationen av innehållet i en sådan bok, eller någon annan dokumenttyp, kallas dess *logiska struktur*. Föreställningen om ett dokuments logiska struktur spelar en viktig roll för PDF-tillgänglighet men som koncept kan logisk struktur verka lite vag och svår att förstå. Följande definition från [Encyclopedia of Database Systems](https://link.springer.com/referenceworkentry/10.1007%2F978-0-387-39940-9_213) ger en hjälpsam insikt: > ”Logisk struktur avser hur information i ett dokument är organiserad; den definierar informationshierarkin och förhållandet mellan olika delar av dokumentet. Logisk struktur anger hur ett dokument är uppbyggt, till skillnad från vad ett dokument innehåller.” Observera att denna definition av logisk struktur inte hänvisar till exakt *hur* att strukturinformationen lagras fysiskt; bara att den ger en representation av ett dokuments struktur och organisation. De exakta detaljerna för hur ett dokuments logiska struktur lagras eller representeras beror på implementationen: en funktion av den programvara som används för att generera och bearbeta den. ### Logisk struktur i PDF-filer PDF-specifikationen tillhandahåller mekanismer genom vilka ett dokuments logiska struktur kan registreras i en PDF-fil—för användning av programvara som till exempel kanske vill exportera PDF:ens innehåll till andra format såsom XML, HTML eller Microsoft Word. Dessa exportprocesser behöver producera ett korrekt strukturerat textdokument som följer reglerna för det målformat som exporteras till—det uppnås bäst när exportbearbetningen styrs av logisk strukturinformation som finns i PDF-filen. Dessutom är den logiska strukturen i en PDF-fil väsentlig för tillgänglighetsprogramvara som till exempel kanske vill utföra text-till-tal-operationer och läsa innehåll högt för någon med synnedsättning. Text-till-tal-processen måste säkerställa att innehållet läses upp i rätt ordning/sekvens, annars skulle det ge meningslösa resultat. Observera också att själva begreppet sida kanske inte har någon meningsfull betydelse för tillgänglighetsprogram som bara är intresserade av PDF:ens innehåll och dokumentets struktur, inte den visuella uppdelningen och presentationen i sidstorleksblock. #### Namnge innehållsobjekt Att registrera (lagra) ett PDF-dokuments logiska struktur kräver någon uppsättning meningsfulla namn som tilldelas de olika *typerna* av innehållsobjekt som sannolikt återfinns i ett typiskt PDF-dokument—och identifierar avsnitt av innehåll som representerar rubriker, stycken, tabeller, listor och så vidare. Dessutom har vissa innehållsobjekt såsom innehållsförteckning, numrerade/punktlistor och tabellmaterial ganska komplexa egna strukturer, så det behöver också finnas viss vägledning/regler för att ange hur dessa mer komplexa innehållsobjekt byggs upp—deras understruktur. Ett ytterligare krav är att tydligt identifiera allt PDF-innehåll som bör ignoreras av hjälpmedelsprogramvara som bearbetar PDF-filen; till exempel är sidhuvuden och sidfötter pagineringsartefakter som innehåller text som är överflödig för personer med svår synnedsättning: det innehållet bör ignoreras. Mekanismerna som PDF använder för att definiera ett dokuments logiska struktur är utformade för att vara flexibla, så i princip skulle olika program som genererar och bearbetar PDF-filer kunna använda namn för innehållstyper enligt vilken konvention de vill. För att maximera dokumentutbytet och låta olika PDF-bearbetningsprogram ge konsekventa resultat definierade Adobe dock en uppsättning standardnamn för typer av innehållsobjekt som PDF-genererande programvara bör följa. Inom PDF-specifikationen kallas dessa standardnamn för taggar, vilket ger upphov till begreppet *taggad* PDF. ### Märkning av PDF-innehåll: En titt ”under huven” För att göra diskussionen något mindre abstrakt ska vi ta en kort titt på internals i taggade PDF-filer—även om vi inte kan täcka alla detaljer eftersom taggad PDF är ett så stort och komplext ämne. #### Markerade innehållssekvenser: byggstenar för taggad PDF På lägsta nivå börjar processen att registrera betydelsen av innehåll som finns på en PDF-sida (dvs. i dess innehållsström) med *markerade innehållssekvenser* som används för att identifiera (ge ”betydelse åt”) kluster eller grupper av PDF-operatorer. Markerade innehållssekvenser tilldelas en numerisk identifierare som kallas dess `MCID` (*markerade innehållsidentifierare*) vilket är ett heltal som går från 0 till något maximum N på varje sida. Dessa `MCID` värden ger ett sätt att unikt identifiera sekvenser av operatorer som finns i innehållsströmmen för en viss sida. För att förtydliga: för varje sida börjar `MCID` identifierarna på 0 och ökar sekventiellt upp till något maximalt värde som beror på hur många markerade innehållssekvenser som finns i en viss sidas innehållsström. Markerade innehållssekvenser är i praktiken grundläggande ”byggstenar” som används för att sammanställa datastrukturer på högre nivå som kallas *struktur-element*. Dessa struktur-element innehåller en tagg, vilket är namnet som används för att identifiera vilken typ av innehållsobjekt de representerar. #### Exempel på struktur-element Här hoppar vi fram något, men det är värt att gå igenom ett exempel. Anta att du har tre små textfragment av sidinnehåll och vart och ett identifieras i innehållsströmmen av en annan markerad innehållssekvens. Var och en av dessa tre textfragment kan paketeras i sitt eget struktur-element, med en tagg, och alla tre kan ”kopplas samman” med hjälp av ett annat struktur-element för att representera ett innehållsobjekt på högre nivå, såsom en rad i en innehållsförteckning. ![Bild som förklarar struktur-element och markerade innehållssekvenser](/files/a6eebea6ca274dae2f02e92e0666c4f65d330270) Genom en form av förälder–barn-datamodell kombineras samlingar av struktur-element för att skapa länkade datastrukturer som representerar mer komplexa dataobjekt såsom numrerade och punktlistor, tabeller, matematik och så vidare. I slutändan kopplas hela samlingen av struktur-element i hela PDF-filen ytterligare samman och kombineras för att skapa PDF-dokumentets logiska struktur—vi återkommer till detta senare i artikeln. ### Vad är en markerad innehållssekvens? I diskussionen ovan använde vi ett enkelt otaggat PDF-dokument som innehöll en tabell (skapad i Microsoft Word) men om vi instruerar Word att skapa en taggad PDF kan vi se att viss ytterligare märkning har dykt upp i sidinnehållsströmmen. Här betraktar vi bara de första raderna i innehållsströmmen (det finns hundratals rader) men observera förekomsten av ytterligare operatorer såsom `/P <> BDC` och `EMC` som används för att identifiera en markerad innehållssekvens. Vi kommer inte att utforska den fullständiga syntaxen för markerade innehållssekvenser utan hänvisar läsaren till sidan 862 i [Adobes officiella PDF 1.7-specifikation](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf). ![Bild som visar markerade innehållssekvenser i en taggad PDF-innehållsström](/files/2f71fa7ed0c6f6149b428d0b5014b7c91e016daf) För enkel referens visar vi återigen den otaggade versionen: ![Bild som visar PDF-innehållsström](/files/20f3d6ca3b2f5ce88be7d5ef7b2b6cf92c8ae40b) I *otaggad* PDF, operatorer såsom `/P <> BDC` och `EMC` saknas men de återstående operatorerna är oförändrade: den otaggade PDF-filen saknar den extra märkning som används för att identifiera vissa sekvenser/samlingar av operatorer. Återigen kan vi också använda Adobe Acrobats *Intern PDF-struktur* funktion för att visa de markerade innehållssekvenserna i en innehållsström—här har vi markerat dem med en grön ram: ![Bild som visar markerade innehållssekvenser i en taggad PDF-innehållsström visad i Adobe Acrobat Pro DC](/files/5ddc302b0eb1555d671c02d397f62cd346879442) Observera att vissa innehållsdelar är markerade med `/Artifact` som identifierar material på PDF-sidan som bör *ignoreras* av hjälpmedelsprogram, såsom de som läser upp text för synskadade. Följande skärmdump visar en utökad vy av den första markerade innehållssekvensen—den med `MCID` värdet av `0`. Slutet på den markerade innehållssekvensen identifieras av PDF-operatorn `EMC`. ![Bild som visar detaljerna för operatorerna som omfattas av en markerad innehållsström](/files/a49022155d98dacb765a3ec992b01ac4dd75029e) ### Lagring av den logiska strukturen Som nämnts krävs det, utöver att ge en beskrivning av enskilda innehållsobjekt (stycken, listor, tabeller etc.), att tillgängliga PDF-filer innehåller en representation av hela dokumentet i form av dess logiska struktur. Enskilda delar av tillgängligt innehåll måste länkas samman för att skapa ett komplett, navigerbart och tillgängligt dokument—på liknande sätt som ett enskilt HTML-dokument konstrueras av stycken, grafik och tabeller för att skapa en webbsida. Dessutom är det väsentligt att ett PDF-dokuments logiska struktur säkerställer att allt innehåll kan navigeras i rätt *läsordning*, oberoende av den ordning i vilken sidinnehållet skrevs ut till PDF-sidornas innehållsströmmar. Vi kommer att utforska läsordning mer i detalj nedan. #### Logisk struktur: ett ”träd” av struktur-element Vi noterade att PDF-filer använder något som kallas en *struktur-element* för att representera enskilda innehållsobjekt, och att ett struktur-element innehåller en tagg för att identifiera vilken innehållstyp det representerar. För att ge en representation av dokumentets logiska struktur länkas alla struktur-element samman med förälder—barn-relationer och organiseras i ett ”strukturträd”. Internt innehåller taggade PDF-filer ett objekt som kallas `StructTreeRoot` som innehåller (pekar på) struktur-element som fungerar som utgångspunkt eller ”rot” för dokumentets logiska strukturträd. Vanligtvis börjar ”roten” i strukturträdet med ett enda struktur-element som är taggat `Document` som innehåller många *barn-* struktur-element som tillsammans representerar hela dokumentets innehåll. All programvara som är utformad för att producera tillgängliga PDF-filer via taggning måste bygga denna mycket komplexa datastruktur (och andra!)—och det inkluderar TeX-motorer och LaTeX. Ett exempel på ett sådant dokumentstrukturträd (`StructTreeRoot`) visas i följande skärmdump av en taggad PDF öppnad i Adobe Acrobat Pro DC: ![Bild som visar StructTreeRoot i en taggad PDF](/files/8bc2c9b67f990a4a52969e96e8a35f3d63e7a625) Jämför ovanstående struktur med den otaggade PDF-versionen: ![Bild som visar frånvaron av StructTreeRoot i en otaggad PDF](/files/0a31f6854d576dbe44b235dcd6c48651b8fd4565) ### Utforska PDF-filers logiska struktur Vi börjar med några illustrationer för att sammanfatta det vi har gått igenom och avslutar med en video som använder Adobe Acrobat Pro DC för att visa mer detaljer om den logiska strukturen i en taggad PDF-fil. Först börjar vi med ett schema som visar de allmänna principerna: en PDF-sida med sin innehållsström märkt med markerade innehållssekvenser (MCS). ![Illustration som visar konceptet markerade innehållssekvenser på PDF-dokumentsidor](/files/37b26e461dde3e53fce41078ee55c07fe20a003f) Dessa MCS kombineras sedan till *struktur-element* som utgör grunden för större innehållstyper som i sin tur länkas samman ytterligare för att lagra PDF:ens logiska struktur inom ett objekt som kallas `StructTreeRoot`. ![Illustration som visar den logiska strukturen i en taggad PDF-fil](/files/eb6d50b63c4e18ce696a223e37e041997069f459) #### Video som visar den logiska strukturen i en taggad PDF Följande video (8 minuter) använder Adobe Acrobat Pro DC för att ta dig på en ”guidad tur” genom detaljerna i den logiska strukturen i en taggad PDF-fil skapad med LaTeX. Den taggade PDF-filen som används i videon heter `tagpdf.pdf`, vilket är ett utmärkt exempel som innehåller dokumentation för det experimentella LaTeX-paketet [`tagpdf`](https://ctan.org/pkg/tagpdf?lang=en). Syftet med `tagpdf` paketet är att tillhandahålla ”verktyg för att experimentera med taggning och tillgänglighet med pdfLaTeX och LuaTeX”. {% embed url="" %} ### En notis om taggning och flexibilitet HTML-specifikationen tillhandahåller ett stort antal fördefinierade taggar för användning när webbplatser konstrueras, men den tillåter också flexibilitet i hur du kombinerar dem för att skapa ditt valda HTML-dokument. På liknande sätt tillhandahåller Adobes specifikation för taggad PDF en uppsättning fördefinierade taggnamn men ställer mycket få begränsningar på hur du kombinerar dessa taggar för att representera komplexa innehållsobjekt i en PDF—av design finns det en stor grad av flexibilitet. Dessutom är det oundvikligt att vissa oklarheter eller problem med tydlighet smyger sig in i den skrivna specifikationen när det gäller vilken specifikation som helst som är så stor och komplex som PDF. Mjukvaruutvecklare som får i uppdrag att implementera en sådan komplex specifikation kan behöva göra ”bedömningar” när de tolkar den eftersom de ställs inför att omvandla skriftliga beskrivningar till fungerande kod. Den inneboende flexibiliteten i taggad PDF tillsammans med tolkningen av specifikationer (eller tillgänglighetsstandarder) påverkar naturligtvis utvecklare av dokumentskapande program: vilka kombinationer av taggar ska användas för att representera användarskapat innehåll när det utmatas till en taggad PDF-fil? Om man lägger till användarnas obegränsade förmåga att skapa alla möjliga typer av innehåll genom att använda funktioner i dokumentskapande programvaran kan man se att automatiserad produktion av tillgängliga taggade PDF-filer är en ganska stor utmaning! Kanske som en spegling av de oundvikliga komplexiteterna i att producera taggade PDF-filer som fullt ut följer tillgänglighetsstandarder är webben full av ”hur man gör”, ”tips” och råd om ”bästa praxis” för att skapa taggade PDF-filer via programvara som Adobe InDesign eller Microsoft Word. Dessutom har PDF Association tagit fram ett användbart dokument kallat [Tagged PDF Best Practice Guide](https://www.pdfa.org/wp-content/uploads/2015/12/StructureElementsBestPracticeGuide_2016-01-19.pdf) skrivet för att hjälpa utvecklare som möter utmaningarna med att implementera taggad PDF och PDF/UA. ## Har du en PDF, men är den tillgänglig? För att avgöra om en viss PDF-fil uppfyller de tillgänglighetsstandarder som krävs, såsom PDF/A eller PDF/UA (se nedan), måste den vara *valideras* med hjälp av en överenskommen valideringsprocess eller ett programverktyg. Validering sker dock vanligtvis efter att dokumentet är färdigt, men den processen kanske inte utförs av dokumentets författare utan av tillgänglighetsspecialister inom den organisation eller det organ som krävde efterlevnad. Om PDF-filen inte klarar valideringen kan den behöva skicklig manuell åtgärd via Adobe Acrobat Pro DC för att rätta till taggningen (om det är möjligt). Alternativt kan den till och med behöva gå tillbaka till författaren för att ändra originaldokumentet, eventuellt genom att undvika att använda de funktioner i dokumentskapande programvaran som orsakade problemen—vilket kan vara extremt svårt att åstadkomma eftersom det kan ligga utanför författarens kontroll. ### Läsordning och innehållsordning Som nämnts ställer produktionen av verkligt tillgängliga PDF-filer ytterligare tekniska krav på den programvara som skapar dokument och, potentiellt, även på dokumentförfattare genom att tvinga fram ”författardisciplin” i hur de använder/tillämpar funktionerna i skapandeprogramvaran. Även om taggad PDF är den mekanism som *möjliggör* produktionen av fullt tillgängliga PDF-filer, betyder *inte* det inte automatiskt att en PDF är fullt tillgänglig, som vi kommer att se i ett exempel nedan. För att producera fullt tillgängliga PDF-filer bör alla innehållsobjekt i PDF:en taggas för att skapa en logisk struktur som säkerställer att innehållet kan nås och läsas i rätt sekvens—kallad *läsordning*. Detta kan tyckas vara ”självklart” men när programvara skriver ut en PDF-fil kan den mata ut grafik och text till sidans innehållsströmmar i vilken ordning den vill. Anta till exempel att en sida börjar med lite text, följs av en tabell och avslutas med en grafik, vilket ger en naturlig *läsordning* av: 1. text 2. table 3. grafik När den skrivs till en PDF-fil kan programvara som genererar en innehållsström för den sidan börja med operatorer för att rita tabellen, sedan mata ut operatorer för att producera grafiken följt av operatorer för texten, vilket i innehållsströmmen skulle ge en *innehållsordning* av: 1. table 2. grafik 3. text Naturligtvis kommer allt att placeras på rätt position när sidan visas. För en helt seende läsare spelar det ingen roll i vilken ordning dessa objekt lagras i sidans innehållsström: de ser en fullständigt återgiven sida med allt på rätt plats. Men om hjälpmedelsprogramvara skulle behöva förlita sig på ordningen på objekten i en innehållsström (innehållsordningen) skulle den stöta på svårigheter om innehållsordningen skilde sig från den naturliga läsordningen; till exempel skulle verktyg för uppläsning läsa materialet i fel sekvens. Lyckligtvis kan hjälpmedelsprogramvara använda en taggad PDF:s logiska ordning (struktur) som måste vara organiserad för att återspegla den sekvens i vilken innehållet ska läsas. Det är av dessa skäl som data som representerar dokumentets logiska struktur lagras separat från det faktiska innehåll som visas på de synliga sidorna, för att möjliggöra > ”... ordningen och nästlingen av logiska innehållselement ska vara helt oberoende av ordningen och placeringen av grafiska objekt på dokumentets sidor.” (sidan 856 i [The PDF Reference, sjätte upplagan, november 2006](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf)) I praktiken är det mycket mer utmanande än det kan verka att garantera en logisk ordning som bevarar läsordningen, så låt oss använda ett enkelt, om än påhittat, exempel som ger en indikation på de problem som är inblandade. #### Felaktig läsordning: Ett exempel med Microsoft Word En dokumentförfattare kanske använder funktionerna i sitt valda dokumentskapande program för att uppnå en specifik visuell effekt—till exempel genom att använda tabeller för att skapa en viss textlayout. Följande skärmdump visar till exempel Microsoft Word-dokumentet som användes i tidigare exempel. Det innehåller en tabell som har använts för att skapa en uppsättning numrerade stycken sida vid sida. Men när det gäller att tagga detta innehåll, hur bör det behandlas: som en tabell eller som en numrerad lista? Båda dessa innehållstyper kräver en komplex taggningsstruktur för att representera dem korrekt. I följande bild, observera i vilken ordning de numrerade styckena är avsedda att läsas: kolumn för kolumn, inte rad för rad. ![Bild av en tabell skapad i Microsoft Word](/files/fe6e361ebb20afa5df79fbae7737c46e963b8bec) Om vi ber Word att spara detta dokument som en PDF med dess inbyggda export – inte Acrobat PDFMaker-pluginet – kan vi säga åt det att skapa taggad PDF: ![Dialogrutan Alternativ i Microsoft Words exportprocess](/files/8c37fb20aab4628fabf587543c4ea0708ecf0e7f) Så, hur taggar Word denna layout? I följande mycket korta video (14 sekunder) använder vi Adobe Acrobat Pro DC för att inspektera taggningsstrukturen som Microsoft Word producerar. {% embed url="" %} För detta dokument har Word skapat ett taggat PDF-dokument som använder en `Tabell` tagg som innehåller två undertaggar: `THead` för tabellens rubrikradgrupp och och `TBody` för att representera gruppen av rader för tabellens brödtext. `THead` och `TBody` båda innehåller `TR` taggar för att representera enskilda rader av innehåll. Taggarna `TR` innehåller ytterligare taggar för att representera den numrerade listpost som finns i varje cell. Följande skärmbild visar den djupt nästlade taggningsstrukturen och den motsvarande komplexa logiska struktur som krävs för att representera även detta extremt grundläggande dokument! ![Bild som visar djupt nästlad taggningsstruktur och logisk struktur för en enkel tabell skapad i Microsoft Word](/files/41318f100ea1a67f7e744450272929a0cadd092f) Jämfört med PDF-filer som genereras av TeX och LaTeX är detta Word-exempel ett extremt enkelt dokument, men det kräver ändå en komplex logisk struktur för att representera det. Föreställ dig nivån av taggningskomplexitet som krävs för att representera LaTeX-genererade PDF-filer som innehåller komplex matematik och tabeller! #### Taggad, ja, men läsordningen är felaktig Även om Word faktiskt producerar en [taggad PDF](https://assets.ctfassets.net/nrgyaltdicpt/3vcgZmG5mkCPYUPTjV30CF/4c34ae919212fa19e979e4cf852e66c1/ReadAloud.pdf) demonstrerar det en av de grundläggande utmaningar som alla applikationer som försöker producera fullt tillgängliga PDF-filer ställs inför: att korrekt representera innehållets avsedda läsordning. Under skapandet av den taggade PDF-filen beslutade Words interna processer att skriva den motsvarande innehållsströmmen genom att mata ut tabellen rad för rad, inte kolumn för kolumn. För en fullt seende läsare som tittar på PDF-filen spelar dessa lågnivådetaljer ingen roll: tabellen visas korrekt. För synskadade personer ger dock Words logiska dokumentstruktur fel resultat eftersom den önskade läsordningen (kolumn för kolumn) inte bevaras: innehållet läses upp i fel ordning. Följande ljudinspelning producerades med hjälp av funktionen ”Read Out Loud” i Adobe Reader DC. Som framgår läses texten upp i fel sekvens: rad för rad, inte kolumn för kolumn: ![En tabell skapad i Microsoft Word](/files/0b6724a2156399daab25f7007965b4e4e4ca4efb) Som nämnts ovan är detta exempel något konstruerat, men det visar hur enkelt det är att använda kombinationer av programvarufunktioner som utlöser tillgänglighetsproblem – men hur förväntas dokumentets författare veta detta i förväg? Det är troligt att detta problem endast skulle upptäckas om den resulterande PDF-filen genomgick praktiska tillgänglighetstester – t.ex. genom att använda hjälpmedelsprogramvara. Potentiellt skulle sådana dokument kunna klara PDF/A-efterlevnads-/valideringstester men misslyckas i ”verklig användning”. Att säkerställa korrekt läsordning för en PDF-fil som denna skulle kräva skicklig manuell intervention med avancerade PDF-redigeringsverktyg såsom Adobe Acrobat Pro DC: en tidskrävande och dyr process. Alternativt skulle dokumentets författare kunna avstå från att använda just denna form av innehållsuttryck eller layout – men bara om de visste att den var problematisk! ### Använda blanktecken för att separera ord När du skriver in text i ordbehandlare eller textredigerare använder du blanktecknet för att markera slutet på ett ord och början på nästa. Om du därefter skapar en PDF från ett sådant dokument kommer de blanktecken du skrev naturligtvis att matas ut och utgöra en del av texten som lagras i PDF-filen. Däremot använder TeX-motorer inte blanktecken för att separera ord i sättningstext; i stället omvandlar de blanktecken till en form av flexibel mellanrumssättning som kallas glue (se denna [Overleaf-artikel](/latex/sv/fordjupade-artiklar/11-boxes-and-glue-a-brief-but-visual-introduction-using-luatex.md) för mer information om TeX-boxar och glue). Inom innehållsströmmen för PDF-sidor som skapas av TeX-motorer åstadkoms avskiljningen av enskilda ord genom att flytta till en annan position på sidan och börja texten för nästa ord – i stället för att mata ut ett blanktecken för att uppnå detta mellanrum. Dessutom varierar mängden utrymme mellan ord i stycken som sätts av TeX-motorer från rad till rad på grund av TeX:s radbrytningsalgoritm. Den variationen återspeglas i de positionsdata som skrivs ut till innehållsströmmen för PDF-sidor. Denna aspekt av TeX:s sättning har konsekvenser för kopiering/klistring av text från dess PDF-filer och för hjälpmedelsprogramvara som försöker läsa upp texten i PDF-filer som produceras av TeX-motorer. Hjälpmedelsprogramvara måste analysera en PDF-sidas innehållsström för att extrahera den text som den behöver bearbeta. Uppenbarligen behöver sådan programvara någon mekanism för att upptäcka början och slutet av ord – den mest uppenbara lösningen är att använda ett blanktecken. Med detta i åtanke kräver tillgänglighetsstandarder att enskilda ord tydligt avslutas (t.ex. med blanktecken), vilket är problematiskt för TeX-motorer på grund av deras användning av interword glue. #### Men allt är inte förlorat! År 2014 införde pdfTeX två nya primitiver för att förbättra stöd för tillgänglighet genom att möjliggöra användning av blanktecken mellan ord i de PDF-filer som den genererar: * `\pdfinterwordspaceon` * `\pdfinterwordspaceoff` Dessa kommandon använder ett ”dummy font” som innehåller endast en blankteckensglyf. Detaljer och ett exempel finns på sidan 29 i [pdfTeX-användarmanualen](http://texdoc.net/texmf-dist/doc/pdftex/manual/pdftex-a.pdf). #### Använda LuaTeX: Ett exempel i Overleaf-galleriet LuaTeX stöder inte dessa pdfTeX-primitiver, men det kan programmeras för att uppnå resultat som ligger mycket nära pdfTeX med hjälp av LuaTeX:s så kallade callback-mekanism. Ett Overleaf-projekt för att konvertera glue till blanktecken finns i Overleaf-galleriet under titeln [Använda LuaTeX för att konvertera interword glue till blanktecken och kerns](https://www.overleaf.com/latex/examples/using-luatex-to-convert-interword-glue-to-spaces-and-kerns/sfdkdkybrvkv). Om du sätter din LaTeX-kod med LuaTeX (dvs. LuaLaTeX-kompilatoralternativet på Overleaf) kan du, genom att använda Lua-kod, efterbehandla ett satt stycke för att hitta eventuell interword glue och ersätta den med ett blanktecken plus en lämplig kern. Mellanrummet som ges av blanktecknets bredd kan läggas till (eller minskas) genom att beräkna ett lämpligt kern-värde för att bevara den mängd mellanrum som interword glue ger, vilket resulterar i ingen visuell skillnad för det satta resultatet. För att förstå vilken skillnad detta gör för användare av tillgänglighetsprogramvara, lyssna på denna ljudinspelning som hämtats från Adobe Reader DC:s *Read Out Loud* funktion. Den spelar in de två raderna text i det projektet som läses upp, före och efter att glue har konverterats till blanktecken. Notera hur den andra uppläsningen av raden, som använder blanktecken, läses upp snabbt och flytande jämfört med raden som använder interword glue. Overleaf-projektet är en vanlig TeX-fil som kompileras med LuaTeX och tillhandahålls endast för experimentellt bruk; det är inte avsett som en fullständig lösning av produktionskvalitet. Det är främst utformat för att hjälpa till att förstå tekniska frågor relaterade till tillgängliga PDF-filer. Lua-koden som används i det projektet bygger på arbete som finns i en mycket tidigare Overleaf-artikel [Boxar och glue: En kort, men visuell, introduktion med LuaTeX](/latex/sv/fordjupade-artiklar/11-boxes-and-glue-a-brief-but-visual-introduction-using-luatex.md). Obs: För enkelhetens skull använder projektet sin egen mycket minimala OpenType-teckensnittsloader som härletts från denna kod: . ### Andra tillgänglighetsproblem och taggad PDF Även om taggning möjliggör identifiering av innehållselement som finns i en PDF, kräver vissa typer av innehåll, såsom grafik eller komplex matematik, ytterligare data eller information om de ska göras tillgängliga via programvara som är avsedd att stödja synskadade personer. För att tillhandahålla och stödja tillgänglighet för ett brett spektrum av innehållstyper ger PDF-specifikationen möjlighet att bifoga ”Alternate Descriptions” eller ”ActualText” till innehållselement, vilket ger lämpliga textbeskrivningar eller andra maskinläsbara representationer. Till exempel har MathML utsetts för detta ändamål inom PDF 2.0-specifikationen. #### Är det ”riktigt innehåll” eller bara en artefakt? För synskadade personer har processen att dela upp och visa innehåll i rektangulära sidorstora stycken oönskade bieffekter, såsom avstavning av ord. Vidare är aspekter av siddesign eller layout som används för att förbättra det visuella intrycket ganska meningslösa för dem som inte kan se dem. Av dessa skäl måste taggning av PDF-innehåll erkänna att visst innehåll i en PDF bör behandlas som en *artefakt* av visuell presentation eller sidbrytning. Till exempel måste sidnummer, sidhuvuden och sidfötter, skuggade bakgrunder eller andra designelement identifieras så att hjälpmedelsprogramvara som bearbetar innehållet vet att ignorera dem. ## Översikt över PDF/A-standarderna Förfrågningar om att producera tillgängliga PDF-filer hänvisar vanligtvis till en ISO-standard kallad [ISO 19005](https://www.iso.org/standard/38920.html), oftare kallad PDF/A. Eftersom PDF/A är en *familj* av standarder kanske en enkel begäran om ”PDF/A-överensstämmelse” inte fullt ut specificerar de faktiska kraven. För att se varför, låt oss börja med en kort översikt av PDF/A från [PDF Associations webbplats](https://www.pdfa.org/resource/iso-19005-pdfa/) (åtkomst 21 maj 2020) som beskriver ISO 19005 (PDF/A) enligt följande: > ”Huvudsyftet med ISO 19005 är att definiera ett filformat baserat på PDF, känt som PDF/A, som tillhandahåller en mekanism för att representera elektroniska dokument på ett sätt som bevarar deras statiska visuella utseende över tid, oberoende av de verktyg och system som används för att skapa, lagra eller återge filerna. > > Ett sekundärt syfte med ISO 19005 är att definiera ett ramverk för att representera den logiska strukturen och annan semantisk information i elektroniska dokument inom överensstämmande filer. > > Ytterligare ett syfte med ISO 19005 är att tillhandahålla ett ramverk för att registrera sammanhanget och historiken för elektroniska dokument i metadata inom överensstämmande filer.” Det är tydligt att PDF/A har flera centrala mål. ### PDF:s utveckling och tillväxt Den [PDF 1.0-specifikationen](https://web.archive.org/web/20150617123515/http://acroeng.adobe.com/PDFReference/PDF%20Reference%201.0.pdf) publicerades 1993 och omfattade bara 230 sidor. Men 13 år senare var specifikationen för [Adobes PDF-version 1.7](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf) väl över 1000 sidor! Med tiden har storleken och komplexiteten hos PDF-specifikationen vuxit genom att den stödda funktionsuppsättningen har utökats: den omfattar nya teknologier och kraven från allt mer sofistikerade PDF-baserade arbetsflöden och användningsfall på olika marknader och i olika gemenskaper. Det är dock sannolikt att ingen användare, eller någon grupp av användare, någonsin utnyttjar alla möjligheter: PDF måste ”täcka alla baser” för att säkerställa att den kan tillgodose behoven hos så breda marknader som möjligt. Till exempel krävs många PDF-funktioner som är utformade för att stödja avancerad kommersiell tryckning inte för typisk daglig kontorsanvändning som format för att lagra eller dela dokumentation. ### PDF/A: ”tillbaka till grunderna” för PDF PDF/A:s centrala mål är att säkerställa att överensstämmande PDF-filer är lämpliga för långtidsarkivering eller innehåller innehåll som är tillgängligt för personer som använder olika hjälpmedelstekniker för att ”konsumera” dessa PDF-filer. För att uppnå dessa mål begränsar PDF/A den uppsättning PDF-funktioner som är tillåtna i överensstämmande PDF-filer och förbjuder användning av funktioner som skulle kunna äventyra arkiverbarhet eller tillgänglighet. Man kan tänka på PDF/A som en uppsättning standarder som specificerar hur överensstämmande PDF-filer använder en *delmängd* av den fullständiga PDF-specifikationen för att producera filer som lämpar sig för långtidsarkivering eller för att säkerställa att deras innehåll är tillgängligt. PDF/A:s begränsningar gör det möjligt att använda PDF-filer som ”arkivdigitalt papper” som är oberoende av den PDF-läsande tekniken och datormiljön som används för att komma åt deras innehåll. Överensstämmande PDF-filer får inte innehålla något vars beteende är ”implementationsberoende” – dvs. beror på den specifika programvara eller de operativsystem som används för att visa eller bearbeta dem. PDF-filer måste också vara *kompletta*: nyckeldokumentresurser måste vara inbäddade i filen – såsom teckensnitt eller färgprofiler. ### PDF/A-versioner och överensstämmelsenivåer Det finns olika *versioner* av PDF/A-standarden, där var och en speglar en viss version av den formella PDF-specifikationen (PDF 1.4, 1.7 och 2.0). Dessutom finns det olika *överensstämmelsenivåer* som anger vilken aspekt/aspekter av PDF/A-standarden som en PDF-fil överensstämmer med. Följaktligen bör du, när du hävdar eller kräver ”PDF/A-överensstämmelse”, tänka på PDF-filer som överensstämmer med **PDF/A-** Till exempel * PDF/A-1a: betyder PDF/A version 1, överensstämmelsenivå a * PDF/A-2b: betyder PDF/A version 2, överensstämmelsenivå b Vi utforskar dessa lite mer i detalj. #### PDF/A-versioner PDF/A-standarden lyder under ISO:s uppsikt och publiceras som en standard kallad ISO 19005. Som nämnts har PDF-specifikationen utvecklats över tid och detta har i sin tur krävt uppdateringar av ISO 19005, vilket resulterat i tabellen nedan: | | | | | ----------------- | ---------------- | -------------------------- | | **PDF/A-version** | **ISO-standard** | **Baserad på PDF-version** | | 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) | Vid skrivandet av detta (april/maj 2020) är en uppdaterad PDF/A-4 (ISO 19005-4) [under utarbetande](https://www.iso.org/standard/71832.html). #### PDF/A-överensstämmelsenivåer Utöver tre PDF/A-versioner (PDF/A-1, PDF/A-2 och PDF/A-3) finns det tre *överensstämmelsenivåer*: * Nivå A (tillgänglig) för tillgänglighet (inkluderar arkiveringskraven för Nivå B) * Nivå B (grundläggande) för arkivering * Nivå U (Unicode) (= arkivering plus användning av Unicode för text) Här är en kort beskrivning av dessa överensstämmelsenivåer: * **Nivå B (grundläggande)** är minimikravet för överensstämmelse enligt PDF/A. Det definierar krav för att säkerställa att överensstämmande PDF-dokument är lämpliga för långtidsarkivering – att de alltid kan visas eller skrivas ut på ett tillförlitligt sätt oberoende av specifik programvara, verktyg eller operativsystem. * **Nivå A (tillgänglighet)** inkluderar kraven för överensstämmelse på nivå B men kräver dessutom användning av taggad PDF för att tillhandahålla logisk struktur och information om läsordning tillsammans med användning av Unicode för att möjliggöra åtkomst till dokumentets text. * **Nivå U (Unicode)** överensstämmelse tillkom i PDF/A-2 och bygger på Nivå B genom att dessutom kräva användning av Unicode för dokumenttext, men går inte lika långt som Nivå A genom att kräva strukturinformation. PDF/A-versioner och överensstämmelsenivåer kan sammanfattas i en tabell: | | | | | | ------------------------ | --------------------------------------- | -------- | -------- | | **Överensstämmelsenivå** | **PDF/A-** | | | | Nivå A (tillgänglig) | PDF/A-1a | PDF/A-2a | PDF/A-3a | | Nivå B (grundläggande) | PDF/A-1b | PDF/A-2b | PDF/A-3b | | Nivå U (Unicode) | Ej tillämpligt (fanns inte för PDF/A-1) | PDF/A-2u | PDF/A-3u | ### PDF/UA (”Universal Accessibility”) Även om PDF/A-standardens överensstämmelse på nivå A till viss del definierar krav för tillgängliga PDF-filer, går en annan ISO-standard kallad [ISO 14289](https://www.iso.org/standard/64599.html), kallad PDF/UA, längre. PDF/UA stärker tillgänglighetskraven och förtydligar vägledningen i PDF/A-standarderna och har blivit den föredragna standarden för tillgängliga PDF-filer. #### Matterhorn-protokollet Läsare med ett djupt intresse av att lära sig mer om PDF/UA-överensstämmelse kan vara intresserade av [Matterhorn Protocol](https://www.pdfa.org/resource/the-matterhorn-protocol-1-02/) som är ”en lista över alla möjliga sätt att misslyckas med PDF/UA-överensstämmelse”. ### Valideringsprogramvara För att kontrollera om en PDF-fil överensstämmer med en viss standard måste den *valideras* användas med överensstämmelseprogramvara som skannar PDF-filen för att kontrollera om dess innehåll och struktur överensstämmer med kraven i den standarden – såsom PDF/UA eller PDF/A-*x*a (där *x* = 1, 2 eller 3). Observera att validering av PDF-filer – att bearbeta dem med ett föredraget valideringsverktyg – kan ge diagnostiska meddelanden eller varningar som kan vara ganska kryptiska för den oerfarne användaren – kanske på grund av några låg-nivå PDF-data (eller struktur) som inte uppfyller den relevanta standarden. För många författare kan det vara ganska utmanande att tolka dessa varningar och omvandla dem till en åtgärdbar fix för deras dokument. #### Gratis valideringsprogramvara * [veraPDF](https://verapdf.org/) som, för att citera deras webbplats (åtkomst 28 maj 2020), är en ”specialbyggd, öppen källkod, filformatsvalidator som täcker alla PDF/A-delar och överensstämmelsenivåer”. * (endast Windows) [PDF Accessibility Checker (PAC 2024)](https://pac.pdf-accessibility.org/en/download) som är ett ”...gratis verktyg för kontroll av PDF-tillgänglighet som har prövats och testats sedan 2010”. #### Kommersiell valideringsprogramvara * [Adobe Acrobat](https://acrobat.adobe.com/uk/en/acrobat/pricing.html) erbjuder en uppsättning PDF-valideringstester tillsammans med verktyg för att redigera och rätta taggar i PDF-filer som inte överensstämmer. ### PDF Association: en utmärkt informationskälla Den [PDF Association](https://www.pdfa.org/) producerar många *utmärkta* resurser om PDF/A, PDF/UA och många andra PDF-relaterade ämnen – inklusive videor på deras [YouTube-kanal](https://www.youtube.com/user/ThePDFAssociation/playlists) tillsammans med artiklar och gratis tekniska publikationer tillgängliga på deras webbplats. En sådan publikation är [PDF/UA in a Nutshell](https://www.pdfa.org/resource/pdfua-in-a-nutshell/) som ger en ovärderlig introduktion till PDF/UA-standarden och dess krav. ## Tillgängliga PDF-filer från TeX-motorer och LaTeX Förhoppningsvis har de föregående diskussionerna visat att produktion av fullt tillgängliga och korrekt taggade PDF-filer är en krävande teknisk utmaning. Dessutom visade till och med det enkla Microsoft Word-exemplet att författare mycket lätt kan använda kombinationer av programvarufunktioner som resulterar i taggade PDF-dokument som inte uppfyller tillgänglighetskriterier. Som författarverktyg ger LaTeX författare nästan obegränsad flexibilitet när det gäller det spektrum och den komplexitet av dokument som du kan skapa – vilket kanske är just anledningen till att välja det från början. LaTeX stöder också utbyggbarhet via tusentals tilläggspaket som författare kan använda som en del av sina dokument. Utöver allt detta har författare friheten att skriva nya TeX- eller LaTeX-makron, eller omdefiniera befintliga, för att uppnå specifika effekter. Men kanske har denna frihet och flexibilitet ett pris, eftersom innehållet som produceras av de otaliga interaktionerna mellan alla dessa LaTeX-paket och makron ”på något sätt” måste orkestreras om LaTeX automatiskt ska generera korrekt taggad och tillgänglig PDF-utdata. I praktiken medför den utbyggbarhet, styrka, mångsidighet och författar-”frihet” som LaTeX ger tekniska utmaningar för sömlös och transparent (”automatisk”) produktion av fullt tillgängliga taggade PDF-dokument som överensstämmer med standarderna PDF/UA eller PDF/A-{1|2|3}a. Den bredare TeX- och LaTeX-gemenskapen arbetar hårt för att ta itu med dessa utmaningar och The TeX User Group (TUG) samordnar forsknings- och utvecklingsinsatser genom arbetsgruppen för PDF-tillgänglighet och PDF-standarder [arbetsgrupp](https://www.tug.org/twg/accessibility/). Det finns en [diskussionslista](https://tug.org/mailman/listinfo/accessibility) som ger intresserade parter ett sätt att diskutera produktion av taggade PDF-filer med TeX och LaTeX. I dessa diskussioner är det värt att komma ihåg att LaTeX egentligen inte är ett körbart sättningsprogram, utan en stor samling sofistikerade makron (kommandon) skrivna i ett lägre nivåspråk som kallas TeX. Mellan ditt noggrant utformade LaTeX-dokument och den slutliga satta PDF-filen finns ett program kallat en TeX-motor vars uppgift är att ”köra” samlingen av LaTeX-kommandon (dvs. makron) som används för att skriva och konstruera ditt dokument – och omvandla dem till den satta representationen av ditt dokument sparad som en PDF-fil. De som är nya i TeX/LaTeX-ekosystemet blir ofta, och förståeligt nog, förbryllade av den uppsjö av kryptiskt klingande namn som används för de verktyg de stöter på: TeX, LaTeX, pdfTeX, pdfLaTeX, XeTeX, XeLaTeX, LuaTeX och LuaLaTeX. Om du känner likadant finns hjälp i Overleaf-artikeln [Vad ligger i ett namn: En guide till de många smakerna av TeX](/latex/sv/fordjupade-artiklar/55-what-s-in-a-name-a-guide-to-the-many-flavours-of-tex.md) som förklarar ursprunget och betydelsen av alla dessa termer. TeX-motorer som pdfTeX, XeTeX eller LuaTeX är en klass av programvara som kallas *dokumentkompilatorer*: de tar din LaTeX-kod och kompilerar den till sin satta form genom att ”omvandla” LaTeX-makron (kommandon) tillbaka till deras instruktioner i det lägre nivåspråket TeX som ”körs” för att producera det satta resultatet. TeX-baserade sättningssystem kan producera extremt komplext innehåll – inklusive avancerad matematik, musiknotation, kemiska strukturer, grafik och sofistikerad flerspråkig satt text. För att säkerställa att dessa komplexa dokument uppfyller tillgänglighetsstandarder och regleringar behöver TeX-motorer, tillsammans med LaTeX-makrosamlingen och LaTeX-paket, generera lämpligt taggade PDF-filer genom att bädda in en stor mängd ytterligare data i de PDF-filer de genererar. Även om TeX-motorer kan generera extremt komplexa PDF-filer har deras interna processer, algoritmer och funktioner inte *inbyggt* funktioner *specifikt utformade* för att stödja produktionen av taggade och tillgängliga PDF-filer. I stället måste stöd för taggning och tillgänglighet uppnås genom komplex makroprogrammering som ”injicerar” ytterligare data i PDF-filer som genereras av TeX-motorer – och skapar de markerade innehållssekvenser, struktur-element och logiska strukturdatastrukturer som lagras i `StructTreeRoot`. Och här blir den där ”orkestreringen” tydligt synlig: kod i LaTeX:s kärna (kernel) tillsammans med kod i tusentals paket och otaliga av författare skapade makron måste samarbeta mycket noggrant för att säkerställa att körningen av makron ger korrekt taggning av de resulterande dokumentens innehåll. Denna ”orkestrering” måste vara tillförlitlig – oavsett hur författare väljer att kombinera och använda funktionerna, kommandona och funktionaliteten i LaTeX, dess paketsystem och kraften i TeX-makron. ### Författarnas behov För de flesta är LaTeX bara ett verktyg som låter dig skapa vackert sätta dokument med friheten att välja och vraka bland paket för att hjälpa dig uppnå detta. Den överväldigande majoriteten av LaTeX-författare vill helt enkelt att deras dokument ska ”fungera”: att sättas utan fel så att de kan lämna in sin avhandling, artikel, rapport eller färdigställa den efterlängtade boken. Inte orimligt förväntar sig LaTeX-användare att deras valda samling av LaTeX-paket ska samexistera fredligt och sömlöst samverka transparent för att tillhandahålla de kommandon och funktioner som behövs för att producera deras dokument. Samma önskemål lär också uppstå när man står inför kravet att producera taggad PDF från LaTeX: det ska ”bara fungera”, transparent och med minimal inblandning från författaren. Tyvärr är vi fortfarande en bit ifrån upplevelsen ”Hokus pokus! taggning sker bara oavsett vad konstiga saker jag gör”. Att koppla ihop de tekniska kraven för tillgänglighet plus taggad PDF med LaTeX och författarfrihet är i sig komplext och kanske är det oundvikligt att någon form av ”författardisciplin” kan krävas om de tekniska utmaningarna ska bli möjliga att praktiskt implementera och lösa. En separat men relaterad fråga är att felaktig taggning kanske inte har någon visuell påverkan på den slutliga PDF-filen: visuellt kan den se perfekt ut och den kommer sannolikt att skrivas ut utan problem också, men okänt för författaren kan taggningen vara ”trasig” och upptäckas först genom efterföljande misslyckande i PDF/A-överensstämmelse-/valideringskontroller och/eller ytterligare praktiska tester via hjälpmedelsprogramvara såsom skärmläsare. ### PDF-filer producerade i Overleaf Overleaf förser sin användargemenskap med en webbläsarbaserad LaTeX-redigerare tillsammans med projekt- och dokumenthanteringsverktyg som underlättar samarbetsbaserat författande – allt byggt ovanpå en standardinstallation av TeX Live. I praktiken låter Overleaf användare ”köra LaTeX på distans” via en webbläsare, vilket ger ett skyddande lager mot komplexiteten i att hantera och underhålla ett fullständigt TeX Live-system. En följd av Overleafs användning av en standardinstallation av TeX/LaTeX är att PDF-filer som produceras från LaTeX-kod skriven i Overleafs redigerare skapas med exakt samma tekniker som finns i alla andra TeX Live-installationer av samma version – inklusive installationer som användare har på sina lokala enheter. Den enda skillnaden är att TeX-motorerna som kompilerar och bearbetar Overleafs LaTeX-kod körs på fjärrservrar, inte på lokala maskiner. Overleaf linjäriserar visserligen den TeX-genererade PDF-filen för effektiv nedladdning/visning i en webbläsare, men den processen är inte relaterad till tillgängligheten hos PDF-innehållet i sig. Produktion av tillgängliga PDF-filer via Overleaf är beroende av de funktioner och egenskaper som är inbyggda i standard-TeX-motorer tillsammans med tillgången till lämpliga LaTeX-makropaket som användare kan använda som en del av sitt dokument. LaTeX-dokument skapade med Overleaf måste förbli kompatibla med andra TeX- och LaTeX-installationer eftersom användare ofta behöver exportera sitt LaTeX-projekt från Overleaf för inlämning till ett brett spektrum av förlags- och journalsystem. Att införa Overleaf-specifika funktioner i dess LaTeX-dokument, eller i de underliggande TeX-motorerna, skulle allvarligt begränsa användarnas frihet att använda sitt arbete någon annanstans. Overleaf erkänner och stödjer behovet av fullt tillgängliga PDF-filer som genereras från TeX/LaTeX-författarsystem: vi investerar tid i att forska kring tillgänglighetsfrågor, utforska de senaste utvecklingarna inom TeX-motorer och experimentella LaTeX-paket som stöder taggad PDF. I slutändan, vid tidpunkten för skrivandet, finns det ingen lösning ”direkt ur lådan” som LaTeX-författare kan använda (via `\usepackage`) för att sömlöst och transparent generera fullt tillgängliga och PDF/UA-kompatibla PDF-filer från generiska LaTeX-dokument. När dessa lösningar blir tillgängliga genom uppdateringar av TeX Live kommer de naturligtvis att bli tillgängliga för Overleafs användargemenskap. ### Några LaTeX-paket för att utforska taggning och tillgänglighet För många människor är [tex.stackexchage](https://tex.stackexchange.com/) den första anhalten för hjälp med TeX, LaTeX eller ConTeXt. Det är en fantastisk resurs och har många frågor om ämnet [tillgänglighet](https://tex.stackexchange.com/questions/tagged/accessibility?tab=Newest) och produktionen av tillgängliga PDF-filer via LaTeX. Om du läser och bläddrar i dessa frågor, och den efterföljande strömmen av svar och kommentarer, är bara en slutsats oundviklig: för närvarande finns det ingen fullständig lösning på produktionsnivå för att automatiskt skapa fullt tillgängliga, standardkompatibla, taggade PDF-filer från alla typer av LaTeX-dokument. Det finns dock vissa paket som stöder taggning – kanske inom ett begränsat spektrum av användningsfall och dokumenttyper. Följande lista tillhandahålls för läsare som vill utforska PDF-taggning baserad på LaTeX: * [`tagpdf` paketet](https://ctan.org/pkg/tagpdf) (Ulrike Fischer): mycket kapabelt paket utformat för experiment med PDF-taggning. Stöder pdfTeX och LuaTeX och tillhandahåller extremt användbar och intressant dokumentation som innehåller några utmärkta anteckningar om de tekniska utmaningarna med att skapa taggade PDF-filer via TeX-motorer; det är starkt rekommenderad läsning för alla som vill bättre förstå de frågor som är inblandade. Framtida fokus lär sannolikt vara LuaTeX. * [`axessibility` paketet](https://ctan.org/pkg/axessibility?lang=en) (Boris Doubrov och University of Turin): tillhandahåller åtkomst till formler i PDF-filer via hjälpmedelsteknik. * [`tillgänglighet` paketet](https://ctan.org/pkg/accessibility) (Andy Clifton): skapar taggade och strukturerade PDF-filer. CTAN-anmärkningarna anger att detta paket är ”avsett för användare av dokumentklasserna KOMA-Script”. * [`accsupp` paketet](https://ctan.org/pkg/accsupp) (Heiko Oberdiek): experimentellt paket för att ge bättre stöd för tillgänglighet i PDF-filer. En ytterligare anmärkningsvärd referens är en artikel från 2018 [Implementing PDF standards for Mathematical Publishing](http://web.science.mq.edu.au/~ross/TaggedPDF/PDF-standards-v2.pdf) av Dr Ross Moore från Department of Mathematics, Macquarie University. I den artikeln inkluderar Dr Moore en kort översikt över utmaningarna med taggning av PDF-filer i LaTeX: > ”Den främsta källan till svårighet ligger i hur olika miljöer kan samverka med varandra. Det finns många situationer i LaTeX där en miljö eller struktur inte riktigt är avslutad förrän nästa har börjat. Så det handlar inte bara om att lägga start- och sluttaggar runt varje del av det tillhandahållna innehållet. I stället behöver man förstå subtiliteterna i hur olika miljöer och andra strukturer faktiskt börjar och slutar, inom ramen för det omgivande materialet.” Dr Moore är också nuvarande förvaltare av [`pdfx`](https://ctan.org/pkg/pdfx) paketet och en expert och pionjär inom taggad PDF med TeX/LaTeX. Hans arbete är väl värt att söka efter – inklusive denna video på YouTube som ger intressanta insikter: {% embed url="" %} #### Anmärkning om pdfx-paketet Den [`pdfx`](https://ctan.org/pkg/pdfx) paketet (Ross Moore m.fl.) ger utmärkt stöd för PDF/A-1|2|3b (arkivering), och andra alternativ, men producerar ännu inte taggad 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/sv/fler-amnen/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.