Тёмная тема и доступность магазина на Битрикс

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

Ниже — практический разбор, как сделать витрину на 1С-Битрикс доступной по стандарту WCAG и добавить тёмную тему, не навредив ни конверсии, ни SEO: контраст, навигация с клавиатуры, семантика и ARIA, доступные формы, CSS-переменные для тем и переключатель без «мигания». Это выжимка из наших проектов по оптимизации конверсии (CRO) интернет-магазинов — с конкретикой по компонентам и шаблонам Битрикса.

Доступность магазина — это про деньги, а не про галочку

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

Разберём, кого именно теряет недоступный магазин. Это не только незрячие пользователи со скринридерами, хотя и они тоже. Это гораздо более широкий круг:

• Слабовидящие. Люди, которые увеличивают шрифт, включают высокий контраст, пользуются экранной лупой. Если вёрстка «ломается» при зуме или текст сливается с фоном — заказ не оформить.
• Пользователи клавиатуры. Кто-то не может пользоваться мышью из-за моторики, кто-то просто привык к клавиатуре. Если по форме нельзя пройти табом и не видно, где фокус, — оформление превращается в квест.
• Ситуативные ограничения. Яркое солнце на экране смартфона, сломанный тачпад, покупка «одной рукой» с ребёнком на другой, шумное метро без звука у видео. Доступность помогает в этих ситуациях каждому.
• Пожилые покупатели. Растущий и платёжеспособный сегмент, которому важны крупный шрифт, понятный контраст и предсказуемое поведение интерфейса.
• Поисковые роботы. Семантичная разметка, осмысленные alt и заголовки, логичный порядок элементов — это ровно то, что помогает и скринридеру, и поисковику понять страницу.

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

WCAG простыми словами: уровни A, AA, AAA

WCAG (Web Content Accessibility Guidelines) — международный стандарт доступности веб-контента. На нём же основан российский ГОСТ по доступности. Пугаться объёма стандарта не нужно: для интернет-магазина достаточно понимать его логику и держать в голове несколько десятков практических критериев.

Весь стандарт строится вокруг четырёх принципов — их удобно запомнить по аббревиатуре POUR:

• Воспринимаемость (Perceivable). Информацию можно воспринять: у картинок есть текстовые альтернативы, у видео — субтитры, контраст достаточный, текст масштабируется.
• Управляемость (Operable). Интерфейсом можно управлять: всё доступно с клавиатуры, нет ловушек фокуса, на действия хватает времени, нет резких вспышек.
• Понятность (Understandable). Контент и работу интерфейса можно понять: предсказуемое поведение, понятные подписи и сообщения об ошибках.
• Надёжность (Robust). Контент корректно интерпретируется разными технологиями, включая вспомогательные: валидный HTML, правильные роли и имена элементов.

У критериев есть три уровня соответствия. Уровень A — базовый минимум, без которого частью функций вообще нельзя пользоваться. Уровень AA — разумная планка для коммерческих сайтов, именно её обычно требуют регуляторы и заказчики. Уровень AAA — максимальный, его целиком достигают редко, отдельные критерии берут точечно. Для интернет-магазина правильная цель — соответствие AA по ключевым критериям, а не гонка за AAA.

Контраст текста и элементов: как проверить и исправить

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

Контраст считается как соотношение относительной яркости двух цветов — от 1:1 (одинаковые) до 21:1 (чёрный на белом). Считать вручную не нужно: коэффициент показывают панель доступности в DevTools браузера, аудит Lighthouse и онлайн-проверялки. Начинать проверку стоит с самых частых на витрине пар цветов.

1. Основной текст на фоне. Тело описаний, характеристик, условий доставки — самый читаемый контент, здесь важен запас по контрасту.
2. Ссылки. Они должны отличаться от обычного текста не только цветом (иначе дальтоник их не увидит), но и подчёркиванием или начертанием.
3. Текст на кнопках. Особенно на цветных кнопках «Купить» и «Оформить» — белый текст на светло-оранжевом часто не добирает до 4,5:1.
4. Бейджи и метки. «Скидка», «Хит», «Нет в наличии» — мелкий текст на цветной плашке легко проваливает контраст.
5. Плейсхолдеры и подписи полей. Бледный серый плейсхолдер в форме — классический провал контраста, к тому же он не заменяет подпись.

Навигация с клавиатуры и видимый фокус

Проверьте прямо сейчас: откройте свою витрину, уберите руку с мыши и попробуйте оформить заказ, нажимая только Tab, Shift+Tab, Enter и стрелки. Большинство неоптимизированных магазинов на этом тесте проваливаются — фокус прыгает непредсказуемо, невидим или застревает во всплывающих окнах. А ведь это ровно тот способ, которым пользуются люди с нарушениями моторики и незрячие со скринридерами.

Что должно работать безупречно:

• Видимый фокус. На каждом активном элементе (ссылка, кнопка, поле) при переходе табом должна быть чёткая рамка или обводка с контрастом не ниже 3:1. Правило outline: none без замены — прямая дорога к недоступности.
• Логичный порядок обхода. Фокус идёт по странице в осмысленном порядке — сверху вниз, слева направо, — а не хаотично. Порядок задаёт структура HTML, поэтому важно не ломать её позиционированием.
• Нет ловушек фокуса. Из модального окна (быстрый просмотр товара, корзина, форма) можно выйти по Esc, а фокус не «убегает» на фон под окном.
• Ссылка «к содержимому». В начале страницы полезна скрытая ссылка «Перейти к основному содержанию», которая появляется по фокусу и позволяет пропустить громоздкое меню.
• Управление кастомными элементами. Самодельные выпадающие списки, табы, аккордеоны должны реагировать на клавиатуру так же, как нативные: стрелки, Enter, Esc.

Особая боль магазинов — меганавигация, большое выпадающее меню каталога. Если оно раскрывается только по наведению мыши и не управляется с клавиатуры, значительная часть каталога становится недоступной. Как построить такое меню правильно, мы подробно разбираем в статье про меганавигацию и меню каталога на Битрикс.

Семантическая вёрстка и ARIA в шаблонах

Основа доступности — не атрибуты ARIA, а правильный семантический HTML. Скринридер и поисковик «читают» страницу по тегам: заголовок — это <h1>–<h6>, кнопка — это <button>, ссылка — <a>, навигация — <nav>. Первое правило ARIA звучит парадоксально: лучший ARIA — это его отсутствие. Если задачу решает нативный тег, ARIA не нужен.

Что чаще всего нужно поправить в вёрстке магазина:

• Заголовки по иерархии. Один <h1> на страницу (название товара или раздела), дальше <h2>, <h3> без «прыжков» через уровень. Заголовки — это оглавление страницы для скринридера.
• Кнопки — кнопками, ссылки — ссылками. «Добавить в корзину» — это <button>, а не <div onclick>. Переход в раздел — это <a href>. Разница критична для клавиатуры и скринридера.
• Ориентиры страницы. <header>, <nav>, <main>, <footer> позволяют быстро перепрыгивать между зонами.
• Осмысленные alt. У фото товара alt описывает товар («Кроссовки Nova синие, вид сбоку»), а не «image1.jpg». Декоративные картинки получают пустой alt="", чтобы скринридер их пропустил.
• Доступные имена иконочных кнопок. Кнопка-иконка «сердечко» без текста должна иметь aria-label="В избранное", иначе скринридер прочитает «кнопка» без смысла.

ARIA нужен там, где нативной семантики не хватает: для динамических состояний и кастомных виджетов. Например, счётчик товаров в корзине, который меняется без перезагрузки, стоит пометить как aria-live="polite", чтобы скринридер объявил обновление. У раскрывающегося блока фильтра логично проставить aria-expanded. Но важно помнить: неправильный ARIA хуже, чем его отсутствие — он переопределяет реальную семантику и может окончательно запутать вспомогательные технологии.

Скринридеры: как звучит ваша витрина

Скринридер (программа экранного доступа) озвучивает содержимое экрана для незрячих и слабовидящих пользователей: NVDA и JAWS на Windows, VoiceOver на macOS и iOS, TalkBack на Android. Чтобы понять доступность на практике, полезно один раз включить VoiceOver или NVDA и пройти по своей витрине с закрытыми глазами. Опыт отрезвляющий.

Типичные проблемы, которые вскрывает скринридер:

• «Ссылка, ссылка, ссылка». Если все ссылки называются «подробнее» или «купить» без контекста, в режиме списка ссылок они неотличимы. Доступное имя должно быть уникальным и осмысленным.
• Немые картинки. Фото без alt читаются как имя файла или пропускаются, и пользователь не понимает, что за товар перед ним.
• Невидимый статус. «Товар добавлен в корзину» показывается всплывашкой, но не объявляется — незрячий покупатель не знает, сработала ли кнопка.
• Хаотичный порядок чтения. Если визуальный порядок расходится с порядком в HTML (из-за CSS-позиционирования), скринридер читает страницу в нелогичной последовательности.
• Таблицы без заголовков. Таблица характеристик без <th> и связей превращается в кашу из ячеек без привязки «свойство — значение».

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

Доступные формы: корзина, оформление, фильтр

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

1. У каждого поля — видимая подпись. Используйте <label>, связанный с полем через for/id. Плейсхолдер не заменяет подпись: он исчезает при вводе и часто проваливает контраст.
2. Понятные сообщения об ошибках. Ошибка описывает, что не так и как исправить («Введите телефон в формате +7…»), находится рядом с полем и связывается с ним через aria-describedby. Не полагайтесь только на красную рамку.
3. Ошибки объявляются. При отправке невалидной формы фокус переводится на первое проблемное поле, а сообщение попадает в aria-live-область, чтобы скринридер его прочитал.
4. Логичные типы полей. type="tel", type="email", inputmode и autocomplete подсказывают браузеру и вызывают удобную клавиатуру на смартфоне — это и доступность, и конверсия.
5. Группировка. Радиокнопки способа доставки или оплаты оборачивайте в <fieldset> с <legend>, чтобы скринридер объявлял, к чему относится выбор.
6. Никаких ловушек в фильтре. Панель фильтра должна раскрываться и управляться с клавиатуры, а применённые значения — быть понятны и удаляемы без мыши.

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

Зачем магазину тёмная тема

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

• Комфорт в темноте. Ослепительно белая витрина ночью утомляет глаза. Тёмный фон снижает нагрузку при чтении длинных описаний и характеристик в условиях слабого освещения.
• Экономия батареи на OLED. На современных смартфонах с OLED-экраном тёмные пиксели почти не потребляют энергию — тёмная тема ощутимо экономит заряд.
• Уважение к выбору пользователя. Многие включили тёмный режим на уровне системы и ждут, что сайт это учтёт. Игнорировать системную настройку — маленькое, но заметное неуважение.
• Восприятие качества. Аккуратно сделанная тёмная тема добавляет продукту ощущение современности и внимания к деталям — а это косвенно работает на доверие и конверсию.

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

Тёмная тема на CSS-переменных (дизайн-токены)

Единственно верный современный способ сделать тему — дизайн-токены на CSS-переменных (custom properties). Идея проста: вы не прописываете конкретные цвета по всему CSS, а объявляете набор смысловых переменных (фон, текст, границы, акцент) и используете только их. Смена темы — это переопределение значений этих переменных, а вся вёрстка остаётся неизменной.

Ключевой принцип — семантические, а не «цветовые» имена. Плохо: --white, --dark-blue. Хорошо: --bg, --surface, --text, --text-muted, --border, --accent. Тогда переменная --bg в светлой теме белая, а в тёмной — почти чёрная, но смысл («фон страницы») один и тот же, и код компонентов не меняется.

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

Технически переменные объявляют на корне для светлой темы и переопределяют внутри селектора тёмной — например, по атрибуту или классу на теге <html>. Дополнительно стоит поддержать системную настройку через медиазапрос prefers-color-scheme: dark для первого визита, а явный выбор пользователя хранить и применять поверх системного.

Переключатель темы без «мигания» (FOUC)

Главный технический враг тёмной темы — вспышка светлой темы (FOUC, flash of unstyled content). Пользователь выбрал тёмный режим, но при следующей загрузке на долю секунды видит белый экран, прежде чем JavaScript успеет применить тему. Это выглядит как баг и особенно бьёт по глазам ночью — ровно в тот момент, ради которого тёмная тема и нужна.

Причина проста: если тему применяет обычный скрипт в конце страницы, браузер сначала рисует светлый вариант, а потом перекрашивает. Лечение — применить класс темы до отрисовки. Порядок действий такой:

1. Сохраняйте выбор в cookie и localStorage. При клике по переключателю пишите значение (light/dark) в оба хранилища, чтобы его можно было прочитать и на сервере, и на клиенте.
2. Ставьте класс как можно раньше. Небольшой инлайновый скрипт в <head> читает сохранённое значение (или системную настройку) и сразу вешает класс на <html> — до того, как отрисуется тело страницы.
3. Уважайте систему при первом визите. Если явного выбора ещё нет, берите prefers-color-scheme; как только пользователь переключил вручную — приоритет за его выбором.
4. Синхронизируйте вкладки. Слушайте событие изменения хранилища, чтобы переключение темы в одной вкладке применялось и в других.
5. Делайте переключатель доступным. Это <button> с понятным именем и aria-pressed, доступная с клавиатуры, а не «div с иконкой».

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

Тёмная тема и доступность: контраст в обоих режимах

Частая ловушка: команда вылизала контраст в светлой теме, а тёмную сделала на глаз — и провалила доступность там, где её никто не проверял. Помните: критерии WCAG действуют в каждой теме отдельно. Тёмный режим — это не «поблажка», а вторая полноценная палитра, которую нужно проверить по тем же порогам контраста 4,5:1 и 3:1.

Специфические подводные камни тёмной темы:

• Чистый чёрный фон вреден. Абсолютно чёрный #000 с белым текстом даёт слишком резкий контраст и эффект «дрожания» текста (halation). Берите очень тёмный, но не чёрный фон (например, #12151C) и не чисто-белый, а слегка приглушённый текст.
• Насыщенные цвета «кричат». Яркие акценты, нормальные на светлом фоне, на тёмном выглядят ядовито и утомляют. В тёмной палитре их приглушают и часто делают чуть светлее для контраста.
• Тени не работают. Глубина в тёмной теме передаётся не тенью, а разной светлотой поверхностей (фон темнее, карточка чуть светлее). Тени на тёмном почти не видны.
• Картинки товаров с прозрачностью. Фото на прозрачном фоне, снятые для белой подложки, на тёмной теряются. Нужны либо подложки под товар, либо контроль фона изображений.
• Состояния и фокус. Индикатор фокуса, hover, disabled нужно перепроверить в тёмной теме — то, что было заметно на белом, на тёмном может исчезнуть.

Практический вывод: закладывайте проверку контраста в обе темы в определение готовности задачи. Автоматический аудит (Lighthouse, axe) прогоняйте и в светлом, и в тёмном режиме — иначе половина вашей аудитории получит непроверенный интерфейс.

Реализация в 1С-Битрикс

Теперь конкретика: где именно в 1С-Битрикс делаются правки под доступность и тёмную тему. Ключевое — работать в шаблоне сайта и шаблонах компонентов в папке /local/templates/, чтобы доработки пережили обновления платформы и не терялись при апдейтах.

1. Объявите токены в стилях шаблона сайта. В общий CSS шаблона (обычно подключаемый через template_styles.css или сборку) добавьте набор CSS-переменных для светлой темы на :root и переопределение для тёмной по классу/атрибуту на <html>. Так токены доступны всем компонентам сразу.
2. Переведите цвета компонентов на переменные. В кастомизированных шаблонах компонентов (каталог, карточка, корзина, меню) замените захардкоженные цвета на var(--...). Это разовая, но важная работа: без неё тёмная тема «зацепит» не всё.
3. Скопируйте и доработайте шаблоны компонентов. Стандартные шаблоны bitrix:catalog.section, catalog.element, sale.basket.basket, menu скопируйте в свой шаблон сайта и добавьте семантику: заголовки по иерархии, <button> вместо кликабельных div, alt к изображениям, label к полям, ARIA к динамике.
4. Добавьте ранний скрипт темы. В header.php шаблона, максимально высоко, поставьте короткий инлайновый скрипт, который читает cookie/localStorage (или prefers-color-scheme) и вешает класс темы на <html> до отрисовки тела. Это убирает FOUC.
5. Учтите композитный кэш. Проверьте, что тема применяется из cookie ранним скриптом, а не «вшита» в кэшируемый HTML. Иначе композит будет отдавать всем одну тему.
6. Разместите доступный переключатель. В шапке шаблона добавьте <button> переключения темы с aria-pressed и понятным именем, привязанный к тому же хранилищу.
7. Проверьте формы оформления. В шаблоне оформления заказа (sale.order.ajax или кастомном) добавьте связку label/for, aria-describedby для ошибок, перевод фокуса на первое невалидное поле и aria-live для сообщений.

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

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

Главный страх бизнеса при внедрении тёмной темы — «а не просядет ли SEO и не упадут ли продажи». Разберём честно, что происходит на самом деле.

SEO. При правильной реализации на CSS-переменных поисковик не видит никакой разницы: HTML один и тот же, контент один и тот же, URL один и тот же, меняются только значения цветовых переменных. Робот индексирует ту же страницу, что и всегда. Более того, доступность помогает SEO: семантичные заголовки, осмысленные alt, логичная структура и валидная разметка — это те самые сигналы, которые поисковик любит. Опасны только неправильные реализации: подмена контента через JavaScript, отдельные URL для тёмной версии, cloaking — вот это дробит сигналы и создаёт дубли. Не делайте так — и с SEO всё будет в порядке.

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

Про воспринимаемую скорость тоже нельзя забывать: доступная и лёгкая витрина обычно и быстрее, что напрямую влияет и на SEO, и на конверсию. Комплексно эти задачи решает услуга по оптимизации конверсии — от аудита барьеров до внедрения правок в шаблоны.

Как тестировать доступность и тему

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

• Автоматический аудит. Lighthouse (встроен в Chrome DevTools) и расширение axe DevTools быстро находят провалы контраста, отсутствие alt и label, проблемы заголовков. Прогоняйте и в светлой, и в тёмной теме.
• Тест клавиатурой. Уберите мышь и пройдите ключевые сценарии — каталог, карточка, корзина, оформление — только с клавиатуры. Проверьте видимость фокуса и отсутствие ловушек.
• Тест скринридером. Включите NVDA (Windows) или VoiceOver (Mac) и послушайте, как звучит витрина: понятны ли ссылки, объявляются ли статусы, читаются ли картинки.
• Тест масштабированием. Увеличьте страницу до 200% и убедитесь, что вёрстка не рассыпается, ничего не обрезается и не появляется горизонтальный скролл.
• Проверка контраста. Пройдитесь по частым парам цветов в обеих темах панелью доступности DevTools или онлайн-проверялкой.
• Проверка FOUC. Перезагрузите страницу в тёмной теме несколько раз и убедитесь, что нет вспышки светлого фона.

Хорошая практика — вынести ключевые пункты доступности в определение готовности задачи (Definition of Done) для фронтенда, чтобы каждый новый компонент проверялся до релиза. Так доступность не «протухает» с каждой доработкой витрины.

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

• Ставят плагин-оверлей «доступность одной кнопкой» вместо реальной работы с вёрсткой — скринридерам от него чаще хуже, чем лучше.
• Убирают outline у элементов ради «красоты» и не дают замены — пользователи клавиатуры теряют фокус из виду.
• Передают смысл только цветом («красное — нет в наличии») — дальтоники и скринридеры этого не считывают.
• Делают кликабельные <div> вместо <button> и <a> — элементы недоступны с клавиатуры и немы для скринридера.
• Оставляют картинки товаров без alt или с «image1.jpg» — незрячий покупатель не понимает, что за товар.
• Делают тёмную тему инверсией «на глаз» без проверки контраста — цены и кнопки становятся нечитаемыми.
• Применяют тему поздним скриптом — ночью пользователь ловит вспышку белого экрана (FOUC).
• Вшивают класс темы в композитно-кэшируемый HTML — всем посетителям отдаётся одна тема из кэша.
• Проверяют контраст только в светлой теме, а тёмную не аудируют — половина аудитории получает непроверенный интерфейс.

Чек-лист внедрения

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

1. Контраст проверен. Основной текст, ссылки, кнопки и бейджи проходят порог AA (4,5:1 и 3:1) в обеих темах.
2. Клавиатура работает. Каталог, карточка, корзина и оформление проходятся только с клавиатуры, фокус виден, ловушек нет.
3. Семантика на месте. Иерархия заголовков, <button>/<a> по назначению, ориентиры header/nav/main/footer.
4. Изображения подписаны. У фото товаров осмысленные alt, декоративные — с пустым alt.
5. Формы доступны. Видимые label, понятные ошибки, aria-describedby, перевод фокуса, корректные типы полей.
6. Динамика объявляется. Корзина, фильтр, статусы используют aria-live и объявляются скринридеру.
7. Тема на токенах. Цвета переведены на CSS-переменные, тёмная палитра подобрана заново и проверена, а не инвертирована.
8. Нет FOUC. Класс темы применяется ранним скриптом из cookie до отрисовки, композитный кэш учтён.
9. Переключатель доступен. Кнопка темы работает с клавиатуры, имеет aria-pressed и понятное имя, выбор запоминается.
10. Аудит пройден. Lighthouse/axe прогнаны в светлой и тёмной теме, ключевые сценарии проверены скринридером.

Вывод

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