Незрячий покупатель дошёл до оформления заказа, включил скринридер — и услышал: «поле редактирования, поле редактирования, кнопка». Что вводить, где ошибка, почему форма не отправляется — непонятно. Он не может завершить заказ и уходит. Форма технически работает, но для этого человека магазина как будто нет.
Эта статья — практический гайд по семантической разметке форм для скринридеров в магазине на 1С-Битрикс: label и aria-атрибуты, доступные ошибки, порядок фокуса и кастомные элементы. Доступность — это не только про инклюзию, но и про конверсию и юридические риски. Если формы живут в кастомном шаблоне и требуют доработки, помогает автоматизация на 1С в связке с фронтенд-разработкой.
Коротко
- Скринридер читает разметку, а не картинку: подписи, роли, состояния и ошибки должны быть в коде.
- Фундамент — связка label с каждым полем; цвет и плейсхолдер подпись не заменяют.
- Ошибки делайте текстовыми и связывайте с полем через aria-describedby, объявляйте через aria-live.
- Предпочитайте нативные элементы; aria добавляйте только там, где нативной семантики не хватает.
Почему доступность форм — это про деньги
Доступность часто воспринимают как благотворительность «для галочки». На деле это прагматика. Во-первых, аудитория: людей, которые пользуются скринридерами, увеличением текста и навигацией с клавиатуры, больше, чем кажется, и каждый из них — потенциальный покупатель. Недоступная форма заказа теряет их деньги напрямую.
Во-вторых, доступная семантика улучшает форму для всех: понятные подписи, ясные ошибки и работа с клавиатуры снижают число брошенных форм и у зрячих пользователей. В-третьих, требования к доступности сайтов постепенно ужесточаются, и привести формы в порядок дешевле заранее, чем под давлением. Так что a11y форм — это конверсия, охват и снижение рисков одновременно.
Как скринридер читает форму
Чтобы размечать осмысленно, надо понимать, что «видит» скринридер. Он не смотрит на визуальное оформление — он идёт по дереву доступности, построенному из HTML и aria-атрибутов, и озвучивает для каждого элемента три вещи:
- Имя. Как называется элемент — обычно из связанного label. Без него поле безымянно.
- Роль. Что это — текстовое поле, кнопка, чекбокс, список. У нативных элементов роль есть сразу.
- Состояние. Обязательно ли, есть ли ошибка, отмечено ли, раскрыто ли.
Если хоть что-то из этого не выражено в разметке, пользователь теряет информацию. Красная рамка ошибки, звёздочка обязательности, подпись только цветом — всё это скринридер не озвучит. Поэтому смысл должен жить в коде, а не только в визуале.
Label: фундамент доступной формы
Самое важное и самое частое упущение — подписи полей. Каждое поле ввода должно иметь программно связанную подпись через элемент label (по атрибуту for и id либо оборачиванием поля). Тогда скринридер, попав в поле, произнесёт его название: «Телефон, поле редактирования».
Частая ошибка — заменять подпись плейсхолдером внутри поля. Это плохо по двум причинам: плейсхолдер исчезает при вводе, и его поддержка скринридерами непоследовательна. Человек начинает печатать и забывает, что это за поле, а незрячий может его вовсе не услышать. Плейсхолдер — это подсказка формата, а не замена подписи. Подпись должна быть видимой и связанной, а не растворяться в поле.
Обязательные поля и подсказки
Обязательность и подсказки тоже должны быть выражены программно, а не только визуально. Звёздочка рядом с полем ничего не говорит скринридеру, если она не связана с полем семантически.
- Обязательность. Помечайте обязательные поля атрибутом required и, при необходимости, aria-required, а не одной звёздочкой.
- Подсказки формата. Пояснение вроде «в формате +7...» связывайте с полем через aria-describedby, чтобы оно прозвучало.
- Не полагайтесь на цвет. Любой смысл, переданный только цветом, для части пользователей теряется.
- Краткость. Подсказка должна быть по делу — скринридер читает её вслух целиком.
Правильно помеченная обязательность экономит пользователю время: он узнаёт требования до отправки, а не после ошибки.
Сообщения об ошибках для скринридера
Ошибки — самое болезненное место форм для незрячих. Типичная недоступная форма подсвечивает поле красным и, может быть, показывает текст рядом — но скринридер не узнаёт об этом. Человек нажимает «отправить», ничего не происходит, и он в тупике.
Хорошая практика: при неудачной отправке перевести фокус на первое ошибочное поле или на область со списком ошибок, а саму область оформить как живой регион, чтобы сообщение прозвучало автоматически. Формулировки — конкретные: не «ошибка», а «Телефон: укажите номер в формате +7...». Тогда незрячий пользователь точно знает, что и где исправить.
Порядок фокуса и работа с клавиатуры
Многие пользователи проходят форму только с клавиатуры — клавишей Tab. Поэтому порядок фокуса должен быть логичным и совпадать с визуальным порядком полей. Если фокус прыгает хаотично, пройти форму невозможно.
- Логичный порядок. Tab ведёт по полям сверху вниз, как читается форма.
- Видимый фокус. Активное поле явно выделено — нельзя убирать обводку фокуса стилями.
- Всё доступно с клавиатуры. Каждый элемент, включая кастомные, управляется без мыши.
- Без ловушек фокуса. Из любого элемента можно уйти клавиатурой, фокус не «застревает».
Проверяется это просто: отложите мышь и пройдите форму одной клавиатурой. Если где-то застряли или потеряли фокус — там проблема, которую надо чинить.
Группировка и структура формы
Длинные формы вроде оформления заказа нужно структурировать, чтобы скринридер и пользователь понимали, где какой блок. Связанные поля группируют, а группам дают понятные названия.
Для групп полей (например, «Контактные данные», «Адрес доставки», «Способ оплаты») используют fieldset с legend — тогда скринридер объявляет принадлежность поля к блоку. Радиокнопки и чекбоксы одной темы тоже группируют, иначе они звучат как разрозненный набор. Осмысленные заголовки блоков помогают ориентироваться в форме на слух так же, как визуальные разделители помогают зрячему. Это часть общей семантики страницы, которая улучшает и восприятие, и SEO.
Кастомные элементы: списки, чекбоксы, календари
Больше всего проблем создают самописные элементы — красивые выпадающие списки, кастомные чекбоксы, календари выбора даты. Визуально они выглядят современно, но для скринридера часто оказываются немыми или ломаными.
| Элемент | Лучшее решение | Если делают кастомным |
|---|---|---|
| Выпадающий список | Нативный select | Нужны роли, состояния, клавиатура |
| Чекбокс/радио | Нативные input | Стилизовать, но сохранить нативное поле |
| Календарь даты | Нативный input типа даты | Полная клавиатурная и aria-поддержка |
| Кнопка | Нативная button | Роль button и обработка Enter/Space |
Правило одно: сначала нативный элемент, кастомный — только при реальной необходимости и с полной доступностью. Стилизовать нативные элементы можно почти как угодно, сохранив внутри рабочее поле, — это надёжнее, чем строить виджет с нуля и потом чинить его доступность.
Динамика и живые регионы (aria-live)
Современные формы динамичны: поля появляются и скрываются, идёт валидация на лету, обновляется стоимость доставки. Проблема в том, что визуальные изменения скринридер не замечает автоматически — он должен быть о них уведомлён.
Для этого служат живые регионы (aria-live): область, помеченная так, озвучивается при изменении содержимого. В неё выводят сообщения об ошибках, статус отправки, обновлённые итоги. Важно не переусердствовать: слишком «болтливые» регионы раздражают. Объявлять стоит значимое — ошибки, успех, ключевые изменения. Динамическое оформление заказа на 1С-Битрикс особенно нуждается в такой проработке, потому что там много живых пересчётов, и без aria-live незрячий пользователь не поймёт, что происходит.
Формы 1С-Битрикс: где смотреть
Штатные компоненты 1С-Битрикс дают в целом валидную разметку, но доступность зависит от шаблона и доработок — считать её «включённой по умолчанию» нельзя. Проверять и дорабатывать стоит в первую очередь:
- Оформление заказа. Самая важная форма — она приносит деньги; часто одностраничная и динамическая.
- Веб-формы. Обратная связь, заявки, регистрация — нередко с нестандартной вёрсткой.
- Кастомные шаблоны компонентов. Именно доработки чаще всего ломают доступность.
- Самописные виджеты. Выпадающие списки и календари поверх штатных полей.
Доработка форм — это фронтенд поверх бэкенда 1С-Битрикс, и её удобно вести аккуратно, не трогая ядро, через переопределение шаблонов. Как устроена чистая работа с компонентами и данными, мы разбираем в статье про D7 и ORM в 1С-Битрикс, а безопасную выкатку изменений — в материале про CI/CD и деплой для 1С-Битрикс.
Частые ошибки доступности форм
- Плейсхолдер вместо label. Подпись исчезает при вводе и не всегда озвучивается.
- Ошибки только цветом. Красная рамка без текста и связи с полем скринридеру не слышна.
- Обязательность одной звёздочкой. Нет required/aria-required — состояние не передаётся.
- Убранный фокус. Обводку фокуса скрыли стилями, и с клавиатуры не видно, где ты.
- Немые кастомные виджеты. Самописные списки и календари без ролей и клавиатуры.
- Динамика без aria-live. Изменения формы происходят молча для скринридера.
- Хаотичный порядок Tab. Фокус прыгает не по порядку, форму не пройти.
Чек-лист доступной формы
- У каждого поля есть label. Видимая подпись связана с полем программно.
- Обязательность выражена в коде. required/aria-required, а не только звёздочка.
- Ошибки доступны. Текстовые, связаны через aria-describedby, объявляются через aria-live.
- Фокус логичен и виден. Порядок Tab по форме, обводка фокуса не скрыта.
- Всё работает с клавиатуры. Форма проходится без мыши, без ловушек фокуса.
- Поля сгруппированы. Блоки помечены fieldset/legend с понятными названиями.
- Кастомные элементы доступны. Предпочтение нативным, у самописных — роли и клавиатура.
- Проверено скринридером. Ключевые формы пройдены со скринридером и одной клавиатурой.
Вывод
Доступность форм — не благотворительность, а прагматика: это конверсия, охват аудитории и снижение юридических рисков одновременно. Скринридер читает разметку, поэтому весь смысл — подписи, обязательность, ошибки, состояния — должен жить в коде, а не только в визуальном оформлении. Фундамент прост: связанный label, текстовые доступные ошибки, логичный фокус и работа с клавиатуры.
На 1С-Битрикс доступность не включена по умолчанию — её проверяют и дорабатывают в конкретном шаблоне, особенно в оформлении заказа и кастомных виджетах. Начните с аудита ключевых форм со скринридером и клавиатурой, чините по приоритету и предпочитайте нативные элементы. Так магазин становится удобнее для всех и перестаёт терять покупателей, которым сегодня просто не пройти форму.
