Adding Ajax

Revisiting In-Page Update Accessibility One More Time

For the polled comments, the fact that screen readers and screen magnifiers don't pick up the updates isn't really that much of an issue, as users can refresh the page and get the updates. This is the traditional functionality for applications of these types, so there is no loss of functionality by providing dynamic in-page updates.

For the in-page edit shown in Example 6-1, the row deletion in Example 6-5, and the add comment feature in Example 6-7, though, in-page updates can be a problem because a screen reader would most likely not discover that the update has taken place. The only way for the user to know that data modification was successful would be to reload the page and check the data—not an acceptable solution.

One way to work around this issue could be to provide a message box that opens and makes a comment about a successful deletion. This spoils the fade, though, as the message box and the fade are really redundant.

Another approach is to provide an option in the application that specifies how users are notified that a change has taken place. One option would be a message box with the information and another would be using the fade and deleting the row in place. These choices could then be stored in cookies, and the program altered accordingly.

What happens, though, if scripting is turned off? That's where the concept of progressive enhancement comes in: create the application to be nonscript-enabled at first, and then ...