Замечательно создавать сайты, которые доступны для всех. Существует как минимум шесть ключевых областей инвалидности, которые мы можем оптимизировать: зрение, слух, мобильность, когнитивные функции, речь и нервная система. Здесь могут помочь многие инструменты и ресурсы, даже если вы совершенно не знакомы с веб-доступностью.
Более 1 миллиарда людей живут с той или иной формой инвалидности. Возможно, вы в какой-то момент находились в громкой комнате, пытаясь услышать разговор вокруг вас, или в условиях слабого освещения, пытаясь найти что-то в темноте. Вы помните разочарование, которое вы испытали при этом обстоятельстве? Теперь представьте, было ли это временное состояние постоянным. Насколько отличается ваш опыт работы в Интернете?
Чтобы быть доступными, сайты должны работать на нескольких устройствах с различными размерами экрана и разными видами ввода, такими как программы чтения с экрана. Более того, сайты должны быть доступны для самой широкой группы пользователей, включая пользователей с ограниченными возможностями. Вот пример из нескольких ограничений, которые могут иметь ваши пользователи:
— Проблемы с обучаемостью — Сонливость или отвлечение — Мигрень — Аутизм — Судороги
— Окружающий шум — Боль в горле — Речевые затруднения — Невозможно говорить
— Депрессия — ПТСР — Биполярное — Тревога
Проблемы со зрением варьируются от невозможности различать цвета до полного отсутствия зрения.
Убедитесь, что для текстового содержимого соблюден минимальный порог контрастности.
Избегайте передачи информации, используя только цвет, и убедитесь, что размер всего текста можно изменять.
Убедитесь, что все компоненты пользовательского интерфейса могут использоваться с вспомогательными технологиями, такими как программы чтения с экрана, увеличители и дисплеи Брайля. Это влечет за собой гарантию того, что компоненты пользовательского интерфейса размечены так, что API-интерфейсы специальных возможностей могут программно определять роль состояние состояние значение и заголовок любого элемент.
Подсказка : при проверке элемента в Chrome, Edge и Firefox DevTools отображает всплывающую подсказку о свойствах CSS, которая включает быструю проверку соотношения цветового контраста.
/ *
Если пользователь выразил предпочтение уменьшенному движению, не используйте анимацию на кнопках.
* / @media ( предпочитает уменьшенное движение : уменьшать ) {
Кнопка { анимация : нет ; } }
Избегайте взаимодействий, основанных на времени.
Это может показаться большим количеством оснований, но мы пройдемся по процессу оценки, а затем улучшения доступности компонентов вашего пользовательского интерфейса.
Подсказка: Команда по доступности Gov.uk предлагает отличные цифровые плакаты, которые можно и не нужно использовать для распространения информации о лучших практиках в вашей команде:
При проверке доступности компонентов пользовательского интерфейса вашей страницы спросите себя:
Можно ли использовать компонент пользовательского интерфейса только с клавиатурой? Удалось ли ему сфокусироваться и избежать ловушек фокусировки? Может ли он реагировать на соответствующие события клавиатуры?
Можете ли вы использовать свой компонент пользовательского интерфейса с программой чтения с экрана? Предоставили ли вы текстовые альтернативы для любой информации, представленной визуально? Вы добавили семантическую информацию, используя ARIA?
Может ли ваш компонент пользовательского интерфейса работать без звука? Отключить динамики и просмотреть варианты использования.
Может ли он работать без цвета? Убедитесь, что компонент пользовательского интерфейса может использовать тот, кто не может видеть цвета. Полезным инструментом для имитации дальтонизма является расширение Chrome под названием SEE (попробуйте все четыре формы симуляции дальтонизма). Вы также можете быть заинтересованы в расширении Daltonize, которое так же полезно.
Может ли ваш компонент пользовательского интерфейса работать в режиме высокой контрастности? Все современные операционные системы поддерживают режим высокой контрастности. High Contrast — это расширение для Chrome, которое может помочь здесь.
Собственные элементы управления (такие как и ) имеют встроенную в браузер доступность. Они могут фокусироваться с помощью клавиши табуляции, реагировать на события клавиатуры (например, Enter, клавиши пробела и клавиши со стрелками) и имеют семантические роли, состояния и свойства, используемые инструментами специальных возможностей. Стиль по умолчанию также должен соответствовать требованиям доступности, перечисленным выше.
Пользовательские компоненты пользовательского интерфейса (за исключением компонентов, которые расширяют собственные элементы, такие как ) не имеют каких-либо встроенных функций, в том числе специальных возможностей, поэтому вам необходимо предоставить их. Хорошее место для начала при реализации доступности — сравнить ваши компоненты с аналогичным собственным элементом (или комбинацией нескольких собственных элементов, в зависимости от сложности вашего компонента).
Подсказка: Большинство браузеров DevTools поддерживают проверку дерева доступности страницы. В Chrome это доступно на вкладке «Специальные возможности» на панели «Элементы».
Можно ли использовать компонент пользовательского интерфейса только с клавиатурой?
В идеале, убедитесь, что все функции вашего компонента пользовательского интерфейса доступны с клавиатуры. При разработке UX подумайте, как бы вы использовали свой элемент только с помощью клавиатуры, и выясните согласованный набор взаимодействий с клавиатурой.
Во-первых, убедитесь, что у вас есть разумная цель фокусировки для каждого компонента. Например, сложный компонент, такой как меню, может быть одной целью фокусировки на странице, но затем должен управлять фокусом внутри себя так, чтобы активный элемент меню всегда фокусировался.
Использование tabindex
Атрибут tabindex позволяет фокусировать элементы / компоненты пользовательского интерфейса с помощью клавиатуры. Пользователи, использующие только клавиатуру и вспомогательные технологии, должны иметь возможность фокусировать внимание клавиатуры на элементах, чтобы взаимодействовать с ними. Нативные интерактивные элементы неявно фокусируются, поэтому им не нужен атрибут tabindex, если мы не хотим изменить их положение в порядке табуляции.
Существует три типа значений tabindex:
tabindex = "0" является наиболее распространенным и размещает элемент в «естественном» порядке табуляции (определяемом порядком DOM).
значение tabindex больше 0 будет размещать элемент в порядке табуляции manual — все элементы на странице с положительным значением tabindex будут посещаться в числовом порядке перед элементами в естественном порядке табуляции.
значение tabindex, равное -1 заставит элемент программно фокусироваться, но не в порядке табуляции.
Для пользовательских компонентов пользовательского интерфейса всегда используйте значения tabindex равные 0 или -1, поскольку вы не сможете заранее определить порядок элементов на данной странице — и даже если мы сделали, они могут быть изменены. Значение tabindex равное -1, особенно полезно для управления фокусировкой внутри сложных компонентов, как описано выше.
Также убедитесь, что фокусировка всегда видна, будь то использование стиля кольца фокуса по умолчанию или применение различимого стиля фокуса. Помните, что не нужно ловить пользователя на клавиатуре — фокус должен удаляться от элемента с помощью только клавиатуры.
Вы также можете быть заинтересованы в перемещениях tabindex или aria-activedescendant описанных в MDN.
Использование автофокуса
Атрибут HTML autofocus позволяет автору указать, что конкретный элемент должен автоматически фокусироваться при загрузке страницы. Это уже поддерживается на всех элементах управления веб-формы, в том числе. Чтобы автофокусировать элементы в ваших собственных пользовательских компонентах пользовательского интерфейса, вызовите метод focus (), поддерживаемый для всех HTML-элементов, которые могут быть сфокусированы (например, document.querySelector ('myButton'). Focus () ).
Добавление взаимодействия с клавиатурой
После того, как ваш компонент пользовательского интерфейса станет фокусируемым, попробуйте представить хорошую историю взаимодействия с клавиатурой, когда компонент находится в фокусе, обрабатывая соответствующие события клавиатуры — например, разрешите пользователю использовать клавиши со стрелками для выбора параметров меню и пробел или ввод для активировать кнопки. Руководство по шаблонам проектирования ARIA дает здесь некоторые рекомендации.
Наконец, убедитесь, что ваши сочетания клавиш доступны для обнаружения. Например, обычной практикой является использование легенды сочетания клавиш (текст на экране), чтобы информировать пользователя о наличии сочетаний клавиш. Например, «Нажмите? Для сочетаний клавиш». В качестве альтернативы подсказка, такая подсказка может использоваться для информирования пользователя о существующем ярлыке.
Важность управления фокусом не может быть преуменьшена. Одним из примеров является ящик навигации. Если вы добавляете компонент пользовательского интерфейса на страницу, вам нужно сосредоточиться на элементе внутри него, иначе пользователям, возможно, придется пролистать всю страницу, чтобы попасть туда. Это может быть неприятно, поэтому обязательно проверьте фокус на всех клавиатурных навигационных компонентах на своей странице.
Подсказка: Вы можете использовать Puppeteer для автоматизации выполнения тестов доступности клавиатуры для переключения состояний пользовательского интерфейса. У WalkMe Engineering есть отличное руководство по этому вопросу, которое я рекомендую прочитать.
Можете ли вы использовать свой компонент пользовательского интерфейса с программой чтения с экрана?
Около 1–2% пользователей будут использовать программу чтения с экрана. Можете ли вы определить всю важную информацию и взаимодействовать с компонентом, используя только программу чтения с экрана и клавиатуру?
Следующие вопросы должны помочь вам в определении доступности программ чтения с экрана:
Все ли компоненты и изображения имеют значимые текстовые альтернативы?
Везде, где информация о названии или цели интерактивного компонента передается визуально, необходимо предоставить доступную текстовую альтернативу.
Например, если ваш компонент пользовательского интерфейса отображает только значок, такой как значок меню настроек, чтобы указать, что это меню настроек, ему нужен доступный текстовый вариант, такой как «настройки», который передает ту же информацию. В зависимости от контекста это может использовать атрибут alt, атрибут aria-label, атрибут aria-labelledby или простой текст в Shadow DOM. Общие технические советы можно найти в кратком справочнике WebAIM.
Любой компонент пользовательского интерфейса, который отображает изображение, должен обеспечивать механизм для предоставления альтернативного текста для этого изображения, аналогичного атрибуту alt.
Вспомогательная технология передает семантическую информацию, которая иначе выражается зрячим пользователям через визуальные подсказки, такие как форматирование, стиль курсора или положение. Нативные элементы имеют эту семантическую информацию, встроенную в браузер, но для пользовательских компонентов вам нужно использовать ARIA для добавления этой информации.
Как правило, любой компонент, который прослушивает щелчок мыши или событие наведения мыши, должен иметь не только своего рода прослушиватель событий клавиатуры, но также роль ARIA и, возможно, состояния и атрибуты ARIA.
Например, пользовательский компонент пользовательского интерфейса может взять на себя роль ползунка ARIA, который имеет некоторые связанные атрибуты ARIA: aria-valuenow, aria-valuemin и aria-valuemax. Связав эти атрибуты с соответствующими свойствами вашего пользовательского компонента, вы можете позволить пользователям вспомогательных технологий взаимодействовать с элементом и изменять его значение, и даже вызывать соответствующее изменение визуального представления элемента.
Могут ли пользователи все понять, не полагаясь на цвет?
Цвет не должен использоваться в качестве единственного средства передачи информации, например указания статуса, запроса ответа или различения визуального пользовательского компонента. Например, если вы создали компонент использующий цвет для разграничения интенсивного, умеренного и легкого трафика, также должен быть доступен альтернативный способ различения уровней трафика: одно из решений может заключаться в наведении на элемент для отображения информации во всплывающей подсказке.
Достаточно ли контрастирует текст / изображения и фон?
Любой текстовый контент, отображаемый в вашем компоненте, должен соответствовать минимальной (AA) контрастной полосе. Подумайте о предоставлении высококонтрастной темы, которая соответствует верхней полосе (AAA), а также убедитесь, что таблицы стилей пользовательского агента могут применяться, если пользователям требуется экстремальный контраст или другие цвета. Вы можете использовать этот Контроллер цветовой контрастности как помощь при разработке дизайна.
Остановлено ли и безопасно ли перемещается или мигает содержимое ваших компонентов?
Контент, который перемещается, прокручивается или мигает и длится более 5 секунд, должен иметь возможность приостанавливаться, останавливаться или скрываться. В общем, старайтесь мигать не чаще трех раз в секунду.
Инструменты доступности
Доступен ряд инструментов, которые могут помочь в отладке доступности ваших визуальных компонентов.
Axe обеспечивает автоматическое тестирование доступности для вашей платформы или выбранного браузера. Axe Puppeteer может использоваться для написания автоматических тестов доступности.
Аудит доступности Lighthouse предоставляет полезную информацию для выявления общих проблем доступности. Оценка доступности — это средневзвешенное значение всех аудитов доступности, основанное на оценках влияния пользователей Ax. Для контроля доступности через непрерывную интеграцию см. Lighthouse CI.