Leaflet: Улучшения доступности

Не хочу брать на себя решение вашей проблемы здесь, @stevevance , но я видел ваш твит об этом ранее и хотел сразу же поговорить о доступности Leaflet в целом. Это может (должно?) Быть отдельной проблемой, но я подумал, что начну здесь, потому что контекст, который вы предоставляете, является отличным вводным пунктом.

Я работаю над цифровым картированием для Службы национальных парков, и все наши продукты должны соответствовать Разделу 508 и WCAG. Недавно мы прошли сторонний аудит доступности для тестирования наших веб-карт, и, поскольку наша библиотека отображений (NPMap.js) построена на основе Leaflet, некоторые выводы и рекомендации аудита применимы непосредственно к самой Leaflet. Я уже давно хотел поднять вопрос об этом, но мне мешали другие вещи. Спасибо за толчок!

Я взял многие рекомендации аудита и превратил их в пункты, требующие принятия мер. Вы можете увидеть открытую проблему на стороне NPMap.js здесь: https://github.com/nationalparkservice/npmap.js/issues/168.

Мы (команда NPMap) хотели бы начать реализацию некоторых из этих исправлений в Leaflet, если будет поддержка для этой работы. В частности, мы хотели бы поработать над этими исправлениями:

1. Используйте кнопки, а не ссылки, для управления
2. Используйте атрибуты alt text вместо title в элементах управления
3. Установите tabIndex элемента HTML с классом leaflet-container на 0
4. Используйте для маркеров элементы привязки, а не div, и укажите атрибут href на идентификатор div всплывающего окна (я чувствую, что это может быть довольно сложно)
5. Установите фокус на элемент заголовка во всплывающем окне, когда отображается всплывающее окно, установив для tabindex значение -1 до того, как элемент будет сфокусирован

Приведенный выше список представляет собой подмножество исправлений, которые мы хотим реализовать в NPMap.js, но я думаю, что это те элементы, которые имеет смысл реализовать в Leaflet. Я считаю, что третий пункт поможет решить проблему с VoiceOver.

Есть более серьезная проблема, решения которой у меня действительно нет: все векторы, а не только маркеры, должны иметь возможность табуляции. В настоящее время табуляции доступны только маркеры. Это означает, что VoiceOver и другие технологии доступности не будут работать для других векторов. На данный момент я недостаточно знаю о доступности и SVG, VML и Canvas, чтобы дать обоснованную рекомендацию, но я готов потратить некоторое время на исследования.

@stevevance + @nateirwin -

Также ознакомьтесь с этой проблемой StackOverflow , она может быть вам полезна, как и для моего приложения:
http://stackoverflow.com/questions/26745454/how-to-make-leaflet-tile-layers-accessible

@geospatialem : Выглядит неплохо. Может, захотите добавить это в список ...

Спасибо всем за чрезвычайно ценный отзыв! В моих интересах улучшить Leaflet на фронте доступности, поэтому связанные с этим PR всегда приветствуются. Я дам более подробный ответ, но просто хотел быстро прокомментировать конкретные изменения @nateirwin :

Используйте кнопки, а не ссылки, для управления

Согласовано!

Используйте замещающий текст вместо атрибутов заголовка в элементах управления

В спецификациях HTML сказано, что атрибут alt применим только к изображениям и входам. Вы хотели сказать что-нибудь кроме «контроля»?

Установите tabIndex элемента HTML с классом контейнера-листовки равным 0

Уже стандартное поведение.

Используйте элементы привязки, а не div для маркеров, и укажите атрибут href на идентификатор div всплывающего окна (я чувствую, что это может быть довольно сложно)

Да, может быть немного сложно. Есть ли альтернативы? Может быть, сделать фокусируемым и весь контейнер всплывающего содержимого и переключить фокус на щелчок маркера - это сработает?

Установите фокус на элемент заголовка во всплывающем окне, когда всплывающее окно отображается, установив tabindex на -1 до того, как элемент будет сфокусирован

Можете описать, как это работает на практике?

Спасибо, @mourner. Чтобы ответить на ваши комментарии:

В спецификациях HTML говорится, что атрибут alt применим только к изображениям и входам. Вы хотели сказать что-нибудь кроме «контроля»?

Извините, я должен был быть яснее. Мы используем изображения в большинстве наших элементов управления (как и некоторые элементы управления Leaflet и многие плагины Leaflet), и в полученном нами руководстве говорится, что мы должны использовать изображения переднего плана (а не фоновые изображения) с указанным на них атрибутом alt . В отчете об атрибутах title сказано следующее:

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

В соответствии с этим руководством мы переключаем все наши элементы управления на изображения переднего плана с указанными атрибутами alt и перестали использовать атрибуты title для большинства элементов.

Уже стандартное поведение.

Ах хорошо. Я думал, что tabindex было установлено на 1.

Да, может быть немного сложно. Есть ли альтернативы? Может быть, сделать фокусируемым и весь контейнер всплывающего содержимого и переключить фокус на щелчок маркера - это сработает?

Я считаю, что намерение использовать якорные элементы с атрибутами href ( href="#popup-div") - это то, что кто-то, использующий программу чтения с экрана, может "щелкнуть" по элементу, и вспомогательная технология прочитает содержимое всплывающего окна Проблема заключается в том, что предполагается, что каждый маркер имеет всплывающее окно div, которое отображается при инициализации слоя. Поправьте меня, если я ошибаюсь, но я считаю, что всплывающие окна обычно создаются на лету, когда маркер щелкает или активируется. с помощью клавиатуры, а затем уничтожены, чтобы не было кучи ненужных элементов DOM.

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

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

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

Можете описать, как это работает на практике?

На практике вы бы сделали что-то вроде этого, когда маркер щелкнули или активировали с помощью клавиатуры:

<h3>Oregon Caves National Monument</h3>
$(‘.leaflet-popup-content h3’).attr(‘tabindex’, -1).focus();

Установив для tabindex значение -1, если клавиатура используется для перехода с помощью табуляции от элемента h3 , вернуться к нему невозможно. Установив фокус на этот элемент, программа чтения с экрана немедленно прочитает заголовок всплывающего окна, обеспечивая важный контекст для последующего содержимого.

Честно говоря, я не на 100% понимаю, почему tabindex из h3 нужно изменить на -1, но я могу получить некоторые пояснения по этому поводу.

Еще одна вещь, которую можно улучшить, - это ссылка закрытия всплывающего окна. Мы можем легко улучшить его доступность, добавив атрибут aria-hidden="true" к диапазону «x». Затем мы могли бы добавить скрытый диапазон с закрытым текстом после него:

<a class="leaflet-popup-close-button" href="#marker-id">

  <span aria-hidden="true">x</span>

  <span class="visuallyhidden">close popup</span>

</a>

.visuallyhidden {
  border: 0;
  clip: rect(0 0 0 0);

  height: 1px;
  width: 1px;
  margin: -1px;
  padding: 0;
  overflow: hidden;
  position: absolute;
}

Рад видеть эту проблему! Спасибо за внимание к этим @stevevance и @nateirwin

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

Полезно ли делать изображения плиток «видимыми» для программ чтения с экрана? Я чувствую, что слепой или слабовидящий пользователь не получит много полезного контекста из нижележащих базовых плиток, особенно если есть дюжина или около того плиток с alt = "Плитка изображения карты".

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

Ой, извините @stevevance, я думаю, это именно то, что вы предлагаете выше. : +1:

@jasonlally Привет, Джейсон!

Итак, я прочитал комментарии @mourner и @nateirwin и все еще застрял: я действительно не знаю, что мне нужно изменить на моем сайте. Некоторые из моих карт имеют изрядное количество самописных функций для взаимодействия с картой, и все они используют плагины.

Самая большая проблема, с которой я столкнулся слепой пользователь, заключалась в том, что каждый раз, когда она касалась карты на своем iPad, iPad считывал имя файла плитки изображения. Это первое, что я хотел бы исправить. Есть ли у кого-нибудь предложения о том, как сообщить iPad, что элемент не «нажимается»?

Что касается того, чтобы iPad игнорировал плитки изображений, поможет ли следующий совет?
http://www.w3.org/WAI/tutorials/images/decorative/

Что-то вроде:

<img src="tile.png" role="presentation" alt="">

Кто-то может возразить, что фрагменты карты - это нечто большее, чем просто украшение, и они предоставляют информацию, но на самом деле контекст обеспечивается информацией о слое в этом основном случае использования. Похоже, что вспомогательные технологии будут игнорировать изображения с alt = "", а более новые технологии будут учитывать тег aria role = "presentation".

У кого-нибудь еще есть мысли по этому поводу? Кажется, что простое изменение в листовке здесь - сделать так, чтобы плитки выводили это по умолчанию?

@nateirwin не уверен, насколько легко изменить элементы управления листовки, чтобы использовать кнопки, а не ссылки, но что, если текущие ссылки использовали role="button" ?

@jasonlally Кажется, что Leaflet по умолчанию не включает в изображения тег alt . Отсутствующий тег alt это то же самое, что и alt="" ?

Есть более серьезная проблема, решения которой у меня действительно нет: все векторы, а не только маркеры, должны иметь возможность табуляции. В настоящее время табуляции доступны только маркеры. Это означает, что VoiceOver и другие технологии доступности не будут работать для других векторов. На данный момент я недостаточно знаю о доступности и SVG, VML и Canvas, чтобы дать обоснованную рекомендацию, но я готов потратить некоторое время на исследования.

Один обходной путь, с которым я экспериментировал, - это обертывание каждого тега пути SVG пустым тегом <a> который доступен с вкладки. Затем я добавил немного кода css, чтобы стилизовать пути, когда они находятся в фокусе:
a:focus>path.leaflet-clickable {stroke-width:5px;}
в мой CSS, чтобы, когда я перехожу к ссылке, окружающей каждый путь, путь меняется, так что я могу визуально определить, какой из них у меня есть.
и теперь я работаю над попыткой захватить событие щелчка из окружающего путь и рассматривать его как событие щелчка на фактическом объекте.

@nateirwin & @stevevance Если вы ищете патч для элементов управления листовки (в то время как более серьезные проблемы привлекают внимание), button s с тегами img внутри .

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

Надеюсь, это поможет тем временем!

Прочитав этот выпуск (в ответ на внутреннюю дискуссию Esri о доступности), я думаю, что можно сделать несколько вещей:

• Используйте role=presentation и alt="" на фрагментах карты, чтобы программы чтения с экрана не читали их URL-адреса.
• Пользователь role=button и aria-label="Zoom In/Out" на кнопках масштабирования. aria-label может быть прочитано другими программами чтения с экрана, чем title .

Отсутствующий тег alt - это то же самое, что и alt = ""?
@stevevance в https://github.com/Leaflet/Leaflet/issues/3210#issuecomment -96029220

Точно нет. В моем собственном тестировании большинство программ чтения с экрана будут читать URL-адреса изображений, если отсутствует атрибут alt . Вы можете посмотреть https://www.w3.org/TR/WCAG20-TECHS/H67 для получения дополнительной информации и https://github.com/Esri/esri-leaflet/blob/10fced2121c5cbc506c8b6e7ee95cc891076eabe/src/Layers/Tiledjs#Layer. L81 -L85 о том, как это реализовано в Esri Leaflet.

Возможно, сделать фокусируемым и весь контейнер всплывающего содержимого и переключить фокус на щелчок маркера
@mourner в https://github.com/Leaflet/Leaflet/issues/3210#issuecomment -73291846

мне действительно очень нравится эта идея. Если пользователь фокусирует всплывающее окно, мы должны отправить фокус всплывающему контейнеру. Я мог бы сначала подумать о том, чтобы поместить это в Esri Leaflet и посмотреть, смогу ли я продвинуть что-нибудь, что может быть полезно, в Leaflet. Это также должно сделать SVG доступными, но я думаю, что здесь что-то есть.

Используйте role=presentation и alt="" на фрагментах карты, чтобы программы чтения с экрана не читали их URL-адреса.

Да. Пожалуйста, воплотите это в реальность.

Привет, в моем собственном тестировании программы чтения с экрана NVDA я заметил, что всплывающие окна открывать непросто. В режиме «навигации» NVDA, когда маркер фокусируется клавишей TAB, программа чтения с экрана произносит альтернативный текст тега img, если таковой имеется. Но нажатие ENTER или SPACE не открывает всплывающее окно.

Добавление только role="button" в тег img маркеров заставляет его работать.

_initIcon: function () { ... if (icon !== this._icon) { ... icon.setAttribute('role', 'button') }... } отлично работает. Есть ли причина не делать этого?

После этого: возможно, содержимое всплывающего окна фокусируется автоматически при popupOpen -> голос может его прочитать -> вернуть фокус обратно маркеру, когда всплывающее окно закрыто -> пользователь может перейти к следующему маркеру.

Это было бы очень полезно в случае, когда всплывающие окна содержат сложную информацию, ссылки или кнопки и не могут быть суммированы только в теге alt значков.

ИЗМЕНЕНО
Эта демонстрация 2015 года очень поучительна: http://melmo.github.io/accessibility/berlin.js/code/dist/leaflet.html

• Они используют role = 'presentation' для плиток (который сейчас находится в ядре буклета)
• Они фокусируют всплывающее окно при открытии и снова фокусируются на маркере при закрытии
• Они используют role = 'application' на карте div

Значение role = 'application' в основном предотвращает передачу вспомогательными технологиями (JAWS / NVDA) JS.
В моем тестировании (Chrome и Firefox, буклет в полноэкранном режиме) он не позволяет программе чтения с экрана читать ВСЕ теги alt значков при загрузке страницы. После этого пользователь может переключаться с одного маркера на другой и открывать маркеры клавишей ENTER. Так же, как и обычная навигация с помощью листовки с клавиатурой без программы чтения с экрана.

Функция role = 'application' может быть опасной, поскольку отключает сочетания клавиш reen reader, к которым может быть использован пользователь, но, похоже, она идеально подходит для листовки.
В статье говорится, что он ломает вещи в firefox. Хотя для меня это нормально.

ПРИМЕЧАНИЕ: добавление role = 'button' в теги img по-прежнему является хорошей идеей:
При наведении табуляции между маркерами пользователь услышит: «это мой альтернативный текст - КНОПКА», а не «это мой альтернативный текст - ГРАФИЧЕСКИЙ». Итак, он знает, что может "щелкнуть" по нему клавишей ввода. отличный!

Они фокусируют всплывающее окно при открытии и снова фокусируются на маркере при закрытии

Это кажется полезным для пользователей клавиатуры. Будет ли это хорошей идеей добавить в буклет?

Альтернативой является вставка всплывающего окна сразу после маркера в HTML. Это может устранить необходимость в вызове focus и позволит перейти из всплывающего окна к следующему маркеру.

https://github.com/Leaflet/Leaflet/issues/3210#issuecomment -73323789

Еще одна вещь, которую можно улучшить, - это ссылка закрытия всплывающего окна. Мы можем легко улучшить его доступность, добавив атрибут aria-hidden = "true" к диапазону "x". Затем мы могли бы добавить скрытый диапазон с закрытым текстом после него:

<a class="leaflet-popup-close-button" href="#marker-id">

 <span aria-hidden="true">x</span>

 <span class="visuallyhidden">close popup</span>

</a>

Одна из оценок доступности, в которой я участвовал, сообщила об этой конкретной проблеме.

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

Они фокусируют всплывающее окно при открытии и снова фокусируются на маркере при закрытии

Это кажется полезным для пользователей клавиатуры. Будет ли это хорошей идеей добавить в буклет?

Альтернативой является вставка всплывающего окна сразу после маркера в HTML. Это может устранить необходимость в вызове focus и позволит перейти из всплывающего окна к следующему маркеру.

Для этого уже существует проблема на https://github.com/Leaflet/Leaflet/issues/2199.

# 3210 (комментарий)

Еще одна вещь, которую можно улучшить, - это ссылка закрытия всплывающего окна. Мы можем легко улучшить его доступность, добавив атрибут aria-hidden = "true" к диапазону "x". Затем мы могли бы добавить скрытый диапазон с закрытым текстом после него:

<a class="leaflet-popup-close-button" href="#marker-id">
> 
 <span aria-hidden="true">x</span>
> 
 <span class="visuallyhidden">close popup</span>
> 
</a>

Одна из оценок доступности, в которой я участвовал, сообщила об этой конкретной проблеме.

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

@ahukkanen - https://github.com/Leaflet/Leaflet/pull/7079 (в частности, https://github.com/Leaflet/Leaflet/pull/7079/commits/45f04d3bc7a357ea6fe8b90e90ac09364a37d92c) улучшает текст для закрытия всплывающего окна.

Что касается переводов: интернационализация не встроена в ядро ​​буклета, но доступна в виде плагина - https://github.com/yohanboniface/Leaflet.i18n

@mourner , @IvanSanchez и другие основные участники, не могли бы вы добавить метку «Доступность» для проблем в этом репо? Если вы считаете, что это не очень полезно с точки зрения отслеживания проблем, я все же прошу вас принять это во внимание, поскольку я считаю, что это побуждает сообщество задуматься о доступности.

@Malvoz
Выполнено

Спасибо @ johnd0e , отлично. Следующие открытые вопросы касаются доступности и могут иметь тот же ярлык:

1. https://github.com/Leaflet/Leaflet/issues/7211
2. https://github.com/Leaflet/Leaflet/issues/7193
3. https://github.com/Leaflet/Leaflet/issues/7192
4. https://github.com/Leaflet/Leaflet/issues/6821
5. https://github.com/Leaflet/Leaflet/issues/6742
6. https://github.com/Leaflet/Leaflet/issues/3472
7. https://github.com/Leaflet/Leaflet/issues/2199