Чек-лист WCAG 2.2 для цифрового меню и самостоятельного заказа

Почему меню и заказ — это отдельная зона проверки

Цифровое меню на планшете у входа, QR-меню на телефоне гостя и терминал самозаказа — это не витрина, а интерактивный интерфейс с формами, модификаторами и многошаговым оформлением. Стандартный аудит доступности сайта ресторана часто ограничивается главной страницей и формой бронирования, оставляя без внимания карточки блюд, выбор начинок, попапы с аллергенами и корзину. WCAG 2.2 — актуальная редакция рекомендаций W3C — даёт конкретные, проверяемые критерии именно для такого рода интерфейсов, включая новые пункты версии 2.2: 2.4.11 (фокус не перекрыт), 2.5.7 (движения перетаскивания) и 2.5.8 (размер цели), которых не было в 2.1.

Фреймворк: Чек-лист доступности мобильного меню и заказа

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

Три зоны, где чаще всего теряется доступность

Текстовые альтернативы для карточек блюд

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

Контраст меток аллергенов и диетических тегов

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

Фокус и клавиатура в модификаторах и на кассе самообслуживания

Модальные окна выбора добавок, drag-слайдеры остроты, счетчики количества — типичные места, где клавиатурная навигация обрывается или фокус визуально не виден. На многошаговом оформлении заказа отдельно проверяйте, что фокус после закрытия попапа возвращается на логичный элемент, а не теряется в начале страницы.

Ограничения этого чек-листа

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

Как измерять и повторно проверять

Практический порядок прогона чек-листа:

1. Пройдите весь путь от открытия меню до подтверждения заказа только клавиатурой, без мыши и без тапов — зафиксируйте, где фокус теряется или становится невидимым.
2. Повторите тот же путь с включённым скринридером (VoiceOver, NVDA или TalkBack) и запишите, какие элементы объявляются без роли или состояния.
3. Прогоните инструмент измерения контраста по всем меткам аллергенов, бейджам и состояниям выбранных модификаторов отдельно от общего текста страницы.
4. Проверьте размеры целей касания на мобильном макете для кнопок модификаторов и счётчиков количества.
5. Зафиксируйте результаты по каждому критерию из таблицы как pass/fail и повторяйте проверку после каждого значимого изменения дизайна меню или флоу заказа.

Полный нормативный текст критериев, включая допустимые исключения и формулировки уровня A/AA/AAA, опубликован W3C в рекомендации WCAG 2.2, и при спорных случаях стоит обращаться к первоисточнику, а не к пересказам вроде этого чек-листа.

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

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

Динамические состояния, которые основной чек-лист не покрывает

Меню и флоу заказа редко статичны: гость включает фильтр «без орехов», блюдо становится недоступным в реальном времени, форма подсказывает ошибку в номере телефона. Эти состояния требуют отдельных критериев WCAG 2.2, которые не входят в базовую таблицу выше.

Фильтры по аллергенам и обновление списка блюд

• 4.1.3 Статусные сообщения: если после включения фильтра «вегетарианское» список блюд обновляется без перезагрузки страницы, сообщение об изменении должно программно объявляться скринридером без переноса фокуса — иначе пользователь не узнает, что список изменился.
• 1.4.13 Контент при наведении или фокусе: если состав блюда или предупреждение об аллергене появляется как всплывающая подсказка при наведении/фокусе, подсказка должна быть доступна для скрытия без перемещения курсора, оставаться видимой, пока пользователь на ней сфокусирован, и не исчезать преждевременно.

Ошибки ввода на кассе самообслуживания

• 3.3.1 Идентификация ошибки: при неверном формате телефона или адреса ошибка должна быть описана текстом, а не только цветом поля или иконкой.
• 3.3.3 Предложение по исправлению ошибки: где это применимо к типу поля, система должна предлагать формат исправления, а не только сообщать «ошибка».

Как встроить проверку в процесс редизайна

Чек-лист из основной части полезен как разовый прогон, но реальная польза появляется, когда проверка встроена в цикл разработки, а не выполняется постфактум.

1. Базовый срез до редизайна: прогоните таблицу критериев на текущей версии меню и зафиксируйте pass/fail по каждому пункту — это точка сравнения для будущих изменений.
2. Ревью макетов до разработки: проверяйте контраст меток аллергенов и размер целей касания ещё на этапе дизайн-макетов, до передачи в разработку — исправление на этом этапе дешевле.
3. Регрессия перед релизом: после любого изменения флоу заказа (новый шаг оплаты, новый тип модификатора) повторяйте клавиатурный и скринридерный проход по затронутым экранам, а не по всему меню.
4. Периодический повторный аудит: назначьте фиксированную частоту полного прогона чек-листа (например, при каждом значимом обновлении меню), поскольку точечные изменения дизайна со временем накапливают регрессии, незаметные при точечном тестировании.

Ограничения измерения и покрытия

Даже при регулярном прогоне чек-листа стоит учитывать границы его применимости.

• Проверка на одном устройстве и одном скринридере не гарантирует одинакового поведения в других комбинациях браузер/вспомогательная технология; результаты стоит трактовать как выборочную, а не исчерпывающую проверку.
• Если меню встроено через стороннюю платформу заказа (агрегатор, виджет партнёра), часть элементов интерфейса может быть вне контроля ресторана — в этом случае чек-лист применим только к тем экранам, разметку и вёрстку которых можно изменить напрямую.
• Автоматизированные сканеры контраста и разметки не проверяют порядок фокуса, корректность объявлений скринридера и логику статусных сообщений (4.1.3) — эти пункты требуют ручного прохода, описанного выше.
• Чек-лист не оценивает многоязычные версии меню отдельно; если меню доступно на нескольких языках, каждую языковую версию стоит проверять как отдельный флоу, поскольку длина текста и структура меток аллергенов могут отличаться.

Краткий артефакт: Mobile Menu & Ordering Accessibility Checklist (дополнение)

Дополнительные пункты для прогона на динамических состояниях, вне основной таблицы:

• [ ] Обновление списка блюд после фильтра объявляется скринридером (4.1.3)
• [ ] Подсказка о составе при наведении/фокусе не исчезает при наведении на неё курсора (1.4.13)
• [ ] Ошибка в поле контактных данных описана текстом, не только цветом (3.3.1)
• [ ] Формат исправления ошибки предложен, где применимо к типу поля (3.3.3)
• [ ] Проверка повторена после последнего значимого изменения флоу заказа

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

• W3C: Web Content Accessibility Guidelines 2.2

FAQ

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