BITSPARK / Статьи / Дизайн и элементы сайта

Бургер-меню: что это и нужно ли оно сайту

Коротко: бургер-меню - меню, которое показывается после нажатия на кнопку. Справка Wix Studio называет его гамбургер-меню, а на страницах W3C, MDN, web.dev и Google, разобранных в статье, этих слов нет. web.dev советует сначала искать способ не прятать меню, называет скрытое меню последним средством и просит подписывать кнопку. W3C описывает кнопку с атрибутом aria-expanded и закрытие списка ссылок клавишей Esc в примере навигации. Нужно ли оно вашему сайту, решают заказчик и подрядчик.

Если в макете мобильной версии меню открывается кнопкой, это бургер-меню на сайте; справка Wix называет его гамбургер-меню. Статья написана для владельца бизнеса или маркетолога, который заказывает сайт или переделывает существующий и хочет понимать, что стоит за этой кнопкой и о чём спросить подрядчика до дизайна. Она разбирает справку Wix Studio, страницу web.dev о паттернах интерфейса, четыре страницы W3C (два учебника WAI, шаблон и пример APG), две страницы WCAG 2.2, страницу MDN об aria-expanded и документацию Центра Google Поиска. Сведения даны по страницам, открытым 21.10.2026.

Страницы W3C, MDN и web.dev написаны по-английски, поэтому английские цитаты даны с переводом, перевод наш. Статья не оценивает конкретный сайт и не учит верстать. Пример вымышленный: кофейня с сайтом example.ru.

Что такое бургер-меню?

Коротко: по справке Wix Studio, гамбургер-меню - компактное меню, которое отображается только после нажатия посетителем на значок меню. Справка выделяет в нём четыре части: кнопку открытия, контейнер, вертикальное меню и кнопку закрытия. Слов бургер и гамбургер нет на страницах web.dev, W3C, MDN и Google из этой статьи.

Определение дано в справке редактора Wix Studio:

«Гамбургер-меню - это минималистичное, компактное меню, которое отображается только тогда, когда посетители нажимают на значок меню.»

Справка написана для пользователей редактора Wix Studio, поэтому определение относится к элементу этого редактора. Общего определения на других страницах статьи нет. В тексте страниц web.dev, W3C, MDN и Google слова бургер и гамбургер не встречаются: меню, раскрывающееся по кнопке, описано там другими словами. Здесь краткое название бургер-меню означает тот же предмет, что и гамбургер-меню в справке Wix: такое сопоставление сделано в этой статье.

Справка Wix делит такое меню на четыре части:

ЧастьКак её описывает справка Wix Studio
Значок гамбургер-меню«Это кнопка, которую посетители нажимают, чтобы открыть меню.» Для кнопки можно решить, «какой значок и / или текст показать»
Контейнер меню и слой«Когда посетители нажимают на значок гамбургер-меню, открывается контейнер.» Среди настроек названа «возможность нажать вне контейнера, чтобы его закрыть»
Вертикальное меню«Это фактический элемент меню.» В нём настраивают «отображаемые страницы, ссылки и подменю»
Значок кнопки «Закрыть»Кнопка X, «которую посетители нажимают, чтобы закрыть меню». Для неё, как и для кнопки открытия, можно выбрать значок, текст или оба

Справка добавляет, что дизайн каждой части можно настроить. Из таблицы следуют вопросы к макету: что написано на кнопке открытия, чем закрывается открытое меню и какие пункты внутри. Как выглядит значок меню и на каких условиях подрядчик берёт значки, объясняет статья об иконках для сайта.

Как W3C называет кнопку, раскрывающую меню?

Коротко: W3C слово бургер не использует. Ближайший описанный шаблон - Disclosure (раскрытие): кнопка и блок содержимого, видимость которого она задаёт. Что кнопка бургер-меню подходит под этот шаблон, - вывод статьи, страницы W3C о бургер-меню не говорят. Примера с меню для экрана телефона на странице нет.

Шаблон Disclosure описан в Руководстве по применению ARIA (APG, ARIA Authoring Practices Guide) на сайте W3C:

"A disclosure is a widget that enables content to be either collapsed (hidden) or expanded (visible)."

Перевод наш: раскрытие - элемент интерфейса, который позволяет свернуть (скрыть) содержимое или развернуть (показать) его.

"It has two elements: a disclosure button and a section of content whose visibility is controlled by the button."

Перевод наш: в нём два элемента - кнопка раскрытия и блок содержимого, видимость которого задаёт кнопка.

Среди примеров шаблона на странице назван Disclosure (Show/Hide) Navigation Menu. По странице самого примера, кнопки раскрытия в нём показывают и прячут выпадающие списки ссылок в панели навигации сайта вымышленного университета, каждая кнопка соответствует разделу сайта. Примера с меню для экрана телефона на странице нет.

По описанию шаблона, Enter и Space активируют кнопку раскрытия и переключают видимость содержимого. У элемента, который показывает и прячет содержимое, роль button.

Нужно ли прятать меню за кнопкой?

Коротко: web.dev (курс Learn Design, страница обновлена 2021-12-23) называет желание спрятать навигацию за кнопкой соблазнительным и указывает цену: два шага до любой страницы. Страница советует сначала искать способ оставить меню на виду, скрытое меню описывает как последнее средство. Это совет учебного курса; требованием или стандартом страница себя не называет. Числа пунктов, начиная с которого меню надо прятать, на странице нет.

Страница «User interface patterns» курса об адаптивном дизайне разбирает навигацию на маленьком экране. Она описывает соблазн и его цену:

"The problem with this solution is that users have to then take two steps to get anywhere: open the menu, then choose an option."

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

Дальше страница даёт совет:

"Try to find a strategy that avoids hiding your navigation."

В переводе: постарайтесь найти стратегию, при которой навигацию не нужно прятать.

Страница называет три варианта:

ВариантЧто пишет web.devУсловия и оговорки на странице
Меню остаётся на экранеЕсли пунктов относительно немного, навигацию можно оформить так, чтобы она хорошо выглядела на маленьком экранеШаблон не масштабируется, если ссылок много; ссылки в две-три строки делают навигацию перегруженной
Overflow pattern (переполнение)Ссылки остаются в одной строке, список обрезается у края экрана, а посетитель проводит пальцем по горизонтали и открывает остальныеМасштабируется на любую ширину и любое число ссылок; посетитель может пропустить ссылки, которых не видно сразу. Первые ссылки должны быть самыми важными, а продолжение списка надо показать визуально (в примере страницы - градиентом)
Меню скрыто по умолчанию и открывается кнопкой (progressive disclosure, постепенное раскрытие)«As a last resort» (перевод наш: в крайнем случае)Нужны два шага до пункта; кнопка должна быть подписана

Фраза про крайний случай стоит в тексте так:

"As a last resort you could choose to have your navigation hidden by default and provide a toggle mechanism for users to show and hide the contents."

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

"Progressive disclosure is a useful way to save space, but be careful about using it for very important content. It's better suited to secondary actions."

Перевод наш: постепенное раскрытие - полезный способ сэкономить место, но будьте осторожны, применяя его для очень важного содержимого. Лучше оно подходит для второстепенных действий. К главному меню сайта страница это замечание отдельно не привязывает.

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

Если макет уже с кнопкой, можно спросить, рассматривались ли они. Что может стоять в шапке сайта и как шапка ведёт себя при прокрутке, описано в статье о шапке сайта.

Чем подписать кнопку: значком или словом?

Коротко: web.dev просит подписывать кнопку, которая показывает навигацию, и не рассчитывать, что значок поймут. Неподписанный значок страница называет навигацией «mystery meat». Справка Wix Studio позволяет выбрать для кнопки значок, текст или оба. Слово для подписи страница не называет.

Совет о подписи стоит в том же разделе Navigation:

"Make sure the button that toggles the display of the navigation is labeled. Don't rely on an icon to be understood."

Перевод наш: убедитесь, что кнопка, которая переключает показ навигации, подписана. Не рассчитывайте, что значок поймут.

"An unlabelled icon is "mystery meat" navigation - users won't know what's in there until they bite into it. Provide a text label to let users know what the button will reveal."

Перевод наш: неподписанный значок - это навигация "mystery meat" (в буквальном переводе "мясо неизвестного происхождения"): пользователи не узнают, что внутри, пока не откусят. Дайте текстовую подпись, чтобы пользователи знали, что откроет кнопка.

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

Что именно написать на кнопке, решают заказчик и дизайнер. Вопрос для макета: есть ли рядом со значком слово. В учебнике WAI о выпадающих меню (Fly-out Menus) у кнопки, раскрывающей подменю, невидимая подпись меняется на "show submenu" или "hide submenu" в зависимости от состояния. Примечание там советует по возможности включить в подпись название пункта-родителя, например "show Space Bears submenu" (перевод наш: показать подменю Space Bears).

Пример относится к подменю внутри навигации, бургер-кнопка на странице не названа.

Что W3C и MDN пишут о состоянии кнопки?

Коротко: MDN и APG описывают кнопку, которая показывает и прячет содержимое, атрибутом aria-expanded: true, когда содержимое показано, false, когда скрыто. Для скрытого меню MDN допускает опустить атрибут, указанный атрибут должен быть false; APG называет значение false для скрытого содержимого. WCAG 2.2 - стандарт доступности W3C; нормативных актов РФ среди источников статьи нет.

aria-expanded - атрибут разметки ARIA, который сообщает состояние элемента управления. Определение из MDN:

"The aria-expanded attribute is set on an element to indicate if a control is expanded or collapsed, and whether or not the controlled elements are displayed or hidden."

В переводе: атрибут aria-expanded ставят на элемент, чтобы показать, развёрнут ли элемент управления или свёрнут и показаны ли управляемые элементы или скрыты.

Три страницы формулируют правило для кнопки по-разному:

СтраницаЧто сказаноК чему относится
MDN, aria-expandedКнопка, переключающая элемент, получает aria-controls с id переключаемого элемента и aria-expanded с текущим состоянием. Для меню: когда меню показано, у кнопки aria-expanded="true"; когда скрыто, атрибут можно опустить, а если он указан, то со значением falseкнопка, переключающая виджет; отдельный абзац о меню
APG, DisclosureУ элемента, который показывает и прячет содержимое, роль button; когда содержимое видно, aria-expanded равен true, когда скрыто - false; aria-controls страница называет необязательным (optionally)шаблон раскрытия
WAI, Fly-out Menusaria-expanded="false" сообщает, что подменю сейчас скрыто, то есть свёрнуто. Для отдельной кнопки-переключателя код примера ставит aria-expanded="true" при открытии и "false" при закрытиивыпадающее подменю пункта навигации

Разметку можно показать подрядчику как образец. Иллюстрация автора по образцу MDN, на вымышленном домене:

<button aria-expanded="false" aria-controls="menu-example">Меню</button>
<nav id="menu-example" hidden>
  <a href="https://example.ru/catalog/">Каталог</a>
</nav>

Фрагмент показывает один атрибут из источника и вопрос для заказчика: меняет ли подрядчик его значение, когда меню открывается и закрывается.

Пример APG сопровождает оговорка, которую стоит знать заказчику. Она стоит в блоке Read This First:

"There may be support gaps in some browser and assistive technology combinations, especially for mobile/touch devices."

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

"Testing code based on this example with assistive technologies is essential before considering use in production systems."

Перевод наш: код на основе этого примера обязательно нужно проверить с вспомогательными технологиями, прежде чем применять его в рабочих системах. Оговорка относится к коду примера. Для заказчика она даёт основание попросить подрядчика показать проверку со вспомогательными технологиями. К ним относятся программы экранного доступа (screen readers): по разделу Key Terms страницы WCAG о критерии 3.2.3, их используют слепые люди, чтобы читать текстовую информацию синтезированной речью или шрифтом Брайля.

WCAG 2.2 (Web Content Accessibility Guidelines) - рекомендации W3C по доступности веб-содержимого. Нормативных актов РФ среди источников статьи нет, и вывод о том, обязательна ли доступность для вашего сайта, здесь не делается. О версии сайта для слабовидящих и о том, кому она обязательна, написано в статье о версии сайта для слабовидящих.

Должно ли меню закрываться клавишей Esc?

Коротко: в примере APG навигации с раскрывающимися списками нажатие Esc закрывает открытый список и возвращает фокус на кнопку, которая его открыла. Tab и Shift+Tab переводят фокус между кнопками и ссылками, Space и Enter переключают список. Пример описывает панель навигации с выпадающими списками, а правил закрытия бургер-меню на этих страницах нет.

Пояснение: фокус - элемент страницы, который выбран сейчас и откликнется на нажатие клавиши. Пример APG описывает поведение кнопок и ссылок:

КлавишаЧто делает в примере APG
Tab, Shift+Tabпереводит фокус между ссылками и кнопками верхнего уровня, а при открытом списке - по ссылкам списка
Space, Enterесли фокус на кнопке раскрытия, активирует её и переключает видимость списка
Escapeесли список открыт, закрывает его и ставит фокус на кнопку, которая этим списком управляет

Страница поясняет закрытие отдельно:

"If a dropdown is open and focus is inside the navigation region, pressing Esc will close the dropdown."

В переводе: если выпадающий список открыт и фокус находится в области навигации, нажатие Esc закроет выпадающий список.

Пример показывает управление клавишами в навигации с кнопками раскрытия. Бургер-меню и экран телефона в нём не названы. Требования закрывать любое меню клавишей Esc страница не формулирует. Поэтому клавиши записывают вопросом подрядчику: открывается ли меню клавишами Space и Enter, закрывается ли оно клавишей Esc, куда после закрытия переходит фокус.

Что решают размер кнопки и порядок пунктов?

Коротко: критерий 2.5.8 WCAG 2.2 называет размер цели для указателя не меньше 24 на 24 CSS-пикселей, с исключениями. Критерий 3.2.3 требует одного относительного порядка у повторяющейся навигации на страницах набора, если изменение не запустил сам посетитель. Учебник WAI о меню добавляет: на разных размерах экрана показанные пункты идут в том же порядке, с теми же формулировками и назначением.

Обе страницы WCAG в этом разделе - пояснения (Understanding) к стандарту; вверху каждой стоит пометка «Informative explanations, not required to meet WCAG» (перевод наш: информативные пояснения, не обязательные для соблюдения WCAG).

Размер. Критерий 2.5.8 WCAG 2.2 (Target Size (Minimum), уровень AA) называет размер цели для указателя не меньше 24 на 24 CSS-пикселей, с исключениями; так написано на странице Understanding Success Criterion 2.5.8: Target Size (Minimum) | WAI | W3C, обновлённой 11 мая 2026 года. Размер областей касания по web.dev разобран в статье о юзабилити сайта.

Порядок. Формулировка критерия 3.2.3 (Consistent Navigation, Level AA):

"Navigational mechanisms that are repeated on multiple web pages within a set of web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user."

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

Та же страница в разделе Key Terms определяет same relative order как "same position relative to other items" (перевод наш: то же положение относительно других элементов). Она добавляет, что порядок считается тем же, даже если другие элементы вставлены или убраны, например, раскрывающееся меню добавляет уровень подробностей. Формулировка критерия задаёт порядок, о составе пунктов в ней не сказано.

О разных размерах экрана пишет учебник WAI «Menu Structure», раздел Responsive design (страница обновлена 13 мая 2024 года):

"Menu structure should be consistent across screen sizes. Some menu items may be collapsed or even hidden in sub navigation menus, but items that show should appear in the same order and with the same wording and destination."

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

Что Google пишет о тех же разделах на телефоне?

Коротко: документация Центра Google Поиска (последнее обновление 2026-02-20 UTC) пишет, что мобильная версия сайта должна содержать те же материалы, что и полная; содержимое можно переместить в аккордеоны или вкладки. Это требование к разработке мобильной версии. Статья не оценивает влияние на позиции в поиске. Страница не упоминает меню, поэтому сравнение разделов меню на телефоне и компьютере - проверка, предложенная в этой статье.

Страница называется «Рекомендации по индексированию с приоритетом мобильного контента». В разделе об оптимизации сайта для мобильных устройств она оговаривает, к каким сайтам относятся её рекомендации, и называет адаптивный дизайн: «Google рекомендует использовать адаптивный дизайн, поскольку с ним проще всего работать.» Оговорка звучит так:

«Рекомендации в этом руководстве применимы только к динамическому показу и разным URL. Если сайт имеет адаптивный дизайн, то в мобильной и полной версиях используется одинаковый контент и метаданные.»

О самой мобильной версии страница пишет:

«Мобильная версия сайта должна содержать те же материалы, что и его полная версия.»

«Вы можете изменить дизайн, чтобы повысить удобство использования сайта (например, переместить контент в аккордеоны или вкладки), но обязательно убедитесь в том, что на мобильном сайте опубликован тот же контент, что и на основном.»

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

Практический вопрос заказчика: есть ли разделы, которые доступны на компьютере и пропали на телефоне. Это проверка, предложенная в статье, по смыслу страницы Google и учебника WAI о показанных пунктах. Как проверить адаптивный сайт целиком, описано в статье об адаптивном сайте.

Что решить до дизайна и спросить у подрядчика?

Коротко: на главной BITSPARK среди шагов работы названы «Структура», «Дизайн» и «Запуск». Ниже восемь вопросов о меню, у каждого указана страница источника. Размер кнопки записан отдельной строкой. Привязка вопросов к шагам - предложение автора статьи: в описании шагов на главной меню не упомянуто.

Главная страница BITSPARK называет шаги по порядку: «Задача», «Структура», «Дизайн», «Разработка», «Запуск». Три из них описаны так:

ШагКак описан на главной
Структура«Собираем архитектуру: сценарии, страницы, контент и логику взаимодействия.»
Дизайн«Формируем характер проекта: типографику, композицию, движение и систему интерфейса.»
Запуск«Проверяем desktop и mobile, скорость, формы и ключевые сценарии - затем запускаем.»

Вопросы к меню удобно записать до дизайна:

  1. Сколько пунктов в меню по структуре и помещаются ли они в видимый ряд на экране телефона? Опора: web.dev, малое число пунктов можно оформить для маленького экрана, при большом числе шаблон не масштабируется.
  2. Рассматривали ли вариант без кнопки: видимое меню или ряд с горизонтальной прокруткой? Опора: web.dev, совет искать стратегию, при которой навигацию не нужно прятать.
  3. Чем подписана кнопка: значком, словом или обоими? Источник: web.dev, кнопка подписана, на значок не рассчитывают; Wix Studio, значок и / или текст.
  4. Как закрывается открытое меню: кнопкой, нажатием вне меню, клавишей Esc? Опора: справка Wix Studio о кнопке «Закрыть» и о нажатии вне контейнера; пример APG об Esc.
  5. Как кнопка сообщает своё состояние программам экранного доступа? Опора: MDN и APG, aria-expanded.
  6. Как меню работает с клавиатуры? Источник: APG, Tab, Space, Enter, Esc, фокус после закрытия.
  7. Одинаковы ли порядок, формулировки и адреса пунктов на всех страницах и на всех размерах экрана? Опора: WCAG 3.2.3, учебник WAI Menu Structure.
  8. Все ли разделы, которые есть на компьютере, доступны на телефоне? Опора: Google, то же содержимое на мобильном сайте; учебник WAI о показанных пунктах.

Размер кнопки записывают отдельной строкой со ссылкой на статью о юзабилити. Что входит в техническое задание, куда можно внести ответы, разобрано в статье о техническом задании на сайт. Пример записи для кофейни example.ru, где в меню пять разделов:

Пунктов в меню: 5 (Каталог, Доставка, О нас, Блог, Контакты)
Меню на телефоне: видимый ряд / ряд с прокруткой / за кнопкой ______; причина ______
Подпись кнопки: ______
Как закрывается меню: ______
Атрибут aria-expanded меняется при открытии и закрытии: да / нет ______
Клавиши: Space, Enter, Esc ______
Порядок, названия и адреса пунктов на всех страницах одинаковы: ______
Разделы на телефоне и на компьютере совпадают: ______
Размер кнопки: ______

Если подрядчик показывает макет, в котором кнопка без подписи, у вас есть вопрос и страница web.dev для разговора. Как смотреть макет-прототип и оставлять замечания к экранам, описано в статье о прототипе сайта.

Что проверить при приёмке на телефоне?

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

Шаг «Запуск» на главной BITSPARK называет проверку desktop и mobile; какие действия войдут в проверку меню, стоит записать в задание. Общий разговор о проверках сайта ведёт статья о тестировании сайта. Для меню на телефоне:

  1. Найдите кнопку на главной и на внутренней странице. Проверьте, есть ли рядом со значком слово. Опора: web.dev, подпись кнопки.
  2. Нажмите на кнопку и убедитесь, что меню открылось. Посчитайте нажатия до нужной страницы: web.dev называет два шага, открыть меню и выбрать пункт.
  3. Закройте меню каждым способом, который назвал подрядчик: кнопкой закрытия, нажатием вне меню, клавишей Esc. Источник: справка Wix Studio и пример APG.
  4. Откройте меню на трёх разных страницах. Порядок пунктов, названия и адреса должны совпасть. Опора: WCAG 3.2.3 и WAI Menu Structure.
  5. Сравните список разделов в меню на телефоне и на компьютере. Опора: Google, то же содержимое на мобильном сайте.
  6. Попросите показать, как меню работает с клавиатуры: Tab, Space, Enter, Esc. Источник: APG.
  7. Если меню скрыто за кнопкой, попросите результат проверки с программой экранного доступа и показать значение aria-expanded при открытом и закрытом меню. Опора: MDN, APG и оговорка APG о тестировании.
  8. Нажмите на кнопку пальцем несколько раз и отметьте промахи. Размер кнопок и областей касания разобран в статье о юзабилити сайта.

Источники

Даты: все страницы открыты 21.10.2026.

Обсудить проект в Telegram: t.me/billioniks

Читайте по теме

Все статьи раздела «Дизайн и элементы сайта» →