Chapter 13. Interactivity

The web is both a hypertext system we navigate to find information and a software application we use to accomplish tasks. As a hypertext system, the Web does an adequate job, with enough built-in functionality to allow for describing and connecting documents and for providing document access. As a software application, the Web is less well equipped.

The Web is a client–server application that does not support page-level interactivity. Web interactions are based on a dialog between the Web browser (client) and the Web server (server). The browser requests a page; the server delivers it. Once the page is delivered, the dialog is suspended until the browser makes another page request. In the Web environment, the only way a user can interact with a page is by clicking on a link or submitting a Web form, which prompts the browser to reopen its dialog with the server. In fact, links and forms are the Web’s only native modes of interactivity. Links allow users to navigate within and among documents; forms collect information from users. As such, the Web cannot provide the level of interactivity that we have come to expect from desktop and CD-ROM applications.

Some sites use scripts, Java applets, ActiveX, and plugins (such as Flash or QuickTime) to provide a higher degree of interactivity than can be provided using standard Web structures. Unfortunately, equitable and universal access is difficult to provide when essential site content is designed using nonstandard formats.

Many factors can get in the way of access to nonstandard content. Users can opt out of nonstandard formats by choosing not to load required plugins or by disabling Java and JavaScript. Some users may encounter difficulties downloading and installing plugins. Some system configurations may not allow users to download and install software, including plugin software. Additionally, plugin installation often requires that users visit other Web sites, which may not be accessible. And finally, many of the guidelines for universal usability are difficult, if not impossible, to implement using nonstandard formats.

Generally, the Web is most accessible when sites are built to standards. However, some sites require functionality that cannot be accomplished using standard Web coding. In these cases, apply the universal usability guidelines to the greatest extent possible, and provide alternate access for users who cannot access the nonstandard content.

FIGURE 13.1 Many sites use add-on technologies such as JavaScript to offer interactive features such as this calendar (1) on the Iberia site. These features often add complexity and hinder accessibility rather than improve usability.

In addition, many of the accessibility features that are built into HTML are not available in other formats. For example, structural markup is not part of the Flash format. Users cannot customize Flash content. However, designers can take measures to make nonstandard content accessible. Current versions of Flash allow designers to add accessibility features, such as alternate text for images and captions for audio. But ultimately, HTML is a more flexible and accessible format, and reliance on other formats means that more users will be unable to access and use site content.

Before moving away from standard HTML constructs, consider carefully: Is the desired functionality necessary, or could the same effect be accomplished using standard HTML? Page-level interactivity may be a more elegant way to address a task such as booking a flight, but the task could certainly be accomplished using standard coding (Figure 13.2, previous page).

FIGURE 13.2 Expedia offers users simple dropdown menus for selecting travel dates.

For universal usability, we need to understand and work with the strengths and limitations of the medium before turning to other, less-accessible formats.

In a nutshell. Add-on technologies—such as JavaScript and Flash—are not as flexible or as accessible as HTML. Explore standard methods fully before resorting to a nonstandard format.

FIGURE 13.3 Meetup provides help information (1) in small, auxiliary windows without navigation, status, or other standard browser toolbars (2).

For instance, designers can use JavaScript to open a new window, set its size and position, and determine which browser elements display—menus, toolbars, status bar, and so on. The new window can be defined as fixed or resizable. The user cannot override these settings. For example, if a designer uses JavaScript to open a page in a small, fixed-size window, users who need large type will be forced to scroll and to read a narrow text column.

Another common technique is to move cursor focus from the top of the page, as is customary, to the search text input field. This action is based on the assumption that users want to search and that they will appreciate having the cursor in position to enter a query. Users who expect to access Web content starting at the top of the page—particularly people who use the keyboard to navigate, and those who use screen reader software—will be disoriented if the cursor is anywhere but at the top of the page.

Designers implement these functions for the sake of usability—to make Web use easier and more efficient. However, we need to recognize and respect the boundary surrounding the user’s domain. The Web allows users to make decisions about their environment based on their needs and preferences. We can make Web use easier and more efficient for more users if we stick with conventional Web behaviors and allow users to control their own environment.

In a nutshell. Users become disoriented when the interface behaves in ways that are inconsistent with expectations. Do not assume control of elements of the interface that belong in the domain of the user, such as window size and cursor position.

For universal Web access, all interactive elements must be designed to function using keyboard commands. Point-and-click interactivity is not possible for nonvisual users; such interactivity assumes a rendered page, and nonvisual users work with code. Other users cannot operate a pointing device and so rely on keyboard commands to work with the Web. An interactive element, such as a link or button, that cannot be activated using the keyboard is nonfunctional to such users.

As well as basic functionality, elements must function properly, behaving in a manner that is consistent with user expectations when operated from the keyboard. Keyboard navigation is a two-step process: a control is selected, and then activated. For example, using the tab key selects actionable elements, such as links and buttons. Pressing the enter key activates the selected link or button. This functionality must be standard with any interactive element, even when designed using a nonstandard format. Interactivity that is triggered using other actions will present problems for keyboard users.

A common example of an interactive control that does not follow standard practices is the select menu used to present quick links to site content. Often, these menus use the “select” action to activate: a page request is triggered when the user selects an item from the menu (Figure 13.4). This approach assumes that the user will use a mouse to point to the desired menu item and then release the mouse, thereby selecting the item and triggering the event. Because keyboard users need to select and then activate, they never get past the first menu item. The menu is triggered by the select action, so once the first item is selected using the keyboard, its action is triggered and the corresponding page loads.

FIGURE 13.4 The John F. Kennedy International Airport home page uses dropdown menus to provide quick access to popular pages. The menus are activated by the “select” action—when a menu item is selected, the corresponding page is loaded. This type of point-and-click interaction is not usable from the keyboard.

In a nutshell. Some users activate elements using the keyboard and will be unable to use an interface that requires point-and-click interaction. Make sure all interactive elements are usable from the keyboard and behave in a manner that is consistent with user expectations.

FIGURE 13.5 Sites that use Flash exclusively for content and navigation (1) must provide an HTML alternative (2). Otherwise, users who cannot access Flash will be unable to use the site.

Whenever providing essential functionality in a format that may be inaccessible to some users, provide the equivalent information as accessible HTML text (Figure 13.6). For example, when using Flash for navigation, provide alternate HTML text links for users who cannot access Flash. When using JavaScript for essential content, use the NOSCRIPT tag to provide equivalent content for users who cannot access JavaScript.

FIGURE 13.6 Nova offers users the choice (1) of viewing Approximating Pi in Flash format (2) or as HTML text and images (3).

In a nutshell. Some users cannot access interactivity designed using JavaScript or Flash. When providing content in a nonstandard format, provide the equivalent content as accessible HTML.