Abstract
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.
Introduction
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:
- Deliver more innovative, customer-focused applications by supporting end user application development.
- Develop applications more quickly with lower skill set requirements at a lower cost.
- Create applications that were previously too costly to build (such as situational applications).
- Extend Web application development beyond IT.
- Reduce IT backlog.
- Lower development costs by reusing already available components, widgets, and gadgets (Bonus: components, widgets, and gadgets can be used across different applications, regardless of the underlying technology. For example: .NET and J2EE and PHP widgets can communicate together on a page or .NET + PHP widgets can be mashed into a J2EE-based app and vice versa).
- Quickly uncover new insights by easily assembling information from multiple sources.
- Solve problems by relying on bigger communities who contribute content and functionality.
- Wire up for interoperability.
So, mashups make sense for some Web application providers. However, aggregating content and data, or, resources, from different sources creates numerous accessibility issues:
- Is the resource accessible?
- Will the accessible resource meet my needs?
- Can the resource be adapted to fit my needs?
- If the resource cannot meet my needs is there an equivalent alternative?
- Will the mashup have consistent keyboard support?
- Is the end solution too cluttered to assist all users?
- Will restructuring the mashup produce a more usable solution?
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:
- Personalization
- If our mashup application is made accessible, will it be more appealing to people in the aging workforce, who have cash, but don't want to show they have a disability?
- How can we create and exploit service and accessibility consulting opportunities for ourselves in partnership with Assistive Technology Vendors (ATVs)?
- Can an accessible mashup application help corporations improve effectiveness of e-training?
- Resource Metadata
- Lawsuits: How does the content aggregator show they did not produce the inaccessible resource?
- System Admin: What accessibility standards did the resource comply to and can I deploy 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:
- Content pulled from two remote Web services and mashed into one situational application could have conflicting accelerator keys, tab ordering, identifiers, and other important attributes.
- Content from a remote Web service and integrated into a situational application UI could be inaccessible (e.g., no keyboard navigation, fixed font sizes).
- Content from a remote Web service could trap user focus.
- Content from a remote Web service could change unexpectedly in a way that makes the situational application suddenly inaccessible (e.g., addition of JavaScript that inappropriately grabs focus).
- Reuse of the situational application UI components as widgets could lead to conflicts among components written by different developers (e.g., keyboard accelerators) and inconsistencies (e.g., politeness levels for ARIA live region markup).
- Widgets that pull content from disparate Web resources may have different interaction paradigms (e.g., Enter submits a form in one widget, resets a form in another).
- The layout of widgets could be affected by the sizing and styling of content from remote services leading to layouts that are difficult to view, understand, and navigate.
- The connections among widgets could be invisible or difficult to ascertain either by looking at the visual UI or an alternative rendering (e.g., clicking submit on a zip code lookup widget updates a weather alerts widget, but not a map widget).
- The status of various widgets or an entire application could be invisible (e.g., server-side code performs a remote fetch without user input on the client).
- Content rendered by a remote service may not respect local user preferences.
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:
- Accessibility Meta Data (ACCMD)
- Accessibility for Learner Information Package (ACCLIP).
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:
- Determining programmatically if a resource is accessible.
- Synchronizing related ISO standards.
- Supporting richer content adaptation.
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.
Summary
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.