Больше половины трафика интернет-магазинов приходит с телефонов, а конверсия на мобильном почти всегда ниже, чем на десктопе. Одна из тихих причин этого разрыва — доступность: серый текст, который не разобрать на солнце, кнопки, в которые не попасть пальцем, цена мельче окружающего текста. Пользователь не жалуется — он просто закрывает вкладку и идёт к конкуренту.
Эта статья — практический разбор трёх опор доступной мобильной версии магазина на 1С-Битрикс: контраста, размеров шрифтов и зон тапа. Разберём конкретные цифры из WCAG, как их применить в адаптивных шаблонах Битрикса и почему доступность напрямую связана со скоростью и конверсией. Если мобильная версия у вас уже «есть, но неудобная», начните с аудита и оптимизации — он показывает узкие места точечно.
Коротко
- Контраст основного текста — не ниже 4,5:1, а для мобильного лучше держать запас до 7:1 из-за бликов на солнце.
- Базовый размер шрифта на телефоне — 16px: читаемо и не вызывает автозума полей в iOS.
- Зона тапа кнопки — минимум 44×44px с отступом 8px от соседей, иначе неизбежны ошибочные нажатия.
- Доступность работает только вместе со скоростью: медленную мобильную версию не спасёт идеальная вёрстка.
Почему доступность мобильной версии — это про деньги
Доступность (accessibility) часто воспринимают как «заботу об инвалидах» и откладывают на потом. На деле она улучшает жизнь всем: человеку с идеальным зрением тоже тяжело читать бледный текст на ярком солнце, попадать в мелкую кнопку в трясущемся автобусе и заполнять форму одной рукой. То, что помогает пользователю с ограничениями, помогает и обычному покупателю в неидеальных условиях.
А неидеальные условия — это норма для мобильного. Телефон держат одной рукой, экран бликует, интернет нестабилен, внимание рассеяно. Каждый барьер — мелкий шрифт, промах по кнопке, невидимая цена — это микроотказ, который суммируется в потерянные заказы. Поэтому доступность мобильной версии стоит считать не благотворительностью, а прямой работой над конверсией.
Контраст: сколько нужно и как считать
Контраст — это отношение яркости текста к яркости фона. Стандарт WCAG задаёт пороги, которые стоит держать как минимум:
- 4,5:1 — для обычного текста (уровень AA). Это базовое требование для основного контента.
- 3:1 — для крупного текста (от 24px обычного или 18px жирного) и для границ интерактивных элементов.
- 7:1 — уровень AAA для обычного текста. На мобильном к нему стоит стремиться для важных блоков.
Считать контраст вручную не нужно: в Chrome DevTools при наведении на элемент показывается его контрастность, а инспектор цвета подсказывает, проходит ли пара по AA и AAA. Отдельные плагины и панель Lighthouse делают то же для всей страницы. Практическое правило для мобильного: светло-серый текст на белом («#999 на #fff») почти всегда проваливает AA и на солнце нечитаем — используйте более тёмный цвет для всего, что важно.
Размеры шрифтов и относительные единицы
Размер шрифта на мобильном — не вопрос вкуса, а вопрос читаемости и технических ловушек. Базовый ориентир: основной текст — 16px, подписи и второстепенное — не мельче 14px, а всё, что участвует в решении о покупке (цена, кнопки, ключевые условия), — крупнее основного.
У числа 16px есть техническая причина: в мобильном Safari поля ввода со шрифтом мельче 16px вызывают автоматический зум при фокусе, из-за чего страница «прыгает» и пользователь теряет контекст. Держите поля форм не мельче 16px — и автозум не сработает.
Второй принцип — относительные единицы. Задавайте размеры в rem и em, а не в жёстких пикселях. Тогда пользователь, увеличивший системный шрифт (а таких немало), увидит увеличенный текст и на сайте, а вёрстка подстроится. Проверьте свои шаблоны на системном шрифте 150–200%: доступная вёрстка выдерживает это без наезжающих друг на друга элементов.
Зоны тапа: 44 и 48 пикселей
Палец — не курсор: он крупный и неточный. Поэтому кликабельные элементы должны быть достаточно большими и не тесниться. Отраслевые ориентиры:
- 44×44px — минимальная зона тапа по рекомендациям Apple.
- 48×48px — ориентир Google Material с рекомендованным шагом сетки.
- 8px — минимальный отступ между соседними интерактивными элементами.
Важно, что речь о кликабельной области, а не о видимом размере иконки. Иконку «в корзину» можно оставить маленькой и аккуратной, но обернуть её в padding так, чтобы палец попадал в зону 44–48px вокруг. Особенно внимательно к этому относятся в местах, где кнопки стоят рядом: «плюс/минус» количества, элементы фильтра, иконки в шапке. Тесно поставленные мелкие кнопки — источник постоянных ошибочных нажатий и раздражения.
Сводная таблица требований
| Параметр | Минимум | Рекомендуемо для мобильного |
|---|---|---|
| Контраст основного текста | 4,5:1 | 7:1 |
| Контраст крупного текста | 3:1 | 4,5:1 |
| Базовый размер шрифта | 14px | 16px и выше |
| Шрифт полей ввода | 16px | 16px (защита от автозума) |
| Зона тапа | 44×44px | 48×48px |
| Отступ между кнопками | 8px | 12px |
Эти значения — не догма, а рабочий каркас. Если вы держите каталог, карточку и оформление заказа в этих рамках, мобильная версия будет читаемой и удобной для подавляющего большинства покупателей.
Адаптив против отдельной мобильной версии
На 1С-Битрикс возможны два подхода: единый адаптивный шаблон, который перестраивается под ширину экрана, и отдельная мобильная версия (например, на поддомене) со своим набором шаблонов. Для большинства магазинов правильнее адаптив: контент и правки одни, поддерживать нужно один код, а доступность и SEO проще держать согласованными.
Отдельная мобильная версия иногда оправдана — например, когда мобильный сценарий радикально отличается от десктопного. Но у неё есть цена: два набора шаблонов легко расходятся, и правка, внесённая в десктоп, забывается в мобильной версии. Если вы всё же поддерживаете два фронта, дисциплина деплоя критична — как выкатывать изменения без рассинхронизации, мы разбираем в статье про CI/CD и деплой на Битрикс.
Доступность в шаблонах 1С-Битрикс
Доступность живёт в шаблонах компонентов и общем шаблоне сайта. Базовые вещи, которые стоит держать под контролем:
- Мета viewport. В шаблоне должен быть корректный
meta viewportбез запрета масштабирования — пользователь должен иметь возможность увеличить страницу. - Семантическая разметка. Кнопки — это
button, ссылки —a, а не «кликабельные div»; это важно для скринридеров и клавиатуры. - alt у изображений. Товарные фото и иконки-ссылки должны иметь осмысленный alt или быть помечены как декоративные.
- Фокус и состояния. Видимый фокус на интерактивных элементах, понятные состояния наведения и нажатия.
Кастомизация шаблонов компонентов (catalog, catalog.smart.filter, форм заказа) — это правка их template.php и стилей. Здесь легко случайно уронить доступность, переопределив вёрстку, поэтому любые кастомные шаблоны стоит проверять на контраст и зоны тапа так же, как основной макет.
Каталог и карточка товара на телефоне
Каталог и карточка — это места, где доступность конвертируется в заказы. На листинге товаров на телефоне важно, чтобы название читалось, цена была крупной и контрастной, а кнопка «в корзину» имела достаточную зону тапа и не жалась к соседней карточке.
В карточке товара критичны цена, наличие и главная кнопка действия. Их нельзя мельчить и «прятать» в бледный цвет ради минимализма — это ровно те элементы, ради которых пользователь пришёл. Умный фильтр catalog.smart.filter на мобильном обычно выносят в отдельный экран или шторку: там особенно важны крупные чекбоксы, читаемые подписи диапазонов и большая кнопка «Показать N товаров». Тесный фильтр с мелкими элементами — частая точка отказа именно на телефоне.
Формы и оформление заказа
Оформление заказа — финальный и самый хрупкий этап. Здесь доступность решает, дойдёт ли пользователь до кнопки «Оформить». Практические правила:
- Поля не мельче 16px. И по читаемости, и чтобы iOS не зумил экран при фокусе.
- Правильные типы полей.
type="tel"для телефона,type="email"для почты — телефон покажет нужную клавиатуру. - Крупные подписи и ошибки. Понятные лейблы над полями и контрастные сообщения об ошибках, а не бледный мелкий текст.
- Большая финальная кнопка. «Оформить заказ» — во всю ширину, контрастная, с явной зоной тапа.
Оформление на Битрикс обычно строится на компоненте sale.order.ajax — его шаблон и стоит приводить к этим требованиям. Если оформление связано с автоматической передачей заказа в учётную систему, доступный фронтенд — только половина дела: вторая половина — надёжная автоматизация продаж и склада на 1С, чтобы оформленный заказ корректно уходил в обработку.
Скорость как условие доступности
Самый доступный интерфейс бесполезен, если страница не успевает загрузиться. На мобильном интернете тяжёлые изображения и блокирующие скрипты превращают магазин в недоступный по факту — пользователь уходит до того, как увидит вашу идеальную вёрстку. Поэтому доступность неотделима от производительности.
На 1С-Битрикс базовые рычаги скорости — композитный сайт (мгновенная отдача статической части страницы), кэширование компонентов, сжатие и современные форматы картинок, отложенная загрузка. Инфраструктура тоже важна: как её выстроить, разобрано в материале про хостинг и инфраструктуру на BitrixVM. Быстрая и читаемая мобильная версия — это одна задача, которую нельзя решать половинами.
Как тестировать доступность
Проверку доступности стоит вести в два слоя — автоматический и ручной, потому что они ловят разное.
- Lighthouse и DevTools. Раздел Accessibility даёт оценку и список формальных проблем: контраст, отсутствие alt, некорректная семантика.
- Инспектор контраста. Проверка конкретных пар «текст/фон» на прохождение AA и AAA.
- Реальный телефон. Пройдите путь каталог → карточка → корзина → оформление одной рукой, при ярком свете, с увеличенным системным шрифтом.
- Клавиатура и скринридер. Хотя бы базовая проверка навигации с клавиатуры и озвучивания ключевых элементов.
Автотесты дают формальную гигиену, но реальные проблемы удобства видно только на живом устройстве в реальных условиях. Регулярную проверку стоит встроить в процесс релизов, чтобы новые правки не откатывали доступность назад.
Частые ошибки
- Бледный текст ради стиля. Серый на белом красиво в макете, но нечитаем на солнце и проваливает контраст AA.
- Мелкие поля форм. Шрифт меньше 16px вызывает автозум в iOS и тяжело читается.
- Тесные кнопки. Иконки без padding и отступов дают постоянные промахи пальцем.
- Запрет масштабирования.
user-scalable=noв viewport лишает пользователя возможности увеличить страницу. - Жёсткие пиксели вместо rem. Вёрстка ломается при увеличенном системном шрифте.
- «Кликабельные div». Не-семантические элементы недоступны с клавиатуры и скринридера.
- Проверка только на десктопе. В эмуляторе всё хорошо, а на реальном телефоне на улице — нет.
- Игнор скорости. Доступная, но тяжёлая страница недоступна по факту — её не дожидаются.
Чек-лист внедрения
- Контраст проверен. Основной текст ≥ 4,5:1, важные блоки ближе к 7:1; бледный серый убран.
- Шрифты читаемы. База 16px, поля форм не мельче 16px, размеры в rem/em.
- Зоны тапа достаточны. Кнопки 44–48px, отступ между ними от 8px, иконки обёрнуты padding.
- Viewport корректен. Масштабирование разрешено, страница адаптивна.
- Семантика в порядке. Кнопки и ссылки семантичны, у изображений есть alt, фокус виден.
- Формы удобны. Правильные типы полей, крупные подписи и контрастные ошибки, большая финальная кнопка.
- Скорость в норме. Композит, кэш, лёгкие картинки; проверены Core Web Vitals на мобильном.
- Протестировано на устройстве. Пройден весь путь на реальном телефоне при ярком свете и увеличенном шрифте.
Вывод
Доступность мобильной версии — это не отдельный «проект по инклюзии», а прямая работа над конверсией. Три простые опоры — достаточный контраст, читаемые шрифты и крупные зоны тапа — убирают барьеры, из-за которых покупатель молча уходит с телефона. Цифры известны и не спорны: 4,5:1 по контрасту, 16px по шрифту, 44–48px по зоне тапа.
На 1С-Битрикс всё это внедряется в адаптивных шаблонах и проверяется в связке со скоростью — потому что медленную мобильную версию не спасёт идеальная вёрстка. Начните с честной проверки на реальном телефоне на улице, приведите каталог, карточку и оформление к рабочим требованиям — и мобильная конверсия перестанет «утекать» на мелочах. При необходимости точечно усилить процесс помогает автоматизация на 1С, чтобы удобный фронтенд подкреплялся надёжной обработкой заказов.
