Ваши PDF — часть доступности вашего сайта
Последнее обновление:
Каждая организация, которая никогда не выпустила бы недоступную веб-страницу, рутинно выпускает недоступные PDF: годовой отчёт, руководство по продукту, форму заявления, прайс-лист. Для посетителя, который их скачивает, разницы нет — документ, который он не может прочитать, это услуга, которой он не может воспользоваться. Эта статья рассматривает опубликованные PDF как то, чем они являются, — часть поверхности доступности сайта — и проходит по шести структурным сигналам, которые решают, может ли вспомогательная технология вообще работать с документом: разметка тегами, язык, заголовок, структура и заголовки, альтернативный текст изображений и закладки. Она также честно проводит границу: лёгкая структурная проверка — это дымовой тест, а не валидация PDF/UA, и знание того, когда вам нужна полная валидация, — часть правильного подхода.
Документы — часть сайта
Работа над доступностью обычно останавливается на границе HTML. Сайт получает аудит, шаблоны исправляют, контраст проверяют — а затем раздел «документы» тихо продолжает подавать отсканированные формы, экспорты без тегов и руководства, весь текст которых — одно встроенное изображение. Однако со стороны экрана пользователя PDF и есть сайт: там живёт пенсионная форма, там живут инструкции по безопасности, там живёт подробный прайс-лист. Пользователь программы чтения с экрана, который гладко проходит ваши доступные страницы и наталкивается на 90-страничный отчёт без тегов, испытал не доступную услугу; он испытал доступный вестибюль и запертую комнату.
Хорошая новость: доступность документов нарушается предсказуемыми, проверяемыми способами. В отличие от оценочных суждений в веб-доступности — понятен ли этот паттерн взаимодействия, логичен ли тот порядок фокуса — самые частые ошибки PDF являются структурными фактами, которые машина может проверить: теги есть или их нет, язык объявлен или нет. Именно это читает проверка доступности PDF на этом сайте, локально в браузере, и она естественно сочетается с проверкой здоровья сайта: одна охватывает страницы, другая — файлы, которые страницы выдают.
Европейский акт о доступности изменил ставки
С 28 июня 2025 года Европейский акт о доступности применяется к широкому кругу продуктов и услуг, предлагаемых потребителям в ЕС, — включая электронную коммерцию, банковское дело, электронные книги, продажу билетов и большую часть повседневного цифрового бизнеса. Его требования обычно выполняются соответствием гармонизированному стандарту EN 301 549, который, в свою очередь, указывает на WCAG, — а WCAG применяется к невеб-документам так же, как к веб-страницам. Проще говоря: для охватываемых услуг недоступный PDF, который нужен клиенту, больше не просто проблема качества или этики; это вопрос соответствия требованиям, по которому органы надзора за рынком могут действовать.
Стоит чётко обозначить две границы, потому что право доступности часто и преувеличивают, и недооценивают. Акт не охватывает каждую организацию и каждый документ — есть исключения (например, микропредприятия, предоставляющие услуги) и переходные положения, а детали различаются по государствам-членам. И никакая автоматизированная проверка, включая проверку на этом сайте, не устанавливает юридическое соответствие; соответствие — это свойство всей услуги в том виде, в каком её испытывают пользователи, при надлежащей оценке. Что Акт меняет для большинства команд, проще: документы теперь однозначно находятся в поле разговора о доступности, поэтому «мы исправим PDF позже» перестало быть безопасной фразой.
Шесть проверок, по одной
1. PDF с тегами. Разметка тегами — это скрытое дерево структуры, которое помечает заголовки, абзацы, списки, фигуры и ячейки таблиц и записывает порядок чтения. Это фундамент: без тегов программа чтения с экрана получает поток содержимого в порядке хранения, который для многоколоночных макетов и экспортированных отчётов может быть близок к словесному салату. Что проверка не может вам сказать: правильны ли теги — документ может быть с тегами и при этом иметь заголовки, помеченные как абзацы. Наличие тегов необходимо, но недостаточно.
2. Язык документа. Запись /Lang в каталоге говорит синтезу речи, на каком языке произносить. Без неё английская программа чтения с экрана весело прочитает немецкий отчёт с английской фонетикой, что варьируется от комичного до непонятного. Проверка бинарна — язык объявлен или нет — и она не может сказать вам, правильный ли объявленный язык, или помечены ли отрывки на других языках по отдельности, как того требует хорошая практика.
3. Заголовок документа. Заголовок в свойствах документа (или метаданных XMP) — это первое, что объявляет вспомогательная технология, то, что показывает вкладка браузера, и то, что должна показывать папка загрузок, — вместо «export_final_v3.pdf». Связанная настройка просмотрщика DisplayDocTitle решает, показывают ли читатели PDF этот заголовок вместо имени файла; проверяющий инструмент сообщает о ней отдельно, потому что присутствующий, но скрытый заголовок — это наполовину сделанное исправление. Что проверка не может судить, так это качество заголовка: «Отчёт» проходит и никому не помогает.
4. Дерево структуры и заголовки. Дерево структуры с настоящими элементами заголовков (H, H1–H6) — это то, как незрячие читатели бегло просматривают: навигация по заголовкам — самая используемая стратегия поиска информации в длинных документах. Проверка считает элементы заголовков, когда дерево можно восстановить. Она не может сказать вам, в разумном ли порядке уровни заголовков или описывают ли заголовки свои разделы, — дерево, полное заголовков «Без названия», проходит подсчёт и подводит читателя.
5. Альтернативный текст изображений. Проверяющий инструмент считает XObject изображений на страницах в сравнении с элементами структуры /Figure с непустым /Alt и помечает результат как приближение — потому что одна фигура может оборачивать несколько изображений, декоративные изображения правильно несут пустой альтернативный текст, а соответствие между нарисованными изображениями и элементами структуры не один к одному. Относитесь к этому как к дымовой сигнализации покрытия, а не как к аудиту. И он никогда не может судить сам альтернативный текст: «image123.jpg» — это непустой альтернативный текст, и он бесполезен.
6. Закладки. Оглавление документа — это поручень для длинных документов: руководство на 200 страниц с закладками навигабельно, без них — это прокрутка. Проверка читает объявленное количество в оглавлении. Она не может сказать вам, полезно ли помечены закладки или указывают ли они на правильные страницы, — только то, что навигация существует. Для коротких документов это наименее важное из шести; для отчётов и руководств это разница между справочником и стогом сена.
Дымовой тест — не валидация PDF/UA
PDF/UA (ISO 14289) — это полный стандарт доступных PDF: структура с тегами, правильный порядок чтения, заголовки таблиц, аннотации ссылок, метки полей форм, контраст и многое другое, проверяемое валидаторами и человеческим тестированием. Бесплатный эталонный валидатор с открытым исходным кодом veraPDF — это настольный инструмент, который глубоко проверяет файл по машиночитаемым правилам PDF/UA. Проверка в браузере по шести сигналам не конкурирует с этим, и инструмент этой статьи говорит об этом на своей собственной странице: это дымовой тест, который вы запускаете по всей библиотеке документов за один день, чтобы найти, каким файлам не хватает основ, а не сертификация, на которую вы ссылаетесь.
Вам нужна полная валидация, когда документ существенен (форма, которую клиент должен заполнить, юридическая информация, экзаменационная работа), когда процесс закупок или соответствия требует доказательств, когда документ длинный и структурный (руководства, годовые отчёты), или когда результатов «не удалось определить» и приближений лёгкой проверки недостаточно для решения, которое вы принимаете. Профессиональное исправление — исправление порядка чтения, таблиц и форм в специализированном инструменте, а затем валидация — это настоящая дисциплина с настоящей стоимостью, и именно поэтому дешёвый дымовой тест сначала заслуживает своё место: он говорит вам, куда эти деньги действительно должны пойти.
Прагматичный порядок исправлений
Исправляйте в этом порядке, по возможности в источнике. Во-первых, конвейер: включите экспорт PDF с тегами в Word, InDesign или вашем инструменте отчётности и задайте язык и заголовок документа в свойствах шаблона — большинство библиотек PDF проваливают одни и те же три проверки, потому что у них общий сломанный шаблон, поэтому одно исправление шаблона навсегда переиздаёт чистые файлы. Во-вторых, заголовки: используйте настоящие стили заголовков в источнике и заново создавайте закладки из них; это исправляет проверки 4 и 6 вместе. В-третьих, изображения: пишите альтернативный текст в источнике для информативных изображений и помечайте декоративные как декоративные — не заполняйте альтернативный текст пакетами имён файлов. В-четвёртых, задолженность: отсортируйте существующую библиотеку по загрузкам и важности, проведите дымовой тест всего с помощью проверяющего инструмента, надлежащим образом исправьте существенные документы и замените или отзовите длинный хвост, за который вы больше не ручаетесь.
Наконец, держите документы в рутине, которая держит страницы честными. Когда публикуется новый PDF, запустите те же шесть проверок до его выхода — это занимает меньше минуты — и повторно запустите проверку здоровья сайта на странице, которая на него ссылается. Регрессии доступности редко приходят как драматичные редизайны; они приходят как один экспорт без тегов, загруженный в пятницу, который никто не проверил. Документы — часть сайта. Проверяйте их как таковые.