KUDUweb website design services in Chester, Liverpool, Manchester, North West, UK

AJAX paper

4.2 Screen Reader friendly AJAX

Lemon & Faulkner argue that
“it isn’t possible to make Ajax work in every known assistive technology, in the same way that it isn't possible to get Ajax to work with older browsers” (2006).
There are however some methods that can be introduced to aid the majority of popular screen readers in making an AJAX request. The primary reason for the in accessibility of AJAX with screen readers is that a screen reader does not know that the page has been updated. The virtual buffer of the majority of screen readers will only respond to click or keypress events in ECMA Script.

It is important to understand how a screen reader reads a webpage to interact with it. A screen reader will have a virtual buffer. The virtual buffer holds a copy of the web page on screen and allows the screen reader to access the attributes of tags as well as the content displayed. This is useful when describing visual content on an HTML page. As the buffer is loaded separately to the visual page on the screen this must be updated as content changes.  This update usually only happens when the page is reloaded.

AJAX usually uses the onreadystatechange event to update the page but the virtual buffer on the screen reader does not update. This suggests that the screen reader needs to be updated to know where the content has been changed. ECMA Script has a focus method this can be used
“to place the focus to the part of the page that has changed”. (Lemon & Faulkner ,2006).

A workaround is still required as only the ‘a’, ‘area’, ‘button’, ‘input’, ‘object’, ‘select’, and ‘textarea’ elements can receive a focus.    The Dynamic Accessible Web Content Roadmap
by the W3 Consortium suggest the current best practice to provide focus to all active elements is to assign a tabindex of -1 (Schwerdtfeger, 2006). This makes any element focusable without placing it in the tab order and avoids confusing users that rely on keyboard input to navigate.
Consider the following pseudo code process:

 

 

arrowConstruct HTTPRequest();
arrowsendRequest();
arrowgetAnswer();
arrowupdatePageContent();
informScreenReader();

The functionality of the AJAX request is the same as before but adding in an informScreenReader method that updates a screen reader of the request. Simply setting the focus will not necessarily allow a screen reader to read the text out depending on the mode of the software. The user may need to request for the element that has received the focus to be read out. It is suggested that an easily discoverable link to a help file could explain this clearly to a screen reader user.

There is another discovered solution for the JAWS screen reader 7.1 and above. As this is a popular screen reader I suggest that the following solution should be investigated and possibly be built into the informScreenReader method.
“In JAWS 7.1 and later, certain script statements cause the virtual buffer to be update without any interaction by the user. For example, under certain conditions, content updated using innerHTML will cause the virtual buffer to update; after the update, the virtual buffer won't contain the content added with innerHTML, but will contain the content before the function was called, so this could be used at the end of an Ajax call to update the virtual buffer.”  (Lemon & Faulkner, 2007)
As innerHTML is not DOM compliant it is not the best method to use. Fortunately it was also discovered that the virtual buffer is also updated “when the setAttribute method is called to update a form control's value” (Lemon & Faulkner, 2007). It is then suggested that a hidden input field could be used to update the virtual buffer. Combining this with the focus command should notify the screen reader of content changes. 

 

previous<< next >>