Этот чек-лист отвечает на конкретный вопрос: можно ли пройти по главному меню, футеру и внутреннему поиску ресторанного сайта, используя только клавиатуру, и понять, что происходит, если что-то пошло не так. Проверка строится вокруг трёх групп критериев WCAG 2.2 — клавиатурная доступность, порядок фокуса и идентификация ошибок — и охватывает именно те узлы сайта, через которые посетитель проходит до того, как открыть меню блюд, корзину заказа или форму бронирования. Ниже — рабочий метод, таблица критериев и то, что этот аудит не может гарантировать сам по себе.
Почему навигация и поиск — отдельный участок проверки
Большинство обзоров доступности ресторанных сайтов концентрируются на форме заказа или виджете бронирования — это логично, потому что там происходит транзакция. Но между заходом на сайт и этой транзакцией посетитель почти всегда проходит через главное меню сайта, ссылки в футере (адрес, часы работы, контакты, политика конфиденциальности) и, если он есть, поле внутреннего поиска. Эти элементы повторяются на каждой странице и определяют, доберётся ли человек до контента вообще.
Если пункт меню нельзя открыть клавишей Tab и Enter, если фокус после клика «прыгает» в непредсказуемое место или сообщение об ошибке поиска звучит как «Ошибка 404» без объяснений, посетитель, работающий без мыши, может закрыть сайт раньше, чем узнает, что ресторан вообще принимает бронирования онлайн. Именно поэтому навигацию, футер и поиск полезно проверять отдельным проходом, а не считать, что аудит формы заказа автоматически покрывает и эти узлы.
Фреймворк «НФП»: три прохода по каждому интерактивному узлу
Практический способ провести такой аудит — три последовательных прохода по одним и тем же элементам: навигации (Н), футеру (Ф) и поиску (П). Каждый проход соответствует одной группе критериев WCAG 2.2 и выполняется отдельно, чтобы не смешивать разные типы проблем.
Проход 1. Клавиатурная доступность (Keyboard Accessibility)
- Пройдите по всей главной навигации только клавишами Tab, Shift+Tab, Enter, пробел и стрелками — без мыши и без трекпада.
- Проверьте, открываются ли выпадающие подменю с клавиатуры и закрываются ли они клавишей Escape.
- Убедитесь, что фокус не «застревает» ни в одном виджете навигации или поиска — то есть Tab всегда позволяет выйти из элемента.
- Проверьте ссылки футера: юридические страницы, контакты, ссылки на карты — все ли доступны без мыши.
Проход 2. Порядок фокуса (Focus Order)
- Двигаясь по Tab, зафиксируйте, соответствует ли визуальный порядок перехода логике страницы (сверху вниз, слева направо для языков с таким направлением письма).
- Проверьте, виден ли индикатор фокуса на каждом элементе и не перекрывается ли он другими блоками — плавающей шапкой, баннером cookie, липкой панелью.
- Отдельно проверьте поведение фокуса после открытия и закрытия модальных окон (например, окна с картой или окна согласия на cookie): фокус должен возвращаться в предсказуемое место, а не «улетать» в начало страницы или пропадать.
Проход 3. Идентификация ошибок (Error Identification)
- Введите в поисковую строку заведомо несуществующий запрос и посмотрите, появляется ли текстовое сообщение о том, что результатов нет, а не просто пустая страница.
- Проверьте, объявляется ли это сообщение программно — например, средствами чтения с экрана, — а не только визуально.
- Если поиск предполагает исправление запроса (например, подсказки «возможно, вы искали»), убедитесь, что эти подсказки доступны с клавиатуры.
Таблица критериев WCAG 2.2 для этого аудита
| Критерий | Уровень | Что проверяется в навигации/футере/поиске |
|---|---|---|
| 2.1.1 Keyboard | A | Все пункты меню, ссылки футера и поле поиска управляются клавиатурой |
| 2.1.2 No Keyboard Trap | A | Из выпадающего меню, модального окна или блока результатов поиска можно выйти клавиатурой |
| 2.4.1 Bypass Blocks | A | Есть механизм пропустить повторяющуюся навигацию и перейти к основному контенту |
| 2.4.3 Focus Order | A | Порядок перехода по Tab соответствует визуальной и смысловой последовательности элементов |
| 2.4.7 Focus Visible | AA | Элемент, находящийся в фокусе, визуально отличим от остальных |
| 2.4.11 Focus Not Obscured (Minimum) | AA | Элемент в фокусе не полностью скрыт под липкой шапкой, баннером или всплывающим окном |
| 3.3.1 Error Identification | A | Ошибка поиска (нет результатов, некорректный запрос) описана текстом, а не только цветом или иконкой |
| 3.3.3 Error Suggestion | AA | Если это применимо, интерфейс поиска предлагает способ исправить запрос |
Полный и актуальный перечень критериев с формальными формулировками — в тексте самого стандарта на сайте W3C (WCAG 2.2, https://www.w3.org/TR/WCAG22/). Таблица выше — не замена стандарту, а рабочая выжимка для проверки именно навигации, футера и поиска.
Как измерять результаты и фиксировать их
- Соберите список страниц-образцов: главная, страница меню блюд, страница контактов, результаты поиска по пустому и по «шумному» запросу.
- Для каждой страницы пройдите три прохода фреймворка «
Как внедрить аудит в рабочий процесс, а не провести его один раз
Чек-лист выше описывает, что проверять. Отдельный вопрос — кто проверяет, в какой среде и как часто. Разовый прогон по трём проходам «НФП» показывает срез на конкретный день, но навигация, футер и поиск обычно меняются при каждом обновлении CMS, теме оформления или подключении нового виджета (карта, онлайн-чат, баннер согласия на cookie). Поэтому аудит имеет смысл встроить в процесс, а не хранить как разовый отчёт.
- Назначьте, кто отвечает за повторную проверку после каждого релиза, затрагивающего шапку, футер или поисковую выдачу — это может быть тот же человек, кто вносит правки в вёрстку, или отдельный ревьюер.
- Проверяйте навигацию и поиск как минимум в двух средах: в браузере на десктопе с физической клавиатурой и в браузере на мобильном устройстве, где управление фокусом может отличаться от десктопной Tab-последовательности.
- Используйте реальную вспомогательную технологию (программу экранного доступа) хотя бы для одного прохода по поиску и навигации, а не только визуальную проверку индикатора фокуса — критерий 3.3.1 требует, чтобы сообщение об ошибке было доступно программно, и это невозможно подтвердить только глазами.
- Фиксируйте не только «прошёл / не прошёл», но и точный шаг воспроизведения: какая клавиша, какой элемент, какой браузер — это нужно, чтобы разработчик мог повторить проблему без повторного полного аудита.
Граничные случаи, которые чек-лист легко упускает
Виджеты сторонних поставщиков в шапке и футере
Баннеры согласия на cookie, встроенные карты, кнопки онлайн-чата и виджеты соцсетей часто размещаются в шапке или футере, но их код и разметка контролируются сторонним поставщиком, а не командой сайта. Такие блоки нужно проверять отдельно на критерии 2.1.2 (нет ловушки фокуса) и 2.4.11 (элемент в фокусе не скрыт другим слоем), потому что обновление стороннего скрипта может сломать доступность без изменений в собственном коде сайта.
Мультиязычные и мультилокационные сайты
Если ресторанная группа использует общий шаблон навигации и футера для нескольких сайтов на разных языках или для нескольких точек, переключатель языка или локации сам становится интерактивным узлом навигации и подлежит той же проверке по критерию 2.1.1: он должен открываться и выбираться клавиатурой, а не только кликом мыши или тапом.
Мобильный вьюпорт и альтернативные способы ввода
Проверка «только клавиатурой» на десктопе не покрывает мобильный опыт: на мобильных устройствах вместо клавиши Tab пользователи могут применять переключатели (switch access) или голосовое управление, а раскрывающееся меню может вести себя иначе из-за экранной клавиатуры, перекрывающей часть вьюпорта. Если ресторан ожидает заметную долю мобильного трафика, стоит повторить хотя бы проход 2 (порядок фокуса) на мобильном устройстве отдельно от десктопного прогона.
Как фиксировать и интерпретировать результаты
Единый отчёт по трём проходам полезно структурировать по степени влияния на задачу пользователя, а не только по номеру критерия WCAG.
Уровень влияния Пример Что делать дальше Блокирует задачу Клавиатурная ловушка в подменю: Tab не выводит фокус из выпадающего списка Исправлять до следующего релиза, не откладывать в общий backlog Затрудняет задачу Индикатор фокуса виден, но слабо контрастен на некоторых пунктах меню Включить в ближайший спринт по вёрстке Не мешает задаче напрямую Порядок Tab в футере не совпадает с визуальным порядком, но все ссылки достижимы Зафиксировать и запланировать без срочности Такая классификация не заменяет формальные уровни соответствия A/AA/AAA из самого стандарта, а помогает команде разработки решить, что чинить первым, когда ресурсов на исправление всего списка сразу нет.
Что этот аудит не гарантирует
Три прохода «НФП» покрывают только клавиатурную доступность, порядок фокуса и идентификацию ошибок в навигации, футере и поиске. Это не полный аудит соответствия WCAG 2.2 — стандарт включает и другие группы критериев (например, контраст текста, альтернативные описания изображений, структуру заголовков), которые в этот чек-лист не входят и требуют отдельной проверки по тексту самого стандарта на сайте W3C.
- Прохождение всех пунктов этого чек-листа не является юридическим заключением о соответствии сайта WCAG 2.2 или локальному законодательству о доступности — для такого заключения нужна отдельная формальная оценка.
- Автоматические сканеры доступности не могут полноценно оценить порядок фокуса или содержательность сообщения об ошибке — они проверяют наличие разметки, но не то, логичен ли порядок перехода для конкретного пользователя или понятен ли текст ошибки по смыслу. Часть проходов из этого чек-листа требует именно ручной проверки человеком.
- Успешное прохождение чек-листа не гарантирует, что реальный посетитель, использующий конкретную вспомогательную технологию, успешно завершит задачу — рекомендуется периодически дополнять аудит тестированием с участием людей, реально использующих такие технологии.
Контекст ChefNet
Этот чек-лист описывает общий метод проверки навигации, футера и поиска по критериям WCAG 2.2 и не привязан к какому-либо конкретному продукту. ChefNet разрабатывает продукты для поиска ресторанов и управления операционной работой заведений; какие именно функции уже доступны в текущей версии продукта, следует уточнять отдельно, а не считать, что они присутствуют по умолчанию.
Первичные источники
FAQ
Распространяется ли WCAG 2.2 именно на навигацию сайта ресторана?
WCAG 2.2 применяется ко всему веб-контенту, включая сайты ресторанов, и не делает исключений для навигации, футера или поиска. Критерии успеха по клавиатурной доступности, порядку фокуса и идентификации ошибок действуют для главного меню и поисковой строки точно так же, как для форм заказа или бронирования. Оператору стоит относиться к основной навигации и поиску как к полноценным интерактивным интерфейсам, подпадающим под те же требования.
Чем аудит навигации отличается от аудита бронирования или заказа?
Навигация, ссылки в футере и внутренний поиск присутствуют практически на каждой странице и используются раньше, чем посетитель доходит до меню, корзины заказа или формы бронирования. Если человек не может перейти по главному меню с клавиатуры или не понимает, что пошло не так после неудачного поиска, он может уйти с сайта, так и не добравшись до транзакционных форм. Этот чек-лист выделяет именно эти «входные» узлы, а не повторяет проверки, уже направленные на заказ или бронирование.
Может ли автоматический сканер полностью заменить такой аудит?
Автоматические инструменты способны находить часть проблем — например, отсутствие видимого индикатора фокуса в коде или повторяющийся текст ссылок, — но они, как правило, не могут надёжно оценить логичность порядка фокуса, понятность сообщений об ошибках или наличие клавиатурных «ловушек» в кастомных виджетах. Ручное тестирование только клавиатурой, а где возможно — с реальными вспомогательными технологиями, остаётся обязательным. Результаты автоматических проверок стоит считать отправной точкой, а не итоговым заключением о соответствии.
Редакционное раскрытие: ChefNet публикует это руководство и разрабатывает продукты для поиска ресторанов и ресторанных операций. Общие рекомендации отделены от заявлений о продукте. Возможности могут меняться по мере развития пилотных проектов. Опубликовано 2026-08-03.