Accessible Rich Internet Applications (ARIA) – Part 1: Introduction

[stefan_schnabel]

Abstract

Companies like SAP using the Web and Intranet along with Web Browsers are challenged to develop applications with reference to their internal accessibility standards. Providing HTML element metadata (roles, states, and properties) within HTML page structure according to the Accessible Rich Internet Applications (WAI-ARIA) specification helps to achieve this goal. WAI-ARIA (or shorter: ARIA) bridges this gap between HTML 4 and HTML 5+ and is already a W3C recommendation for enhanced accessibility support in the Web. SAP currently implements the ARIA standard in a variety of its web-based products.

Structure of the Article

This first part of the article discusses the need for complex Web controls, presents various Web content types, and explains why there is a need for something better than current solutions offer – this is where ARIA comes in. The second part of the article introduces ARIA itself and describes its specifications, basic concepts and design patterns, support in user agents, assistive technologies, and development toolkits, its, and finally turns to future challenges.

Table of Content

• Introduction


• Web Content Types
  
  
  
  • HTML Documents
  
  
  • Brochures
  
  
  • Web Applications
  
  
  • Rich Web Applications
  
  
  
  


• The Need For Something Better

 

Introduction

Complex business applications used in Intranet scenarios and in the Web and in Internet scenarios demand for rich user interaction with specialized elements exclusively designed for this purpose. To achieve this, the HTML document object model has to be used and to be extended. : A general problem is here that the number of UI elements in the standard HTML4 element set is limited and partly insufficient. For instance, there is no standardized HTML4 “slider”, no “tree” element, and no “interactive data table” specified.

 Figure 1: A custom CSS-styled slider element

This has been “resolved” by reinventing the wheel a dozen times creating these “custom” elements using standard HTML elements. As a consequence, common API’s to identify roles, states and properties, and states to Assistive Technology (AT) are bypassed or are even used in a confusing manner (This is the same as styling plain text to look like a heading, rather than using a heading element – the plain text looks like a heading, but is not revealed as a heading to assistive technology). Although there is now a host language definition for e.g. a slider-like “element” in the HTML5 specification (the input type="range" state), visual representation in the various user agents will differ, for there is no custom CSS styling concept for the element yet. For a specific design to be implemented, this will again demand for custom modifications of the DOM assembling a slider from various styled parts, so the situation has not much improved. Also, page updates as a result of a page interaction are often missed by people using assistive technology. Assistive technologies usually expect Web content to change in response to a navigate event, such as following a link or submitting a form. Web applications use techniques, such as AJAX, to update content silently in the background, which is sometimes missed by assistive technology. Even if assistive technology is aware of updates, the user still might not be aware that the content has been updated, or how to locate the updated content. Even more so, there is currently no standard for user agent-assistive technology interoperability regarding this issue. Finally, along with providing alternative text for non-text objects, being able to interact with interface elements using the keyboard alone is one of the most basic accessibility provisions. Developers who understand accessibility might build custom widgets using components that can receive focus, such as the input element with a type property value of image (type="image" ...>). Unfortunately, most widgets are not built using components that are keyboard accessible, but instead use elements such as the img element, or may consist of composite elements that need to be in a container element, such as a div element, which is unable to receive keyboard focus by default.

Web Content Types

People communicate with Web content by using browsers. People with disabilities use assistive technologies in addition. Content is created by Web developers using authoring and evaluation tools. The situation is depicted below (image source: IBM):

Figure 2: Relationships between developers, content, and users

The content created serves multiple different needs for different purposes, and dependent on that, follows completely different interface design concepts and Gestalt principles. To understand the situation in more detail, let us have a closer look at some of the variations of content with respect to focusing on business needs (we will not discuss Multimedia Web sites like [YouTube] etc. here).

HTML Documents

HTML was originally designed to be a hypertext system for structuring and sharing linked documents among scientists and generally in the academic circles. Early HTML drafts defined tags, such as headings, paragraphs, lists, and anchors, to add structure to text-based documents. The first proposal for an HTML specification by the IETF also included the img element to allow graphics to be displayed inline.

Figure 3: A classic HTML document

Variations of this concept include newspaper-like layout of pages. The interaction model is passive, in a reading and browsing manner. Still quite a few Web sites are mainly document-oriented.

Brochures

“Web brochure” is a term for Websites, which primarily offer information to users, but only little interaction with respect to data entry or selection. A typical Web brochure is, for example, a museum Website presented in a brochure-like appearance where users can learn about a museum’s exhibits.

Figure 4: A Web “brochure” (display of goods in a brochure-like manner) (click image for larger version)

Users may want to browse this catalog, in order to see what the museum has to offer, get background information for the exhibits, and learn when the museum is open to the public. In Brochures, the interaction is still passive. If any, “active” communication with the server takes place by filling out *get me more information” contact forms using the small set of interface components.

Web Applications

Web applications may also offer information, as is done, for example, in product catalogs. But their main goal is to enable users to accomplish a certain task, like ordering products from an online store.

Figure 5: Web page expecting user input (using “shopping cart metaphor” to order goods) (click image for larger version)

The application example also offers a catalog, but here the users browse the catalog in order to find and order products, like T-shirts or shoes. The main or eventual goal of the users lies in the ordering action. Like for brochures, still standard HTML form elements are used to handle these requests (the first formal HTML specification was HTML2, based on the early HTML drafts. This specification introduced forms, and defined a small set of interface components to create edit boxes, buttons, checkboxes, radio buttons, and dropdown lists). The ordering process is typically restricted with respect to the UI by using only this limited set of form elements because all common browsers support them.

Rich Web Applications

Rich Web applications try to emulate regular desktop applications, except Web applications run inside another regular desktop application – a “User Agent”, i.e. a browser.

 Figure 6: Yahoo Mail

The interaction model is complex, fast responses are expected, and complex UI elements are “emulated” using generic native host language elements like simple styled images and text. Intranet-based use cases include, for example, Employee Self-Service (ESS). ESS means that typical tasks that had been delegated to secretaries or other colleagues in the past, are now done by the employees themselves. Some typical ESS applications are:

• Maintain personal data


• Enter holidays and view approval status


• Time management: arrival, leave, absence


• Find people, addresses, phone numbers, …


• Order products online


• Order services online


• Book rooms


• Book trainings

Business-to-customer applications (B2C apps) are services offered by companies to their customers on the Internet. This scenario implies that end-users vary widely in their computer literacy. Thus B2C applications should be as easy to use and self-explaining as possible.

• Direct Sales


• Restricted product range, for example books, music CDs, media in general, photography articles, computers, flowers


• Catalogs, i.e. broad product range (warehouses, technical warehouses)


• Product configuration for computers, cars, etc.


• Direct Booking


• Train, flights, ferry, car rental, hotels (incl. “combined packages”)


• Direct Banking, Auctions


• Online banking (status requests, information, orders, transfers, …)


• Online auctions


• Status, Information


• Status of shipments in general (e.g. UPS, FedEx, German Post)


• Online Sales, e.g. shipment status, product availability


• Product information


• Products and price comparisons, dealer comparisons, references to dealers


• Business-to-Business

Business-to-business applications (B2B apps) comprise business scenarios taking place either on the Intranet within a company, or on the Internet between companies. B2B applications are typically used on a regular basis; therefore they need not be as self-explaining as B2C applications. However, the degree of computer literacy may vary widely among users, depending on how much effort a company puts into training its employees.

• Intranet


• Retail (whole process, including goods entry, inventory, specials, master data, time management, …) Example: SAP Retail Store


• Internet


• Orders from external vendors Example: Procurement Suite (complete order process for external vendors)


• Bidding from and comparisons of vendors

 

The Need for Something Better

Developing a typical Business-to-customer and Business-to-business application using HTML reveals fundamental differences between HTML, its communication model, and a regular desktop application:

• Regular desktop applications have a behavior layer that is not dependent on requests to a server (stateful frontend scenarios).


• Regular desktop applications have a far richer set of interface components to simplify specific complex tasks (Non-standard HTML elements (editable data tables, trees, tab strips, drag and drop, Status/Message Areas, Alerting mechanisms, etc.).


• In the development environments for custom application interface components (“User Controls”) there is native platform support to include platform accessibility API’s and custom keyboard handlers

In order to emulate regular desktop applications, Web applications use JavaScript to add behavior (for example, JavaScript might be used to allow a menu item to expand and collapse when the user interacts with it). Occasionally, data may be required from the server (for example, the application may have to fetch records from a database on the server to update information on the current page). When applications have to interact with the server, web applications use techniques such as AJAX or hidden IFrame elements to communicate silently in the background. As HTML has very few interface components, Web applications sometimes need to create more complex widgets, such as a tri-state checkbox or a slider control. The look and feel of these widgets is usually created by drawing the widget as a graphic, and adding scripting to make them behave like the native component. The communication model for HTML is based on the client server model. In the client server model, the client sends requests and can receive replies; the server listens for requests, processes the request on the server, and sends replies back to the client. As HTML did not have a behavior layer, communication was intended to be sequential – the client requests a page from the server; the server processes the request and sends a page to the client. This has some implications, for example, for direct client-side fast responses as a result of user interactions there is no built in support. This can be addressed using AJAX and making server requests in the background yielding a more responsive user experience. All of the above results in a number of accessibility problems that are particularly bad for users of assistive technologies, such as screen reader users.

• Widgets built this way in HTML are rarely keyboard accessible.


• The role of the widget, what it does, is not available to assistive technology.


• States and properties of the widget are not available to assistive technology.


• Updates and discovery of the updates are not reported to assistive technology.

It was really time to do something. WAI-ARIA is an attempt in this direction: It is basically a metadata specification that provides a means of describing roles, states, and properties for custom widgets so that they are recognizable and usable by assistive technology users. WAI-ARIA is described in the second part of this article in detail.