Основы доступности, которые должен знать каждый веб-разработчик
Вы создали стильный сайт с современными фреймворками, но когда пользователь, использующий скринридер, пытается навигировать, он теряется. Или человек, который не может пользоваться мышью, обнаруживает, что ваше кастомное выпадающее меню невозможно открыть. Доступность — это не просто галочка в чек-листе, а фундаментальная часть качественной веб-разработки. В этой статье вы узнаете основные принципы и практические методы, чтобы сделать ваши сайты удобными для всех.
Почему доступность важна
Доступность (часто сокращается как a11y) гарантирует, что люди с инвалидностью могут воспринимать, понимать, навигировать и взаимодействовать с вебом. Это включает людей с нарушениями зрения, слуха, моторики и когнитивных функций. Помимо этической необходимости, доступные сайты часто лучше ранжируются в поисковых системах, охватывают более широкую аудиторию и соответствуют юридическим требованиям, таким как ADA или WCAG.
Более того, улучшения доступности приносят пользу всем пользователям. Чёткие заголовки, сочетания клавиш и высокий контраст помогают людям при ярком солнечном свете, на медленном соединении или с временно травмированными руками. Речь идёт об универсальном дизайне.
Основные принципы: POUR
Руководства по доступности веб-контента (WCAG) построены на четырёх принципах, которые удобно запомнить как POUR:
- Воспринимаемость (Perceivable): Информация должна быть представлена так, чтобы все пользователи могли её воспринимать. Предоставляйте текстовые альтернативы для изображений, субтитры для видео и достаточный цветовой контраст.
- Управляемость (Operable): Пользователи должны иметь возможность управлять интерфейсом. Убедитесь, что все функции доступны с клавиатуры, и дайте пользователям достаточно времени для чтения контента.
- Понятность (Understandable): Контент и управление должны быть понятными. Используйте чёткий язык, предсказуемую навигацию и помощь при вводе.
- Надёжность (Robust): Контент должен работать с текущими и будущими вспомогательными технологиями. Пишите валидный, семантический HTML.
Начните с семантического HTML
Основа доступности — использование правильных HTML-элементов по назначению. Скринридеры полагаются на семантику элементов для передачи смысла. <button> объявляется как кнопка и по умолчанию получает фокус; <div> с обработчиком клика — нет.
Общие семантические элементы, которые следует использовать:
<nav>для блоков навигации<main>для основного контента<h1>–<h6>для заголовков в логическом порядке<button>для кликабельных действий<a>для ссылок<ul>,<ol>,<li>для списков<label>связанный с полями формы
Например, вместо:
<div>Submit</div>
Используйте:
<button type="button">Submit</button>
Это простое изменение делает элемент управления фокусируемым, объявляет его роль и позволяет активировать его с клавиатуры.
Навигация с клавиатуры и управление фокусом
Многие пользователи не могут использовать мышь. Они полагаются на клавишу Tab для перемещения по интерактивным элементам. Убедитесь, что:
- Все интерактивные элементы доступны через Tab.
- Порядок табуляции следует логической последовательности.
- Фокус всегда виден (не удаляйте обводку без замены).
- Кастомные виджеты (например, модальные окна или выпадающие списки) правильно захватывают фокус и возвращают его при закрытии.
Проверьте свой сайт, отключив мышь и используя только клавиатуру. Сможете ли вы получить доступ ко всем функциям?
ARIA: используйте с осторожностью
Атрибуты ARIA (Accessible Rich Internet Applications) могут улучшить доступность, когда нативный HTML не справляется. Однако первое правило ARIA: не используйте ARIA, если можно использовать нативный HTML. Например, используйте <button> вместо <div role="button">.
Когда ARIA действительно нужна, распространённые атрибуты включают:
aria-labelдля предоставления метки, когда нет видимого текста.aria-expandedдля указания, открыт ли сворачиваемый раздел.aria-hidden="true"для скрытия декоративных элементов от скринридеров.roleдля определения назначения элемента, когда нет семантического тега.
Неправильное использование ARIA может ухудшить ситуацию, поэтому всегда тестируйте с вспомогательными технологиями.
Цвет и контраст
Достаточный цветовой контраст гарантирует, что текст читаем людьми с ослабленным зрением или дальтонизмом. WCAG рекомендует коэффициент контраста не менее 4.5:1 для обычного текста и 3:1 для крупного текста (18pt+ или 14pt жирный). Используйте такие инструменты, как WebAIM Contrast Checker, для проверки.
Также никогда не полагайтесь только на цвет для передачи информации. Например, если вы используете красный цвет для обозначения ошибки, добавьте также иконку или текстовое сообщение.
Текстовые альтернативы для изображений
Каждое изображение должно иметь атрибут alt. Значение зависит от контекста:
- Если изображение передаёт информацию, опишите его кратко:
alt="Красный предупреждающий треугольник". - Если оно декоративное, используйте пустой alt:
alt="". - Если это сложный график, предоставьте более длинное описание рядом или через
aria-describedby.
Отсутствие alt-текста — одна из самых распространённых ошибок доступности. И её легко исправить.
Тестирование сайта на доступность
Автоматизированные инструменты могут выявить около 30% проблем. Ручное тестирование критически важно. Вот практический рабочий процесс:
- Запустите автоматический аудит: Используйте axe DevTools, Lighthouse или WAVE, чтобы найти очевидные проблемы.
- Тест клавиатуры: Навигируйте по сайту, используя только Tab, Shift+Tab, Enter и стрелки.
- Тест скринридера: Попробуйте VoiceOver (Mac), NVDA (Windows) или Orca (Linux). Послушайте, как объявляется контент.
- Масштабирование и контраст: Увеличьте масштаб до 200% и проверьте, остаётся ли контент удобным. Проверьте коэффициенты контраста.
- Тестирование с пользователями: По возможности включайте людей с инвалидностью в юзабилити-тестирование.
Распространённые ошибки, которых следует избегать
- Использование
divилиspanдля кнопок и ссылок. - Удаление обводки фокуса без предоставления альтернативы.
- Добавление
aria-hidden="true"к фокусируемым элементам. - Использование placeholder-текста в качестве единственной метки для полей ввода.
- Автовоспроизведение медиа со звуком.
- Недостаточный цветовой контраст.
Краткий справочник: что делать и чего не делать
| Делайте | Не делайте |
|---|---|
| Используйте семантические HTML-элементы | Используйте div для всего |
| Предоставляйте текстовые альтернативы | Оставляйте атрибуты alt пустыми для информативных изображений |
| Обеспечьте управление с клавиатуры | Полагайтесь только на события мыши |
| Поддерживайте достаточный контраст | Используйте светло-серый текст на белом |
| Подписывайте поля форм | Используйте placeholder как метки |
FAQ
В чём разница между WCAG A, AA и AAA?
Уровни соответствия WCAG указывают на возрастающую доступность. Уровень A — минимальный, AA — стандарт, на который ссылается большинство законов, а AAA — высший уровень, часто непрактичный для всего контента. Стремитесь к AA.
Можно ли использовать ARIA для исправления всех проблем доступности?
Нет. ARIA следует использовать только тогда, когда нативный HTML не может обеспечить нужную семантику. Неправильная ARIA может навредить доступности. Всегда предпочитайте семантический HTML.
Как проверить мой сайт на доступность?
Сочетайте автоматизированные инструменты (например, axe или Lighthouse) с ручными проверками: навигация с клавиатуры, тестирование скринридером и анализ цветового контраста. По возможности привлекайте пользователей с инвалидностью.
Готовы улучшить доступность вашего сайта? Начните с проверки структуры HTML и поиска распространённых проблем. Для быстрого форматирования и валидации JSON попробуйте наш JSON Formatter, чтобы убедиться, что ваши данные чистые и хорошо структурированы.