Skip to main content

Web 2.0 mashup accessibility

Rich Schwerdtfeger, Distinguished Engineer, Accessibility Architecture and Strategy, IBM
Peter Parente, Accessibility Architect, IBM


Mashups are Web applications that combine data and content from more than one source into an aggregated user experience. They are the next stage in the evolution of Web 2.0 applications and a "programmable Web." However, mashups Introduce a number of accessibility issues and usability problems stemming from inaccessible services, inconsistent keyboard navigation, and usability problems.

This presentation discusses the issues and near term techniques addressing the accessibility problems experienced by Mashup providers. The talk also describes how IBM is working to pull together a number of standards efforts in order to advance the global Web infrastructure and make a more flexible Web that adapts to users' needs for improved mashup accessibility and usability. Participants are introduced to emerging standards from the IMS Global Learning Consortium and how, when combined with W3C WAI-ARIA specifications for content, these standards can help mashups deliver an accessible solution geared to the individual.


The industry has made considerable progress on addressing the accessibility of Web 2.0 applications through the development of the W3C Web Accessibility Initiative Accessible Rich Internet Application Specifications (WAI-ARIA) an effort led by IBM at the W3C. WAI-ARIA-enabled widget libraries, like the Dojo Toolkit, are springing up and providing for a semantically rich accessible experience for those who use ARIA.

Companies are now exposing content and data through public service APIs creating what is called the "programmable Web." The programmable Web is generating opportunity for rapid application development through content aggregation called "mashups." A mashup is a Web application that combines content and data, typically from third parties via public services APIs, into an aggregated user experience. Sources of content and data may be from Web feeds (RSS or Atom), Web services, and screen scraping. To date mapping, photo sharing, and video sharing services lead the pack of applications well-suited to mashups. Also, rich browser-based mashup editors are coming on the scene that merge many services including rich UI componentry.

Business opportunities for a flexible web

Mashups are catching on across businesses because they provide development speed, flexibility, innovation and real-time problem solving. They create a "self-serve" environment where enterprises can assemble new applications instead of creating new ones. Mashups enable businesses to:

So, mashups make sense for some Web application providers. However, aggregating content and data, or, resources, from different sources creates numerous accessibility issues:

Ensuring the mashup's accessibility may not seem to make sense. It could be viewed as just another development cost. A provider should ask the following questions to help decide whether or not spending some time on accessibility is worth it:

Accessibility and Usability Study - QED Wiki

QED Wiki is a situational application builder. It allows a user to quickly mash data and content from a variety of sources on the Web into a user interface (UI) suited for a particular purpose. For example, an emergency response team handling the effects of a natural disaster might create a situational application pulling together weather predictions, directions to hospitals, and dispersal of medical supplies on a map of affected cities and neighborhoods. Such an application must be constructed in a matter of days or hours and is only useful for the brief duration of the operation.

The melding of data and content from multiple Web services and local resources into a single Web-based user experience reveals numerous accessibility and usability challenges. Applications like QED Wiki must address issues such as the following:

Next-generation standards adoption for resource meta data and user preferences

It is clear from the accessibility issues at hand that mashup providers don't know if the resource they may use is accessible, whether the resource can be adapted to meet the user needs or whether an equivalent resource is needed. If the mashup editor could be aware that a resource was not accessible, alternatives could be offered such as selecting a collection of accessible ARIA-enabled UI components instead of another inaccessible collection. A Flash video may by closed-captioned in English but the hearing impaired user may require a Spanish alternative—in this case, the mashup provider may want the editor to automatically omit the Flash video all together.

The IMS Global Learning Consortium has defined the AccessForAll specifications with two components:

ACCMD describes the accessibility of a resource. ACCLIP describes user preferences for resources that are designed to map directly to ACCMD meta data.

The IMS Accessibility working group, which includes IBM, is working to extend these specifications to support:

The working group is also creating service APIs for ACCMD that any service used by a mashup could support to aid a mashup provider in delivering accessible content. The group is also defining service APIs for ACCLIP and a matching service API to assist mashup providers with accessibility.

Service APIs is one way to gain access to user preferences. IBM is working with IMS, ISO, and the W3C Ubiquitous Web effort to define ways to pass these user preferences through the browser using Composite Capabilities/Preference Profiles (CC/PP).

Fluid - a working example

IBM is involved with the first open, on-demand, customizable, Web 2.0 Flexible User Interface project for learning called Fluid. Fluid will incorporate AccessForAll specifications and content based on the W3C WAI-ARIA specifications.


The growth of the "programmable Web" is resulting in rapid application development in the form of mashups and mashup editors. New specifications are now available to make Web 2.0 applications accessible, but the Web is in a wild transformation stage where one cannot assume that all third-party services are accessible. In addition, you cannot assume that merging resources from various services will produce an accessible solution that meets all user needs, even if those resources are accessible individually. The need for infrastructure standards that go beyond Web content to produce a personalized, flexible, Web has reached the tipping point. We have an opportunity to produce an accessible Web personalized for all users if we work together. We have an opportunity to make accessibility a true usability feature and not simply a cost of doing business.