Изображение с сайта Dribbble

Пишем JavaScript, не забывая о доступности

Советы о том, как улучшить доступность JavaScript-компонентов и дать пользователям более удобные способы взаимодействия с вашим сайтом или веб-приложением.

JavaScript — не враг

Виртуозное управление фокусом важно

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

Делайте нефокусируемые элементы доступными для фокуса

Возможно превратить элемент из недоступного для фокуса в доступный при помощи добавления атрибута tabindex с целым числом в качестве значения. Если значение будет 0, то элемент станет доступным для фокуса и выбора с клавиатуры.
Если значением будет отрицательное число, то на элементе можно будет сфокусироваться (например, при помощи JavaScript), но добраться до него с клавиатуры не получится. Вы теоретически можете использовать значения больше 0, но эту нарушит естественный порядок переключения между элементами, что считается анти-паттерном.

<h2 tabindex=”0">Заголовок, на котором можно сфокусироваться</h2>

Фокусируемся на элементе при помощи JavaScript

Даже если на элементе можно сфокусировать, иногда бывает так, что он находится не в том месте DOM. Чтобы проиллюстрировать эту ситуацию, я создал простое модальное окно на HTML, CSS и JS (демо и сам пен).

Короткое видео, которое иллюстрирует нелогичный порядок фокуса

HTML

// Добавим tabindex="0"
<div class="modal" id="modal2" tabindex="0">
...
</div>

Javascript

// Используем метод focus() для установки фокуса
function showModal() {
...
var modal = document.getElementById('modal2');
modal.focus();
...
}
// Переменная для хранения последнего элемента в фокусе
var lastFocusedElement;
function showModal() {
...
// Сохраняем последний элемент в фокусе
lastFocusedElement = document.activeElement;
var modal = document.getElementById(modalID);
modal.focus();
...
}
function removeModal() {
...
// Возвращаем фокус на последний элемент в фокусе
lastFocusedElement.focus();
...
}
Короткое видео, которое иллюстрирует логичный порядок фокуса

Если нужна кнопка, используйте элемент <button>

Я уже писал о кнопках в первой статье, но, видимо, многие люди используют другие элементы взамен кнопок. Так что, я думаю, не повредит написать еще раз об этой теме.

// Кнопка попадает в фокус
<button class="btn">I'm a button</button>
// div не попадает в фокус
<div class="btn">I'm a div</div>
// Все еще просто div, но попадает в фокус
<div class="btn" tabindex="0">I'm a div</div>
// Назначена роль кнопки и доступна для фокуса
<div class="btn" tabindex="0" role="button">I'm a div</div>

Пользователи экранных читалок должны быть в курсе когда контент меняется динамически

Обычно экранные читалки произносят тот контент, который находится в сфокусированном элементе или пользователь использует определенные клавиши навигации. Если контент подгружается динамически и вставляется в DOM, то только зрячий человек будет в курсе этого. ARIA Live Regions (далее живые регионы) предоставляют несколько опций для работы с этой задачей. Я покажу пару примеров.
Предположим, у вас есть страница настроек профиля, на которой вы можете редактировать персональные данные и сохранять их. При нажатии на кнопку изменения сохраняются без перезагрузки страницы. Предупреждения информируют пользователя, было ли сохранение успешным или нет. Предупреждение может появится сразу же или через какое-то время. Я записал небольшое видео чтобы показать вам этот пример.

Видео с иллюстрацией работы ARIA Live regions
<div class="message" role="status">Изменения сохранены!</div>

Будьте вежливы по отношению к пользователям

Разница между status и alert в том, что последний будет прерывать скринридер, если он в этот момент произносит какой-то другой контент. status дождется, когда читалка закончит читать фрагмент.

<div role="alert" aria-live="assertive"></div>

Иногда имеет смысл проговорить не только изменившийся контент

По умолчанию экранные читалки проговаривают только изменившийся контент, даже если в пределах одного живого региона есть другой контент. Но иногда имеет смысл проговорить весь текст целиком.
Есть способ изменить стандартное поведение при помощи атрибута aria-atomic. Если вы установите значение true, вспомогательные технологии произнесут все содержимое элементы.

Учитывайте следующие моменты

  • Живые регионы не перемещают фокус, они только вызывают повторное прочтение текста
  • Используйте alert только при критических изменениях. status больше подойдет в большинстве ситуаций, поскольку он более учтивый
  • Избегайте создания автоматически скрывающихся уведомлений, поскольку они могут пропадать слишком быстро
  • Во время своих тестов я использовал VoiceOver. Скрытие уведомлений через CSS или их динамическое создание вообще не срабатывали. Убедитесь, что вы протестировали свои живые регионы в разных браузерах и на разном ПО.

Вам не нужно гадать, какие шаблоны взаимодействия должен поддерживать ваш виджет

Часто сложно составить полный список возможностей, которые должен покрывать виджет с точки зрения навигации и доступности. К счастью, существует ресурс под названием WAI-ARIA Authoring Practices 1.1, который может помочь нам в этом. «WAI-ARIA Authoring Practices это гайд по использованию WAI-ARIA для создания доступных интернет-приложений. В нем описаны предпочтительные WIA-ARIA шаблоны и дается представление о концепциях, стоящих за ними.»

Доступные JavaScript-компоненты

Существуют также крупные ресурсы с доступными компонентами на JavaScript.

Резюмируя

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

За рамками

На сегодня это все. Я надеюсь, эти советы помогут вам писать более доступный JavaScript. Огромное спасибо Хейдону Пикерингу, поскольку его книга «Inclusive Front-End Design Patterns» заложила фундамент для большей части из того, что вы только что прочитали. Если вам интересно узнать больше о доступности и инклюзивном дизайне, то я крайне рекомендую вам эту книгу.

Больше фишек доступности

Эта статья является второй в серии из четырех. Остальные находятся в разработке и вскоре будут выпущены.

  1. Пишем HTML, не забывая о доступности
  2. Пишем JavaScript, не забывая о доступности
  3. Пишем CSS, не забывая о доступности
  4. Дальше: Learn how to design and develop with accessibility in mind

Ресурсы

--

--

Frontend-дева. Верстаю, пишу и перевожу статьи, менторю, выступаю.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Workafrolic (±∞)

Frontend-дева. Верстаю, пишу и перевожу статьи, менторю, выступаю.