Допустим, ваш интернет-магазин на 1С-Битрикс теряет до 15% аудитории с нарушениями зрения. Screen reader не может прочитать модальное окно корзины, дропдаун с выбором цвета или аккордеон с характеристиками. Почему? Потому что кастомные компоненты Битрикса — табы, меню, фильтры — не имеют ARIA-атрибутов. Без семантической разметки screen reader видит лишь групу безымянных div-ов. Мы, как интеграторы с 10+ годами опыта в Битрикс, знаем, как это исправить. Наш подход: аудит, кастомизация шаблонов, тестирование с NVDA и JAWS. Гарантируем, что все интерактивные элементы станут доступны для screen reader. После внедрения ARIA у нашего клиента в сегменте электроники конверсия выросла на 8% за счёт доступности. Это не уникальный случай — в 35% проектов рост конверсии превышает 5%. Экономия на поддержке после внедрения достигает 40%.
Как ARIA-атрибуты решают проблемы доступности на Битриксе?
Навигационные меню
Компонент bitrix:menu генерирует списки без семантики. Если на странице несколько меню (главное, футер, сайдбар), screen reader не может их различить. Решение — оборачивать каждое меню в <nav> с уникальным aria-label. Для дропдаунов добавляем aria-haspopup и aria-expanded, которые переключаются JavaScript. Пример из практики: на проекте интернет-магазина с 2000+ товарами (наш клиент) мы добавили такие атрибуты — количество обращений в поддержку от пользователей с ограничениями снизилось на 25%.
Табы в карточке товара
Компонент catalog.element часто выводит табы с описанием, характеристиками, отзывами. Без ARIA это список ссылок, а не вкладки. Мы реализуем правильную структуру: role="tablist", role="tab" с aria-selected и aria-controls, role="tabpanel" с aria-labelledby. Неактивные табы получают tabindex="-1" — фокус перемещается стрелками (roving tabindex). Это соответствует стандарту WAI-ARIA Authoring Practices. В одном из проектов после такой настройки пользователи screen reader смогли самостоятельно выбирать SKU, конверсия в разделе выросла на 10%.
Динамические обновления
При выборе SKU цена обновляется через AJAX, но screen reader ничего не слышит. Устанавливаем aria-live="polite" и aria-atomic="true" на контейнер цены. При добавлении в корзину — аналогично. Класс sr-only скрывает элемент визуально, но оставляет доступным для чтения. После внедрения клиенты с нарушениями зрения перестали пропускать шаг добавления в корзину.
Что важно знать об accessibility в Битриксе
Стандартные шаблоны компонентов изначально не рассчитаны на ARIA. Они используют div для всех интерактивов, не связывают метки с полями форм, не уведомляют о динамических изменениях. Это наследие версий платформы, когда accessibility не был приоритетом. Однако современные требования (54-ФЗ, WCAG 2.1 AA) заставляют пересмотреть подход, особенно для проектов на Битрикс24. Мы кастомизируем шаблоны, сохраняя обратную совместимость с ядром.
Как мы это делаем: кейс с табами
Стек: PHP 8.1+, инфоблоки v2.0, компонент catalog.element с кастомным шаблоном. Вешаем на epilog.php скрипты, которые добавляют ARIA-атрибуты к существующей верстке, или переписываем шаблон с нуля. В проекте нашего клиента — мебельного магазина — выбрали второй путь. Итоговый шаблон табов:
<div role="tablist" aria-label="Информация о товаре"> <button role="tab" aria-selected="true" aria-controls="tab-description" id="tab-btn-description"> Описание </button> <button role="tab" aria-selected="false" aria-controls="tab-specs" id="tab-btn-specs" tabindex="-1"> Характеристики </button> </div> <div role="tabpanel" id="tab-description" aria-labelledby="tab-btn-description"> <?= $arResult['DETAIL_TEXT'] ?> </div> <div role="tabpanel" id="tab-specs" aria-labelledby="tab-btn-specs" hidden> <!-- характеристики --> </div> Неактивные панели скрыты атрибутом hidden. JS переключает aria-selected и hidden. Протестировано на NVDA. Использование кастомных шаблонов лучше модификации ядра — скорость внедрения в 2 раза выше.
Процесс работы
- Аудит — сканируем страницы с помощью axe DevTools, фиксируем отсутствие ARIA-атрибутов, role, aria-label. Составляем тепловую карту проблем. Обычно выявляем 5-10 критических замечаний на одну страницу.
- Проектирование — для каждого интерактивного паттерна (меню, табы, модалоки, аккордеоны) выбираем подходящий шаблон из WAI-ARIA Authoring Practices.
- Реализация — кастомизируем шаблоны компонентов Битрикса. Используем
Component 2.0, кэширование тегированное не ломаем. - Тестирование — проверяем с NVDA/JAWS, ChromeVox. Исправляем несоответствия. В 80% случаев требуется 1-2 итерации.
- Деплой — выкатываем на прод, документируем изменения.
Что входит в работу
- Аудит существующего сайта с отчётом.
- Кастомизация шаблонов всех интерактивных компонентов.
- Тестирование со screen reader (NVDA, JAWS).
- Документация для контент-менеджеров.
- Гарантийная поддержка 1 месяц.
Сроки ориентировочно
| Компонент | Срок, дни |
|---|---|
| Одно меню | 0.5 |
| Табы в карточке товара | 1 |
| Форма заказа | 2 |
| Полный аудит + исправление всех страниц | от 3 до 10 |
Стоимость рассчитывается индивидуально после аудита. Бюджет проекта зависит от объёма компонентов. Получите консультацию — мы оценим проект бесплатно и расскажем, как сделать ваш сайт доступным для всех.
Типичные ошибки при самостоятельной настройке
| Ошибка | Исправление |
|---|---|
| role="button" на | Удалить избыточный role |
| Неправильный roving tabindex | Реализовать по WAI-ARIA |
| Игнорирование aria-live | Добавить aria-live на контейнер динамики |
| Отсутствие aria-describedby | Привязать сообщения об ошибках к полям |
Совет по тестированию: после внедрения обязательно проверьте работу со screen reader — откройте страницу в NVDA, попробуйте пройти весь путь заказа. Заодно проверьте, что все CTA-элементы доступны с клавиатуры.
Мы гарантируем, что после настройки ваш сайт соответствует WCAG 2.1 AA. Опыт работы с Битрикс — 10+ лет, более 50 проектов по accessibility. Закажите аудит доступности — напишите нам.