Доступность веб-дизайна

Вы открываете сайт, и он молчит. Не в метафорическом смысле — он буквально не передаёт информацию тому, кто пользуется скринридером. Это не ошибка верстальщика, а нарушение спецификации WCAG 2.2 на уровне AA. Доступность веб-дизайна — это не про добрые намерения, а про точное следование техническим стандартам, которые диктуют, какой цвет фона должен быть при определённом цвете текста, как должен вести себя фокус при нажатии Tab и какие ARIA-атрибуты обязаны присутствовать в каждом custom-компоненте.
Здесь вы не найдёте общих фраз про «сделайте удобно для всех». Вместо этого вы погрузитесь в спецификацию contrast ratio — минимум 4.5:1 для обычного текста и 3:1 для крупного. Вы узнаете, что браузеры по-разному обрабатывают атрибут role в зависимости от движка, и что aria-live может быть polite, assertive или off — и каждый вариант даёт разную задержку озвучивания. Конкретные числа, конкретные свойства, конкретные тесты.
Как технические стандарты WCAG 2.2 меняют вёрстку
Каждый уровень соответствия (A, AA, AAA) предъявляет измеримые требования. Для достижения AA (самый распространённый стандарт для государственных и коммерческих сайтов) необходимо обеспечить: контраст не ниже 4.5:1, возможность навигации только с клавиатуры без застревания в focus trap, и текстовые эквиваленты для всех нетекстовых элементов. Эти критерии проверяются автоматическими инструментами (axe DevTools, WAVE) и ручным тестированием. На курсе вы пройдёте чек-лист из 50 пунктов — каждый с точным указанием, какой HTML-элемент или ARIA-атрибут нужно использовать.
Ошибка в одном aria-label может сделать интерактивный элемент невидимым для скринридера. Например, если у кнопки нет текстового содержимого, но есть aria-label, устройство прочитает его — но только если role элемента соответствует кнопке. Если поставить role="button" на <div>, а aria-label не задать — пользователь услышит пустоту. Каждая деталь имеет значение, и вы научитесь видеть их на уровне спецификации.
ARIA-атрибуты: что, зачем и как именно
Accessible Rich Internet Applications (ARIA) — это не дополнение, а обязательный слой для динамических интерфейсов. aria-expanded сообщает, открыт ли аккордеон. aria-current помечает активную страницу в навигации. aria-hidden прячет декоративные элементы от скринридера, но его неправильное использование может скрыть важный контент. Каждый атрибут имеет свою спецификацию, и вы отработаете их на реальных макетах: модальные окна, autocomplete, выпадающие меню, drag-and-drop.
Особое внимание уделяется состоянию фокуса. У :focus-visible и :focus разная логика: первый показывается только при клавиатурной навигации, второй — всегда. Для доступности критично использовать :focus-visible, чтобы не запутывать пользователей мыши, но давать чёткий контур тем, кто перемещается по Tab. Вы узнаете, как настроить контур с толщиной не менее 2px и с контрастным цветом, отличным от фона.
Контраст и цвета: точные цифры и инструменты проверки
Соотношение контраста рассчитывается по формуле: (L1 + 0.05) / (L2 + 0.05), где L1 — относительная яркость более светлого цвета, L2 — более тёмного. Недостаточно просто посмотреть — нужно измерить. На курсе вы освоите работу с Color Contrast Analyzer и с WebAIM Contrast Checker. Вы узнаете, что при выборе палитры не полагаться на зрение, а проверять каждый цветовой канал: градиенты, полупрозрачность, фоны с текстурами — всё это снижает реальный контраст.
Для AAA уровня контраст должен быть 7:1 для обычного текста. Это исключает многие пастельные оттенки. Вы поймёте, как подбирать цветовую схему, которая одновременно соответствует бренду и проходит все проверки. Например, если брендовый синий (#1a73e8) на белом фоне даёт контраст 4.5:1 — этого достаточно для AA, но для AAA нужно затемнить или изменить фон. Конкретные Hex-коды и рекомендации по их модификации.
Семантическая разметка: как DOM влияет на accessibility tree
Accessibility tree строится на основе DOM, но не совпадает с ним. <div> с обработчиком клика не передаёт информацию о своём предназначении. <button> — передаёт. <nav> автоматически создаёт landmark, который можно быстро найти скринридером. <main> отмечает основное содержание. Вы научитесь выбирать правильный элемент для каждого блока: формы — только <form> с role="form" для старых браузеров, таблицы данных — только <table> с <caption> и <th scope="...">.
Ошибка в иерархии заголовков — <h1> затем <h3> — нарушает принцип последовательной навигации. Пользователь скринридера может пропустить раздел, потому что не поймёт структуру. Вы отработаете правильную вложенность: <h1> — уникальный на странице, <h2> — разделы, <h3> — подразделы. Без прыжков, без пропусков.
Клавиатурная навигация и элементы форм
Все интерактивные элементы должны быть достижимы и управляемы только с клавиатуры. tabindex="0" включает элемент в естественный порядок, tabindex="-1" позволяет фокусироваться программно, но не через Tab. tabindex="5" — антипаттерн, ломает ожидаемый порядок. Вы научитесь управлять фокусом в сложных компонентах: каруселях, панелях вкладок, деревьях навигации.
Формы требуют связанных <label> для каждого поля. for и id должны совпадать — это не рекомендация, а обязательное условие. Если метка не связана, скринридер не найдёт пояснение. Вы также научитесь группировать поля с помощью <fieldset> и <legend>, чтобы пользователь понимал, какие данные относятся к одной категории (например, группа переключателей для выбора страны).
Практические инструменты и ежедневная проверка
Вы освоите не только теорию, но и инструменты для постоянного контроля. Среди них:
- Axe DevTools — расширение для Chrome, которое автоматически находит до 90% нарушений WCAG. Интегрируется в CI/CD и даёт отчёт с номерами критериев.
- WAVE — проверяет контраст, ARIA-атрибуты и структуру заголовков прямо в браузере с цветовой индикацией ошибок.
- NVDA — бесплатный скринридер для Windows. Вы прослушаете свои страницы и поймёте, как их воспринимают незрячие пользователи.
- Lighthouse — встроенный в Chrome инструмент для аудита производительности и доступности (с оценкой от 0 до 100). Цель — не меньше 90 баллов.
- Colour Contrast Analyser — настольное приложение для измерения контраста на экране с пипеткой и сохранение результатов.
Каждый инструмент даёт не просто «зелёную галочку», а конкретные указания: например, «цвет фона #FFD700 при тексте #333333 даёт контраст 3.2:1 — требуется не менее 4.5:1». Вы исправляете ошибку, перепроверяете и видите зелёный свет. Так строится уверенность.
Критерии приёмки (Acceptance Criteria) для доступности
При разработке нового компонента вы будете использовать чек-лист, который включает:
- Проверку семантики: правильный HTML-тег и роль (например,
<button>илиrole="button"). - Проверку контраста: текста, границ, иконок (не менее 3:1 для некрупных иконок).
- Проверку фокуса: видимый контур, толщина не менее 2px, отступ от элемента 1-2px.
- Проверку текстовых эквивалентов:
altдля изображений,aria-labelдля иконок-кнопок. - Проверку клавиатуры: все действия доступны с Tab, Enter, Escape. Нет dead-зон.
- Проверку динамики: уведомления через
aria-live, сворачивание/разворачивание черезaria-expanded. - Проверку масштабирования: при увеличении до 200% интерфейс не ломается и не теряет функциональность.
Каждый пункт можно проверить автоматизированным тестом (Jest + axe-core) или вручную. Вы научитесь и тому, и другому, чтобы интегрировать контроль в рабочий процесс.
Заключение: от стандарта к привычке
Когда каждый новый проект начинается с семантического каркаса, когда цвета проверяются инструментом до написания CSS, когда фокус контур продуман заранее — доступность становится не дополнительной задачей, а фундаментом. Вы перестанете делать «доступную версию» в конце и начнёте строить доступное с первой строчки кода. И именно такой подход — единственный, который гарантирует соответствие современным стандартам и удовлетворение пользователей с любыми возможностями.
Начните с одного компонента: возьмите форму регистрации, добавьте <label>, проверьте контраст, убедитесь, что все поля достигаются через Tab. Через месяц это будет автоматика. Через полгода — неотъемлемая часть вашего стиля кодирования.
Добавлено: 23.04.2026
