Ajax accessibility: implementing a fallback mechanism

Ajax can be a really powerful tool if used properly. A common mistake in Ajax implementation is the lack of a fallback mechanism to be deployed when Ajax support is not present or partial. A common scenario in that sense is made up by text browsers and screen readers.

Text browsers (like Lynx) don't support Ajax at all just because they don't support JavaScript at all. Imagine a situation where you have to perform an Ajax call triggered by a onfocus event on a text input, for example when you have to display some warnings during form validation. Here's how you can implement a fallback mechanism:

<input type="text" name="email" id="email" />
<noscript>
  <p>The email format must be in the name@domain.extension format.</p>
</noscript>

By doing so, the message will be available even to text browsers that, in addition, don't support CSS neither so that you cannot hide text with CSS properties.

Coming to screen readers, you have to bear in mind that this kind of applications have a very limited support to Ajax and JavaScript in general. Further, since the overwhelming majority of screen reader users generally use keyboard to move through page contents, you have to replace mouse events with keyboard events. But the real problem lies in the content updates performed via Ajax. Screen readers have a feature called virtual memory. By default, this feature is disabled. Without virtual memory turned on, if your content is updated via Ajax, screen readers will restart to read your document from the very beginning. In addition to this, you should always trigger Ajax on elements that can have focus, such as links or form inputs.

In a nutshell, the best thing to do is to implement a solution like the one mentioned above instead of relying on a support that can be very poor or absent.

Leave a Reply

Note: Only a member of this blog may post a comment.