Last October, I wrote an article in conjunction with Aaron Barker in which we tried to find out how screen readers (particularly Jaws and Window Eyes) interact with JavaScript. I had no idea at the time that I would end up using it so much as a reference. However, in hopes that it will be useful to someone other than just me, I thought I should post a link to it here.

Following are a few excerpts:

To understand why screen readers have problems with JavaScript in the first place, we have to understand how screen readers read web pages. The name screen reader is a misnomer since they do not read the screen. Screen readers load the page content from the browser’s document object model (DOM) into a virtual buffer. The user is then able to review this virtual buffer at will, using numerous hotkeys. Items such as links, form fields, and some other elements are identified when they are read. When the user finds a link or other clickable element that they wish to activate, they simply press Enter, and the screen reader tells the browser where they “clicked”. In Jaws, this event [the scroll event] is fired at seemingly random times, including sometimes on page load. In Window Eyes, on the other hand, it fires at much more logical times after the user has read several lines of text. However, keep in mind that all scrolling, as such, is taken care of by the screen reader. From the user’s perspective, there is no such thing as below the fold, as everything on the page is all in one big buffer, and screen readers give no indication to the user when they scroll the screen.

As you can see, it’s not exactly light reading, but can save some time when you want a quick summary of how a screen reader might handle a given piece of JavaScript.