AJAX and Screen Readers - Content Access Issues
AJAX and Screen Readers - Content Access Issues
Join the DZone community and get the full member experience.Join For Free
Learn how error monitoring with Sentry closes the gap between the product team and your customers. With Sentry, you can focus on what you do best: building and scaling software that makes your users’ lives better.
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:
- Users not having access to content changes.
- 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”).
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.
To use a text
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
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:
- the ‘Google’ link will load the Yahoo page
- the ‘Yahoo’ link will load the article page
- 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:
- pressing the ‘yes’ button will press the no button
- 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
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.
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.
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.
Kindly contributed by Steve Faulkner , Technical Director, The Paciello Group (TPG)
Published at DZone with permission of Schalk Neethling . See the original article here.
Opinions expressed by DZone contributors are their own.