Было время, когда доступность JavaScript
просто означала постепенную деградацию, когда JavaScript был недоступен. Но с момента появления Ajax и многофункциональных интернет-приложений JavaScript используется не только для несущественных улучшений юзабилити. JavaScript теперь является ядром веб-приложений, поэтому когда мы говорим о доступности JavaScript сегодня, мы имеем в виду, что сам JavaScript доступен.
Эхо будущего
Одним из наиболее значительных достижений в области доступности веб-сайтов за последние несколько лет является Инициатива доступности веб-приложений Инициативы веб-доступности (WAI ARIA), которая определяет семантику для обеспечения доступности интерактивного контента для вспомогательных технологий, таких как программы чтения с экрана. Поскольку взрыв Web 2.0 произошел практически без учета доступности, WAI ARIA возникла по необходимости. JavaScript теперь используется в критически важном коде, и поэтому вспомогательные технологии должны иметь возможность интерпретировать динамический контент.
Вернуться на Землю
К сожалению, ARIA пока не очень хорошо поддерживается. Только последние версии (очень дорогих) программ чтения с экрана имеют какую-либо поддержку, и ни одна из них не поддерживает все. Кроме того, поддерживаемые биты не обязательно реализованы должным образом.
Когда ARIA получит широкую поддержку, это не будет волшебной пулей. Начнем с того, что доступность JavaScript больше, чем определяет ARIA. ARIA может опираться только на прочную основу понимания потребностей пользователей в сочетании с разработкой на основе стандартов.
JSPro посвятит несколько статей изучению доступного JavaScript. Мы начнем с простых вещей, которые вы можете сделать прямо сейчас, чтобы сделать ваш JavaScript более доступным. Позже мы углубимся в мир ARIA. Но перед всем этим мы рассмотрим некоторые теоретические основы.
Личность внутри
Доступность JavaScript можно разделить на три широкие группы потребностей пользователей. Этот раздел описывает эти группы более подробно.
Пользователи вспомогательных технологий
В первую группу входят люди, использующие программы чтения с экрана, шрифты Брайля или аналогичные вспомогательные технологии. Слепые являются главными среди этой группы, но в нее также входят люди со слабым зрением и когнитивными нарушениями, которые используют программы чтения с экрана, чтобы помочь чтению и пониманию.
Вспомогательные технологии представляют всю информацию в виде структурированного текста. Поэтому все функции JavaScript должны принимать форму, которая может быть интерпретирована как текст. Например, показанный ниже скрипт-индикатор выполнения предоставляет визуальную информацию, поэтому ее необходимо дополнить текстом, который предоставляет ту же информацию.
Индикатор прогресса на 76%, который отображается визуально, а также в процентах.
Одного текста недостаточно, если у него нет структуры и связей, которые вспомогательные технологии могут понять программно. Текст обычно структурируется очень простыми способами, такими как списки и таблицы. Это структуры, которые вспомогательные технологии могут легко понять. Все, что нам нужно сделать, это использовать их правильно.
Создавая такие вещи, как раскрывающиеся меню с использованием неупорядоченных списков и структурных меток , вспомогательные технологии могут получить свое значение из семантики и иерархии этих элементов. Или мы можем создать виджеты календаря, где каждый месяц представляет собой таблицу. Затем мы можем вызвать его с помощью кнопки и описать его с помощью метки. Семантика твердого элемента должна быть основой всего интерактивного контента.
Пользователи клавиатуры
Вторая группа — это люди, которые используют только клавиатуру. В эту группу пользователей входят люди, которые являются слепыми и используют программу чтения с экрана, но также и зрячие люди, которые не могут использовать мышь из-за двигательной недостаточности, а также люди с когнитивными нарушениями, которые считают, что фокус отслеживания помогает им сосредоточиться. Для размещения этой группы все функции JavaScript должны быть доступны для клавиатуры. Например, взаимодействия должны быть ограничены наиболее интуитивными нажатиями клавиш, такими как Tab , клавиши со стрелками , Enter и Escape .
Поддержка клавиатуры часто предоставляется бесплатно, если вы исходите из предположения, что лучшее событие является наиболее независимым от устройства. Таким образом, проверка формы должна быть связана с немодальным событием submitclickmousedowntouchstartkeydown
Для более сложных взаимодействий часто требуется сочетание событий. В Руководстве по доступности веб-контента говорится о сопряжении событий — сопряжении событий мыши с ближайшим эквивалентом клавиатуры. Примером сопряжения могут быть события mousedownkeydown Тем не менее, это неправильный взгляд на это, потому что он фокусируется на механике деятельности, а не на цели. Это не должно иметь значения, если клавиатурный способ сделать что-то совершенно другой, если он достигает той же цели.
Для чего-то вроде перетаскивания не существует клавиатуры, эквивалентной событию mousemove То, что мы называем перетаскиванием, на самом деле представляет собой два разных вида взаимодействия. Во-первых, элементы можно перемещать вверх и вниз для их сортировки, и это можно реализовать с помощью простых нажатий клавиш « Стрелка вверх» и « Стрелка вниз» . Второй — захватывать и перемещать действия, такие как перетаскивание файлов между папками, и это можно сделать с помощью чего-то вроде пробела, чтобы выбрать элемент, затем Tab, чтобы выбрать целевой объект, и Enter, чтобы отбросить его.
Когда используются неочевидные нажатия клавиш, для их объяснения должен присутствовать сопроводительный текст. И, по правде говоря, некоторые взаимодействия с клавиатурой неизбежно будут более запутанными, чем их эквивалентные взаимодействия с мышью. Но это не обязательно имеет значение, если оно выполняет ту же работу. Доступность — это эквивалентность, а не равенство.
Другое важное соображение, касающееся доступности клавиатуры, — это поддержание логического порядка содержимого . Например, когда используются расширенные всплывающие подсказки, они должны быть вставлены непосредственно после элемента, который их вызвал, чтобы вы могли сразу перейти к ним и чтобы читатели экрана читали их дальше.
Пользователи, которые чувствительны к перепрошивке контента или ограничениям по времени
Последняя группа — это люди, которые чувствительны к миганию или миганию контента или которые не могут реагировать на события в реальном времени ожидаемым образом. Что касается мигания контента, это затрагивает людей с светочувствительной эпилепсией, у которых припадки могут быть вызваны такими эффектами, а также людей, которые имеют когнитивные нарушения и которым труднее сосредоточиться, когда вещи движутся в их периферийном зрении. Ограничения на перепрошивку содержимого определяются совершенно определенно WCAG и суммируются как три вспышки или ниже порога .
Ограничения по времени также могут быть проблематичными, поскольку для прослушивания произносимого контента требуется гораздо больше времени, чем для его чтения. Навигация с помощью клавиатуры также занимает больше времени, чем при использовании мыши. Следовательно, основанная на времени активность в JavaScript должна быть управляемой пользователем. Ограничения на основанную на времени активность не очень специфичны, потому что есть несколько различных вариантов использования для рассмотрения.
Общий принцип для сроков состоит в том, что всякий раз, когда действие должно быть завершено в течение определенного времени, пользователь получает предупреждение о том, что срок истекает, и ему предоставляется возможность продлить его. Например, интерфейс онлайн-банкинга может иметь строгие ограничения по времени бездействия сеанса, но пользовательский контроль может быть обеспечен простым диалогом confirmбанкоматах, когда они спрашивают, нужно ли вам больше времени).
Когда контент анимирован, анимация не должна длиться более пяти секунд, если только у пользователя нет способа управлять им. Анимация может быть чисто декоративным эффектом, поэтому ограничение по времени полезно для людей с когнитивными нарушениями, которым постоянная периферийная анимация может затруднить сосредоточение на основном контенте.
В качестве альтернативы, анимация может быть прокруткой или перемещением контента, и здесь существует ограничение, позволяющее пользователям выполнять задачу без неожиданных изменений контекста. Например, тикер новостей, который прокручивается автоматически, должен иметь кнопку паузы, чтобы пользователь мог читать каждый элемент со своей скоростью и быть уверенным, что он не изменится, пока они его читают! Аналогичная логика применяется, когда большие блоки контента или целые страницы обновляются автоматически. Это часто встречается на сайтах, которые содержат информацию об акциях или спортивные результаты. Вы просто не должны делать это вообще, если вы не предоставляете явный пользовательский контроль над частотой обновления (по умолчанию никогда).
Но временные рамки часто являются неотъемлемой частью деятельности, для которой они используются. Многие игры изначально основаны на времени, и снятие ограничения по времени сведет на нет цель игры. В таких случаях справедливо сказать, что контент просто нельзя сделать доступным без изменения его значения. WCAG допускает такую возможность, если контент четко описан как таковой.
Вывод
Мы видели, как доступность JavaScript сводится к следующим трем основным принципам.
- Все функции JavaScript должны принимать форму, которая может быть интерпретирована как текст.
- Все функции JavaScript должны быть доступны для клавиатуры.
- Основанная на времени активность в JavaScript должна быть управляемой пользователем, если это не изменит ее значения.
В следующий раз мы перейдем от этой теоретической основы к рассмотрению некоторых простых, но практичных вещей, которые вы можете сделать прямо сейчас , чтобы сделать функциональность JavaScript более доступной. Это не сфера узко поддерживаемых, недоказанных и передовых разработок, а то, чем мы занимаемся годами.