Александр Чудеснов написал, как сделать доступным продукт из множества приложений, которые написаны разными командами.

— Страница с правильной цветовой контрастностью, структурой заголовков и HTML-вёрсткой, скорее всего, уже отвечает критериям доступности;
— Есть нюансы: разная реализация некоторых функций в разных браузерах, отдельные неудобные элементы вроде нативного поля ввода даты;
— Проблема в том, что Single Page Applications выходят за рамки возможностей HTML. В них много компонентов, которые не предоставляет сам браузер. При их создании надо отвечать на множество вопросов о взаимодействии с помощью клавиатуры, разметке для скринридеров, управлении фокусом;
— Дизайн-система не всегда спасает: проработанный компонент из ДС может не подходить продукту и не использоваться;
— Относитесь к ДС как к продукту: собирайте статистику использования и обратную связь, отслеживайте и исправляйте проблемы;
— ДС должна решать проблемы команд, предоставлять компоненты с разумными дефолтами, которые можно менять в определённых рамках. Без инструкций в формате «собери сам»;
— Есть проблема в совмещении визуальных и интерактивных паттернов. Кроме визуального стиля компонента важно прорабатывать способы взаимодействия с ним и возможную композицию с другими элементами;
— ДС может содержать визуальный слой, слой интерактивных паттернов и отдельно — собранные готовые компоненты (как в ДС Adobe Spectrum);
— Не пренебрегайте автоматическим тестированием. Тестировать компоненты в разных состояниях проще в Storybook, чем в продакшене. После ручного аудита (в Lighthouse или axe DevTools) стоит написать автоматизированные тесты (axe-Selenium);
— Важно, чтобы доступность интерфейсов стала частью культуры компании: помогите сформировать запрос на доступность, зовите на тестирование людей с инвалидностью, дайте сотрудникам возможность научиться создавать доступные продукты, установить цели, связанные в том числе и с процессами («80% команд знают и используют принципы обеспечения доступности»).

#accessibility