Доступность (accessibility) интернет-магазина на 1С-Битрикс

Представьте покупателя, который не видит экран и «читает» ваш магазин голосом программы-скринридера. Или человека с травмой руки, который не может пользоваться мышью и ходит по сайту одной клавишей Tab. Или пожилого посетителя, которому мелкий светло-серый шрифт на белом фоне попросту не разобрать. Все они хотят купить у вас товар — и все они уйдут, если кнопка «В корзину» сделана из безымянного div, у картинок нет описаний, а по форме заказа невозможно пройти с клавиатуры. Доступность сайта (accessibility, коротко a11y) — это не благотворительность и не «галочка для отчёта», а свойство магазина, которое расширяет аудиторию и одновременно улучшает удобство для всех.

В этой статье разберём по-инженерному, из чего складывается доступный интернет-магазин на 1С-Битрикс: что такое веб-доступность и стандарт WCAG (обзорно, с уровнями A и AA), кому и зачем это нужно, как устроены семантическая вёрстка и ARIA-роли, навигация с клавиатуры (фокус, порядок обхода, skip-link), контраст и размер шрифта, alt-тексты и подписи полей, доступные формы, модалки, меню, карусели и умный фильтр, что такое «версия для слабовидящих» и в чём её ограничения, как всё это ложится на компоненты Битрикса и кастом, и как это тестировать скринридером, клавиатурой и автоаудитом. Материал основан на нашей практике оптимизации конверсии (CRO) и разработки интернет-магазинов на 1С-Битрикс — без выдуманных «процентов роста», зато с рабочими принципами.

Что такое веб-доступность (a11y) и почему это не «для галочки»

Веб-доступность (accessibility) — это свойство сайта, при котором им может полноценно пользоваться максимально широкий круг людей, в том числе те, у кого есть постоянные, временные или ситуативные ограничения. Сокращение a11y — это то же слово «accessibility», где 11 символов между первой буквой «a» и последней «y»; так же образованы i18n (internationalization) и l10n (localization). За модным сокращением стоят очень конкретные вещи: сможет ли незрячий человек со скринридером купить товар, дойдёт ли до конца заказа человек, у которого нет мыши, прочитает ли подписи слабовидящий.

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

• Скринридер — программа, которая озвучивает содержимое страницы голосом или выводит на брайлевский дисплей. Она «видит» не картинку, а разметку: заголовки, ссылки, кнопки, подписи, тексты альтернатив.
• Только клавиатура — человек перемещается по интерактивным элементам клавишей Tab, нажимает Enter и пробел, ходит по спискам стрелками. Мыши у него нет вовсе.
• Экранная лупа и увеличение — сильное масштабирование страницы, при котором вёрстка не должна ломаться и обрезать контент.
• Голосовое управление — команды голосом, которым нужны понятные, видимые названия элементов.

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

Кому важна доступность: не только незрячие

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

• Нарушения зрения. Полная слепота (скринридер), слабовидение (нужен крупный шрифт и высокий контраст), нарушения цветовосприятия (нельзя кодировать смысл только цветом — например, «красное — нет в наличии» без подписи).
• Нарушения слуха. Для магазина это в первую очередь субтитры и текстовые расшифровки к видеообзорам товаров: если весь смысл ролика только в звуке, часть покупателей его не получит.
• Нарушения моторики. Людям, которым тяжело точно попадать мышью или которые пользуются только клавиатурой либо специальными устройствами ввода, критична работа сайта без мыши и крупные зоны нажатия.
• Когнитивные особенности. Простой язык, предсказуемое поведение интерфейса, понятные ошибки и отсутствие резких неожиданных изменений помогают тем, кому сложно удерживать внимание или разбирать сложные конструкции.
• Пожилые покупатели. С возрастом хуже видно, точность движений снижается, реакция замедляется — здесь работают ровно те же меры: контраст, крупный шрифт, крупные кнопки, понятные подписи.

А теперь про ситуативные ограничения, которые случаются с каждым. Яркое солнце на экране телефона на улице — временное «слабовидение». Сломанная или севшая мышь — временная «только клавиатура». Шумный вагон метро без наушников — временная «глухота» к видео. Рука занята пакетами, и телефон в другой руке — временная «моторная» проблема. Получается, что улучшения ради людей с инвалидностью помогают и абсолютно всем в неудобных условиях. Именно поэтому доступность часто называют частным случаем хорошего UX, а не отдельной от него темой.

Зачем доступность бизнесу: аудитория, SEO, требования

У доступности есть не только этическая, но и вполне деловая сторона. Разложим по пунктам, что именно она даёт магазину.

Шире аудитория и меньше потерь в воронке

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

Связь с SEO

Поисковый робот в некотором смысле — это «слепой пользователь»: он не видит картинку и не воспринимает интерфейс «на глаз», а опирается на разметку. Поэтому многое из доступности напрямую полезно для SEO: одна корректная структура заголовков, осмысленные alt у изображений, текстовые ссылки с понятными формулировками, подписи полей, семантические теги. Работая над доступностью, вы попутно приводите в порядок семантику, а это фундамент технического SEO. Подробнее пересечение мы разбираем в материале про технический SEO-аудит магазина на 1С-Битрикс.

Требования и репутация

Для части сайтов доступность — не пожелание, а требование. Государственные, образовательные, медицинские и другие социально значимые ресурсы во многих странах обязаны соответствовать определённому уровню доступности, и «версия для слабовидящих» с базовым a11y там нередко обязательна. Коммерческому магазину стоит проверять применимость таких норм к своему случаю по актуальным нормативам, а не полагаться на слухи. Но даже там, где формальных требований нет, доступность — это про зрелость продукта и репутацию: недоступный сайт легко становится поводом для публичной критики.

WCAG обзорно: четыре принципа и уровни A/AA/AAA

Главный ориентир в доступности — WCAG (Web Content Accessibility Guidelines), международные рекомендации по доступности веб-контента. Это не закон и не набор «хитростей», а структурированный свод критериев, по которым можно проверить сайт и понять, что улучшить. Знать WCAG наизусть не нужно, но полезно понимать его логику — четыре принципа и три уровня.

Четыре принципа

WCAG держится на четырёх принципах, которые удобно запомнить по первым буквам (POUR в оригинале): контент должен быть воспринимаемым, управляемым, понятным и надёжным.

Три уровня соответствия

Каждый критерий WCAG отнесён к одному из трёх уровней:

• A — базовый минимум. Без него контент часто вообще недоступен части людей (например, картинка-ссылка без текстовой альтернативы).
• AA — практический стандарт. Именно на него ориентируется большинство сайтов и на него ссылаются требования во многих странах. Сюда входят контраст текста, работа с клавиатуры, подписи, предсказуемость.
• AAA — самый строгий уровень. Достижим не для всего контента и обычно внедряется точечно, а не сплошь.

Для коммерческого интернет-магазина разумная цель — уровень AA. Практичный путь: сначала закрыть критерии уровня A (без них совсем плохо), затем последовательно довести до AA, а отдельные требования AAA внедрять там, где это уместно и не мешает бизнес-логике. Важно понимать, что WCAG — это про смысл, а не про «зелёные галочки» инструмента: автоматический аудит проверяет лишь часть критериев, остальное требует ручной проверки клавиатурой и скринридером.

Семантическая вёрстка: теги вместо div-супа

Самый дешёвый и самый мощный инструмент доступности — семантическая вёрстка, то есть использование HTML-тегов по их смыслу. Заголовок — это <h1>…<h6>, кнопка — <button>, ссылка — <a href>, список — <ul>/<ol>, навигация — <nav>, основное содержимое — <main>, таблица данных — <table> с <th>. Каждый такой тег несёт встроенный смысл, который скринридер объявляет пользователю, а браузер обрабатывает правильным поведением.

Противоположность этому — «div-суп»: страница, целиком собранная из <div> и <span> с классами. Визуально она может выглядеть идеально, но для скринридера это плоский поток безликого текста без заголовков, кнопок и ориентиров. Разница особенно наглядна на кнопке и ссылке.

Практические правила семантики для магазина:

• Один h1 на странице и логичная иерархия h2–h3 без «перепрыгивания» уровней. По заголовкам скринридер строит оглавление, а поисковик — структуру.
• Кнопки — это button, ссылки — a href. Действие (добавить в корзину, открыть модалку) — button; переход на другой URL — a. Не наоборот.
• Списки — списками. Каталог, меню, характеристики — это ul/ol, а не набор div. Скринридер объявит «список из N пунктов».
• Ориентиры страницы. header, nav, main, footer дают пользователю скринридера быстрые «прыжки» по областям страницы.
• Таблицы данных — table с заголовками. Сравнение характеристик, тарифы, размерные сетки — настоящая таблица с th, а не сетка из div.

Семантика — это тот случай, когда «сделать правильно» не дороже, чем «сделать как попало»: button писать не сложнее, чем div class="btn". Просто первое доступно всем, а второе — только тем, у кого есть мышь.

ARIA-роли и атрибуты: когда нужны, а когда вредят

ARIA (Accessible Rich Internet Applications) — набор специальных атрибутов (role, aria-label, aria-expanded, aria-hidden и других), которые добавляют разметке смысл для вспомогательных технологий там, где обычного HTML не хватает. ARIA умеет объявлять роль элемента («это диалог», «это вкладка»), его состояние («раскрыто/свёрнуто», «выбрано») и связи между элементами. Это мощный инструмент — но с важной оговоркой.

Главное правило ARIA формулируют так: «первое правило ARIA — не использовать ARIA». Звучит парадоксально, но смысл прост: если задачу решает нативный HTML-тег, надо брать его, а не имитировать поведение через ARIA на div. Нативный button уже «кнопка» и работает с клавиатурой; писать <div role="button"> и вручную добавлять обработку клавиш — лишний труд и источник ошибок. ARIA нужна там, где нативных средств действительно нет: сложные виджеты вроде модальных окон, вкладок, аккордеонов, «умных» выпадающих меню и каруселей.

Где ARIA в магазине уместна и полезна:

• Иконки-кнопки без текста. Кнопка-корзина или кнопка-лупа без подписи получают aria-label="Корзина" / aria-label="Поиск", иначе скринридер объявит «кнопка» без пояснения.
• Состояние раскрытия. Бургер-меню, аккордеон характеристик, фильтр-шторка используют aria-expanded="true/false", чтобы сообщать, открыт элемент или закрыт.
• Модальные окна. Диалог помечают role="dialog" и aria-modal="true", связывают с заголовком через aria-labelledby.
• Декоративные элементы. Чисто оформительские иконки и картинки скрывают от скринридера через aria-hidden="true", чтобы не засорять озвучку.
• Динамические сообщения. «Товар добавлен в корзину», счётчик найденного в фильтре — области aria-live, которые скринридер озвучит без перезагрузки.

Навигация с клавиатуры: фокус, порядок, skip-link

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

Как это устроено:

• Tab перемещает фокус на следующий интерактивный элемент (ссылку, кнопку, поле), Shift+Tab — на предыдущий.
• Enter активирует ссылку и кнопку, пробел нажимает кнопку и переключает чекбоксы.
• Стрелки перемещают внутри составных элементов: радиокнопок, вкладок, выпадающих списков.
• Esc закрывает модальные окна и выпадающие панели.

Чтобы это работало, все интерактивные элементы должны быть настоящими интерактивными тегами (см. раздел про семантику): нативные a, button, input попадают в порядок обхода автоматически. Как только кнопку делают из div, она выпадает из клавиатурной навигации — на ней нельзя остановиться клавишей Tab, а значит, и нажать её без мыши невозможно.

Skip-link — ссылка «к содержимому»

На каждой странице магазина сверху десятки ссылок: логотип, меню, разделы каталога, поиск, корзина. Пользователю клавиатуры пришлось бы «протабать» их все на каждой странице, чтобы добраться до товаров. Решение — skip-link: скрытая ссылка «Перейти к содержимому», которая появляется при фокусе первой же клавишей Tab и переносит фокус сразу к основному содержимому (main). Это стандартный приём, который сильно облегчает навигацию и почти ничего не стоит в реализации.

Видимый фокус и логичный порядок обхода

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

Не убирайте обводку фокуса

Браузер по умолчанию рисует вокруг элемента под фокусом рамку или подсветку. Это ориентир пользователя клавиатуры: «я сейчас здесь». Дизайнерам она порой кажется лишней, и в CSS появляется печально известное outline: none — после чего по сайту невозможно ходить с клавиатуры, потому что не видно, где ты. Правильный подход — не убирать фокус, а оформить его под стиль сайта: заметная рамка, подсветка, изменение фона. Современные браузеры умеют показывать фокус только при навигации с клавиатуры (через :focus-visible), не мешая тем, кто кликает мышью, — это удобный компромисс.

Порядок обхода должен совпадать со смыслом

Фокус должен переходить по элементам в логичном порядке: сверху вниз, слева направо, как читается страница. Обычно это обеспечивается порядком элементов в HTML. Проблемы начинаются, когда визуальный порядок расходится с порядком в коде (элемент переставлен стилями) или когда в вёрстку добавляют tabindex с положительными числами, пытаясь «управлять» обходом вручную, — почти всегда это ломает естественный порядок. Правило простое: держите логичный порядок в разметке, используйте tabindex="0" только чтобы включить в обход нестандартный элемент и tabindex="-1" чтобы программно ставить фокус (например, в модалке), и избегайте положительных значений tabindex.

Не создавайте ловушек фокуса

«Ловушка фокуса» — ситуация, когда фокус попал в элемент и не может из него выйти клавиатурой (частая беда самодельных модалок и виджетов). Внутри модального окна фокус, наоборот, полезно временно «запереть» (пока оно открыто, Tab ходит только по нему), но с обязательным выходом по Esc и возвратом фокуса на кнопку, которая окно открыла. А вот на обычной странице никаких ловушек быть не должно: из любого элемента фокус должен свободно двигаться дальше.

Контраст текста и размер шрифта

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

WCAG задаёт конкретные ориентиры по контрасту для уровня AA:

Ещё несколько правил, тесно связанных с контрастом и шрифтом:

• Не кодируйте смысл только цветом. «Красное — нет в наличии, зелёное — есть» без подписи или значка недоступно людям с нарушением цветовосприятия. Добавляйте текст или иконку рядом с цветом.
• Разрешайте масштабирование. Не запрещайте зум на мобильном (user-scalable=no — антипаттерн) и следите, чтобы при увеличении текста до 200% вёрстка не ломалась и контент не обрезался.
• Задавайте размеры в относительных единицах. Шрифт в rem/em уважает настройки пользователя, который увеличил базовый размер в браузере, а жёсткие пиксели — нет.
• Комфортный базовый размер. Для основного текста магазина мелкий шрифт — плохая идея; крупнее и «воздушнее» почти всегда читается лучше, особенно на телефоне и для пожилых.

Проверяют контраст не на глаз, а инструментами: контраст-чекерами и автоаудитами (Lighthouse, axe), которые считают соотношение точно. Глаз дизайнера на хорошем откалиброванном мониторе — плохой судья: то, что ему кажется «нормальным серым», на бюджетном телефоне под солнцем исчезает.

Alt для изображений и текстовые альтернативы

Скринридер не видит картинку — он читает её alt (текстовую альтернативу из атрибута alt). В интернет-магазине изображений очень много: фото товаров, баннеры, иконки, логотипы, схемы. Правильные alt-тексты делают их доступными и попутно помогают SEO (поисковик тоже «читает» alt).

Как писать alt в магазине:

• Информативные изображения (фото товара) — alt описывает, что на картинке, по сути: «Смеситель для кухни, хромированный, с выдвижным изливом». Для карточки логично собирать alt из названия и ключевых свойств товара.
• Декоративные изображения (узоры, разделители, фоновые картинки) — пустой alt="". Тогда скринридер их пропустит и не будет засорять озвучку. Пустой alt — это осознанный выбор «здесь нет смысла», а не забытый атрибут.
• Функциональные изображения (картинка внутри ссылки или кнопки) — alt описывает действие, а не картинку: у иконки-корзины в ссылке alt «Перейти в корзину», а не «изображение тележки».
• Текст на картинке — по возможности не выносите важный текст (цену, условия акции) в изображение. Если пришлось — продублируйте его в alt, иначе для скринридера и поиска этого текста не существует.
• Не «фото», не «картинка». Слова «изображение», «фото» в alt лишние — скринридер и так объявляет, что это графика. Пишите суть.

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

Доступные формы и подписи полей

Формы — сердце магазина: поиск, фильтр, добавление в корзину, регистрация, а главное — оформление заказа. Недоступная форма означает, что человек не может купить, даже если очень хочет. Основа доступной формы — правильные подписи (label).

Ключевые правила доступных форм:

• У каждого поля — связанный label. Подпись должна быть программно привязана к полю (через for/id или обёртку), чтобы скринридер объявил «Телефон, поле ввода», а не просто «поле ввода». Клик по подписи при этом ставит фокус в поле — удобно всем.
• Плейсхолдер — не замена подписи. Серый текст-подсказка внутри поля исчезает при вводе, часто имеет низкий контраст и не читается частью скринридеров как подпись. Подпись должна быть отдельной и видимой.
• Правильные типы полей. type="tel", type="email", type="number" дают верную клавиатуру на телефоне и подсказывают браузеру формат. Это и доступность, и удобство ввода.
• Автозаполнение. Атрибут autocomplete (имя, телефон, адрес) позволяет браузеру подставить данные — огромная помощь тем, кому тяжело печатать.
• Обязательные поля помечены явно. Не только звёздочкой-цветом, но и текстом/атрибутом required, чтобы скринридер сообщил, что поле обязательное.
• Группы полей. Радиокнопки способа доставки или оплаты объединяют в fieldset с legend, чтобы был понятен общий вопрос группы.
• Крупные зоны нажатия. Поля, чекбоксы, радиокнопки и их подписи — достаточно крупные и с отступами; мелкие цели трудны и для моторики, и на телефоне.

Особое внимание — форме оформления заказа. Чем она короче и понятнее, тем доступнее: каждое лишнее поле — это лишний барьер для всех, а для человека со скринридером или без мыши — вдвойне. Убирайте необязательное, не заставляйте регистрироваться до покупки, подставляйте данные автозаполнением. Доступный checkout и удобный checkout — это, по сути, одно и то же.

Доступные ошибки и валидация

Отдельно стоит разобрать, как форма сообщает об ошибках — это частая точка провала доступности. Представьте: человек заполнил заказ, нажал «Оформить», а форма молча не отправилась или где-то наверху появилась красная надпись, которую пользователь скринридера или клавиатуры не заметил. Заказ потерян.

Как сделать ошибки доступными:

• Ошибка — у своего поля и текстом. Сообщение об ошибке размещают рядом с конкретным полем и формулируют понятно: «Введите телефон в формате …», а не общее «Проверьте форму» где-то вверху.
• Не только цветом. Красная рамка недоступна человеку с нарушением цветовосприятия. Всегда дополняйте её текстом ошибки и, при необходимости, значком.
• Связывайте ошибку с полем. Через aria-describedby текст ошибки привязывают к полю, а само поле помечают aria-invalid="true" — тогда скринридер объявит и поле, и в чём проблема.
• Сообщайте об ошибке «вслух». Область с ошибками делают aria-live (или переносят фокус на первое ошибочное поле), чтобы скринридер озвучил проблему, а не оставил пользователя в неведении.
• Не сбрасывайте введённое. После ошибки все корректно заполненные поля должны сохранить значения — заново вводить всё вслепую особенно тяжело без мыши.
• Подтверждайте успех. «Заказ оформлен» тоже должно быть доступным сообщением, а не только визуальной галочкой, которую скринридер не увидит.

Доступные модальные окна

Модальные окна (диалоги) в магазине повсюду: быстрый просмотр товара, форма обратного звонка, «товар добавлен в корзину», подтверждение, вход. Самодельные модалки — один из главных источников проблем доступности, потому что нативного тега «модальное окно», работающего идеально, исторически не было, и их собирают вручную.

Что делает модалку доступной:

• Роль и заголовок. Диалог помечают role="dialog" и aria-modal="true", а связку с заголовком дают через aria-labelledby — скринридер объявит «диалог: Обратный звонок».
• Фокус переходит в модалку. При открытии фокус ставят на первый значимый элемент внутри окна (или на заголовок), а не оставляют где-то на странице под окном.
• Фокус заперт внутри. Пока окно открыто, Tab ходит только по его элементам и не «утекает» на страницу за ним. Это тот случай, когда «запирать» фокус правильно.
• Закрытие по Esc и по кнопке. Модалку можно закрыть клавишей Esc и явной кнопкой-крестиком с доступной подписью (aria-label="Закрыть").
• Возврат фокуса. После закрытия фокус возвращается на элемент, который окно открыл, — иначе пользователь клавиатуры «теряется» в начале страницы.
• Фон недоступен. Пока модалка открыта, содержимое под ней скрыто от скринридера и не кликается, чтобы не было навигации «сквозь» окно.

Если стоит выбор между самодельной модалкой и проверенным компонентом, почти всегда лучше взять готовое доступное решение или, где возможно, нативный элемент <dialog>, который берёт часть этой работы на себя. Свою модалку с нуля легко сделать красивой, но недоступной.

Доступное меню и выпадающие списки

Навигация магазина — это меню, часто многоуровневое, с выпадениями каталога. Доступность здесь ломается двумя классическими способами: меню работает только по наведению (hover) и меню собрано на div без клавиатуры.

• Не только hover. Выпадающее меню, раскрывающееся исключительно при наведении мыши, недоступно ни с клавиатуры, ни на сенсорном экране. Раскрытие должно работать и по фокусу/клику, а не только по наведению.
• Настоящие ссылки и кнопки. Пункты меню-переходы — это a href, а кнопка раскрытия подменю — button. Тогда меню проходится Tab и стрелками, а не только мышью.
• Состояние раскрытия. Кнопке раскрытия дают aria-expanded="true/false", чтобы скринридер сообщал, открыт подраздел или нет. Бургер-меню на мобильном — тот же случай.
• Управление с клавиатуры. Внутри меню логично двигаться стрелками, закрывать по Esc, а фокус не должен «проваливаться» в скрытые пункты закрытого подменю.
• Скрытое — по-настоящему скрыто. Свёрнутое подменю должно быть недоступно и для фокуса (не просто спрятано визуально), иначе Tab уводит в невидимые ссылки.

Тот же принцип касается аккордеонов (характеристики, FAQ, разделы мобильного меню): кнопка-заголовок с aria-expanded, содержимое раскрывается по клику и с клавиатуры, состояние объявляется скринридеру. Хорошая новость: если делать меню на семантике (ссылки, кнопки, списки) и добавить пару ARIA-атрибутов состояния, оно становится доступным почти без дополнительных усилий.

Доступная карусель и галерея товара

Карусели (слайдеры баннеров) и галереи фото товара — красивый, но проблемный с точки зрения доступности элемент. Типичные беды: слайды переключаются только свайпом или мышью, автопрокрутка нельзя остановить, а точки-индикаторы не работают с клавиатуры.

• Управление с клавиатуры. Кнопки «предыдущий/следующий» и точки-индикаторы — настоящие button с доступными подписями (aria-label="Следующее фото"), доступные по Tab и Enter, а не мышиные стрелки на div.
• Пауза автопрокрутки. Если карусель крутится сама, у пользователя должна быть возможность её остановить. Автодвижущийся контент мешает людям с когнитивными особенностями и просто раздражает; по WCAG движущийся дольше нескольких секунд контент нужно уметь ставить на паузу.
• Понятная озвучка. Скрытые слайды не должны читаться скринридером как активные; текущий слайд и их количество полезно сообщать (например, «фото 2 из 6»).
• Галерея товара со свайпом и не только. На карточке фото листают свайпом — но должна быть и альтернатива: миниатюры-кнопки, стрелки, доступные с клавиатуры. Зум по тапу дополняют доступным способом рассмотреть детали.
• Alt у каждого фото. Каждое изображение в галерее — с осмысленным alt, а не «фото 1», «фото 2».

Часто самый доступный вариант — вообще отказаться от сложной автокарусели баннеров в пользу статичного блока или простой галереи с явными кнопками. Автослайдер редко приносит столько пользы, сколько создаёт проблем — и с доступностью, и со скоростью, и с конверсией.

Доступный умный фильтр каталога

Умный фильтр — мощный, но сложный интерактивный компонент, и его доступность легко упустить. Покупатель отбирает товары по свойствам, ценам, наличию, и всё это должно работать без мыши и со скринридером.

• Чекбоксы и радиокнопки — нативные. Условия фильтра лучше строить на настоящих input type="checkbox" / radio с подписями label, а не на div-«кнопках». Тогда фильтр из коробки доступен и с клавиатуры, и со скринридером.
• Понятные группы. Каждая группа свойств (цвет, бренд, размер) — с заголовком, желательно оформленным как группа полей, чтобы был ясен общий вопрос.
• Обратная связь о результате. Счётчик «найдено N товаров» полезно выводить в aria-live-область, чтобы при изменении условий скринридер озвучил, сколько нашлось, без перезагрузки страницы.
• Фокус не теряется при обновлении. Если выдача обновляется через AJAX, важно не «сбрасывать» фокус в начало страницы — иначе пользователь клавиатуры каждый раз оказывается наверху.
• Мобильная шторка. Фильтр-шторка на телефоне — это, по сути, та же модалка: ей нужны управление фокусом, закрытие по Esc, доступная кнопка вызова с aria-expanded.
• Сброс и применение. Кнопки «Показать N товаров» и «Сбросить» — настоящие кнопки, крупные и доступные.

Про мобильную специфику фильтра-шторки, sticky-панелей и тап-зон мы подробно писали в материале про мобильную версию магазина на 1С-Битрикс — доступность и мобильный UX тут почти полностью совпадают: крупные цели, работа без наведения, предсказуемое поведение полезны всем.

«Версия для слабовидящих»: когда нужна и её ограничения

Отдельного разговора заслуживает «версия для слабовидящих» — тот самый переключатель (часто иконка глаза в шапке), включающий крупный шрифт, высокий контраст, отключение картинок и упрощённое оформление. Вокруг него много путаницы, поэтому разложим честно.

Когда она действительно нужна

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

В чём её ограничения

Главное, что важно понять: кнопка «для слабовидящих» — это не то же самое, что доступный сайт. У неё есть принципиальные ограничения:

• Помогает только тем, кто её найдёт и нажмёт. Слабовидящий должен сначала увидеть саму иконку — а если основной сайт недоступен, он может до неё и не добраться.
• Не помогает незрячим. Человеку со скринридером крупный шрифт и высокий контраст не нужны вовсе — ему нужна семантика, alt, работа с клавиатуры. Их «версия для слабовидящих» не даёт.
• Не помогает клавиатурной навигации и моторике. Переключение цвета и размера никак не решает проблему кнопок из div и потерянного фокуса.
• Часто урезает функциональность. Нередко такой режим ломает часть интерфейса или отключает важные элементы, превращаясь в неполноценную копию.

Гораздо надёжнее и дешевле в поддержке — делать доступным сам основной сайт: достаточный контраст в базовой теме, масштабируемый шрифт в относительных единицах, семантику, поддержку клавиатуры, alt и подписи. Тогда слабовидящему часто вообще не нужен отдельный режим (он увеличит страницу штатными средствами браузера/ОС), незрячий пользуется скринридером, а человек без мыши — клавиатурой. «Версия для слабовидящих» в этом случае становится приятным дополнением там, где она требуется, а не фиговым листком, за которым прячут недоступный магазин.

Доступность в компонентах Битрикса и кастоме

Теперь о том, как всё это ложится на 1С-Битрикс. Хорошая новость: типовые компоненты и решения уже используют формы, ссылки и кнопки, поэтому базовая доступность в них присутствует. Плохая новость: кастомные доработки и «дизайнерская» вёрстка часто эту доступность ломают. Разберём по слоям.

Где обычно всё в порядке

Штатные компоненты каталога (catalog.section, catalog.element), корзины (sale.basket.basket), оформления (sale.order.ajax), форм и поиска в основе используют семантические теги: настоящие ссылки на товары, поля с подписями, кнопки. Пока вы не переопределяете их вёрстку на div-суп, базовая доступность и клавиатурная навигация в них работают.

Где обычно ломается

• Кастомные шаблоны компонентов. При редизайне ссылки и кнопки нередко заменяют на div со стилями и обработчиками клика — и доступность рушится. Правило: в шаблонах компонентов держите семантические теги.
• Самодельные виджеты. Модалки быстрого просмотра, кастомные выпадающие меню, слайдеры, «умные» фильтры на div — главные нарушители. Их нужно доводить до доступности вручную (роли, фокус, клавиатура) или брать проверенные решения.
• Тема оформления. Низкий контраст, убранная обводка фокуса (outline: none), мелкий шрифт, смысл только цветом — это уровень стилей темы, и правится в CSS.
• alt у товаров. Их удобно генерировать из свойств инфоблока в шаблоне, чтобы не проставлять руками.

Как правильно внедрять доступность в Битриксе:

1. Не трогайте ядро — работайте в шаблонах. Все правки делайте на уровне шаблонов компонентов (template.php) и стилей, а не в самих компонентах — так проще обновлять платформу и не ломать корзину с оформлением.
2. Проверьте семантику шаблонов. Убедитесь, что кнопки — это button, ссылки — a, списки — списки, заголовки идут по иерархии, а не «на глаз» размером шрифта.
3. Наведите порядок в теме. Контраст текста и элементов до нужного уровня, видимый фокус (:focus-visible), относительные единицы шрифта, отказ от кодирования смысла только цветом.
4. Добавьте alt из инфоблоков. Соберите alt фото товаров из названия и свойств прямо в шаблоне каталога и карточки.
5. Доведите виджеты. Модалки, меню, слайдеры, фильтр — роли, управление фокусом, клавиатура, aria-expanded, паузы автопрокрутки.
6. Проверьте формы и ошибки. Подписи label, правильные типы полей, autocomplete, доступные сообщения об ошибках у полей.
7. Прогоните тестами. Клавиатура, скринридер, автоаудит — по ключевым страницам (каталог, карточка, корзина, оформление).

Если магазин большой и кастома много, доступность разумно закладывать как часть разработки интернет-магазина на 1С-Битрикс — тогда семантика, клавиатура и контраст встроены с самого начала, а не «прикручиваются» потом ценой переделок.

Тестирование доступности

Доступность, как и скорость, нельзя «сделать на глаз» — её проверяют. Причём в три слоя, потому что ни один инструмент по отдельности не даёт полной картины.

1. Клавиатура — самый быстрый тест

Отложите мышь и пройдите ключевой сценарий «каталог → карточка → корзина → оформление заказа» только с клавиатуры: Tab/Shift+Tab для перехода, Enter/пробел для нажатия, стрелки внутри списков, Esc для закрытия. Отмечайте проблемы: куда нельзя попасть Tab'ом, где не видно фокуса, где он «застревает» в ловушке или уводит в невидимые элементы, где skip-link отсутствует. Этот тест не требует инструментов и вылавливает большинство грубых нарушений за десять минут.

2. Скринридер — как это слышат

Включите скринридер и послушайте страницу. На технике Apple это встроенный VoiceOver, на Windows — бесплатный NVDA или встроенный «Экранный диктор». Пройдите по заголовкам, ссылкам, кнопкам, полям, картинкам и оцените: понятно ли, что это за элемент; объявляются ли кнопки как кнопки; читаются ли alt у фото; понятны ли подписи полей и сообщения об ошибках; не засоряют ли декоративные картинки озвучку. Скринридер показывает сайт «ушами» — совсем иначе, чем глазами, и обнажает проблемы, невидимые визуально.

3. Автоаудит — массовая проверка

Автоматические инструменты быстро находят частые формальные ошибки на многих страницах:

• Lighthouse — встроен в инструменты разработчика браузера, даёт вкладку Accessibility с оценкой и списком проблем (контраст, отсутствие alt и подписей, структура заголовков).
• axe DevTools — расширение браузера, один из самых точных автоаудитов доступности с понятными пояснениями, что и как чинить.
• Контраст-чекеры — отдельные инструменты для проверки соотношения контраста конкретных пар «текст/фон».

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

Доступность, SEO и мобильная версия

Доступность не существует в вакууме — она тесно переплетена с двумя другими важными для магазина темами: SEO и мобильным UX. И это отличная новость, потому что усилия окупаются трижды.

Общий фундамент с SEO

Поисковый робот воспринимает страницу похоже на скринридер: он не видит картинку и интерфейс «на глаз», а читает разметку. Поэтому многое из доступности — это одновременно и техническое SEO:

• Один h1 и логичная иерархия заголовков — и для скринридера, и для поиска.
• Осмысленные alt у изображений — и для незрячих, и для картиночного поиска.
• Понятные тексты ссылок вместо «подробнее»/«тут» — и для навигации скринридером, и для оценки ссылок поиском.
• Семантические теги и валидная разметка — общая база для обеих задач.

Как выстроить эту семантическую основу системно, мы разбираем в материале про технический SEO-аудит магазина на 1С-Битрикс — многие пункты там дословно совпадают с чек-листом доступности.

Общие цели с мобильной версией и скоростью

Мобильный UX и доступность совпадают почти полностью: крупные зоны нажатия помогают и людям с моторными нарушениями, и всем на телефоне; работа без наведения (hover) обязательна и на сенсорном экране, и для клавиатуры; отсутствие скачков вёрстки (CLS) полезно и незрячим со скринридером, и зрячим, целящимся в кнопку. А быстрый, лёгкий сайт с предсказуемым поведением удобнее для всех, включая пользователей вспомогательных технологий. Про метрики скорости и стабильности, которые тут пересекаются с доступностью, мы писали в материале про Core Web Vitals интернет-магазина.

Вывод простой: доступность — это не «ещё одна задача поверх остальных», а во многом та же работа, что и качественное SEO и мобильный UX, но взятая под другим углом. Сделав сайт доступным, вы попутно улучшаете его для поиска и для мобильных покупателей.

Частые ошибки

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

• Сайт работает только мышью. С клавиатуры невозможно пройти воронку: кнопки из div, ловушки фокуса, элементы вне порядка обхода.
• div вместо кнопок и ссылок. «Кнопка» — это div class="btn" с обработчиком клика; для клавиатуры и скринридера её не существует.
• Нет alt у изображений. Фото товаров без описаний, картинки-ссылки без текстовой альтернативы — незрячий не понимает, что это и куда ведёт.
• Низкий контраст. Светло-серый текст на белом, бледные подписи и плейсхолдеры не читаются частью покупателей и на дешёвых экранах.
• Убрана обводка фокуса. outline: none в CSS — и по сайту невозможно ходить с клавиатуры, потому что не видно, где ты.
• Меню только по hover. Выпадения работают лишь при наведении мыши — недоступно ни с клавиатуры, ни на сенсоре.
• Плейсхолдер вместо подписи. Поля без label, подсказка исчезает при вводе, скринридер не объявляет назначение поля.
• Ошибки формы «молча» или только цветом. Красная рамка без текста и озвучки — человек не понимает, что не так, и бросает заказ.
• Смысл только цветом. «Красное — нет в наличии» без подписи недоступно людям с нарушением цветовосприятия.
• Недоступные модалки. Фокус не входит в окно или не выходит из него, нет закрытия по Esc, фон читается «сквозь» окно.
• Автокарусель без паузы. Баннеры крутятся сами, их нельзя остановить, стрелки и точки не работают с клавиатуры.
• «Версия для слабовидящих» вместо доступности. Кнопку добавили, а сам сайт остался недоступным для незрячих и клавиатуры.
• Запрет масштабирования. user-scalable=no мешает слабовидящим увеличить страницу на телефоне.
• Проверяли только автоаудитом. «Зелёный Lighthouse» приняли за доступность, а клавиатурой и скринридером сайт никто не проходил.

Чек-лист доступности

Сведём всё в практический список, по которому удобно принимать готовность магазина к доступности — перед запуском или после доработки.

Эта таблица — отправная точка для аудита, а не догма. Пройдитесь по каждой строке на своём реальном магазине: сначала клавиатурой, потом скринридером, потом автоаудитом — и слабые места проявятся сами. Чаще всего оказывается, что «в целом всё есть», но кнопка «В корзину» сделана из div, у половины фото нет alt, а по форме заказа с ошибкой невозможно понять, что не так, — и именно эти детали закрывают дверь части покупателей.

Вывод

Доступность интернет-магазина на 1С-Битрикс — это не благотворительность и не «версия для слабовидящих ради галочки», а свойство сайта, которое расширяет аудиторию, снижает потери в воронке и попутно улучшает SEO и мобильный UX. В её основе лежит понятная и во многом бесплатная работа: семантическая вёрстка (теги по смыслу вместо div-супа), навигация с клавиатуры с видимым фокусом и skip-link, достаточный контраст и масштабируемый шрифт, осмысленные alt и текстовые альтернативы, доступные формы с подписями и понятными ошибками, а также аккуратно доведённые модалки, меню, карусели и фильтр. ARIA при этом — не замена семантике, а добавка поверх неё там, где нативного HTML не хватает.

Ориентир — стандарт WCAG уровня AA с его четырьмя принципами: контент должен быть воспринимаемым, управляемым, понятным и надёжным. В 1С-Битрикс база доступности есть уже в типовых компонентах, а внедрять её правильно — на уровне шаблонов и стилей, не трогая ядро: проверить семантику, навести порядок в контрасте и фокусе, собрать alt из инфоблоков, довести кастомные виджеты и формы. И обязательно протестировать в три слоя — клавиатурой, скринридером и автоаудитом, — потому что «зелёный Lighthouse» ещё не значит «доступный сайт». Сделайте это — и ваш магазин перестанет молча терять уже пришедших покупателей только из-за того, что кнопка сделана из div, а подпись — светло-серым по белому.