5.3 Доступность

Обзор и мотивация

Доступность (нередко сокращаемая до «a11y») это практика построения программ, которые люди с ограниченными возможностями могут воспринимать, понимать, ориентироваться в них и использовать. Это включает людей слепых или слабовидящих, глухих или слабослышащих, с двигательными нарушениями, с когнитивными или учебными особенностями и сталкивающихся с временными или ситуативными ограничениями вроде сломанной руки, яркого солнца или шумной комнаты. Примерно у одного из пяти человек есть ограничение возможностей, а от доступного дизайна в какой-то момент выигрывает каждый. Это не нишевое приспособление. Это базовый уровень качества.

Для больших команд доступность нужно встроить в систему, а не оставлять на добрые намерения отдельных людей. Когда многие команды поставляют в один продукт, один недоступный компонент (поле формы без подписи, индикатор статуса только цветом, ловушка клавиатуры в модальном окне) может запереть пользователей с ограниченными возможностями вне целого пути. Встраивание доступности в общие компоненты, токены дизайна, конвейеры тестирования и определения готовности единственный способ сделать её надёжной в масштабе. Дооснащение постфактум дорого и подвержено ошибкам. Проектирование заранее дёшево и долговечно.

Для государства доступность юридическое требование и гражданская обязанность, а не приятное дополнение. Государственные услуги должны служить каждому члену общества, а у граждан с ограниченными возможностями нередко нет альтернативного поставщика: если сайт правительства недоступен, они не могут получить своё пособие, лицензию или проголосовать иным способом. Законы и стандарты по всему миру делают доступность обязательной для государственных органов и всё чаще для частного сектора. Эта глава воспринимает доступность как три вещи одновременно: юридическую обязанность, этическую обязанность и просто хороший дизайн.

См. также: глава 5.2 (дизайн интерфейсов и дизайн-системы), глава 5.6 (фронтенд-разработка) и глава 5.1 (основы UX).

Ключевые принципы

Доступность базовый атрибут качества, как безопасность и производительность, а не необязательная функция.
Принципы POUR: интерфейсы должны быть воспринимаемыми (Perceivable), управляемыми (Operable), понятными (Understandable) и надёжными (Robust).
Сначала семантический HTML; используйте ARIA только для заполнения подлинных пробелов, никогда как замену нативным элементам.
Всё, что можно использовать мышью, должно быть доступно одной клавиатурой.
Не передавайте информацию только цветом, формой или положением.
Автоматические инструменты ловят лишь часть проблем; ручное тестирование и тестирование с вспомогательными технологиями необходимы.
Доступный дизайн лучше для всех (“эффект бордюрного спуска”, когда функции, построенные для людей с ограниченными возможностями, приносят пользу всем).
Проектируйте и тестируйте вместе с людьми с ограниченными возможностями, а не только для них.

Компромиссы: плюсы и минусы

Подход	Плюсы	Минусы
Встраивать доступность с самого начала	Дешевле всего, долговечно, лучше для всех	Требует предварительного обучения и дисциплины
Дооснащать / устранять позже	Откладывает усилия, разблокирует быстрый запуск	Намного дороже, хрупко, юридическая экспозиция в промежутке
Только автоматическое тестирование	Быстро, дёшево, ловит регрессии в CI	Пропускает ~две трети проблем; ложная уверенность
Ручное тестирование + со вспомогательными технологиями	Ловит реальные барьеры удобства использования	Медленнее, нужны опытные тестировщики и устройства
Тестирование с пользователями с ограниченными возможностями	Истина о реальном опыте	Усилия и цена набора, нужно делать уважительно

Центральный компромисс это предварительная дисциплина против отложенной цены. Доступность, встроенная заранее, недорога и улучшает качество для всех; доступность, дооснащаемая под юридическим давлением, дорога, неполна и стрессова. В долгосрочной перспективе нет настоящего компромисса со «скоростью»: недоступная программа просто не работает для пятой части ваших пользователей. Это дефект, а не экономия.

Вопросы для обсуждения с командой

Валят ли регрессии доступности нашу сборку так, как сломанный тест, а если нет, почему? Автоматические сканеры ловят лишь около трети проблем, но те, что они ловят (отсутствующие подписи, провалы контраста, элементы управления без подписей), дёшево ловить в CI и дорого находить в аудите перед запуском. Воспринимание регрессии как отказа сборки то, что переводит доступность из героических усилий отдельных людей в надёжное свойство системы, а это единственное, что работает, когда многие команды поставляют в один продукт. Решите, какие проверки блокирующие, какие рекомендательные и кто может переопределить отказ. Принесите на встречу результаты вашего текущего сканера и ваше определение готовности. Если критерии доступности не записаны в определение готовности на каждую историю, их отодвинут в миг, когда срок сожмётся.
Каково наше правило для заказных виджетов и кто рецензирует ARIA до выпуска? Нативные элементы HTML приходят с поведением клавиатуры и поддержкой вспомогательных технологий даром, а неправильный ARIA хуже никакого, потому что активно вводит в заблуждение программы чтения с экрана. Договоритесь, что семантический HTML значение по умолчанию и что любой заказной виджет (самодельный выпадающий список, выбор даты или модальное окно) требует прохода с клавиатуры и программой чтения с экрана перед слиянием в соответствии с практиками разработки ARIA. Это важнее всего для интерактивных компонентов, повторно используемых многими командами, потому что одно сломанное модальное окно с ловушкой клавиатуры может запереть пользователей с ограниченными возможностями вне целого пути. Принесите список ваших заказных виджетов и спросите, какие тестировались с настоящей программой чтения с экрана. Те, что нет, обязательства, скрытые в общем коде.
Какова наша политика в отношении оверлеев доступности и верит ли кто-либо, что они настоящее исправление? Оверлеи рекламируются как скрипт из одной строки, делающий сайт соответствующим, и они соблазнительны, когда приходит юридическое давление, а срок маячит. Они не дают подлинного соответствия, могут ухудшить опыт пользователей вспомогательных технологий, а для государства оставляют лежащую в основе юридическую обязанность невыполненной. Решите явно, что вы будете вкладываться в семантическую разметку, поддержку клавиатуры и тестирование с людьми с ограниченными возможностями, а не покупать виджет, замазывающий проблему. Принесите цену подписки на оверлей и сравните с построением доступности в ваши компоненты и конвейер один раз. Ранняя постановка этого предотвращает паническое решение о закупке позже, тратящее деньги и ничего не исправляющее.
Участвуют ли люди с ограниченными возможностями в нашем дизайне и тестировании или мы всё ещё проектируем для воображаемого пользователя, которого сами выдумали? Автоматические сканеры и даже экспертные аудиты говорят, соответствует ли разметка; они не говорят, может ли слепой пользователь действительно завершить ваше оформление заказа или человек с когнитивным нарушением понять ваши сообщения об ошибках. Привлечение участников с ограниченными возможностями единственный источник истины, и оно меняет то, что вы строите, но поднимает реальные вопросы о том, как честно набирать, как компенсировать людям их время и как не воспринимать одного участника как представителя каждого ограничения. Принесите ваш текущий список исследователей, практики набора и оплаты и честный подсчёт, сколько изучений за последний год включало участников с ограниченными возможностями. Для большой организации постоянная панель с честной компенсацией и охватом по зрению, слуху, двигательным и когнитивным потребностям то, что превращает это из разового жеста в надёжный вход; в государстве привлечение общества, которому вы служите, нередко часть юридического и гражданского обязательства, а не необязательная любезность.
Когда мы покупаем или встраиваем сторонний компонент, требуем ли мы доказательства доступности и кто это проверяет? Многое из поставляемого в большом продукте не написано внутри: выбор даты из библиотеки, платёжный виджет во фрейме, пакет диаграмм, целый модуль SaaS. Один недоступный встроенный компонент может провалить весь путь, как бы ни был чист ваш собственный код, а после подключения его замена дорога. Решите, что доступность требование закупок, что поставщики обязаны предоставить отчёт о соответствии доступности (документ вроде VPAT, указывающий, как продукт измеряется относительно WCAG) и что кто-то технический проверяет заявление, а не подшивает его. Принесите опись ваших сторонних компонентов и спросите, у каких есть актуальные достоверные свидетельства соответствия. В корпоративных и государственных закупках записывайте соответствие WCAG 2.2 AA и право на устранение в договор, потому что обещание до подписания гораздо дешевле принудить, чем барьер, обнаруженный после ввода в работу.
Каков наш целевой уровень соответствия, кто им владеет и как мы держим его актуальным по мере движения стандартов? WCAG 2.2 AA сегодняшний пол, и на него ссылается большинство законов, но 2.2 добавил критерии, которые многие команды не приняли, а WCAG 3.0 приходит с иной структурой. Без названного владельца стандарт дрейфует: разные команды нацеливаются на разные версии, никто не отслеживает разрыв, а соответствие тихо гниёт между аудитами. Решите точную версию и уровень, по которым строите, у кого полномочия его повышать и как новые критерии попадают в дизайн-систему и определение готовности. Принесите вашу текущую заявленную цель, свидетельства того, где команды реально её достигают, и короткую дорожную карту принятия пропущенных критериев 2.2. Для большой или публичной организации владелец доступности или центр компетенций, опубликованное заявление о доступности и документированный план на следующую версию стандарта то, что позволяет ответить регулятору или суду свидетельствами, а не добрыми намерениями.

Взгляд по секторам

Стартап. Скорость здесь на вашей стороне, потому что доступность дешевле всего, пока кодовая база мала. Добавьте автоматический сканер в CI и проход с клавиатуры в контрольный список запроса на слияние с первого спринта и опирайтесь на семантический HTML, чтобы получить поддержку клавиатуры и программ чтения с экрана даром. Пропустите оверлеи и тяжёлые инструменты; отдача в том, что когда закупочная команда клиента попросит отчёт о соответствии посреди продажи, вы ответите за дни, а не метаясь.

Малый бизнес. Без специалиста по доступности и при ограниченном бюджете покупайте доступность, а не стройте её: выбирайте платформу, тему или библиотеку компонентов, которая уже соответствует и заявляет об этом, и предпочитайте поставщиков, публикующих заявление о доступности. Покрывайте высокоценные основы сами бесплатными инструментами, проверкой только клавиатурой, проверкой контраста и ясными подписями у каждого поля, потому что это ловит отказы, чаще всего исключающие клиентов. Воспринимайте неверный или непригодный автоматический поток как потерянного клиента, поскольку малый бизнес редко предлагает канал с помощью, к которому можно откатиться.

Крупная организация. В масштабе работа в том, чтобы сделать доступность свойством системы по многим командам. Поставляйте доступные компоненты по умолчанию в дизайн-системе, блокируйте регрессии в CI и поднимите владельца или центр компетенций с процессом устранения и обучением для дизайнеров, инженеров и авторов контента. Отслеживайте соответствие во времени как метрику, записывайте соответствие WCAG в закупки и управляйте сторонними компонентами как портфелем, чтобы один встроенный виджет не мог тихо провалить общий путь.

Государственный сектор. Доступность юридический мандат и гражданский долг, поскольку у граждан с ограниченными возможностями нередко нет альтернативного поставщика пособия, лицензии или голосования. Стройте по стандарту, на который ссылается ваша юрисдикция (например, Section 508, EN 301 549 или Европейский акт о доступности, отображённые на WCAG 2.2 AA), публикуйте заявление о доступности с путём сообщения о барьерах и тестируйте с обществом с ограниченными возможностями, которому вы служите. Отвергайте оверлеи как замену настоящему соответствию и требуйте от поставщиков предоставить достоверные свидетельства и право на устранение в контракте.

Примеры

Стартап. Стартап из трёх человек, строящий инструмент найма, добавил сканер доступности в сборку и быстрый проход с клавиатуры в контрольный список запроса на слияние с самого первого спринта, рассудив, что оставаться доступным дешевле, чем исправлять позже. Когда закупочная команда клиента среднего размера попросила отчёт о соответствии доступности в ходе цикла продаж, стартап уже использовал семантический HTML, подписал каждое поле и имел видимый фокус везде, поэтому ответил за дни, а не метаясь. Эта готовность выиграла сделку, которую конкурент проиграл по тому же требованию.

Крупная организация. Крупный ритейлер столкнулся с коллективным иском, потому что слепые клиенты не могли завершить оформление заказа с программой чтения с экрана. Помимо урегулирования и юридических расходов, компании пришлось устранять недостатки по срокам под надзором суда. Затем она перестроила доступность в свою дизайн-систему и конвейер CI, добавила тестирование программой чтения с экрана в определение готовности и обучила команды. Перестроенное доступное оформление заказа также повысило конверсию и сократило обращения в поддержку для всех: исправления, помогшие пользователям программ чтения с экрана (ясные подписи, сообщения об ошибках, логичный порядок), помогли всем пользователям.

Государственный сектор. Государственное ведомство пособий по закону должно было соответствовать WCAG 2.1 AA для своего онлайн-заявления. Раннее тестирование со слепыми и слабовидящими пользователями, пользователями только с клавиатуры и пользователями с когнитивными нарушениями показало, что индикатор «обязательное поле» только цветом, недоступный выбор даты и не объявляемые ошибки проверки мешали людям завершить. Исправление этого через семантическую разметку, видимый фокус, объявления ошибок в живых областях и помощь простым языком позволило гражданам с ограниченными возможностями впервые подавать заявление самостоятельно. Это сократило зависимость от помощи лично и снизило стоимость обслуживания, выполнив юридический мандат.

Бизнес-обоснование: мотивы, ROI и TCO

Бизнес-обоснование опирается на охват рынка, юридический риск, стоимость обслуживания и качество. Люди с ограниченными возможностями и их семьи контролируют значительную покупательную способность; их исключение её упускает. Доступные услуги сокращают потребность в дорогих каналах с помощью (телефон и личная помощь), что прямая операционная экономия, особенно для государства. А поскольку улучшения доступности (ясные подписи, поддержка клавиатуры, читаемое содержимое, надёжная разметка) помогают всем, они обычно повышают общее завершение и удовлетворённость.

По TCO стоимость принятия это обучение, инструменты и встраивание доступности в компоненты и конвейеры, всё скромно, когда делается с самого начала. Цена непринятия сурова и приходит с нескольких сторон: юридическая ответственность (иски, урегулирования, предписанное судом устранение, регуляторные штрафы), гораздо более высокая цена дооснащения под давлением срока, репутационный ущерб и постоянная цена обслуживания исключённых пользователей по более дорогим каналам. Дооснащение обычно стоит в несколько раз больше, чем стоило бы проектирование заранее.

Чтобы обосновать это перед руководством, начинайте с юридического обязательства там, где оно применяется (оно не подлежит обсуждению для государства и всё чаще для частного сектора). Затем выразите числами охватываемое население, которое вы исключаете, стоимость каналов с помощью, порождаемую этим исключением, и выигрыш «бордюрного спуска» для всех пользователей. Подавайте доступность как управление рисками плюс качество, а не благотворительность.

Антипаттерны и ловушки

Доступность как галочка перед запуском: аудит в конце вместо непрерывной практики, гарантирующий дорогую переделку в последний момент.
«Суп из div»: несемантическая разметка с обработчиками щелчков на общих элементах, невидимая вспомогательным технологиям.
Неверное использование ARIA: прикручивание ARIA к сломанной разметке, вводящее программы чтения с экрана в заблуждение сильнее обычной разметки.
Информация только цветом: статус только цветом, невидимый дальтоникам.
Невидимый фокус: удаление контуров фокуса ради эстетики, оставляющее пользователей клавиатуры без пути.
Ловушки клавиатуры: модальные окна и виджеты, захватывающие или теряющие фокус.
Самодовольство по автоматическому сканированию: прохождение сканера и допущение, что продукт доступен.
Оверлеи доступности: сторонние виджеты «исправление в одну строку», не дающие настоящего соответствия и способные ухудшить опыт.
Исключение пользователей с ограниченными возможностями из исследований: проектирование для воображаемого пользователя с ограничениями вместо тестирования с настоящими.

Модель зрелости

Уровень 1: Начальный. Нет практики доступности. Проблемы обнаруживаются только когда пользователь жалуется или приходит иск, а реакция реактивна. Разметка несемантическая и не тестируется, и никто не владеет проблемой.

Уровень 2: Развитие. Осведомлённость есть, и некоторые команды действуют: автоматический сканер в сборке здесь, проход с клавиатуры там, аудит перед запуском перед большим выпуском. Практика базовая и непоследовательная между командами, доступность всё ещё контрольный список поздней стадии и нередко отодвигается под давлением расписания.

Уровень 3: Стандартизация. WCAG 2.2 AA документированный стандарт, принуждаемый по организации. Доступность встроена в дизайн-систему, так что компоненты поставляются доступными по умолчанию, тестируются автоматически и вручную и записаны в определение готовности. Команды обучены, есть владелец или центр компетенций, и определён процесс устранения.

Уровень 4: Управление. Доступность измеряется и контролируется данными относительно базовых значений. Организация отслеживает метрики соответствия во времени (доли прохождения сканера, число открытых барьеров по серьёзности, покрытие критичных путей тестированием программой чтения с экрана и время устранения), сообщает их по командам на панели и воспринимает регрессии как отказы сборки, а не рекомендательные предупреждения. Цели заданы относительно базового значения, а прогресс пересматривается, так что отстающая команда видна до того, как её находит аудит.

Уровень 5: Оркестрация. Доступность непрерывно улучшается и интегрирована по организации. Люди с ограниченными возможностями регулярно участвуют в исследованиях и тестировании, а доступность встроена в закупки, токены дизайна и CI. Организация адаптируется по мере движения стандартов (принимая новые критерии WCAG и готовясь к WCAG 3.0) и влияет на поставщиков и партнёров, так что соответствует вся цепочка поставки.

Идеи для обсуждения

Как не дать доступности быть отодвинутой, когда сроки сжимаются?
Какова правильная смесь автоматического, ручного и пользовательского тестирования для вашего профиля риска?
Как следует записывать соответствие доступности в договоры с поставщиками и закупки?
Как обращаться с разрывом между соответствием WCAG и подлинным удобством для людей с ограниченными возможностями?
Как командам готовиться к WCAG 3.0, строя сегодня по 2.2?
Как честно и уважительно набирать и компенсировать участников исследований с ограниченными возможностями?

Главные выводы

Доступность базовый атрибут качества и, для государства, юридическое требование.
Проектируйте по WCAG 2.2 AA как по полу; используйте принципы POUR как ментальную модель.
Сначала семантический HTML; ARIA только для заполнения реальных пробелов и сделанный правильно.
Автоматические инструменты ловят около трети проблем; ручное тестирование и тестирование со вспомогательными технологиями необходимы.
Тестируйте с людьми с ограниченными возможностями, а не только для них.
Встроить доступность дёшево и долговечно; дооснащать дорого и хрупко.
Доступный дизайн лучше для всех: эффект бордюрного спуска реален.

Источники и дополнительное чтение

W3C, Web Content Accessibility Guidelines (WCAG) 2.2 and supporting Understanding/Techniques documents
W3C, WAI-ARIA Authoring Practices Guide
W3C Web Accessibility Initiative (WAI), introductory and tutorial materials
Laura Kalbag, Accessibility for Everyone
Sarah Horton and Whitney Quesenbery, A Web for Everyone
Regine Gilbert, Inclusive Design for a Digital World
U.S. Section 508 standards and Section508.gov guidance
European standard EN 301 549 and the European Accessibility Act
Government accessibility guidance (e.g., UK GDS accessibility manual)
WebAIM, research and articles including the annual accessibility analyses

5.3 Доступность

Обзор и мотивация

Ключевые принципы

Рекомендации

Проектируйте и стройте по WCAG, нацеливаясь на текущий стандарт

Используйте семантический HTML и правильный ARIA

Гарантируйте управляемость с клавиатуры и вспомогательными технологиями

Тестируйте автоматическими инструментами, ручной рецензией и настоящими пользователями

Делайте доступность организационной, а не героической