Yksittäinen päätös, joka muovaa jokaista myöhempää vaihetta, on tekijyysympäristö. PDF, joka on generoitu asianmukaisesti rakennetusta InDesign-dokumentista Make Accessible -toiminnon kanssa, kantaa 80 prosenttia saavutettavuusmetadatastaan ennen kuin kukaan avaa Acrobatin. PDF, joka on viety Word-dokumentista, jossa otsikot on tehty lihavoinnilla ja suuremmalla tekstillä, kantaa lähes mitään, eikä mikään jälkikäteinen remediaatio pysty täysin pelastamaan sitä. Tekijyystyökalun valinta ei siis ole esteettinen. Se on rakenteellinen.

Kolme tuotantopolkua hallitsee institutionaalista julkaisemista vuonna 2026. Adobe InDesign Make Accessible -toiminnolla on standardi ladotuille dokumenteille — vuosiraporteille, oppikirjoille, sääntelyhakemuksille — joissa asettelu on kiinteä ja tiedosto lähtee suunnittelutiimistä vain kerran. Microsoft Word Tallenna saavutettavaksi PDF:ksi -toiminnolla on toimistoasiakirjojen — käytäntöjen, sopimusten, kirjeiden — työkalu, jossa lähdettä muokataan jatkuvasti ja PDF on renderöinti eikä kohde. LibreOffice PDF Accessibility Checker -luovutuksella on avoimen lähdekoodin polku, jota käyttävät hallitukset ja yliopistot, joilla on poliittisia syitä välttää Microsoftin ja Adoben teknologiapinoja.

Jokaisen saavutettavan PDF:n alla on rinnakkainen looginen rakenne — tunnistepuu — jolla ei ole mitään tekemistä visuaalisen asettelun kanssa. Näkyvä PDF on koordinaattiosoitteinen maaliohjejoukko. Tunnistepuu on erillinen hierarkkinen dokumentin oliorakenne, joka sanoo tämä maalausoperaatio on ensimmäinen otsikko, tuo on toisen listan kolmas luetelmakohta, tämä kuva on koristeellinen, tuolla kuvalla on alt-teksti “Neljännesvuosittainen liikevaihto segmenteittäin, TP24”. Ruudunlukuohjelma lukee tunnistepuun, ei maalin.

Kuusi tunnistekategoriaa kantaa suurimman osan merkityksestä todellisissa dokumenteissa: otsikot (H1–H6) muodostavat navigoitavan jäsennyksen; kappaleet (P) ovat proosakohdat; listat (L, LI, Lbl, LBody) ovat järjestetyt tai järjestämättömät luettelot; taulukot (Table, TR, TH, TD) ovat dataruudukot, joissa sarake- ja rivi-otsikot on esitetty Scope-attribuutin kautta; kuvat (Figure) kantavat alt-tekstin Alt- tai ActualText-attribuutissaan; ja lukemisjärjestys, joka on puun syvyys-ensin-läpikäynti, sanelee järjestyksen, jossa ruudunlukuohjelma puhuu dokumentin. Sivu, joka näyttää oikealta kahdessa sarakkeessa, voi lukeutua väärässä järjestyksessä, jos tunnistepuu laittaa oikean sarakkeen ennen vasenta.

Kaksi lisäattribuuttia on tärkeä jokaisessa tunnistessa oikein tuotetussa tiedostossa. Kieliattribuutti (Lang) kertoo ruudunlukuohjelmalle, mitä ääntämyssanakirjaa käyttää — englanninkieliseen kappaleeseen lainattu ranska tarvitsee oman Lang-attribuutin Span-tunnisteessa, tai se luetaan englantilaisilla foneemeilla. Ja artefaktimerkki erottaa koristeellisen sisällön rakenteellisesta; ylätunnisteet, alatunnisteet, sivunumerot ja koristeelliset viivat on merkittävä artefakteiksi, jotta ruudunlukuohjelma ohittaa ne.

PDF/UA on kansainvälinen standardi saavutettaville PDF-tiedostoille, julkaistu nimellä ISO 14289-1 vuonna 2014 ja päivitetty vuonna 2024. Siinä missä WCAG on teknologianeutraali ja alustandriippumaton, PDF/UA on PDF-spesifinen — se on sopimus dokumentin tuottajaohjelmiston, dokumentin kuluttajaohjelmiston ja avustavan teknologian välillä, joka sanoo tämän tiedoston tunnistepuu, metatiedot ja rakenne ovat todennettavien ehtojen mukaisia, joten vaatimustenmukaisella lukijalla on niihin luottaminen.

Standardi toteutetaan Matterhorn-protokollan kautta, jota ylläpitää PDF Association ja joka hajottaa PDF/UA:n 31 numeroiduksi virheehdoksi, joissa on sekä koneellisesti tarkistettavia että ihmisen tarkistettavia variantteja. Koneellisesti tarkistettavat virheet sisältävät dokumentin otsikon puuttumisen metadatasta, kuvien Alt- tai ActualText-attribuutin puuttumisen, L/LI-tunnisteiden ulkopuolella rakennetut listat sekä puuttuvat kieliattribuutit dokumentissa tai kielenvaihdoissa. Ihmisen tarkistamat virheet kattavat asiat, joita ohjelmisto ei voi itsenäisesti tarkistaa — onko Figure-elementin alt-teksti oikea, vastaako lukemisjärjestys loogista järjestystä, ovatko otsikot loogisesti sisäkkäisiä eikä tasoja ohiteta.

Vuoden 2024 päivitys sovitti PDF/UA:n WCAG 2.2 -onnistumiskriteereihin ja selkeytti digitaalisten allekirjoitusten ja lomakkeiden käsittelyä — saavutettavissa PDF-lomakkeissa on esitettävä kenttätunnisteet, kenttätyökaluvihjeet ja välilehtijärjestys, ja allekirjoitetuissa PDF-tiedostoissa ei saa estää ruudunlukuohjelman pääsyä taustalla olevaan tunnistepuuhun allekirjoituksen jälkeen.

Kun PDF saapuu ilman käyttökelpoista tunnistepuuta — ja useimmat vanhat PDF-tiedostot saapuvat ilman — insinöörin valinta kaventuu neljään remediaatioympäristöön. Jokaisella on erilainen yhdistelmä vahvuuksia tunnistepuun muokkauksessa, OCR:ssä skannatuille alkuperäisille, eräkäsittelyssä ja PDF/UA-raportoinnissa. Alla oleva matriisi kartoittaa kyvykkyyden työkalua vastaan.

Oikein merkitty PDF on vain tuottajan puoli ketjusta. Toinen puoli on ruudunlukuohjelma, ja neljä ohjelmaa, joita käyttäjät tosiasiassa käyttävät, käsittelevät samaa tiedostoa hienovaraisesti eri tavoin. Erot ovat merkittäviä, koska dokumentti, joka luetaan sujuvasti JAWSissa, voi kompastua NVDAssa, ja tiedosto, joka toimii VoiceOverissa macOS:ssa, saattaa käyttäytyä eri tavalla, kun sama tiedosto avataan ChromeVoxilla Chromen sisäisessä PDF-katseluohjelmassa.

JAWS tarjoaa syvimmän ja vanhimman PDF-tuen mistään kaupallisesta ruudunlukuohjelmasta. Sen PDF-tila renderöi merkityt PDF-tiedostot Acrobatin tai Acrobat Readerin kautta ja paljastaa tunnistepuun suoraan — otsikoiden lista (Insert+F6), lomakkeiden lista (Insert+F5), taulukkosolunavigaatio vakio-JAWS-taulukonäppäimillä. Kun PDF:stä puuttuvat tunnisteet, JAWS tarjoutuu päättelemään rakenteen, mutta päätelty tulos on epäluotettava; insinöörien ei pidä validoida JAWS-päätellyin lukemisiin.

NVDA lukee merkittyjä PDF-tiedostoja myös Acrobatin tai Acrobat Readerin kautta selausmoodin navigoinnilla, joka peilaa sen verkkosivumallia — H otsikkojen välillä hyppäämiseen, K linkkien välillä hyppäämiseen, T taulukoiden välillä hyppäämiseen. NVDA:n PDF-tuki on parantunut merkittävästi vuodesta 2022, mutta jää silti jälkeen JAWSista monimutkaisissa taulukoissa ja lomakekentissä. NVDA antaa rehellisempää palautetta dokumenteista, joissa on muodoltaan virheellisiä tunnisteita: siinä missä JAWS saattaa jatkaa, NVDA taipuu vaikenemaan, mikä on diagnostisesti hyödyllistä.

VoiceOver macOS:ssa lukee PDF-tiedostoja Previev’n ja Safarin kautta roottorin navigoinnilla (VO + U) otsikoiden, linkkien, taulukoiden ja lomakekenttien yli. VoiceOver on sallivin neljästä — se rekonstruoi lukemisjärjestyksen jopa huonosti merkityille tiedostoille — mutta sen anteeksianto voi peittää todellisia virheitä. Dokumentti, joka luetaan hyväksyttävästi VoiceOverissa, on silti tarkistettava JAWSia tai NVDAa vastaan, ei toisinpäin.

ChromeVox ChromeOS:ssa, ja laajemmin minkä tahansa ruudunlukuohjelman käyttäytyminen vuorovaikutuksessa Chromen sisäisen PDF-katseluohjelman kanssa, kuuluu eri kategoriaan. Chromen PDF-katseluohjelma rasterisoi ja uudelleenpoimii tekstin sen sijaan, että renderöisi alkuperäistä tunnistepuuta, joten puhtaan tunnistepuun omaava PDF voi menettää suuren osan rakenteestaan, kun se avataan suoraan Chromessa. Kiertotie saavutettavuuskriittisissä yhteyksissä on pakottaa tiedosto lataamaan ja avaamaan Acrobat Readerissa tai tarjota HTML-vaihtoehto.

Ketjun kokoaminen yhteen: yksi saavutettava PDF kulkee kuuden konkreettisen vaiheen läpi. Ne ovat peräkkäisiä — minkä tahansa vaiheen ohittaminen tuottaa tiedoston, joka epäonnistuu jossakin myöhemmistä vaiheista tai käyttäjän käsissä.

Tiimit, jotka käsittelevät PDF-saavutettavuutta loppuvaiheen remediaatio-ongelmana, päätyvät maksamaan laskun kahdesti — kerran remedioidakseen tiedoston, joka on tuotettu ilman rakenteellista tarkoitusta, ja uudelleen joka kerta, kun tiedostoa päivitetään. Tiimit, jotka käsittelevät sitä tekijyysongelmana, rakentavat tunnistepuun lähteessä, generoivat sen puhtaasti jokaisessa versiossa ja käyttävät PAC:ia ja ruudunlukuohjelmaa tarkistamiseen eikä korjaamiseen. Kustannusero näiden kahden lähestymistavan välillä on suuri; saavutettavuusero on suurempi.

Yllä dokumentoitu ketju on tarkoituksella työkaluneutraali jokaisessa lenkissä. Olipa ylävirran työkalu InDesign tai LibreOffice, muokkaaja Acrobat tai Foxit, tarkistin PAC ja ruudunlukuohjelma JAWS tai NVDA, rakenteellinen logiikka on sama: kappaleasetukset kartoitetaan tunnisteisiin, tunnisteet ovat PDF/UA:n mukaisia, PDF/UA tarkistetaan PAC:lla ja ruudunlukuohjelmat lukevat tuloksen. Työkalut muuttuvat; ketju ei.

Hankinta- ja vaatimustenmukaisuustiimeille operatiivinen johtopäätös on, että PDF-saavutettavuusselosteet pitäisi viitata tuotantoketjuun — tekijyystyökaluun, vientitoimintoon, tarkistimeen — eikä pelkästään Acrobatin tarkistustulokseen. Suunnittelutiimeille johtopäätös on, että tunnistepuu on totuuden lähde ja tunnistepuu rakennetaan ylävirran kohteeksi käyttäjän koskaan näkemästä PDF:stä. Käytännön tuotantolaboratorion opasta, joka täydentää tätä primeria, katso PDF-saavutettavuuden vaiheittainen peliopas.