AJAX and Screen Readers – Content Access Issues

The rise in the use of AJAX to dynamically change content without refreshing the page has resulted in accessibility problems for users of Assistive Technology such as Screen Readers. The problem can be divided into two issues

1. Users not having access to content changes.
2. Users not being aware of the changed content if they can access it.

The first issue, which is detailed in this article, is largely confined to 2 software products, the JAWS and Window Eyes Screen Readers. The second issue potentially affects users of most Assistive Technology including Screen Readers and Screen Magnifiers.

Access to updated or new content

JAWS and Window Eyes are the 2 most popular screen readers on the Windows operating system. They both provide access to web pages by taking a copy of the DOM of the page displayed in the web browser and storing it in a “virtual buffer”. It is this copy that the user interacts with when browsing (known as “browse mode”), unless they are interacting with some types of form controls in which case they interact directly with the browser (known as “forms mode”).

Browse mode

When in browse mode the user can navigate to or list many components of page structure including headings, controls, paragraphs and links using keystrokes. One major limitation of browse mode for users of JAWS prior to version 7.1 and all Window Eyes versions is, that unless they do something such as press a button, their view of the content is static. If an independent content update occurs in the browser view of the page it is not automatically updated in the AT users view. Also user dependent changes are not reliably updated, especially when AJAX is used, due to the latency issue. Another limitation is that the user cannot interact with some types of form controls.

Forms mode

To use a text input, textarea or select element the user must step out of browse mode into forms mode. When in forms mode only content contained in elements that can receive focus or content associated with controls (implicit – content positioned near a control or explicit – label element or title attribute) is practically available to the user. Compared to browse mode, the user’s ability to navigate and access non interactive content is severely restricted.

Triggering and Update – JAWS prior to version 7.1 and all Window Eyes versions

An update of the screen reader view is never triggered by a change in content in the browser view, only by a user action, either knowingly or unknowingly. For the users view of the content to be updated and synchronised with the browser view, the user must either manually refresh (Window Eyes ctr+shift+A twice, JAWS insert+esc) the screen readers copy of the page or press the enter or spacebar keys, actions which occur when a user activates a link, button or an element with an onclick event attached.

enter and spacebar

The developers at GWMicro (Window Eyes) and Freedom Scientific (JAWS) both implemented a similar substandard fix to the issue of updating the virtual copy in response to JavaScript based changes in browser content. They figured that if they attached a virtual buffer update command in response to the pressing of the enter or spacebar keys, any content change that may occur, if by chance the element triggered a JavaScript based content change would be included in the new copy, and thus be available to the user.

On the surface this may have seem like a reasonable solution, but it has a number of major flaws; the most glaring being that the user must do something in order for the content to be updated, secondly the JavaScript content change process must be completed within 400 – 1000 milliseconds (the average time it takes for the virtual copy update to occur after it is triggered, this varies across screen readers, browsers and browser versions) of the user pressing the enter or spacebar key. If it is not completed within this time frame the updated content will not be included within the updated screen reader view. For most JavaScript routines the time frame is adequate and the change is caught by the copy update, but when AJAX is used for content updates it can regularly take longer than 400 milliseconds to complete. This latency leads to a disconnect between content the user has access to and what is displayed in the browser.

Browser and screen reader view disconnect – independent content change

An example of the occurence of a disconnect between the browser and screen reader view due to a change in content independent of user action is demonstrated in the independent content change test page. In this example the page loads, after 5 seconds a script is called that removes 1 of the 3 links and 1of the 2 buttons on the page.

Users of JAWS < 7.1 and Window Eyes will be presented with the initial content displayed on page load. they will not be informed that a change in content has occurred in the browser and will be able to browse through the original content, although it has changed in the browser.

If the JAWS user attempts to follow a link the result will be:

1. the ‘Google’ link will load the Yahoo page
2. the ‘Yahoo’ link will load the article page
3. the ‘back to article’ link will update the screen reader view so it corresponds with the browser view, but the link will not be followed.

For the Yes and No buttons:

1. pressing the ‘yes’ button will press the no button
2. pressing the ‘no’ button will update the screen reader view so it corresponds with the browser view, but the action associated with the button is not triggered.

For the Window Eyes user, if they try to activate a link or button that no longer exists in the browser, the screen reader view is updated and the browser/screen reader views are synchronized.

Browser and screen reader view disconnect (the latency issue) – user dependent content change

An example of the occurance of a disconnect between the browser and screen reader view due to a change in content dependent on user action is demonstrated in the dependent content test page. In this example when the 200 (millisecond) button is pressed a request is sent to the server using AJAX and a response is returned that changes the alt attribute content of the image to “200 milliseconds” and add the text “200 milliseconds” to an empty paragraph.

Users of JAWS < 7.1 and Window Eyes will be able to access the changed content in the screen reader view as the time taken for the change to occur (200 milliseconds approximately) is within the acceptable latency period between action and content change. It is caught by the buffer update.

When the 1000 (millisecond) button is pressed the same process occurs, but the latency period is 1000 milliseconds (approximately). In this case the buffer update has already occured by the time the content change occurs. As a consequence JAW < 7.1 and Window Eyes users will not have access to the changed content in the screen reader view. So for example, if the user has previously pressed the 200 button, they will still “see” the image alt and text as “200 milliseconds” although the content has changed (to “1000 milliseconds”) in the browser view.

JAWS version 7.1 + and content change

With the release of JAWS 7.1 there was a marked change in the way content changes are handled. The virtual buffer update is no longer tied to a user action (pressing the enter or spacebar keys), but updates in response to content change events in the browser. So, for example, if text is added or removed , it triggers a buffer update. This is a major improvement in relation to both user dependent and independent JavaScript based content changes. The latency issue (particularly in relation to AJAX) is no longer a problem and the user does not have to do anything for the content change to be updated in the screen reader view. The examples of user dependent and independent content change do not cause a disconnect between browser and screen reader view.

There are still some issues which Gez Lemon and I detailed in Improving Ajax applications for JAWS users, but with subsequent releases (current JAWS release is version 9), the support has improved.

Conclusion

The use of AJAX based content changes is still a formidable accessibility barrier for users of JAWS and Window Eyes, although the technical accessibility issue of access to content changes has been largely resolved in later versions of JAWS, Window Eyes has yet to tackle the problem. It is interesting to note that NVDA, a free screen reader, has better support for content updates than Window Eyes.

Furthermore the issue of informing users of content change has not been resolved. There are work arounds such as the use of the JavaScript focus() method to move focus to changed content, but this is not reliable and of use only in limited circumstances. The implementation of support for WAI ARIA live regions by Assistive Technology vendors is required to provide developers with the tools required to resolve the AJAX accessibility issue.