7

Я создаю a website for a reading service for the blind and visually impaired, и я использую JavaScript (с jQuery) для печати некоторых материалов на некоторые страницы после загрузки страницы.Считыватели экрана и Javascript

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

От this page - «Как правило, [устройства для чтения с экрана] обращаются к DOM (Document Object Model), и они используют API-интерфейсы браузера (интерфейсы прикладного программирования) для получения необходимой им информации».

и мы знаем, что jQuery является библиотекой манипуляций DOM.

Таким образом, вопрос становится ... читатели экрана берут копию всего DOM, а затем анализируют его и читают? Или они читают DOM, тот, который работает jQuery?

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

<div id="now-playing-div"></div> 

<script> 

// invoke the audio-reader javascript library 
$(document).ready(function() { 
    var callback = nowPlaying; // catalog, schedule, podcasts, archive or nowPlaying 
    var selector = '#now-playing-div'; 
    makeAudioReaderPage(callback, selector); 
}); 

</script> 

Так как вы можете видеть, если читатель экрана не читает то, что JavaScript/JQuery печатает на # теперь-игры-DIV то он не будет читать ничего. Затем мы начали получать несколько писем путаных слушателей, которые задавались вопросом, что случилось с ссылкой «Сейчас играть».

Так сегодня утром я прибавил:

<div id='no-js'>Please enable JavaScript to receive this content.</div> 

<script> 
$(document).ready(function() { 
    $('#no-js').toggle(); 
}); 

</script> 

Но если проблема не то, что JavaScript должен быть включен (a recent survey shows, что 99% пользователей чтения с экрана включили JavaScript), то проблема не решена и сделана еще хуже, потому что теперь пользователь экранного устройства подумает, что JavaScript не включен.

Что делать ??

+1

Вам нужно будет проверить с помощью конкретного провайдера экранных прошивок. Невозможно ответить на этот вопрос - они ** ДОЛЖНЫ ** запрашивать живое пространство и поэтому обратите внимание на любые изменения. Но если конкретный запрос один раз и кэшируется, то его, вероятно, не следует использовать. «Статические» страницы больше не существуют, и отключение немедленно мертвой/бесполезной/устаревшей копии страницы чрезвычайно бессмысленно/глупо. –

+2

Существует хороший способ изначально проверить это - установить [NVDA] (http://www.nvaccess.org/), бесплатный экранный ридер для Windows. Если вы находитесь на Mac, попробуйте VoiceOver. Вы также можете загрузить и запустить пробную версию [JAWS] (http://www.freedomscientific.com/Downloads/JAWS). Получите [обзор видео NVDA] (https://www.youtube.com/watch?v=Vx1vSd5uYS8) или [сочетания клавиш для всех] (https://www.paciellogroup.com/blog/2015/01/basic -screen-ридер-команд-для-доступности тестирования /). После этого исследуйте [живые регионы ARIA] (https://www.paciellogroup.com/blog/2014/03/screen-reader-support-aria-live-regions/). – aardrian

ответ

0

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

Это делается с атрибутами ARIA.

Я добавил aria-live="polite" в свой html. «Вежливый» параметр говорит читателю экрана, что он должен читать новый контент, но не прерывать то, что в настоящее время говорят. IIRC - другие настройки: off и assertive.

<div id="now-playing-div" aria-live="polite"></div> 

<script> 

// invoke the audio-reader javascript library 
$(document).ready(function() { 
    var callback = nowPlaying; // catalog, schedule, podcasts, archive or nowPlaying 
    var selector = '#now-playing-div'; 
    makeAudioReaderPage(callback, selector); // the callback will append HTML to the element via jquery with the selector as the query term 
}); 

</script> 

Прямо сейчас у меня есть парень, который не может видеть ничего проверить веб-сайт, он использовал, чтобы быть в состоянии видеть, и он научился пользоваться компьютером, прежде чем он потерял глаз зрение.К сожалению, ему сложно провести время с сайтом. Проблема в том, что, когда он добирается до страницы, чтобы прослушать аудио, он использует свои сочетания клавиш для поиска кнопки воспроизведения, но кнопка воспроизведения отсутствует, потому что кнопка воспроизведения (jplayer) находится во всплывающем окне, которое появляется после нажатия ссылка. Он расстраивается, и телефонный звонок завершен :(

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

3

Вы можете протестировать это, не зная, как читатели экрана анализируют DOM. Я предлагаю этот ответ прежде всего потому, что вы не предложили какой-либо код для тестирования («некоторые вещи для некоторых страниц» не являются кодом для тестирования), и ваш пример не обеспечивает достаточного контекста.

  • Установите NVDA, бесплатный читатель экрана для Windows.
  • Если на Mac включите VoiceOver.
  • Если на Ubuntu/Gnome, установите Orca
  • Загрузите и выполните пробную версию JAWS.
  • Если на iOS включите VoiceOver.
  • Если на Android, включите TalkBack.
  • Черт, попробуйте Рассказчик на Windows.

Существует множество учебников, которые помогут вам начать работу. Вот пара:

Затем, если вы обнаружите, что ваш сценарий изменяет DOM после чтения с экрана уже разобран его, исследовать ARIA live regions, а затем посмотреть на browser support.

Наконец, ваш пример выше об обнаружении, если скрипт включен в действительности не нужен скрипт для работы, если вы используете <noscript> элемент:

<noscript> 
<p> 
Please enable JavaScript to receive this content. 
</p> 
</noscript> 

Если браузер скрипт включен, это не будет оказывать (который хороший). Тем не менее, это не относится к случаям, когда блок сценариев, который вы хотите показать, не работает по другим причинам (сетевое отставание, ошибки и т. Д.). More on <noscript>

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

+0

Это скорее лекция, чем ответ, но хорошо –

+1

Извините, это было не мое намерение (хотя теперь я вижу, что это звучит немного укол). Частью проблемы является то, что это движущаяся цель, поэтому трудно дать простой ответ. – aardrian

2

«Как правило, [читатели экрана] обращаются к DOM (Document Object Model) и используют API-интерфейсы браузера (интерфейсы прикладного программирования) для получения необходимой им информации».

Современные устройства чтения с экрана используют API доступности. Им не нужно ничего знать о Javascript или о реальных DOM и HTML (за исключением ChromeVox).

По этой причине один и тот же скринсейвер будет использоваться, чтобы проконсультироваться с Интернетом с вашим любимым браузером, написать письмо с вашей любимой программой (Thunderbird, Outlook, ...) или сыграть в игру flash player. поскольку эти программы предоставляют правильную информацию для их API доступности. Они не анализируют HTML напрямую, а доступное древовидное представление документа.

Это означает, что если ваш браузер понимает javascript, ваш экранный инструмент будет. Это потому, что ваш экранный ридер не будет обращаться к DOM непосредственно при загрузке страницы, но будет взаимодействовать с API-интерфейсом Accessibility, предоставляемым вашим браузером.

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

Это краткое резюме, а в следующей статье может дать вам больше информации о парсинга DOM чтения с экрана: Why accessibility APIs matter