屏幕阅读器和Javascript

Question

I'm creating a website for a reading service for the blind and visually impaired and I'm using JavaScript (with jQuery) to print some stuff to some of the pages after the page has loaded.

Will the screen reader read the content that is printed to the page with jquery after the page has been loaded?

From this page - "Generally, [screen readers] access the DOM (Document Object Model), and they use browser APIs (Application Programming Interfaces) to get the information they need."

and we know that jQuery is a DOM manipulation library.

So the question becomes.. do screen readers take a copy of the whole DOM and then parse it and read it? Or do they read the DOM, the same one that jQuery works on?

Here's an example of one of the pages that I use JavaScript on. It uses a function that determines what program we have playing over the air and then prints the name of the program and a link to listen to it.

<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>

So as you can see, if the screen reader doesn't read what the javascript/jquery prints to the #now-playing-div then it will read nothing. Then, we started getting a few emails of confused listeners wondering what happened to the Now Playing link.

So this morning I added this:

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

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

</script>

But if the problem isn't that JavaScript needs to be enabled ( a recent survey shows that 99% of screen-reader users have JavaScript enabled) then the problem is not solved and is made even worse because now the screen reader user would think that JavaScript is not enabled.

What to do??

Answer 1

You can test this without needing to know how screen readers parse the DOM. I offer this answer primarily because you haven't offered any code to test ("some stuff to some of the pages" is not code to test) and your example doesn't provide enough context.

• Install NVDA , a free screen reader for Windows.
• If on a Mac, turn on VoiceOver.
• If on Ubuntu / Gnome, install Orca
• Download and run a trial of JAWS .
• If on iOS, turn on VoiceOver.
• If on Android, turn on TalkBack.
• Heck, try Narrator on Windows.

There are plenty of tutorials to get you up and running. Here are a couple:

• A video overview of NVDA .
• Get a list of keyboard shortcuts for many screen readers .

Then, if you find that your script modifies the DOM after the screen reader has already parsed it, explore ARIA live regions and then look at browser support .

Finally, your example above about detecting if script is enabled doesn't actually need script to work if you use the <noscript> element:

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

If a browser has script enabled, this will not render (which is good). This does not, however, address cases where the script block you want to show fails for other reasons (network lag, bugs, etc). More on <noscript>

Since you say you are "creating a website for a reading service for the blind and visually impaired" the onus is really on you to learn the tools and how to test with them.

Answer 2

"Generally, [screen readers] access the DOM (Document Object Model), and they use browser APIs (Application Programming Interfaces) to get the information they need."

Modern screen readers use the Accessibility API. They do not have to know anything about Javascript , or about the real DOM and HTML (with the sole exception of ChromeVox) .

For that reason, the same screenreader will be used to consult Internet with your favorite browser, to write mail with your favorite program (Thunderbird, Outlook, ...) or to play a flash player game, as long as those programs provide the correct informations to their Accessibility API. They don't parse the HTML directly but an accessible tree view of a document.

This means that if your browser understands javascript, your screenreader will. That because, your screen reader will not access the DOM directly on the load of the page, but will interact with the Accessibility API provided by your browser.

Now, evidently, if your screenreader reads the content before it was modified by javascript, it won't have any clue about modifications made by javascript. For that matter, you can use aria-live attribute.

This is a short abstract, but the following article can give you more informations about the parsing of the DOM by screen readers: Why accessibility APIs matter

Answer 3

I needed to tell the screen reader that the page has changed and that it needs to read the content again.

This is done with the ARIA attributes.

I've added the aria-live="polite" to my html. The "polite" setting tells the screen reader that it should read the new content but not interrupt what is currently being said. IIRC the other settings are off and 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>

Right now I'm having a guy who can't see anything test out the website, he used to be able to see and he learned to use computers before he lost his eye sight. He's having a hard time with the website unfortunately. The problem is that when he gets to the page to listen to the audio, he uses his keyboard shortcuts to search for the play button but there is no play button because the play button (jplayer) is in a popup window that pops up after clicking a link. He gets frustrated and the phone call is over :(

So the good news is that he is able to read the content that is appended to the document via jquery, but the bad news is that there is bigger problems with the flow of the website and his expectations. This is my fault of course.