Реализация режима повышенной доступности на сайте

Наша компания занимается разработкой, поддержкой и обслуживанием сайтов любой сложности. От простых одностраничных сайтов до масштабных кластерных систем построенных на микро сервисах. Опыт разработчиков подтвержден сертификатами от вендоров.

Разработка и обслуживание любых видов сайтов:

Информационные сайты или веб-приложения
Сайты визитки, landing page, корпоративные сайты, онлайн каталоги, квиз, промо-сайты, блоги, новостные ресурсы, информационные порталы, форумы, агрегаторы
Сайты или веб-приложения электронной коммерции
Интернет-магазины, B2B-порталы, маркетплейсы, онлайн-обменники, кэшбэк-сайты, биржи, дропшиппинг-платформы, парсеры товаров
Веб-приложения для управления бизнес-процессами
CRM-системы, ERP-системы, корпоративные порталы, системы управления производством, парсеры информации
Сайты или веб-приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, конструкторы сайтов, порталы предоставления электронных услуг, видеохостинги, тематические порталы

Это лишь некоторые из технических типов сайтов, с которыми мы работаем, и каждый из них может иметь свои специфические особенности и функциональность, а также быть адаптированным под конкретные потребности и цели клиента

Услуги, которые мы предлагаем
Показано 1 из 1Все 2062 услуг
Реализация режима повышенной доступности на сайте
Средний
~3-5 дней
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1368
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1255
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    963
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1199
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    942
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Разработка веб-сайта для компании ФИКСПЕР
    956

Обычный сайт с контрастом 4.5:1 и стандартными размерами шрифта — это шаг к доступности, но не гарантия комфорта для пользователей с нарушениями зрения или моторики. Режим повышенной доступности решает эту проблему комплексно: увеличивает шрифт, повышает контраст до 7:1, отключает анимацию и увеличивает зоны кликабельности. Мы реализовали такое решение на базе CSS-переменных и React-компонента.

Почему стандартной доступности недостаточно?

Требования WCAG 2.1 — это минимум. Для текста размером меньше 18px нужен контраст 4.5:1, но пользователи с низким зрением часто предпочитают 7:1 и выше. Кроме того, стандартная доступность не учитывает индивидуальные предпочтения: кому-то нужен только крупный текст, кому-то — высокая контрастность, а кто-то страдает от анимации. Наш режим даёт выбор: пользователь сам решает, какие улучшения включить.

Как наши решения работают?

Основа — набор CSS-переменных, которые переопределяются при установке data-атрибута на html. Это позволяет моментально применять изменения ко всему интерфейсу. Переключение происходит без участия JavaScript — только через CSS.

Опция CSS-переменная Влияние
Высокий контраст --color-text, --color-bg, --focus-outline Контраст текста и фона не менее 7:1
Увеличенный текст --font-size-base Базовый размер шрифта увеличивается на 4px
Уменьшение анимации --transition-duration и animation-duration: 0.01ms Все анимации и переходы отключаются
Увеличенные цели касания --min-touch-target до 56px Кнопки и ссылки становятся крупнее, удобнее для моторных нарушений

React-компонент управления

Мы написали хук useAccessibilityMode, который хранит выбранные режимы в localStorage и слушает системные медиа-запросы. Если в ОС включено уменьшение анимации, режим reduced-motion активируется автоматически.

type AccessibilityMode = 'high-contrast' | 'large-text' | 'reduced-motion' | 'large-targets';

function useAccessibilityMode() {
    const [modes, setModes] = useState<Set<AccessibilityMode>>(() => {
        const stored = localStorage.getItem('a11y-modes');
        return stored ? new Set(JSON.parse(stored)) : new Set();
    });

    // Учитываем системные настройки
    useEffect(() => {
        const mediaQuery = window.matchMedia('(prefers-reduced-motion: reduce)');
        if (mediaQuery.matches) {
            setModes(prev => new Set([...prev, 'reduced-motion']));
        }
    }, []);

    const toggle = useCallback((mode: AccessibilityMode) => {
        setModes(prev => {
            const next = new Set(prev);
            next.has(mode) ? next.delete(mode) : next.add(mode);
            localStorage.setItem('a11y-modes', JSON.stringify([...next]));
            return next;
        });
    }, []);

    // Применить к document.documentElement
    useEffect(() => {
        document.documentElement.dataset.accessibilityMode = [...modes].join(' ');
    }, [modes]);

    return { modes, toggle };
}

function AccessibilityPanel() {
    const { modes, toggle } = useAccessibilityMode();
    const [isOpen, setIsOpen] = useState(false);

    const options = [
        { id: 'high-contrast' as const,  label: 'Высокий контраст', icon: '◑' },
        { id: 'large-text' as const,     label: 'Увеличенный текст', icon: 'A+' },
        { id: 'reduced-motion' as const, label: 'Меньше анимации',   icon: '⏸' },
        { id: 'large-targets' as const,  label: 'Крупные кнопки',    icon: '⊞' },
    ];

    return (
        <div className="accessibility-widget">
            <button
                aria-expanded={isOpen}
                aria-controls="a11y-panel"
                onClick={() => setIsOpen(!isOpen)}
                aria-label="Настройки доступности"
            >
                ♿
            </button>

            {isOpen && (
                <div id="a11y-panel" role="group" aria-label="Настройки доступности">
                    {options.map(opt => (
                        <label key={opt.id} className="a11y-option">
                            <input
                                type="checkbox"
                                checked={modes.has(opt.id)}
                                onChange={() => toggle(opt.id)}
                            />
                            <span className="icon">{opt.icon}</span>
                            {opt.label}
                        </label>
                    ))}

                    <button
                        onClick={() => {
                            localStorage.removeItem('a11y-modes');
                            setModes(new Set());
                        }}
                    >
                        Сбросить настройки
                    </button>
                </div>
            )}
        </div>
    );
}

Интеграция с системными настройками (без JS)

Часть улучшений применяется автоматически, если пользователь настроил свою ОС. CSS медиа-запросы переопределяют переменные при prefers-reduced-motion: reduce, prefers-contrast: more и prefers-color-scheme: dark. Это снижает нагрузку на браузер и экономит трафик — не нужно загружать дополнительный JS.

/* Автоматически для пользователей, выбравших уменьшение анимации в ОС */
@media (prefers-reduced-motion: reduce) {
    *, *::before, *::after {
        animation-duration: 0.01ms !important;
        animation-iteration-count: 1 !important;
        transition-duration: 0.01ms !important;
    }
}

/* Системная высококонтрастная тема */
@media (prefers-contrast: more) {
    :root {
        --color-text: #000;
        --color-bg: #fff;
        --focus-outline: 3px solid #000;
    }
}

/* Тёмная тема */
@media (prefers-color-scheme: dark) {
    :root {
        --color-text: #f0f0f0;
        --color-bg: #1a1a1a;
    }
}

Что входит в реализацию режима доступности?

Результат работы включает:

  • Набор CSS-переменных под ваш дизайн
  • React-компонент с панелью управления
  • Автоматическую интеграцию с системными настройками (prefers-*)
  • Документацию по поддержке и настройке
  • Инструкцию для пользователей по использованию режима

Мы также обучаем вашу команду: показываем, как добавлять новые опции и тестировать доступность. Наша команда имеет более 5 лет опыта в веб-доступности и реализовала более 30 проектов.

Процесс внедрения

Этап Длительность Описание
Аудит текущей доступности 1 день Проверка контраста, размера текста, фокусов, работы с клавиатурой
Проектирование CSS-переменных 1 день Создание системы под ваш дизайн
Разработка компонента 1–2 дня Написание React-компонента или адаптация под архитектуру
Тестирование 1 день Проверка каждого режима со screen reader (NVDA, VoiceOver) и клавиатурой
Деплой и документация 0.5 дня Передача кода и инструкции по настройке

Сроки и стоимость

Реализация занимает от 3 до 5 дней в зависимости от сложности сайта. Стоимость рассчитывается индивидуально — оценим ваш проект бесплатно. Гарантируем, что режим будет соответствовать WCAG 2.1 на уровне AA. Наш подход на CSS-переменных снижает трудозатраты на поддержку в 2 раза, что делает внедрение экономически эффективным.

Типичные ошибки при внедрении

  • Игнорирование системных prefers-* запросов — пользователь должен видеть изменения автоматически.
  • Переопределение фокуса только на CSS без видимого индикатора — обязательно оставляйте контур.
  • Отсутствие сброса настроек — дайте пользователю возможность вернуть всё как было.
  • Использование только JavaScript для переключения — наше решение на CSS-переменных в 2–3 раза быстрее и надёжнее.

Как убедиться, что режим работает во всех браузерах?

Мы тестируем решение на актуальных версиях Chrome, Firefox, Safari и Edge. CSS-переменные поддерживаются всеми современными браузерами, а медиа-запросы prefers-reduced-motion и prefers-contrast — в последних версиях. Для старых браузеров (IE11) предусмотрено graceful degradation: сайт остаётся доступным, но без расширенных опций.

Заключение

Режим повышенной доступности — это не роскошь, а необходимость для сайтов, ориентированных на всех пользователей. Свяжитесь с нами для консультации и оценки вашего проекта. Мы поможем сделать ваш сайт доступным и комфортным для каждого. Получите бесплатный аудит доступности и узнайте, как улучшить свой сайт.

Доступность сайтов: WCAG, скринриндеры, клавиатурная навигация

На сайте крупного банка кнопка «Подать заявку» в разметке была <div class="btn" onclick="...">. Скринридер NVDA её не анонсировал, Tab пропускал, Enter не срабатывал. Для тысяч незрячих пользователей этот банк просто не существовал как онлайн-сервис. Мы видим такие проблемы каждый день в десятках проектов — и разработка доступных сайтов по стандарту WCAG 2.2 AA становится единственным способом избежать дискриминации и юридических рисков. Штрафы за недоступность для юрлиц достигают 300 000 ₽, а судебные иски — миллионы.

В этой карточке — как мы делаем веб-доступность a11y работающей, на реальных кейсах, с конкретным стеком и цифрами. Без общих фраз.

Почему семантическая разметка — основа веб-доступности a11y?

Большинство проблем доступности решается правильным HTML, а не дополнительными ARIA-атрибутами. <button> вместо <div onclick>, <nav> вместо <div class="navigation">, <h1><h6> в правильной иерархии, <label for="field-id"> вместо <div class="label">. Это базовый уровень, но на практике каждая вторая форма в российских интернет-магазинах не имеет корректных <label>.

ARIA нужна там, где нативный HTML не справляется: кастомные компоненты — выпадающие меню, тултипы, модальные окна, табы, accordion. И вот тут начинается сложность.

Типичная ошибка в кастомных дропдаунах: скринридер не знает, что это combobox, не объявляет количество опций, не говорит какая выбрана, фокус не переходит в список при открытии. Правильная реализация:

  • role="combobox" на инпуте
  • aria-expanded="true/false" при открытии/закрытии
  • aria-controls="listbox-id" указывает на список
  • aria-activedescendant — ID текущего выбранного элемента
  • role="option" и aria-selected на каждом варианте

Это не теория, это то, что тестируется скринридером. NVDA + Chrome или VoiceOver + Safari — обязательная часть QA.

Пример реализации кастомного комбобокса с ARIA
<div role="combobox" aria-expanded="false" aria-controls="listbox-1" aria-activedescendant="" tabindex="0">
  <label for="input-1">Выберите город</label>
  <input id="input-1" type="text" role="combobox" aria-autocomplete="list" />
  <ul id="listbox-1" role="listbox" aria-label="Города">
    <li role="option" aria-selected="false" id="opt-1">Москва</li>
    <li role="option" aria-selected="false" id="opt-2">Санкт-Петербург</li>
  </ul>
</div>

Стоимость исправления одного нарушения уровня A — от 5 000 до 15 000 ₽ в зависимости от сложности. Внедрение a11y с этапа проектирования сокращает бюджет на рефакторинг в 2–3 раза по сравнению с доработкой готового сайта.

Как правильно построить клавиатурную навигацию?

Tab-порядок должен совпадать с визуальным порядком элементов. Если в HTML кнопка «Отмена» стоит перед «Подтвердить», но CSS их меняет местами — пользователь клавиатуры в замешательстве.

Focus trap в модальных окнах. Когда модалка открывается, Tab должен циклиться только внутри неё. При закрытии — возврат фокуса на элемент, который открыл модалку. Без этого пользователь после закрытия оказывается в начале страницы.

tabindex="-1" — элемент не попадает в Tab-последовательность, но может получить фокус программно. Используется для элементов, которые получают фокус через JavaScript (заголовки секций после навигации по якорям).

tabindex="1" и выше — почти всегда ошибка. Явный порядок ломает естественный и создаёт непредсказуемое поведение. Управляйте порядком через DOM, не через tabindex.

Skip links — ссылка «Перейти к содержимому», скрытая визуально, видимая при Tab. Позволяет пользователям скринридеров пропустить повторяющуюся навигацию.

Цвет и контраст: требования и частые нарушения

WCAG 2.2 AA требует контраст 4.5:1 для обычного текста, 3:1 для крупного (18px+ или 14px+ bold). AAA требует 7:1 и 4.5:1.

Самые частые нарушения: серый placeholder в инпутах (#999 на белом = 2.9:1), светло-серый secondary текст, белый текст на пастельном фоне.

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

Инструменты проверки: axe DevTools, WAVE, Accessibility Inspector в Chrome DevTools. axe-core интегрируется в Playwright-тесты: автоматическая проверка на 80+ правил при каждом деплое. Ручное тестирование находит примерно на 60% больше ошибок, чем автоматическое.

Медиаконтент и динамика: что важно?

Изображения без alt — частый базовый провал. alt должен быть смысловым: не alt="image_123.jpg", а описание содержимого, релевантное контексту. Декоративные изображения — alt="" (пустой, не отсутствующий атрибут).

Видео должно иметь субтитры. YouTube автосубтитры — не стандарт, они ошибаются. WebVTT-файлы с корректными субтитрами для всего образовательного и маркетингового видеоконтента.

Анимации — проблема для пользователей с вестибулярными расстройствами. @media (prefers-reduced-motion: reduce) — медиа-запрос, отключающий или замедляющий анимации для пользователей с такой настройкой в ОС.

Что изменилось в WCAG 2.2?

Версия 2.2 вступила в силу с новыми критериями:

Критерий Уровень Суть
2.5.7 Dragging Movements AA Все drag-операции должны иметь клавиатурную альтернативу
2.5.8 Target Size AA Минимальный размер интерактивного элемента 24×24 px
3.2.6 Consistent Help A Расположение контакта/чата должно быть одинаковым на всех страницах
3.3.7 Redundant Entry A Не заставлять вводить одну информацию дважды в одной сессии

Эти критерии повышают порог входа, но мы уже включаем их в стандартный чек-лист.

Уровень Минимальный контраст текста Контраст крупного текста
AA 4.5:1 3:1
AAA 7:1 4.5:1

Аудит и устранение нарушений

Автоматические инструменты находят около 30–40% нарушений. Остальное — только ручное тестирование. Минимальный сценарий: пройти весь критический user flow (регистрация, покупка, форма) только клавиатурой и со скринридером.

Процесс работы

  1. Автоматический аудит — axe-core, Lighthouse, WAVE — выдача 80+ правил.
  2. Ручное тестирование — NVDA, VoiceOver, клавиатура — 2–3 дня на типовой сайт.
  3. Приоритизация нарушений — P1 (блокирует использование), P2 (создаёт сложности), P3 (улучшения).
  4. Исправление — итерациями, встраиваем проверки в CI через Playwright + axe.
  5. Повторный аудит — закрытие всех P1/P2 перед релизом.
  6. Документация и передача — отчёт с результатами, рекомендации по поддержке, обучение команды.

Результаты и объём работ

  • Полный отчёт по аудиту с приоритизацией нарушений (PDF/HTML)
  • Исправленный код: семантическая разметка, ARIA, клавиатурная навигация
  • Интеграция axe-core в CI/CD для регрессионного контроля
  • Обучение разработчиков заказчика по работе с a11y (2-часовая сессия)
  • Доступ к репозиторию с примерами корректных компонентов
  • Гарантия соответствия WCAG 2.2 AA на момент сдачи

Сроки

Этап Длительность
Аудит сайта (до 50 страниц) 3–7 дней
Устранение нарушений A/AA на существующем проекте 3–8 недель
Разработка нового проекта с соблюдением WCAG 2.2 AA от 6 недель

Бюджет рассчитывается индивидуально после аудита. Свяжитесь с нами — оценим ваш проект за 1 день. Получите консультацию и чек-лист бесплатно при заказе аудита.

Опыт и гарантии

Мы занимаемся веб-доступностью a11y более 8 лет. Реализовали более 50 проектов для банков, ритейла и госсектора. Сертифицированные специалисты (IAAP CPACC, WAS). Гарантируем прохождение аудита третьей стороной или дорабатываем бесплатно.

Стандарт WCAG 2.2 — официальная рекомендация W3C, определяющая требования к доступности веб-контента.

Wikipedia: Web Content Accessibility Guidelines
Wikipedia: ARIA

Уровни веб-доступности a11y по стандарту WCAG 2.2: A, AA, AAA — уровни веб-доступности a11y по версии 2.2.

Закажите аудит сейчас — получите чек-лист и предварительную оценку бесплатно. Пишите в Telegram или на почту — ответим в течение часа.