Чтобы Интернет был доступен для людей с ограниченными возможностями, принципиально важно, чтобы различные компоненты веб-разработки и взаимодействия работали вместе. Доступность компонентов важна; вы не можете создавать доступные веб-сайты, если ваши компоненты недоступны. Как разработчики компонентов, мы всегда уделяли особое внимание доступности, и мы постоянно ее улучшали.
За последние несколько месяцев некоторые из наших клиентов начали тесно сотрудничать с нами, делясь с нами результатами своих тестов и отзывами пользователей. Это помогло нам проверить и улучшить нашу поддержку специальных возможностей. В этой статье мы расскажем о нашем опыте повышения доступности компонентов. Мы планируем и дальше улучшать поддержку специальных возможностей, отслеживая стандарты ARIA и используя отзывы наших клиентов.
Ролевой атрибут
Первый шаг, необходимый для обеспечения доступа к компонентам, - это использование атрибута role. Атрибут роли связывает области с проблемами доступности, которые нельзя решить с помощью собственного HTML. Он работает, позволяя вам указывать атрибуты, которые изменяют способ преобразования элемента в дерево доступности. Например, вы можете сообщить браузерам и вспомогательным технологиям, что определенный элемент div действует как меню, сетка или список.
Существуют заранее определенные роли ARIA, распознаваемые браузерами и вспомогательными технологиями. Их можно разделить на виджет, составной, структура документа и ориентир. Вы можете найти полный список ролей в разделе Модель ролей документации W3C. У многих компонентов есть части, которые играют связанные роли. Например, элементы с ролью сетка обычно содержат элементы с ролью строка, которые, в свою очередь, содержат элементы с ролью ячейка сетки. Правильное распределение всех ролей в сложных компонентах - нетривиальная задача. Чтобы помочь с этим, в Chrome есть инструмент аудита доступности, который анализирует модель DOM и сообщает о неправильном использовании атрибута роли.
Атрибуты доступных полнофункциональных интернет-приложений (ARIA)
После того, как вы правильно настроили атрибут роли для элементов, составляющих компонент, следующим шагом будет добавление атрибутов ARIA, описывающих текущее состояние компонентов. Эти атрибуты зависят от роли элемента и могут включать «aria-selected», «aria-required» и «aria-valuenow».
Существуют также общие атрибуты, такие как «aria-label» и «aria-labelledby», которые зависят от приложения и их труднее предоставить разработчикам общих компонентов. В этих случаях важно, чтобы компоненты вызывали события в подходящее время, чтобы разработчики могли добавлять свои собственные метки ARIA к элементам компонента.
Марки ARIA и интернационализация
Атрибут aria-label важен для элементов, не имеющих текстового содержимого. Например, кнопки с изображениями и без текста. В этих случаях вспомогательные технологии используют атрибут aria-label для предоставления контекстной информации для элемента. Обеспечение адекватных значений aria-label является проблемой для веб-компонентов, которые могут использоваться в разных культурах. В этих случаях значения меток должны быть глобализированы, чтобы ориентироваться на поддерживаемые культуры.
Wijmo справляется с этим, включая более 40 файлов культур, которые содержат строки пользовательского интерфейса (включая метки aria) для разных культур. Файлы культуры создаются автоматически с помощью инструмента, который использует Microsoft Multilingual App Toolkit (MAT). Набор инструментов включает в себя инструменты автоматического машинного перевода и обслуживания, которые позволяют нам отслеживать и обновлять переводы по мере необходимости. По нашему опыту, создание и обслуживание файлов культуры вручную - вариант, если у вас есть только несколько строк и несколько культур, которые нужно поддерживать. Во всех остальных случаях необходим инструмент для поддержания актуальности файлов культуры.
Поддержка клавиатуры
Добавление атрибутов ARIA к элементам компонентов - важный первый шаг в поддержке доступности. Также важна последовательная и эффективная работа с клавиатурой. В документе W3C WAI-ARIA Authoring Practices описываются взаимодействия с клавиатурой, обычно ожидаемые для общих типов компонентов.
Маркировка пользовательских компонентов
Элементы меток важны, потому что они помогают идентифицировать элементы ввода и улучшают работу с мышью. Щелчок по метке вызывает событие щелчка для отмеченного элемента. Однако элементы меток можно использовать только для меток «маркируемых» элементов, которые включают только несколько определенных элементов HTML (кнопка, ввод, текстовое поле, выбор и некоторые другие).
Для поддержки меток пользовательские компоненты должны использовать технику, подобную описанной Робом Додсоном в его видео Как маркировать пользовательские элементы. Основная идея состоит в том, чтобы убедиться, что у метки есть идентификатор, а затем связать элемент ввода вашего компонента с меткой с помощью атрибута aria-labelledby.
Все входные компоненты Wijmo используют эту технику, поэтому вы можете написать такую разметку:
<!-- component contained in the label --> <label>Combo <div id="cmb"></div> </label><!-- label with "for" attribute--> <label for="theDate">InputDate</label> <div id="theDate"></div>
Когда компоненты создаются, они автоматически проверяют наличие меток или меток, нацеленных на основной элемент компонента. Если метка найдена, элемент управления гарантирует, что у нее уникальный идентификатор, и автоматически добавит атрибут aria-labelledby к соответствующему элементу ввода внутри компонента. При нажатии на метки фокус автоматически переносится на элемент ввода компонента, как и ожидалось.
Указатель ровницы
Пользователи ожидают, что клавиши курсора переместят выбор к следующему / предыдущему элементу (символу, ячейке, табуляции, узлу) в текущем фокусированном компоненте. Клавиша табуляции должна перемещать фокус на следующий / предыдущий компонент на странице.
Компоненты, содержащие несколько дочерних элементов, должны обеспечивать фокусировку только на одном из их дочерних элементов. Невыполнение этого требования создает «ловушки для клавиатуры», которые расстраивают пользователей. Для этого во многих компонентах используется метод, называемый «индексирующий индекс табуляции». Этот метод заключается в изменении атрибута tabindex дочерних элементов компонента таким образом, чтобы, когда пользователь перемещался по странице, компонент представлял единственную остановку, при этом текущий выбранный вложенный элемент получает фокус.
Многие компоненты Wijmo реализуют индекс перемещающихся вкладок, включая FlexGrid, ListBox, Calendar, TabPanel и Компоненты TreeView.
Для получения дополнительных сведений см. Видео Roving TabIndex Роба Додсона, Видео Roving TabIndex или Roving Tabindex в статье MDN Виджеты JavaScript с возможностью навигации с клавиатуры.
Индикаторы фокуса
По умолчанию браузеры добавляют «кольцо фокусировки» вокруг элемента, который в данный момент находится в фокусе клавиатуры. Это важно, потому что без него пользователям может быть сложно определить, какой элемент в настоящее время находится в фокусе. Это основное требование контрольного списка WCAG 2.0 (2.4.7). Из-за этого простое отключение кольца фокусировки браузера обычно не является хорошей идеей. Но у кольца фокусировки по умолчанию есть проблемы:
- Он может не соответствовать вашему дизайну (например, синий контур на синем фоне).
- Это несовместимо между браузерами (синяя линия в Chrome, пунктирная линия в IE / Edge).
- Он работает для элементов HTML, но не для составных компонентов.
К счастью, есть простые способы решить эти проблемы. Индикатор фокуса клавиатуры может принимать разные формы. Один из распространенных способов - это курсор в текстовом поле, чтобы указать, что текстовое поле находится в фокусе клавиатуры. Другой - визуальное изменение кнопки, чтобы указать, что эта кнопка находится в фокусе клавиатуры.
Этот курс Udacity содержит примеры, которые показывают, как вы можете использовать CSS, чтобы указать внешний вид кольца фокусировки, чтобы добиться единообразного внешнего вида, соответствующего вашему дизайну:
*:focus {
outline: 2px solid rgba(90, 160, 215, .5);
outline-offset: 2px;
}Это решит первые две проблемы, указанные выше. Последний вопрос посложнее. Возьмем, к примеру, простой компонент ComboBox:
Компонент состоит из элементов HTML. Внутренний элемент ввода имеет фокус, но вы можете видеть только правую сторону кольца фокуса, потому что другие стороны привязаны к содержащему элементу. Даже если вы настроили CSS, чтобы сделать все кольцо видимым, кольцо должно быть не вокруг ввода, а вокруг всего элемента управления (включая границу и кнопку).
Чтобы помочь разработчикам решить эту проблему, компоненты Wijmo имеют псевдоселектор «wj-state-focus», который позволяет идентифицировать компонент, на котором сфокусирован фокус. Этот селектор позволяет вам писать такие правила:
.wj-state-focus,
a:focus,
button:not(.wj-btn-default):focus,
input:not(.wj-form-control):focus,
input[type=checkbox]:focus {
box-shadow: 0 0 5px 3px rgba(90, 160, 215, .5);
}Это правило изменяет индикатор фокуса, чтобы выделить весь компонент (оно также применяет индикатор фокуса к нескольким другим элементам, которые не являются компонентами Wijmo):
Селектор «wj-state-focus» также работает в сценариях с вложенными компонентами. На изображении ниже показан компонент ColumnFilterEditor, который содержит сфокусированный компонент MultiSelect:
Узнать больше о доступности в Интернете
Идеальная доступность - это движущаяся цель. Стандарты развиваются, как и браузеры, вспомогательные инструменты и компоненты. Чтобы проверить доступность создаваемых вами страниц, воспользуйтесь инструментом аудита доступности Chrome. Он прост в использовании, комплексен и постоянно совершенствуется. Если у вас есть предложения или запросы, которые помогут нам улучшить доступность наших компонентов, сообщите нам об этом в комментариях ниже.
Следите за страницей блога GrapeCity, чтобы увидеть новые веб-семинары, демонстрационные видео, новости отрасли и многое другое.
