Единственото решение, което оформя всяка следваща стъпка, е средата за създаване. PDF, генериран от правилно структуриран документ в InDesign с приложено действие „Make Accessible“, носи 80 процента от метаданните си за достъпност, преди някой изобщо да отвори Acrobat. PDF, експортиран от документ в Word, в който заглавията са имитирани с по-удебелен и по-голям текст, не носи почти нищо и никакво последващо отстраняване на проблеми няма да го спаси напълно. Изборът на инструмент за създаване, с други думи, не е естетически. Той е структурен.

Три производствени пътя доминират институционалното издателство през 2026 г. Adobe InDesign с действието „Make Accessible“ е стандартът за наборни документи — годишни отчети, учебници, регулаторни документи — където оформлението е фиксирано и файлът напуска дизайнерския екип само веднъж. Microsoft Word със „Save as Accessible PDF“ е работният кон за офис документи — политики, договори, писма — където източникът се редактира непрекъснато, а PDF е изобразяване, а не крайна цел. LibreOffice с предаване към PDF Accessibility Checker е пътят с отворен код, използван от правителства и университети, които имат политически причини да избягват стековете на Microsoft и Adobe.

Под всеки достъпен PDF има успоредна логическа структура — дървото от тагове — която няма нищо общо с визуалното оформление. Видимият PDF е набор от инструкции за изчертаване, адресирани по координати. Дървото от тагове е отделен йерархичен документен обектен модел, който казва тази операция по изчертаване е първото заглавие, онази е третата точка от втория списък, тази картина е декоративна, а онази друга картина има алтернативен текст „Тримесечни приходи по сегмент, ФГ24“. Екранният четец чете дървото от тагове, а не изчертаването.

Шест категории тагове носят по-голямата част от смисъла в реалните документи: заглавия (H1 до H6) формират навигируемия план; абзаци (P) са пасажите от проза; списъци (L, LI, Lbl, LBody) са подредените или неподредените изброявания; таблици (Table, TR, TH, TD) са решетките с данни с изложени чрез атрибута Scope заглавия на колони и редове; фигури (Figure) носят алтернативния текст в атрибута си Alt или ActualText; и редът на четене, който е обхождането на дървото в дълбочина и диктува последователността, в която екранният четец изговаря документа. Страница, която изглежда правилно в две колони, може да се чете в грешен ред, ако дървото от тагове поставя дясната колона преди лявата.

Още два атрибута имат значение на всеки таг в правилно произведен файл. Езиковият атрибут (Lang) казва на екранния четец кой речник за произношение да използва — френски, цитиран в английски абзац, се нуждае от собствен атрибут Lang на таг Span, иначе ще се прочете с английски фонеми. А маркерът за артефакт различава декоративното от структурното съдържание; колонтитули, номера на страници и декоративни линии трябва да се маркират като артефакти, за да ги прескочи екранният четец.

PDF/UA е международният стандарт за достъпни PDF файлове, публикуван като ISO 14289-1 през 2014 г. и обновен през 2024 г. Докато WCAG е технологично неутрален и платформено неутрален, PDF/UA е специфичен за PDF — той е договорът между софтуера за създаване на документи, софтуера за консумиране на документи и помощната технология, който казва, че дървото от тагове, метаданните и структурата на този файл съответстват на проверим набор от условия, така че съответстващ четец да може да разчита на тях.

Стандартът се привежда в действие чрез Matterhorn Protocol, поддържан от PDF Association, който разлага PDF/UA на 31 номерирани условия за провал с варианти, проверими както от машина, така и от човек. Машинно проверимите провали включват отсъствието на заглавие на документа в метаданните, наличието на фигури без Alt или ActualText, списъци, структурирани извън тагове L/LI, и липсващи езикови атрибути на документа или на пасажи с превключен език. Проверимите от човек провали обхващат нещата, които софтуерът не може да провери сам по себе си — дали алтернативният текст на дадена Figure действително описва фигурата, дали редът на четене съответства на логическата последователност, дали заглавията са вложени логически, а не с прескачане на нива.

Обновлението от 2024 г. приведе PDF/UA в съответствие с критериите за успех по WCAG 2.2 и поясни третирането на цифровите подписи и формуляри — достъпните PDF формуляри трябва да излагат етикети на полета, подсказки на полета и ред на табулиране, а подписаните PDF файлове не трябва да блокират достъпа на екранния четец до подлежащото дърво от тагове след подписването.

Когато PDF пристигне без използваемо дърво от тагове — а повечето стари PDF файлове са такива — изборът на инженера се стеснява до четири среди за отстраняване на проблеми. Всяка има различна комбинация от силни страни в редактирането на дървото от тагове, OCR за сканирани оригинали, пакетна обработка и отчети за PDF/UA. Матрицата по-долу съпоставя възможностите спрямо инструмента.

Правилно тагнатият PDF е само половината от веригата на производителя. Другата половина е екранният четец, а четирите четеца, които потребителите реално използват, третират един и същ файл по фино различни начини. Разликите имат значение, защото документ, който се чете чисто в JAWS, може да се спъне в NVDA, а файл, който работи във VoiceOver на macOS, може да се държи различно, когато същият файл се отвори от ChromeVox във вградения PDF четец на Chrome.

JAWS има най-дълбоката, най-старата поддръжка на PDF от всеки търговски екранен четец. Неговият PDF Mode изобразява тагнати PDF файлове през Acrobat или Acrobat Reader и излага дървото от тагове директно — списък със заглавия (Insert+F6), списък с формуляри (Insert+F5), навигация по клетки на таблици със стандартните клавиши за таблици на JAWS. Когато на PDF му липсват тагове, JAWS ще предложи да изведе структура, но изведеният резултат е ненадежден; инженерите не бива да валидират спрямо изведени от JAWS прочити.

NVDA също чете тагнати PDF файлове през Acrobat или Acrobat Reader, с навигация в режим на разглеждане, която отразява модела му за уеб страници — H за прескачане между заглавия, K за прескачане между връзки, T за прескачане между таблици. Поддръжката на PDF в NVDA се подобри значително от 2022 г. насам, но все още изостава от JAWS при сложни таблици и полета на формуляри. NVDA дава по-честна обратна връзка за документи с неправилно оформени тагове: там, където JAWS може да продължи напред, NVDA обикновено замлъква, което е полезно за диагностика.

VoiceOver на macOS чете PDF файлове през Preview и Safari с навигация чрез ротор (VO + U) по заглавия, връзки, таблици и полета на формуляри. VoiceOver е най-снизходителният от четирите — той ще възстанови ред на четене дори за лошо тагнати файлове — но снизходителността му може да прикрие реални провали. Документ, който се чете приемливо във VoiceOver, все пак трябва да се провери спрямо JAWS или NVDA, а не обратното.

ChromeVox на ChromeOS и по-широкото поведение на всеки екранен четец, взаимодействащ с вградения PDF четец на Chrome, попадат в различна категория. PDF четецът на Chrome растеризира и повторно извлича текст, вместо да изобразява оригиналното дърво от тагове, така че PDF с чисто дърво от тагове може да изгуби голяма част от структурата си, когато се отвори директно в Chrome. Заобиколното решение за критични за достъпността контексти е да се принуди файлът да се изтегли и да се отвори в Acrobat Reader или да се предостави HTML алтернатива.

Като свържем веригата: един достъпен PDF преминава през шест конкретни стъпки. Те са последователни — пропускането на която и да е от тях произвежда файл, който ще се провали в някоя от по-късните стъпки или в ръцете на потребителя.

Екипите, които третират достъпността на PDF като проблем за отстраняване на проблеми на последно минаване, в крайна сметка плащат сметката два пъти — веднъж за отстраняване на проблемите във файл, произведен без структурно намерение, и отново всеки път, когато този файл се обновява. Екипите, които я третират като проблем на създаването, изграждат дървото от тагове в източника, регенерират го чисто при всяка ревизия и използват PAC и екранен четец като проверка, а не като поправка. Разликата в цената между двете нагласи е голяма; разликата в достъпността е още по-голяма.

Веригата, документирана по-горе, е умишлено независима от инструментите във всяка брънка. Независимо дали източникът е InDesign или LibreOffice, редакторът е Acrobat или Foxit, инструментът за проверка е PAC, а екранният четец е JAWS или NVDA, структурната логика е същата: стиловете на абзаците се преобразуват в тагове, таговете съответстват на PDF/UA, PDF/UA се проверява от PAC, а екранните четци четат резултата. Инструментите се променят; веригата — не.

За екипите по обществени поръчки и съответствие оперативното следствие е, че декларациите за достъпност на PDF трябва да препращат към производствената верига — инструмента за създаване, действието за експорт, инструмента за проверка — а не само към резултат от инструмента за проверка на Acrobat. За инженерните екипи следствието е, че дървото от тагове е източникът на истината, а дървото от тагове се изгражда в източника на всеки PDF, който потребителят някога вижда. За практическо производствено ръководство, което допълва това ръководство, вижте стъпка по стъпка наръчника за достъпност на PDF.