Site Map



Dynamic, JavaScript-Enabled Content

JavaScript is a powerful programming language that executes within the web browser. It can be used for simple things, such as client-side validation of form inputs (as discussed in the last few Best Practice in "Forms"), and for extremely complex things, such as web application interfaces. JavaScript is commonly used to perform a live update to part of a web page—for example, content that changes without refreshing the entire page. It is commonly used to animate controls or "widgets" on a web page—for example, a navigation menu or toolbar whose deeper levels "fly-out" when the mouse hovers over them or sections of a page that collapse and expand when clicked.

Detailed discussion of dynamic content is beyond the scope of our best practices. However, we can offer a few recommendations geared toward making developers of educational content aware of the major pitfalls encountered when incorporating JavaScript-enabled dynamic content. In the "Resources," section for this topic, we provide references should you want to explore accessibility of JavaScript-enabled dynamic content further.

1. Ensure that controls or actions are useable with keyboard alone and that focus is visible

Discussion

JavaScript-enabled controls need to be able to receive focus using the tab key. Once a control has focus, it should be able to be activated by hitting the space bar or the enter key. It is also important that there be some visual indication that the control has focus, for example, a highlight or border that appears. Some more complex controls, a toolbar that contains many buttons or an expanding tree menu, for example, may be navigable also using arrow keys—the toolbar gets the focus with the tab key and then right and left arrow keys move the user through controls. Again, we are getting beyond the domain of a best practices that focuses on education content and is geared to teachers and instructional designers. However, a good model to keep in mind when evaluating complex user-interface controls in web pages is this: Does this control meet my expectations for how such a control should work? Does it behave like I am used to from using desktop applications?

2. Ensure that dynamic content can be read by a screen reader without deviating from "normal" modes of page navigation and that visually hidden content can be read by a screen reader

Discussion

As in the previous Best Practice, the general rule is that we want to meet user expectations for interaction. For example, if I reach a heading, by navigating by headings in my screen reader, when I down arrow from that point, I expect content related to my heading to be read. The fact that I am on a collapsible section—a heading styled to appear to the student who can see the screen as a collapsible content area—is totally irrelevant to the screen reader using student. He/She expects that a down arrow key press will move her into the content area. In some implementations of collapsible panels, however, the developer hides the collapsed content by making it "display:none" in the stylesheet. As we know, this will hide it also from the screen reader user. But whereas the sighted student will intuitively know that the collapsing panel must be activated to show the content, it is unlikely the screen reader using student will realize it. In such a circumstance, the content should have been hidden from view using an "off-left" positioning technique that allows the screen reader to read what is invisible to the sighted student. Such issues come up regularly with JavaScript-enabled content and controls. And it is why it is crucial to evaluate using a screen reader or, at minimum, know their behaviors—and best, perform a usability test with screen reader using students.

3. Ensure that content that is dynamically updated can be read by a screen reader

Discussion

The term "AJAX" is commonly used to refer to web page content that is updated without a screen refresh. (The term actually refers to the activity of injecting into a page content from a remote web resource, database, or external web page.) When such dynamic changes occur and page content that is not currently focused by the screen reader updates, how will the screen reader user be informed of the change? How will we draw his/her attention to the updated content? And, even if we can draw attention to it, how can we be certain that her screen reader will have an updated representation of this new content and not simply read back the outdated content that was stored in his/her screen reader's cache of the page? The unfortunate answer is that we cannot be certain. There are emerging standards for coding web pages that can help guarantee that screen readers are aware of dynamic changes to page content, but acceptance and implementation of these standards varies from AT to AT and from browser to browser. While it is certainly important to be apprised of emerging specifications whose goal is to make rich internet content accessible, such as the W3C's ARIA specification (see Resources for this section of the best practices), the only truly valid means for ensuring that updated content can be read is by testing with AT and, preferably, doing user tests. The point to take away from this Best Practice and this section of the document, in general, is that while there are clear and reliable techniques for ensuring accessibility when we are implementing static HTML pages, dynamic pages require on the part of the content developer and designer creative thinking, heightened awareness of accessibility issues, and willingness to perform rigorous evaluations.

4. If you manipulate the cursor focus or otherwise update the student's position within a web page, only do so when she expects such actions to occur

Discussion

JavaScript allows for a great deal of control over how a web page behaves. But JavaScript can also modify where the user's cursor is focused. To take an example, if we use JavaScript to create a custom dialog, we will want elements in the dialog to get the cursor focus—so that the next tab key press goes to the confirmation button on the dialog or so the screen reader using student knows that he/she is in a dialog. What we want to avoid, however, is changing the cursor focus unexpectedly. If the student clicks a button, there is the expectation that some action should occur. The student will expect that he/she will be redirected to some other resource or part of the page or that he/she will get a confirmation that some action has occurred. By contrast, if he/she is filling out a form and tabs out of control, only to find himself/herself in another part of the page—where a Shift + Tab will not return him/her to the previous location— he/she will be disoriented.


Resources