Посібники

Доступний PDF: PDF/UA і чого не бачить чекер

Як влаштований доступний PDF: дерево тегів, порядок читання, PDF/UA і WCAG2ICT. Чому з 136 умов Matterhorn 47 може перевірити тільки людина.

Андрій Вдовин

17 вересня 2026 р.

11 хв читання

Коротко

PDF/UA — це ISO 14289-1: теги, порядок читання, мова, метадані, таблиці й форми.
Matterhorn Protocol розкладає стандарт на 136 умов відмови: 87 перевіряє машина, 47 — людина, 2 не мають тесту взагалі.
Чиста перевірка чекером означає коректну структуру файлу, а не доступний документ.
EN 301 549 перевіряє документ за розділом 10, а не за розділом 9, яким перевіряють сайт.

Чому PDF — це окрема історія

Організація вкладає місяці в доступність сайту, а потім кладе на нього звіт, тарифи або заяву у PDF — і для незрячого відвідувача все обривається саме на цьому файлі. Причина не в недбалості, а в тому, що PDF влаштований принципово інакше за вебсторінку.

HTML описує зміст: заголовок є заголовком, тому що він у теґу заголовка. PDF за походженням описує друковану сторінку — де поставити гліф, якою фарбою, яким кеглем. Літери в ньому не зобов’язані навіть лежати в порядку читання: вони лежать у порядку малювання. Тому доступність PDF тримається на окремому, паралельному шарі — дереві тегів, яке пояснює програмі читання, що з намальованого є заголовком, що абзацом, що таблицею, а що просто рамкою.

Цей шар не видно на екрані. Документ може виглядати бездоганно й водночас не мати жодного тега — тоді скрінрідер прочитає суцільний потік символів у випадковому порядку або не прочитає нічого. Саме тому візуальна перевірка «ну ж бо гарно і зрозуміло» тут не працює взагалі.

PDF/UA, WCAG і чому потрібні обидва

PDF/UA (Universal Accessibility) — міжнародний стандарт ISO 14289-1. Він описує технічний бік: документ має бути повністю тегованим, теги мають відповідати змісту, порядок читання — логічним, мова — заданою, декоративні елементи — позначеними як artifact, таблиці — мати заголовки, форми — підписані поля.

WCAG написаний для вебсторінок. Щоб застосувати його до документів, W3C випустив окрему записку WCAG2ICT, яка пояснює, як читати кожен критерій поза вебом. Звідти приходять вимоги, яких у PDF/UA немає: контраст тексту, змістовність альтернатив, зрозумілі підписи посилань, поведінка при збільшенні.

Простими словами: PDF/UA каже, як має бути влаштований файл, а WCAG — якої якості має бути його вміст. Документ із бездоганним деревом тегів і сірим текстом на світло-сірому фоні проходить PDF/UA й провалює WCAG. І навпаки.

Розділ 10 — не розділ 9

EN 301 549 перевіряє вебсторінку за розділом 9, який посилається на WCAG. Документ перевіряється за окремим розділом 10 «Документи, що не є вебсторінками», і там є вимоги, яких у вебі просто немає: порядок читання тегів, artifact-розмітка декору, метадані файлу, закладки для довгих документів. Тому висновок «сайт відповідає стандарту» нічого не говорить про PDF, який на цьому сайті лежить.

136 умов Matterhorn: скільки з них бачить машина

PDF Association розклала PDF/UA на практичний протокол перевірки: 31 чекпоінт, усередині яких 136 умов відмови. Це найточніша відповідь на питання «а що взагалі означає перевірити документ». Розподіл умов пояснює, чому чекера недостатньо.

перевіряє машина

Наявність тегів, мова, метадані, присутність alt-атрибута, коректність структури таблиці. Секунди роботи валідатора.

вимагають людини

Чи логічний порядок читання. Чи змістовний alt. Чи справді цей елемент декоративний. Чи відповідає тег ролі елемента.

не мають тесту

Умови, для яких протокол не пропонує ані машинної, ані формалізованої ручної процедури.

Тобто автоматика закриває близько двох третин умов — і це рівно та третина роботи, яку найлегше зробити. Усе, що стосується змісту, а не форми, лишається людині. Валідатор бачить, що в зображення є атрибут alt; він не бачить, що там написано «image1.png».

Порядок читання — головна проблема, якої не видно

Якщо з усієї статті запам’ятати один пункт, нехай це буде цей. Порядок читання — послідовність, у якій скрінрідер проходить теги, — не зобов’язаний збігатися з тим, як око читає сторінку. І найчастіше не збігається.

Класичні місця, де він ламається:

Двоколонкова верстка: замість «ліва колонка згори донизу, потім права» виходить читання рядками впоперек обох колонок.
Колонтитули й номери сторінок, які не позначені як artifact, — назва компанії озвучується посеред речення на кожній сторінці.
Підпис під ілюстрацією, що потрапляє в потік до самої ілюстрації або через абзац після неї.
Бокові врізки й плашки «зверніть увагу», які опиняються в кінці розділу або на початку наступного.
Текст у згрупованих об’єктах з макета — інколи він узагалі випадає з дерева тегів.

Жодна з цих проблем не зробить документ «невалідним». Усі теги на місці, усі атрибути заповнені, чекер показує зелене. Просто читати такий файл на слух неможливо.

Сім кроків до доступного документа

Порядок має значення: кожен наступний крок спирається на попередній. Спроба почати з шостого — типова причина, чому «ми вже пробували, і нічого не вийшло».

Почніть зі стилів, а не з оформлення

Заголовок — це стиль «Заголовок 1», а не текст 20-м кеглем напівжирним. Список — це список, а не рядки, що починаються з дефіса. Саме зі стилів експорт будує дерево тегів, і жодна подальша правка не врятує документ, у якому структури не було з самого початку.

Опишіть зображення й приберіть декор

Інформативна графіка отримує змістовний alt, який передає суть і призначення, а не перелік намальованого. Роздільники, рамки й фонові плашки позначаються як artifact — інакше скрінрідер читатиме їх як контент.

Розмітьте таблиці заголовками

Комірка має озвучуватися разом зі своїм заголовком рядка й стовпця. Для цього потрібні теги TH із заданою областю дії, а для складних таблиць — явні зв’язки між комірками. Таблиці, зроблені табуляцією або текстовими рамками, доведеться перебудувати.

Задайте мову документа і фрагментів

Мова файлу визначає, яким голосом і з якою вимовою читатиме скрінрідер. Якщо всередині української сторінки є англійський абзац або назва, він отримує власну мовну розмітку — інакше синтезатор прочитає його українськими правилами.

Заповніть метадані й заголовок

Title документа — це те, що людина чує першим, і те, що показує вкладка застосунку. Порожній Title означає, що вона почує ім’я файлу на кшталт «scan_2024_final_v3». Окремо вмикається налаштування показувати саме Title, а не ім’я файлу.

Перевірте порядок читання вручну

Це єдиний крок, який неможливо делегувати чекеру. Документ проходиться від першої сторінки до останньої зі скрінрідером або в панелі порядку тегів. Колонтитули, підписи під ілюстраціями й бокові врізки — типові місця, де порядок ламається.

Прогоніть чекер і збережіть звіт до й після

Звіт валідатора — це доказ, який можна показати аудитору або замовнику. Порівняння «до» і «після» водночас показує вашій команді, які саме звички у верстці створюють проблеми.

Чим перевіряти

Інструменти безкоштовні, і почати можна сьогодні. Головне розуміти, що кожен із них показує.

Інструмент	Що показує	Чого не покаже
PAC axes4, безкоштовно	Найповніша перевірка PDF/UA за Matterhorn плюс частина критеріїв WCAG. Має перегляд документа очима скрінрідера й дерево тегів.	Чи осмислений порядок читання і чи змістовні альтернативи — ті самі 47 умов.
veraPDF відкритий код	Валідація PDF/UA і PDF/A. Запускається з командного рядка, тому вбудовується в конвеєр складання документів.	Те саме: формальна структура так, людське судження ні.
Перевірка в Acrobat Adobe, платно	Зручна для правки на місці: панель тегів, порядок читання, підказки щодо кожної помилки.	Перелік перевірок вужчий за Matterhorn, тож «усе гаразд» тут менш суворе.
Скрінрідер NVDA, VoiceOver	Єдиний спосіб почути реальний результат: порядок, паузи, озвучення таблиць і посилань.	Не дає формального звіту, який можна додати до документації.

Робоча зв’язка проста: валідатор доводить формальну частину до нуля помилок, скрінрідер перевіряє, що документ узагалі можна слухати. Одне без одного не працює.

Джерело чи готовий PDF

Найдорожчий сценарій — правити сам PDF. Структуру доводиться будувати поверх готової верстки, і робота повторюється щоразу, коли документ оновлюють. Якщо ж збереглося джерело — InDesign, Word, PowerPoint, — правки лягають у нього, і кожен наступний експорт виходить доступним без додаткових витрат.

Окремий випадок — скани. Зображення сторінки не містить тексту як такого, тож спершу потрібне розпізнавання й вичитка результату, і лише потім побудова структури. Це найдовший і найдорожчий шлях, тому перед замовленням варто пошукати, чи не лишився десь цифровий оригінал.

Якщо документів багато

Ми перебираємо структуру документа вручну й повертаємо файл, який проходить перевірку PAC, разом зі звітом до і після та результатом ручної перевірки порядку читання зі скрінрідером. Надішліть один документ — подивимось, що з ним не так, і назвемо обсяг робіт.

Доступність документів Ручне тестування сайту

Часті запитання

Чи достатньо експортувати PDF з Word із галочкою «доступність»?

Для простого суцільного тексту — інколи так. Але щойно з’являються таблиці, багатоколонкова верстка, зображення з текстом, колонтитули або форми, експорт видає теги, які не відповідають змісту. Порядок читання при цьому найчастіше лишається візуальним, а не логічним, — і саме це найбільше заважає скрінрідеру. Перевірити результат усе одно доведеться вручну.

Що таке PDF/UA і чим він відрізняється від WCAG?

PDF/UA — це ISO 14289-1, технічний стандарт доступного PDF: дерево тегів, порядок читання, мова, метадані, закладки, коректні таблиці й форми. WCAG написаний для вебсторінок, і щоб застосувати його до документа, W3C випустив окрему записку WCAG2ICT. На практиці стандарти доповнюють один одного: PDF/UA каже, як має бути влаштований файл, WCAG — якою має бути якість контенту, наприклад контраст і змістовність альтернативних текстів.

Чи означає «PAC без помилок», що документ повністю доступний?

Ні. Matterhorn Protocol від PDF Association розкладає PDF/UA на 136 умов відмови. З них 87 перевіряє машина, 47 вимагають людського судження, а ще дві не мають автоматичного тесту взагалі. Тобто чекер закриває приблизно дві третини умов — саме тих, що описують формальну структуру файлу. Чи правильний порядок читання, чи змістовний alt-текст і чи справді елемент декоративний, машина не знає.

Правити вихідний файл чи сам PDF?

Якщо джерело збереглося — InDesign, Word, PowerPoint — вигідніше правити його. Тоді кожен наступний експорт лишається доступним, і за рік не доведеться замовляти ту саму роботу вдруге. Якщо джерело втрачене або документ прийшов від підрядника готовим PDF, працюють безпосередньо з PDF. Це дорожче, бо структуру доводиться будувати заново поверх готової верстки.

Чи поширюються вимоги доступності на PDF на сайті?

Так, і це найчастіша помилка в плануванні. EN 301 549 перевіряє вебсторінку за розділом 9, а документ — за окремим розділом 10 «Документи, що не є вебсторінками». Тому висновок «сайт доступний» нічого не говорить про PDF, який на цьому сайті лежить. Для державних органів України вимога прямо закріплена постановою КМУ № 757 від 21 липня 2023 року, яка посилається на ДСТУ EN 301 549:2022.

Джерела та посилання

Останнє оновлення: 19.09.2026