Представьте покупателя, который не пользуется мышью: он ходит по сайту клавиатурой или слушает его через экранный диктор. Он доходит до каталога, хочет отфильтровать товары — и упирается в стену: по фильтру нельзя пройти с клавиатуры, а выпадающее меню открывается только при наведении мыши, которого у него нет. Для него ваш магазин просто не работает, и он уходит, не оставив следа в аналитике.
Эта статья — о доступности (a11y) двух самых проблемных элементов магазина на 1С-Битрикс: умного фильтра и выпадающих меню. Разберём, как сделать их управляемыми с клавиатуры, понятными экранным дикторам и удобными на мобильных — не жертвуя скоростью каталога. Если фильтр заодно нужно ускорить и привести в порядок на уровне данных, помогает аудит и оптимизация 1С и всей связки каталога.
Коротко
- Доступность — это удобство для всех: клавиатура, скринридеры, увеличение, ограничения моторики и зрения.
- Фильтры и меню чаще всего недоступны, потому что сделаны на JS без семантики и без учёта клавиатуры.
- Основа — нативные HTML-элементы, управление с клавиатуры, видимый фокус и объявление изменений для дикторов.
- Доступность не конфликтует со скоростью: она про семантику, а не про тяжёлый код, и часто улучшает UX для всех.
Почему доступность — это про деньги
Доступность часто воспринимают как «дополнительную опцию для меньшинства», и это дорогая ошибка. Люди, которым нужен доступный интерфейс, — это заметная доля аудитории, и каждый из них такой же покупатель с деньгами. Недоступный сайт просто отсекает их от покупки, а вы даже не видите этих потерь в отчётах — ушедший клиент не оставляет следов.
Но выгода шире. Доступный интерфейс удобнее вообще всем: понятный фокус помогает тем, кто пользуется клавиатурой для скорости; крупные зоны нажатия удобны на мобильных; чистая семантика снижает путаницу. Плюс семантически аккуратная вёрстка обычно лучше понимается поисковыми роботами, так что доступность работает и на SEO. Это инвестиция в аудиторию и конверсию, а не благотворительность.
Кто и как пользуется сайтом иначе
Чтобы делать доступно, полезно представлять реальных пользователей, а не абстрактные требования. Способов взаимодействия с сайтом больше, чем «мышь и глаза».
- Только клавиатура. Человек не пользуется мышью и перемещается по Tab, стрелкам, Enter и Esc.
- Экранный диктор. Незрячий пользователь слушает озвучку интерфейса и полагается на семантику.
- Увеличение. Слабовидящий увеличивает страницу, и вёрстка должна не разваливаться.
- Ограничения моторики. Человеку трудно точно попадать в мелкие цели, важны крупные зоны нажатия.
- Ситуативные ограничения. Яркое солнце, одна рука, шум — временно каждый оказывается в «особых» условиях.
Последний пункт особенно важен: доступность помогает не только людям с постоянными ограничениями, но и обычным покупателям в неудобных ситуациях. Это делает её универсально полезной.
Почему меню и фильтры ломаются
Из всех элементов магазина выпадающие меню и умный фильтр — самые уязвимые к проблемам доступности, и не случайно. Это сложные интерактивные компоненты, которые часто собирают на «голом» JavaScript, думая о внешнем виде и забывая о семантике и клавиатуре.
| Проблема | Кого отсекает | Решение |
|---|---|---|
| Меню только по наведению | Клавиатуру и мобильных | Открытие по нажатию/фокусу |
| Фильтр без клавиатуры | Всех без мыши | Нативные чекбоксы, обход Tab |
| Невидимый фокус | Клавиатурных пользователей | Явный стиль фокуса |
| Молчащие изменения | Экранные дикторы | Объявление обновления результатов |
| Мелкие цели | Моторику и мобильных | Крупные зоны нажатия |
Общий корень всех этих бед — отказ от нативных HTML-элементов в пользу «див с обработчиком клика». Нативная кнопка, ссылка и чекбокс уже доступны из коробки; их замена на стилизованные div-ы — это и есть источник большинства проблем. Если фильтр или меню собраны как отдельный кастомный компонент, доступность закладывают в него с самого начала — как устроена такая разработка, мы разбираем в статье про разработку модуля для 1С-Битрикс.
Управление с клавиатуры
Базовый тест доступности — пройти по элементу только с клавиатуры. Если фильтр и меню полностью управляемы без мыши, половина работы уже сделана. Ожидаемое поведение хорошо знакомо пользователям и предсказуемо.
- Tab. Перемещает фокус между интерактивными элементами в логичном порядке.
- Enter / Пробел. Активирует кнопку, ссылку, отмечает чекбокс фильтра.
- Стрелки. Перемещают внутри сложного компонента — по пунктам меню или опциям.
- Esc. Закрывает открытое меню или мобильную панель фильтра и возвращает фокус.
Ключевое — использовать нативные фокусируемые элементы. Кнопка получает фокус и реагирует на Enter сама; div — нет, и его приходится «чинить» атрибутами и обработчиками, что легко сделать неправильно. Поэтому правило простое: сначала нативный HTML, и лишь потом, при нехватке, доработка.
Видимый фокус и порядок обхода
Клавиатурному пользователю жизненно важно видеть, где он находится. Видимый фокус — это визуальная рамка или подсветка на активном элементе, и убирать её (частая «косметическая» правка ради красоты) — значит ослеплять пользователя, который ходит по Tab.
Не менее важен порядок обхода: фокус должен двигаться по странице логично — сверху вниз, слева направо, в порядке смысла, а не хаотично прыгать из-за особенностей вёрстки. В фильтре это означает, что Tab последовательно проходит по группам свойств и опциям, а в меню — по пунктам. Когда открывается мобильная панель фильтра или подменю, фокус должен переходить внутрь неё, а при закрытии — возвращаться на кнопку, которая её открыла. Такое управление фокусом — основа предсказуемого поведения.
Скринридеры и семантика
Экранный диктор «видит» страницу через семантику: он озвучивает роль элемента (кнопка, ссылка, флажок), его состояние и текст. Если вместо кнопки стоит div, диктор не понимает, что это кнопка, и пользователь остаётся в неведении. Поэтому доступность для дикторов начинается с правильной семантической разметки.
В контексте фильтра и меню это значит: заголовки групп свойств — настоящие заголовки, опции — настоящие чекбоксы или ссылки, кнопки — кнопки. Тогда диктор внятно объявляет «флажок, Красный, не отмечен» и пользователь понимает, что делает. А главное — при обновлении результатов фильтра диктор должен сообщить об изменении, иначе незрячий покупатель не узнает, что выдача поменялась. Это делается пометкой области результатов как динамически обновляемой.
ARIA без перегибов
ARIA — набор атрибутов, добавляющих информацию для вспомогательных технологий там, где не хватает обычного HTML. Это мощный инструмент, но с ним легко переусердствовать, и тогда становится хуже, чем без него.
Главное правило доступности так и звучит: первое правило ARIA — не использовать ARIA, если есть нативный HTML-элемент. Нативная кнопка лучше, чем div с ролью кнопки. ARIA уместна для того, чего в HTML нет: сообщить состояние развёрнутости у кнопки-раскрытия меню, связать панель фильтра с открывающей кнопкой, пометить область результатов как живую. Избыточные и неверные ARIA-атрибуты (роли поверх нативных элементов, ложные состояния) сбивают дикторы и вредят. Поэтому ARIA применяют точечно и осознанно, а не «для надёжности везде».
Выпадающие меню правильно
Выпадающее меню каталога — классический источник проблем, потому что его часто делают открывающимся только по наведению мыши. На клавиатуре и на мобильном такого наведения нет, и меню становится недоступным. Правильное меню устроено иначе.
- Кнопка-триггер. Раскрытие — это нативная кнопка с указанным состоянием развёрнутости, а не просто наведение.
- Открытие по действию. Меню открывается по нажатию/активации, работает и мышью, и клавиатурой, и на тач-экране.
- Навигация внутри. По пунктам можно ходить стрелками, активировать Enter.
- Закрытие по Esc. Меню закрывается, фокус возвращается на кнопку-триггер.
- Управление фокусом. При открытии фокус уходит внутрь меню, при закрытии — обратно.
Такое меню одинаково удобно всем: мышью — по клику, клавиатурой — по Tab и стрелкам, на телефоне — по нажатию. Отказ от «только hover» решает большинство проблем разом.
Умный фильтр 1С-Битрикс и a11y
Умный фильтр (компонент catalog.smart.filter) — сердце каталога, и его доступность особенно важна, потому что без фильтра выбрать товар в большом ассортименте почти невозможно. Хорошая новость: доступность фильтра не конфликтует с его скоростью — это независимые задачи.
Скорость фильтра на 1С-Битрикс обеспечивают фасетный индекс и кэш, а доступность — семантика и клавиатура. Опции фильтра делают нативными чекбоксами с понятными подписями, группы свойств — с заголовками, применение фильтра — доступным с клавиатуры, а область результатов помечают так, чтобы диктор объявлял обновление. Всё это никак не мешает фасетному индексу работать быстро. Как устроена быстрая выборка под капотом фильтра, мы разбираем в статье про D7 ORM в 1С-Битрикс, а порядок в данных и обмене помогает навести автоматизация на 1С.
Мобильные жесты и зоны нажатия
На мобильных доступность имеет свою специфику. Наведения мышью здесь нет вовсе, поэтому любое «только по hover» на телефоне не работает по определению — меню и фильтр обязаны открываться по нажатию. Экранные дикторы на смартфонах управляются жестами, и логика фокуса и семантики остаётся такой же важной.
Отдельно критичны зоны нажатия: на маленьком экране мелкие опции фильтра и пункты меню, расположенные вплотную, трудны для всех, а для людей с ограничениями моторики — непреодолимы. Достаточный размер целей и отступы между ними решают проблему сразу для широкой аудитории. Как заметно, доступные решения на мобильных совпадают с обычными улучшениями UX — крупные кнопки, открытие по нажатию, понятное поведение полезны каждому покупателю.
Как тестировать
Доступность нельзя «сделать и забыть» — её проверяют, причём в основном руками. Автоматические инструменты полезны, но ловят лишь часть проблем; ключевые сценарии тестируют вживую.
- Клавиатурный проход. Пройдите меню и фильтр только с клавиатуры, без мыши: всё ли доступно, виден ли фокус.
- Экранный диктор. Включите диктор и послушайте, понятно ли, что за элемент в фокусе и что происходит.
- Увеличение. Увеличьте страницу и проверьте, что вёрстка не разваливается.
- Автопроверка. Прогоните автоматический аудит доступности, чтобы поймать очевидное.
- Мобильный тест. Проверьте открытие по нажатию, размеры целей и работу диктора на телефоне.
Такой набор проверок вскрывает подавляющее большинство проблем. Начинать стоит с клавиатурного прохода — он быстрый и сразу показывает, доступны ли фильтр и меню в принципе.
Частые ошибки
- Меню только по hover. Раскрытие по наведению мыши недоступно с клавиатуры и на мобильных.
- Div вместо кнопки. Стилизованные div-ы вместо нативных элементов теряют доступность из коробки.
- Убрали фокус. Ради красоты сняли видимую рамку фокуса — клавиатурный пользователь ослеп.
- Молчащий фильтр. Результаты обновились, но диктор об этом не сообщил.
- ARIA поверх всего. Избыточные атрибуты и роли поверх нативных элементов сбивают дикторы.
- Мелкие цели. Опции фильтра и пункты меню слишком малы и близки для пальца.
- Проверяют только автоматом. Полагаются на инструмент и не тестируют вживую клавиатурой и диктором.
Чек-лист доступности
- Нативная семантика. Кнопки — кнопки, ссылки — ссылки, опции фильтра — чекбоксы.
- Клавиатура работает. Меню и фильтр полностью управляемы через Tab, стрелки, Enter, Esc.
- Фокус виден. Активный элемент явно подсвечен, порядок обхода логичен.
- Диктор понимает. Роли и состояния озвучиваются, обновление результатов объявляется.
- ARIA точечно. Атрибуты добавлены только там, где не хватает HTML, без перегибов.
- Мобильный порядок. Открытие по нажатию, крупные зоны нажатия, работа диктора на телефоне.
- Протестировано вживую. Пройдено клавиатурой и диктором, а не только автопроверкой.
Вывод
Доступность фильтров и меню — это не благотворительность и не формальность, а работа на аудиторию и конверсию. Недоступный фильтр или меню, открывающееся только по наведению мыши, молча отсекают часть покупателей, которых вы даже не видите в отчётах. А доступный интерфейс удобнее вообще всем и заодно чище для поисковых роботов.
Рецепт понятен и не требует переписывать сайт: опираться на нативный HTML, обеспечить управление с клавиатуры и видимый фокус, дать дикторам понятную семантику, применять ARIA точечно и тестировать вживую. Важно, что доступность не спорит со скоростью умного фильтра 1С-Битрикс — фасетный индекс и кэш отвечают за быстроту, семантика за доступность, и вместе они дают каталог, который работает для каждого покупателя.
