Цель данного поста, с одной стороны, продемонстрировать насколько незрячим пользователям сложно, а порой и вовсе невозможно работать с html контролами, не реализующими требования доступности, а с другой — показать, что реализовать эти требования совсем не трудно.
Здесь, на Хабре, уже были статьи описывающие способы достижения доступности сайта, однако, в них вопросы доступности не нативных html элементов управления, затрагивались самым общим образом, тогда как я уверен в том, что это главный фактор влияющий на web accessibility.
Под кастомными или не нативными html контролами тут понимаются элементы управления представленными не, к примеру, стандартными тегами типа:
А просто блочными элементами с соответствующим визуальным оформлением и обработчиками событий типа:
Хочу заметить, что данная статья не претендует на исчерпывающее руководство по доступности, она призвана только дать общее понимание и донести важность следования рекомендациям wai-aria при использовании собственных элементов управления.
Посредством одного из api доступности поддерживаемого браузером, IAccessible2, windows automation и пр. вспомогательные технологии, в данном случае скринридер, получает всю необходимую информацию об элементах управления в обрабатываемом документе, но только в том случае, когда она присутствует.
Это справедливо для нативных элементов типа:
Или
Они по умолчанию поддерживают все необходимые роли, свойства, клавиши управления и реализуют соответствующую логику.
Однако если элемент управления представлен обычным дивом, с соответствующим визуальным оформлением, то для скринридера, а значит и для пользователя, это просто див и ничего больше.
К примеру, вот что скринридер сообщит незрячему пользователю если встретит стандартный checkbox: «отметь меня check box not checked», то есть сообщит тип элемента и его состояние, а если встретится такое:
(реальный фрагмент верстки находящийся на странице настроек vk.com) то скринридер озвучит это так: «Специальные возможности clickable» (т.е. никакой информации). Незрячий пользователь не сможет не только определить состояние элемента, но и его тип. В некоторых случаях данный элемент будет активироваться крайне не стабильно, а так как пользователь его текущее состояние узнать не может, то использование этой опции становится очень затруднено.
Вот к чему приводит не соблюдение требований доступности. А меж тем соблюсти эти требования крайне просто. К примеру, в данном конкретном случае достаточно просто сделать следующее — это присвоить атрибуту role соответствующее значение;
И вот уже скринридер распознает элемент как checkbox;
Обработать не только событие onclick, но и onkeydown, чтобы позволить пользователям активировать checkbox посредствам клавиши “space”
Добавить в обрабатывающий событие js код логику изменения свойства aria-checked. Что-то вроде такого:
И всё. Небольшая правка в верстке, несколько строк кода и элемент становится полностью доступным. Конечно, для других элементов может быть немного больше кода, к примеру, radiobutton, т.к. придется прописывать чуть больше логики и обрабатывать больше клавиш, но в итоге все равно это достаточно просто.
UPD:
Как совершенно верно заметили в комментариях, чтобы с элементом было возможно взаимодействовать с помощью клавиатуры, для него должен быть установлен tabindex, то есть корректная разметка элемента выглядела бы так:
На странице: WAI-ARIA Authoring Practices Представлено большое количество примеров реализации тех или иных элементов управления.
Наибольшие проблемы для незрячих пользователей приносит недоступность различных элементов управления. Когда это возможно, следует использовать специализированные html теги, они доступны поумолчанию и максимум, что потребуется так это установить aria-label; Однако если это не возможно, то стоит посетить WAI-ARIA Authoring Practices И просмотреть каким образом рекомендуется реализовать тот или иной виджет.
Здесь, на Хабре, уже были статьи описывающие способы достижения доступности сайта, однако, в них вопросы доступности не нативных html элементов управления, затрагивались самым общим образом, тогда как я уверен в том, что это главный фактор влияющий на web accessibility.
Под кастомными или не нативными html контролами тут понимаются элементы управления представленными не, к примеру, стандартными тегами типа:
<button>нажми меня</button>
А просто блочными элементами с соответствующим визуальным оформлением и обработчиками событий типа:
<div class="button" onclick"...">нажми меня</div>
Хочу заметить, что данная статья не претендует на исчерпывающее руководство по доступности, она призвана только дать общее понимание и донести важность следования рекомендациям wai-aria при использовании собственных элементов управления.
Посредством одного из api доступности поддерживаемого браузером, IAccessible2, windows automation и пр. вспомогательные технологии, в данном случае скринридер, получает всю необходимую информацию об элементах управления в обрабатываемом документе, но только в том случае, когда она присутствует.
Это справедливо для нативных элементов типа:
<button>нажми меня</button>
Или
<input type=”checkbox”>отметь меня</input>
Они по умолчанию поддерживают все необходимые роли, свойства, клавиши управления и реализуют соответствующую логику.
Однако если элемент управления представлен обычным дивом, с соответствующим визуальным оформлением, то для скринридера, а значит и для пользователя, это просто див и ничего больше.
К примеру, вот что скринридер сообщит незрячему пользователю если встретит стандартный checkbox: «отметь меня check box not checked», то есть сообщит тип элемента и его состояние, а если встретится такое:
<div class=" checkbox on _settings_access " id=" settings_a11y" onclick="checkbox(this); Settings.accessCheck(isChecked(this));">Специальные возможности</div>
(реальный фрагмент верстки находящийся на странице настроек vk.com) то скринридер озвучит это так: «Специальные возможности clickable» (т.е. никакой информации). Незрячий пользователь не сможет не только определить состояние элемента, но и его тип. В некоторых случаях данный элемент будет активироваться крайне не стабильно, а так как пользователь его текущее состояние узнать не может, то использование этой опции становится очень затруднено.
Вот к чему приводит не соблюдение требований доступности. А меж тем соблюсти эти требования крайне просто. К примеру, в данном конкретном случае достаточно просто сделать следующее — это присвоить атрибуту role соответствующее значение;
<div class=" checkbox on _settings_access " id=" settings_a11y" onclick="checkbox(this); Settings.accessCheck(isChecked(this));" role="checkbox">Специальные возможности</div>
И вот уже скринридер распознает элемент как checkbox;
Обработать не только событие onclick, но и onkeydown, чтобы позволить пользователям активировать checkbox посредствам клавиши “space”
<div onkeydown”toggleCheckbox(evend)”>специальные возможности</div>
Function toggleCheckbox(evend) {
If (event.keyCode === 32){
…
}
}
Добавить в обрабатывающий событие js код логику изменения свойства aria-checked. Что-то вроде такого:
var state = node.getAttribute('aria-checked').toLowerCase()
if (state === 'true') {
node.setAttribute('aria-checked', 'true')
}
else {
node.setAttribute('aria-checked', 'false')
}
И всё. Небольшая правка в верстке, несколько строк кода и элемент становится полностью доступным. Конечно, для других элементов может быть немного больше кода, к примеру, radiobutton, т.к. придется прописывать чуть больше логики и обрабатывать больше клавиш, но в итоге все равно это достаточно просто.
UPD:
Как совершенно верно заметили в комментариях, чтобы с элементом было возможно взаимодействовать с помощью клавиатуры, для него должен быть установлен tabindex, то есть корректная разметка элемента выглядела бы так:
<div tabindex=^_^quot quot^_^ role="checkbox" aria-checked="true">специальные возможности</div>
На странице: WAI-ARIA Authoring Practices Представлено большое количество примеров реализации тех или иных элементов управления.
Резюме
Наибольшие проблемы для незрячих пользователей приносит недоступность различных элементов управления. Когда это возможно, следует использовать специализированные html теги, они доступны поумолчанию и максимум, что потребуется так это установить aria-label; Однако если это не возможно, то стоит посетить WAI-ARIA Authoring Practices И просмотреть каким образом рекомендуется реализовать тот или иной виджет.