Аудит доступности PDF-меню: метод четырёх проходов по WCAG 2.2

Если ресторан публикует меню в виде скачиваемого PDF-файла, простого визуального просмотра недостаточно, чтобы понять, насколько документ доступен для посетителей, использующих скринридеры или другие вспомогательные технологии. Нужен повторяемый процесс проверки структуры документа, порядка чтения, текстовых альтернатив и навигации — именно это и даёт метод четырёх проходов, описанный ниже. Он опирается на структурные и навигационные концепции WCAG 2.2 и применяется к уже готовому PDF-файлу перед публикацией на сайте.

Почему PDF-меню требует отдельного аудита

PDF-меню — это не веб-страница, хотя часто ссылка на него размещена прямо на сайте ресторана. Скринридеры интерпретируют PDF через внутреннюю структуру тегов документа, а не через HTML-разметку и не через DOM браузера. Если PDF экспортирован из макета без сохранения структуры — например, из графического редактора без разметки заголовков и таблиц — файл может выглядеть аккуратно визуально, но быть практически нечитаемым для вспомогательных технологий. Отдельный аудит нужен именно потому, что визуальная проверка макета не выявляет проблемы с тегами, порядком чтения или отсутствующими текстовыми альтернативами.

Метод четырёх проходов: практический фреймворк

Ниже — последовательность из четырёх проходов. Каждый проход выполняется отдельно и с использованием разных инструментов: панели тегов, инструмента порядка чтения и, при возможности, самого скринридера.

Проход 1. Проверка тегирования документа

Первый проход отвечает на вопрос: размечен ли документ вообще как структурированный контент, а не как «плоское» изображение текста. В панели тегов большинства PDF-редакторов проверяется:

• Присутствует ли дерево тегов, соответствующее видимой структуре меню (заголовки разделов, названия блюд, цены, описания).
• Использованы ли теги заголовков (H1–H3 или их аналоги) для разделов меню, а не только визуально увеличенный шрифт.
• Помечены ли таблицы (если меню оформлено таблицей) как таблицы с заголовками строк и столбцов, а не как набор несвязанных текстовых блоков.
• Нет ли в дереве тегов «осиротевшего» контента — текста, который присутствует визуально, но отсутствует в структуре тегов.

Проход 2. Проверка порядка чтения

Второй проход проверяет, в какой последовательности скринридер озвучит содержимое, и совпадает ли эта последовательность с логикой чтения меню человеком: раздел → название блюда → описание → цена. Инструмент порядка чтения в PDF-редакторе показывает нумерованную последовательность блоков. Частая проблема — макет из нескольких колонок, где визуально второй колонки является продолжением раздела, но в порядке чтения он идёт раньше первой колонки или между несвязанными блюдами.

Проход 3. Проверка текстовых альтернатив

Третий проход касается нетекстового контента: логотипов, декоративных значков (например, «острое» или «вегетарианское»), фотографий блюд и сканированных изображений. Для каждого такого элемента проверяется:

• Есть ли альтернативный текст, и передаёт ли он смысл, важный для понимания меню (например, значок «острое» описан словом, а не оставлен пустым).
• Помечены ли чисто декоративные элементы как декоративные, чтобы скринридер их пропускал, а не зачитывал бессмысленное имя файла.
• Нет ли в меню цены или названия блюда, встроенных только в изображение без параллельного текстового варианта.

Проход 4. Проверка навигации и метаданных

Четвёртый проход проверяет, может ли пользователь скринридера ориентироваться внутри документа, а не только линейно его прослушивать. Здесь проверяются:

• Заголовок документа (Title) в метаданных файла — заполнен ли он осмысленно, а не оставлен как имя файла с датой экспорта.
• Язык документа, указанный в свойствах файла, соответствует ли фактическому языку меню.
• Наличие закладок (bookmarks) для длинных меню с несколькими разделами, позволяющих переходить сразу к нужному разделу.
• Логическая последовательность табуляции между интерактивными элементами, если в PDF есть ссылки или поля.

Ограничения этого процесса

Метод четырёх проходов — это практический чек-лист, а не формальная процедура сертификации соответствия WCAG 2.2. WCAG 2.2 сформулирован для веб-контента, и применение его критериев к PDF всегда происходит через интерпретацию — проверку структурных аналогов, а не буквальное сопоставление с критериями, написанными для DOM-модели браузера. Кроме того, поведение конкретного файла в конкретном скринридере может отличаться от результатов, показанных инструментом порядка чтения в PDF-редакторе: последний показывает заявленную структуру, а не гарантированный результат озвучивания. Финальную проверку стоит проводить хотя бы одним реальным скринридером, а не полагаться только на автоматические индикаторы редактора. Этот процесс также не решает вопрос о том, стоит ли вообще публиковать меню в формате PDF вместо HTML-страницы — это отдельное решение, требующее отдельного анализа.

Как фиксировать результаты аудита

Чтобы аудит был воспроизводимым при каждом обновлении меню (сезонное меню, новые цены, новые блюда), результаты каждого прохода стоит фиксировать в таблице, а не держать в памяти. Ниже — пример структуры такой записи.

Такую таблицу удобно хранить вместе с исходным файлом макета меню и обновлять при каждой новой версии, а не создавать заново с нуля. Это также упрощает передачу задачи другому сотруднику или подрядчику, если обновлением меню занимается не всегда один и тот же человек.

Где здесь может быть уместен ChefNet

ChefNet развивает продукты для поиска ресторанов и операционных задач HoReCa, и часть таких продуктов может со временем затрагивать способы публикации и структурирования информации о меню. Это общее описание направления развития, а не перечень доступных сегодня функций: если вы рассматриваете использование инструментов ChefNet в рамках работы над доступностью меню, уточняйте у команды продукта, какие возможности реализованы на текущий момент, а какие только находятся в разработке.

Итоговый порядок действий

1. Откройте PDF-меню в редакторе с панелью тегов и инструментом порядка чтения.
2. Пройдите четыре прохода последовательно, не пропуская пункты, даже если предыдущий проход не выявил проблем.
3. Зафиксируйте результат каждого прохода в таблице аудита.
4. Проверьте итоговый файл хотя бы одним реальным скринридером перед публикацией.
5. Повторяйте процесс при каждом обновлении меню, а не только при первой публикации.

Как сопоставить каждый проход с конкретными критериями WCAG 2.2

Чтобы аудит был не просто интуитивным чек-листом, а опирался на проверяемые формулировки, каждый из четырёх проходов стоит явно связать с соответствующими критериями успеха WCAG 2.2. Это не превращает PDF-аудит в формальную сертификацию, но даёт общий язык для обсуждения проблем с дизайнером, подрядчиком или другим сотрудником.

Пограничные случаи, которые часто пропускают

Сканированное меню без распознанного текста

Если PDF получен сканированием бумажного меню без последующего распознавания текста (OCR), документ фактически представляет собой изображение — весь текст недоступен скринридеру независимо от результатов первых трёх проходов. Такой файл нужно выявлять до начала аудита: попытка выделить текст курсором в PDF-редакторе быстро показывает, есть ли под изображением текстовый слой.

Многоязычные меню в одном файле

Если меню содержит разделы на нескольких языках, свойство языка документа не может корректно описывать оба раздела одновременно. В этом случае стоит проверять, размечены ли языковые фрагменты на уровне тегов внутри документа, а не полагаться только на одно значение в метаданных файла.

Интерактивные PDF-формы

Если в меню встроены поля — например, форма предзаказа или бронирования, — четвёртый проход должен дополнительно проверять, что каждое поле имеет программно связанную подпись и что последовательность табуляции между полями логична, а не определяется порядком добавления элементов при вёрстке.

Ограничения автоматических проверок доступности PDF

Встроенные в некоторые PDF-редакторы автоматические отчёты о доступности выявляют отсутствие тегов, пустые альтернативные тексты или незаполненные метаданные, но не могут оценить смысловую корректность найденного — например, признать альтернативный текст «изображение1» формально присутствующим, хотя он не описывает содержимое. Поэтому автоматический отчёт стоит рассматривать как фильтр для первого прохода, а не как замену ручной проверке текстовых альтернатив и порядка чтения.

Что делать при повторяющихся ошибках между версиями меню

1. Если один и тот же тип ошибки (например, непомеченные декоративные значки) повторяется в нескольких обновлениях меню подряд, проблему стоит искать не в конкретном файле, а в исходном шаблоне вёрстки, из которого экспортируется PDF.
2. Стоит зафиксировать источник шаблона отдельной пометкой в таблице аудита, чтобы при следующем обновлении сначала проверить, изменился ли сам шаблон, а не только содержимое меню.
3. Если ошибка воспроизводится в шаблоне систематически, её устранение на уровне шаблона снижает объём ручной проверки для последующих версий меню.

Пределы применимости этого раздела

Формулировки WCAG 2.2 написаны для веб-контента, и их использование при аудите PDF остаётся интерпретацией по аналогии, а не прямым применением. Соответствие критериям, перечисленным в таблице выше, не эквивалентно формальному заключению о соответствии WCAG 2.2 в целом и не гарантирует одинаковое поведение файла во всех скринридерах и версиях PDF-редакторов.

Первичные источники

• W3C: Web Content Accessibility Guidelines 2.2

FAQ

Редакционное раскрытие: ChefNet публикует это руководство и разрабатывает продукты для поиска ресторанов и ресторанных операций. Общие рекомендации отделены от заявлений о продукте. Возможности могут меняться по мере развития пилотных проектов. Опубликовано 2026-08-04.