11.2 Design Principles for Accessible Interfaces

This section enumerates a set of design principles that ensure accessible user interface design. These design principles are phrased in the context of user interaction authored via markup languages and deployed to a Web browser; however, many of them are applicable to general user interface design as well.

11.2.1 Content Should Encapsulate Relevant Metadata

When creating user interfaces via markup languages such as XHTML, the content designer should ensure that all relevant metadata for each user interface element is contained within the declarative markup for that element. As an example, if the user interface contains a widget that is created via markup element gadget , then all metadata pertaining to this user interface gadget , for example, the label to display, the tooltip that is popped up, or the help information that is displayed upon request, should all be encapsulated by the markup for element gadget .

Legacy HTML fails to meet this design principle but instead relies on visual layout to help the reader associate various user interface controls with their labels.

Meeting this guideline requires that the markup language being used contain the necessary constructs for such encapsulation. It also requires that the markup language enable designers to achieve the various layouts they need when using the structured markup provided by the language.

11.2.2 Separate Content from Layout and Presentation

Separating details of layout and presentation from the content markup is a key requirement for ensuring the accessibility and device independence of the resulting user interface. HTML started as a simple markup language but over time degraded into a confused mix of structure and presentation markup. The increased adoption of CSS for styling has finally enabled sites to factor out presentational rules into style sheets.

This still leaves the problem of HTML authors using multiple levels of tables for achieving a desired visual layout. More advanced CSS features, such as CSS pseudoelements and CSS absolute positioning, are beginning to provide a solution to this problem. The advantage of these modern approaches to customizing the style and layout of Web content is that the resulting XHTML documents are easily rendered on a variety of display devices. In addition, using CSS to design visually pleasing pages has the advantage that the resulting Web pages display significantly faster than the earlier HTML tables solution. The success of this approach can be judged by the fact that recently, Wired ^[1] magazine (a site that was notoriously inaccessible due to its attempt to create a magazine-like appearance using HTML tables) switched to XHTML 1.1 and CSS 2. The resulting site downloads and renders significantly faster while being fully accessible.

^[1] http://www.wired.com

11.2.3 Ensure That Content Can Be Refactored

Well-structured XML content has the advantage of being suitable for generating multiple views; in fact, this is one of the original motivations behind structured markup languages. As an example, when a book is authored as a well-structured XML document, it is extremely easy to generate a table of contents, or to display only the figures in the book. This form of content refactoring and filtering is extremely useful when building alternative modes of information access. For example, such content refactoring and filtering enables efficient eyes-free access to information.

The advantages enumerated in the case of structured documents apply equally well to the domain of user interfaces created via markup languages, where the document is the interface. Markup languages that provide structural elements that can be used to group related elements of the user interface are well suited for this form of accessibility. Examples of these include the ability to group related choices in a menu or to group related user interface controls to appear within a common container. The ability to refactor the user interface, rearrange elements of the user interface, and progressively reveal relevant portions of an interface is significant both to users of small devices and to users with special needs.

11.2.4 Ensure That Rich Content Degrades Gracefully

To ensure that Web interfaces remain accessible and device independent, the underlying user interface framework should ensure that rich content degrades gracefully. As an example, stock market performance may be displayed as a bar graph when using a rich visual display, as a table of numbers on a textual display, and as a succinct spoken summary when using an eyes-free interface. In a well-designed system, all three of these representations should be derivable from the same underlying representation. In a system that fails to degrade gracefully, the information might get hard coded as a table or a graphic and prove impossible to access via a cell phone with a small display or with a speech-only interface.

11.2.5 Avoid Device-specific Events

The behavior of a user interface is often a function of the interaction events to which it responds. When creating accessible Web interfaces designed to be used from a variety of end-user devices, it is important to ensure that the events the Web application responds to are not device specific.

As an example, a Web page that is explicitly authored to respond to mouse movement events is impossible to use in the absence of a pointing device; such pages are unusable by a functionally blind user. Authoring the same Web application to respond to a more generic event, for example, DOMFocusIn can make the same application usable from a variety of devices and ensure accessibility. This is because the specific device in use can map the available device-specific events to platform-independent events such as DOMFocusIn . The result is that a blind user might generate the DOMFocusIn event by moving focus with a press of the tab key, while the cell phone user might generate the same event with a special navigation key. In either case, the application continues to function correctly.

A corollary to this principle is the consistent use of accelerator keys to ensure that an application is keyboard accessible. Keyboard accessibility is often cited as an essential requirement to ensure that an application is accessible to blind users. However, lack of keyboard access is usually symptomatic of the bigger problem of relying on platform- or device-specific events.

11.2.6 User Interfaces Should Exhibit Predictable Behavior

Predictability is a key factor in determining the overall usability of a user interface. Web interfaces often attempt to grab the user's attention by using fancy gimmicks in the user interface. Although these do succeed in drawing the user's attention, they do not necessarily aid in rapid task completion. ^[2] Where predictability in the user interface speeds task completion for the average user, it can often be the difference in being able to complete a task at all in the case of users with special needs.

^[2] A point that was probably in their favor during the eye-ball counting dot-com boom.

Consistent use of keyboard shortcuts and, more generally , consistent binding of device-specific events to standard actions can significantly enhance overall accessibility.

11.2.7 Allow for Late Binding of Interaction Behavior

A follow-up to the previous principle of graceful degradation is the late binding of presentation and interaction behavior to structured content. We emphasized the importance of separating content from presentation and interaction earlier; ensuring the late binding of presentation and interaction semantics ensure that a user interface can be best customized to match the user's needs and abilities .

11.2.8 Enable Centralized Event Handling

Adaptive technologies often need to attach additional handlers that alert the user to changes in application state. Such behaviors are best attached at a centralized location in the interface hierarchy rather than at each widget making up the user interaction.

As an example, an adaptive technology might wish to attach a special alert message whenever the user is about to send out personal information. A complex Web interface may provide many points in the user interface where the user is likely to trigger such a submission. Attaching the specialized alert message to each such point in the application can be tedious and can result in errors. Centralized event handling, that is, the ability to attach the custom behavior at a single point in the user interface hierarchy, provides a reliable means of ensuring that the user always receives the alert message.

Notice that this design pattern is not specific to adaptive technology alone; it is a key requirement for enabling any kind of augmentative behavior in the user interface.

11.2.9 Raise Notification Events for Key State Changes

Adaptive technologies and augmentative user interfaces that cater to a user's special needs often perform their function by triggering specialized handlers that produce custom behaviors at appropriate points during user interaction. But to be effective, this design pattern requires that the underlying user interface framework raise a rich set of notification events that can be responded to by such handlers.

Notification events need to encapsulate sufficient contextual information about the state change that is being communicated. The eventing framework that is exposed by the underlying platform also needs to be sufficiently flexible to allow such behaviors to propagate these notification events to a central point in the interface hierarchy where they can be handled in a consistent manner.

11.2.10 Provide Hooks for Attaching Special Behavior

The right set of notification events and a flexible eventing framework are necessary conditions for hooking specialized behaviors. To be sufficient, the framework also needs to enable complete access to the current interaction context from within handlers that implement specialized behavior. In addition, handlers that implement augmentative behaviors may need to pass information about their actions to the rest of the interaction framework.

Thus, in a well-designed user interface framework, augmentative behaviors that have been created as specialized event handlers that respond to state changes and other notifications blend into the main application and become an integral part of the final user experience. In this sense, creating such accessible behaviors as an augmentation ”rather than as a part of the original application ”is mostly a programming convenience that enables the core interaction framework to carry functionality that is needed by all users while enabling specific augmentations to be added based on a given user's needs and abilities.

11.2.11 Use Declarative Handlers in Favor of Scripts

Event handlers written in scripting languages like Javascript can prove an effective means to experiment with new user interaction behaviors. Once a set of effective behaviors has been arrived at, it is often advantageous to recast these behaviors as declarative handlers that are authored via XML markup. In addition to being more maintainable and allowing the binding of different programming languages to the declarative handler at runtime, this approach also has a significant benefit when it comes to adding augmentative behaviors to match a user's special needs.

Once a commonly used handler has been codified using declarative markup, this establishes a clear contract as to the actions that that handler is expected to perform. As a result, XML documents that use such declarative handlers to attach interaction behavior can be statically analyzed and the results of such analysis used in automatically attaching specialized behavior.

As an example, consider a Web application that invokes an action handler to display a help message in a pop-up window. If this is achieved via a standard declarative handler, all instances of its use can be automatically augmented with an additional handler that also speaks the help message. However, if this same action is achieved via a fragment of imperative Javascript, such augmentation would require human intervention since it would be impossible to derive the result of invoking the script fragment automatically.