WebView | Web Mobile | Web Desktop
Разработка
WCAG
Один из основных ориентиров при разработке веб-приложений в части доступности — это стандарт W3C Web Content Accessibility Guidelines (WCAG).
Требования в нём подразделяются на 3 уровня:
- Level A - базовый, очень простой уровень
- Level AA - уровень доступности достаточный для большинства людей с ограничениями
- Level AAA - продвинутый уровень доступности
WCAG Level AA — это тот уровень, который нужно реализовать как baseline (базовый минимум). Он покрывает наибольшую часть критических и распространённых проблем доступности.
Карты для более удобной навигации по конкретным пунктам спецификации относительно уровней:
ARIA
ARIA-атрибуты — это семантическое расширение разметки HTML, позволяющее сделать вёрстку более доступной для ассистивных технологий. Суть и логика подобных расширений описаны в отдельной спецификации.
При работе с ARIA есть 4 важных правила:
- Главное и первое правило при использовании ARIA: если можно обойтись без ARIA, следует избегать его в пользу правильной семантической разметки. Семантические теги
<button>,<a>,<label>, заголовки, списки, таблицы и визуально скрытые текстовые подсказки (например, через класс.visually-hidden) гораздо лучше взаимодействуют с ассистивными технологиями, чем ARIA-атрибуты. - Не изменяйте исходные семантические параметры, если в этом нет крайней необходимости.
- Все интерактивные элементы управления ARIA должны быть совместимы с клавиатурой.
- Не используйте атрибуты
role="presentation"илиaria-hidden="true"для элемента, на котором можно сфокусироваться.
Шаблоны APG
Для сложных компонентов, таких как меню, вкладки, диалоговые окна, аккордеоны, карусели, поля со списком, ползунки и т. д., следуйте устоявшимся шаблонам разметки из ARIA Authoring Practices Guide (APG).
Туториалы WAI
При работе с конкретными компонентами обращайтесь к официальным материалам W3C Web Accessibility Initiative (WAI) — подразделения W3C, которое фокусируется и занимается вопросами доступности:
Практические руководства WAI:
- Общие советы по разработке: WAI Tips
- Простые проверки: WAI Test-Evaluate
Библиотеки компонентов и UI Kit
Лучшим советом в части доступности будет рекомендовать брать уже готовые популярные решения — библиотеки компонентов, в которых уже учтены все нюансы доступности, ARIA-разметки и взаимодействия с ассистивными технологиями / экранными дикторами.
Примеры популярных UI Kit с доступностью из коробки:
Как правило, в таких библиотеках уже учтена работа с фокусом (Focus Lock / Focus Trap, Focus Management), правильная семантика и ARIA-атрибуты, а также они протестированы с большинством популярных экранных дикторов. Если разрабатывать свои компоненты, то придётся учитывать все эти механизмы и правила самому, а также самостоятельно тестировать компоненты на экранных дикторах.
Многие из этих библиотек предоставляют специальные компоненты-шаблоны для улучшения доступности. К примеру, в Chakra UI есть компонент SkipNavLink (для пропуска навигации) и VisuallyHidden (для визуального скрытия текста с сохранением доступности для дикторов).
Тестирование и Отладка
Инструменты автоматизации и сканирования могут найти только от 30% до 60% проблем с доступностью в приложении, поэтому ручного тестирования и отладки никак не избежать.
С помощью axe-core можно автоматически выявлять в среднем 57% проблем, соответствующих стандартам WCAG. Источник https://github.com/dequelabs/axe-core
Критически важно проверять доступность вручную, используя ассистивные технологии, поскольку только так можно оценить реальный опыт пользователей с ограниченными возможностями.
Обязательно тестируйте с экранными дикторами:
- На мобильных устройствах:
- Android: TalkBack (предустановлен)
- iOS: VoiceOver (предустановлен)
- На десктопе:
- NVDA (Windows) — бесплатный, наиболее популярный в среде тестировщиков
- JAWS (Windows) — платный, широко распространён в корпоративной среде
- VoiceOver (macOS) — встроен в систему
- Менее популярные, но также полезные:
- Orca (Ubuntu / Linux)
- Narrator (Windows) — встроенный базовый диктор
Популярность различных дикторов согласно отчету WebAIM можно посмотреть тут.
Инструменты аудита
Лучший инструмент аудита доступности на рынке — это Deque axe, который можно подключить как расширение в DevTools.
В дополнение можно использовать следующие инструменты:
- WAVE от WebAIM — онлайн-сервис для проверки семантики, структуры контента, порядка табуляции и контраста
- Colour Contrast Analyser (CCA) от Vispero/TPGi — десктопное приложение, которое позволяет удобно проверить контраст в разных местах
- Sim Daltonism — приложение для macOS, позволяющее проверить цвет и контраст относительно различных форм цветоаномалий (Альтернативная опция на iOS / macOS: Настройки → Универсальный доступ → Дисплей и размер текста → Фильтры цветов)
Альтернативные популярные сканеры доступности:
- Lighthouse (секция Accessibility) — встроен в Chrome DevTools
- WebHint (секция Accessibility, под капотом используется тот же Deque axe)
Статическая типизация
Один из самых дешевых способов автоматизировать проверку доступности на уровне кода — это статическая типизация. Почти все популярные статические анализаторы кода предлагают очень неплохую настройку проверки базовых правил доступности. По крайней мере, уже на этом уровне, можно добиться результата, где ни одна картинка не останется без alt-текста и ни один div/span не пробежит с событием onClick без соответствующей семантической роли.
Ниже список самых популярных линтеров и их настроек для правил по доступности:
- ESLint - eslint-plugin-jsx-a11y
- Oxlint - settings-jsx-a11y
- Biomejs - rules a11y
Тесты и Автоматизация
CI/CD
Более дорогой и ресурсоемкий вариант автоматизации проверки доступности это внедрить аудит страниц прямо в CI/CD конвейеры. Deque axe и Lighthouse имеют возможность подключения к CI/CD:
Runtime
Прямо в тестовом окружении или локально при разработке можно запустить программно axe-core и выводить в консоль результаты аудита:
if (isDevEnv() || isStageEnv()) {
// Даём приложению время догрузиться после ре-рендеров, чтобы меньше ложных срабатываний axe
const AXE_DEBOUNCE_MS = 6000;
void Promise.all([import('@axe-core/react'), import('react-dom')]).then(([axe, ReactDOM]) => {
axe.default(React, ReactDOM, AXE_DEBOUNCE_MS);
});
}E2E Tests
Более прагматичный вариант это внедрить проверку доступности прямо в тесты автоматизации, почти каждый популярный фреймворк тестирования предоставляет API для проверки доступности:
- Playwright
- Cypress
- WebDriver
Unit Tests
Независимо от инструмента конфигурирования и старта модульных JavaScript тестов, рекомендуется использовать фреймворк testing-library, который построен по принципу accessibility-first.
API этого инструмента при тестировании само по себе мотивирует к правильной семантике и разметке, методы вроде getByLabelText, getByRole, getByAltText и т.д. помимо основного модульного теста компонента несут в себе побочный эффект проверки и доступности.
ИИ-интеграция и агенты
AGENTS.md
При работе с ИИ агентами нужно обязательно явно прописать правила кодирования с прицелом на доступность.
Большинство LLM моделей обучаются на открытых данных интернета, где у большой части веб-сайтов имеются огромные проблемы с доступностью. Примеры разделов правил для AGENTS.md можно посмотреть в проектах с открытым исходным кодом.
Все вышеописанные разделы этого гайда также могут послужить хорошей базой для оформления и описания таких правил.
Agent Skills
Умения могут быть отдельным мощным инструментом как в реализации доступности в проекте и коде, так и в проверке уже существующей кодовой базы.
Примеры умений:
Связанные заметки
- [Практический аудит веб-доступности: 5 шагов без фанатизма]
- [Аудит доступности веб-приложения Приорбанка]
- [Аудит доступности Wildberries. Может ли незрячий пользователь купить Бэтмобиль?]
- [Skip Links — невидимый маркер хорошего вкуса]
- [Веб-доступность — это не хайп, а ответственность]
- [Веб и тактильная типографика]
- [Когда функции доступности ломают дизайн, а иногда и саму доступность]