Web 2.0 Mashup Accessibility CSUN 2008

Uploaded on


  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads


Total Views
On Slideshare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide
  • Broad definition, so best explained via examples – let’s start with consumer web Zillow- home prices on map Seatsnapper- Event tickets website. Can view eBay listings on interactive seating maps, and have events that you cannot attend flagged via the Google Calendar API. Pageflakes- personalized start or home pages Very different apps.. But what really makes something a mashup? On the consumer web, Google Personalized Home Page is a good representative of these characteristics. For example, you may build your personalized page with Google Map, Travelocity, Currency Converter, and weather gadgets to compose a travel planning mashup.
  • We referenced widgets on the previous slide, but what are they really? Widgets are really just portable chunks of code that can run in any HTML-based web page without requiring separate compilation. Widgets are typically HTML fragments with some associated meta-data, like name, title, etc. They can be written in any language and can be generated by server side code, if so desired. Also, unlike portlets, they don’t require deployment or complex packaging. There are several names for widgets – like gadgets, blocks, flakes, etc., but they all refer to the same type of thing. I'd add to the widget slide that widgets are basically URL addressable fragments, portlets are Java code, a special case of an iWidget implementation is implementing it as a portlet that's exposed as an iWidget, but for iWidgets there are many other ways to implement them as well, as you already mention on the chart. You can create widgets in HTML tools like Dreamweaver Our Hello World iwidget can be written in a couple of lines and doesn't require deployment, whereas a portlet needs multiple files, packaging, deployment
  • Self-Service: empower business users to assemble new applications (mashups), reducing application backlog Deliver more innovative, customer-focused applications by supporting end user application development Increase flexibility by delivering more nimble applications Improve productivity and collaboration by delivering situational applications Quickly uncover new business insights by easily assembling information from multiple sources Bigger communities of folks contributing content and functionality Speed Flexibility Innovation Real time problem solving
  • The slide shows an on-demand personalization for a broad (wide area) network. In this slide different types of resources, found in the network, feed an aggregating server. These resources include, charts, captioned video, maps, RSS/Atom data feeds, basic web pages, search tools, and a web log. The aggregating server takes these resources to form searches, Web 2.0 mashups, etc. The aggregating server then has requests made on it by cell phones, laptops or personal computers, and high-end PDAs like an IPhone. The aggregating server is provided a number of user, device, environmental, and ACCLIP preferences from these devices through a context managing Device Profile Evolution server, possibly managed by the Open Mobile Alliance, in such a way that the content provided by the aggregating server is up to date with the user’s context. The context is defined by these preferences. The aggregating server provides in-context, aggregated versions of the requested resources to the requesting device on demand.
  • The slide shows on-demand personalization of a potential local network implementation. In this slide different types of resources, found in the network, feed an aggregating server. These resources include, charts, captioned video, maps, RSS/Atom data feeds, basic web pages, search tools, and a web log. The aggregating server takes these resources to form searches, Web 2.0 mashups, etc. The aggregating server then has requests made on it by a laptop or personal computer. The aggregating server is provided ACCLIP preferences from an identity broker which also feeds the user’s laptop or desktop device in such a way that the content provided by the aggregating server is static based on the last time the user provided the information to a company’s local network. This may be a preferred configuration for a company’s local network where corporate intranets store user profile information on common data store managed by an identity broker. The aggregating server provides in-context, aggregated versions of the requested resources to the requesting device on demand.


  • 1. Web 2.0 Mashup Accessibility CSUN 2008 Rich Schwerdtfeger IBM Distinguished Engineer Peter Parente Software Engineer Emerging Technologies
  • 2. Agenda
    • State of Web 2.0 Accessibility
    • Quick look WAI-ARIA
    • Introduction to the Programmable Web and Mashups
    • IBM Mashup Accessibility Analysis
    • Short Term Solutions
    • Long Term: Flexible, Personalized Web
  • 3. State of Accessibility for Web 2.0
    • Tremendous progress on Web 2.0 Application accessibility
      • IBM led W3C Accessible Rich Internet Applications (WAI-ARIA)
      • Reusable, Accessible RIAs springing up: (Dojo AJAX Toolkit, JQuery)
      • IAccessible2, Gnome ATK/ATSPI Allows ATs full access to RIAs through the browser
      • AccProbe Test Tool, (Firefox, Opera, IE) browser support under way
      • ATV support: Window-Eyes, JAWS, ZoomText, Orca, NVDA
    • WAI ARIA – Allows for
      • Full interoperability with ATs
      • Keyboard usability of the desktop
      • Semantics for content adaptation
    • Accessibility of all applications has its limitations
      • One size fits all
      • Great if you control all the content/code
      • The web is becoming programmable and distributed
  • 4. Quick Look at WAI-ARIA
    • Extends and fills gaps in (X)HTML to support accessibility
    • Uses Meta data found in Rich Desktop Applications to provide for full interoperability with assistive technologies
      • Role, state, property information for widgets
      • Identify Drag and Drop information
      • Defines relationships between UI components
      • Provides information to handle live regions
      • Provides navigational landmarks
    • Allows Web authors to provide desktop keyboard navigation
      • Tab to significant areas and arrow within the widget
      • All HTML keyboard accessible
      • Allows all items to be focusable without impacting the tab order
    • Is cross-cutting and helps all users
  • 5. The programmable web
    • Companies making Web 2.0 API public as a service API
      • Fragments, data, reusable widgets
      • programmableweb.com > 660 APIs
    • RSS and Atom Data Feeds made public
    • Opportunity for rapid Web 2.0 application development
    *RSS – Real Simple Syndication
  • 6. What is a Mashup?
    • A mashup is a web application combining data or capabilities from more than one source into an integrated experience
      • Popular on the consumer web - over 3.45 new mashups/day are appearing:
    Zillow SeatSnapper
    • What typically characterizes a mashup?
      • Lightweight integration of applications (enables rapid development)
        • “ Widgets” that make up a mashup are often developed and deployed independently without knowledge of each other
        • Widgets can be mashed and wired together in the browser
      • Utilize web technologies like HTTP, **JSON, XML, JavaScript, Atom, RSS
      • Often incorporates one or more public API and online services
      • Often, mashups can be customized by the end user
    Pageflakes.com **JSON – JavaScript Object Notaton
  • 7. What is a Widget?
    • A widget is a portable chunk of code that can run in any web application without requiring separate compilation
    • How is a widget different than a portlet?
      • Widgets are URL addressable fragments and can be written in any language (Java, .NET, PHP, etc.). Portlets are Java code.
      • Widgets can be as simple as an HTML fragment, so they don’t have to involve any server side code (but they can).
      • Simplicity of model enables developers to learn how to create widgets in a matter of hours versus days.
      • Widgets don’t have a complex packaging structure or require a complex deployment model.
      • >> A simple “hello world” widget can be written in a tool like Dreamweaver, and the file can copied into the file structure on the server. A “hello world” portlet would require a Java-based tool and also consists of multiple files, packaging, and deployment.
    • No widget standards and many vendors have created their own names: gadgets, blocks, flakes, etc.
  • 8. Mashups are Catching on in the Enterprise, But Why?
    • Lightweight integration enables rapid development and lowers skill set requirements
      • Enables the creation of applications that were previously too costly to build (like situational applications)
      • Extends web app development beyond IT – out to even knowledge workers
      • Reduces IT backlog
    • Availability of many widgets and gadgets allows organizations to assemble applications at a lower cost
    • Once a component is developed, it can be easily reused across different applications, regardless of the underlying technology
      • .NET and J2EE and PHP widgets can communicate together on a page
      • .NET + PHP widgets can be mashed into a J2EE-based app (and vice versa)
    • Wire up for interoperability
      • Gartner: By 2010, more than 30% of Global 2000 organizations will enter a new era of end-user computing via user-assembled, composite applications created with enterprise mashup environments.
  • 9. Examples of Enterprise Mashups Competition Tracker / Web Site Sales – Customer Trip Prep Data Center Administrator Mashup Collaborative Web App for Project Teams
  • 10. Mashup Example
  • 11. Accessibility/Usability Wild Wild West - issues from content aggregation are extensive
    • Is the resource accessible?
    • Will the accessible resource meet my needs (WAI-ARIA is new)?
    • 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?
  • 12. Accessibility Study QED Wiki
    • No Accessibility Assessment of Data Feeds (RSS/Atom)
    • Keyboard problems
      • Conflicting accelerator keys, tab ordering, IDs, etc.
      • Content from a remote service traps input focus
      • Dynamic content inappropriately grabs focus
    • Inaccessible services
      • No WAI-ARIA support
      • No keyboard support
      • Fixed sizes, styles, and layout (Can’t respond to system settings –font/color)
    • Interaction inconsistencies
      • Different defaults
      • Different paradigms
      • Disrespect for local user settings
    • Invisible relationships
      • Missing status indicators for widgets
      • Missing controller-controlled by relations among widgets
    • Drag/Drop Layout construction problems
  • 13. Near term solutions
    • Mashup runtime environment must take responsibility for exposing relations among widgets.
      • Use WAI-ARIA relationships (controls, flowto, labelledby)
      • Use WAI-ARIA to mark regional landmarks (main, secondary, contentinfo, etc.)
    • Mashup runtime should attempt to repair any problems it can.
      • Compute a global tab ordering by inspecting explicit tabindex in widgets.
      • Fix overlapping IDs. (Store Widgets in IFrames where possible)
      • Override widget styling.
    • Mashup designer tooling must support creation of accessible mashups.
      • Provide reusable accessible widgets when available
      • Prompt user for WAI-ARIA information when possible
    • Ultimately, must address the accessibility of the original widget content.
      • Services providers must adopt WAI-ARIA
  • 14. Near Term solutions for Mashup construction
    • Layout grid templates for widgets
      • Allows all users to use keyboard to navigate pre-designed template
      • Use WAI-ARIA to apply keyboard navigation/semantics to the grid
    • Provide accessible utilities to wire up widgets
    • Ensure mashup UI consists of accessible WAI-ARIA enabled components (Dojo Toolkit)
  • 15. Aggregation issues expose bigger problems which also create business opportunity
    • One size fits all approach
    • Usable access may require equivalent alternatives
    • Content Aggregators: Unaware if a resource is accessible (Web 2.0 mashups)
  • 16. Problems with one-size fits all
    • Learning disabilities needs vary greatly
      • Managing content density, highlighting specific text, providing different color schemes, use of symbols, etc.
    • Complex visualizations may require equivalent alternatives for blind consumers
    • Use of closed captioning or transcripts depends on the language spoken by the consumer
    • Restructuring content may benefit mobility impaired user
    • Does not adapt to the environment the user is operating in
      • High background noise, low light, temporary mobility impairment, etc.
  • 17. Basis for the solution resides in the learning space
    • IMS Access For All Specifications (Version 2 under development now)
    • ISO JTC1 SC36 Standard nearly final
    • http://www.imsglobal.org/accessibility
    *DC – **LOM – Learning Object Metadata
  • 18. Access for All Standards
    • A description of the user’s personal needs and preferences (*ACCLIP)
    • A description of a digital resource (**ACCMD)
    • Can be used with or without other personal profiles and other resource metadata
    *ACCLIP – Accessibility Learner Information Package **ACCMD – Accessibility Meta Data
  • 19. Business Value
    • Personalization
      • How much business is lost when people walk away from an online purchase?
      • What additional revenue could search companies realize if results were easier to use (advertising service contracts)?
      • Aging workforce, with cash, don’t want to show they have a disability
      • Service opportunity for ATVs and accessibility consulting
      • Corporations improve effectiveness of e-training
      • When does a person’s environment make the IT unusable?
    • 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?
  • 20. Strategy Moving Forward – Demands Personalization
    • Address accessibility of resource content
      • Continue to evangelize and drive industry toward WAI-ARIA adoption
      • Develop Best Practices for addressing accessibility Merge Issues
      • Perform accessibility study of data feeds (RSS, ATOM, others)
      • Identify transformations needed (Fluid Project)
    • Develop “flexible internet highway infrastructure” map user preferences with the appropriate resource and adapt the resource where necessary
      • Develop standards for resource meta data and user preferences (IMS AccessForAll)
      • Work with W3C/**OMA Deliver user preferences over *DPE?
      • Deliver Accessibility Preferences from identity brokers?
      • Potential – Fluid Project
    • Drive Industry Adoption of flexible highway
      • Providing resource meta data (catalog of accessibility capabilities and equivalent resources
      • Drive understanding of business value
    *DPE – Device Profile Evolution **OMA – Open Mobile Alliance
  • 21. Take advantage of ability to:
    • Transform the user interface of resources (display and control)
    • Re-aggregate resources
    • Configure tools to meet user needs
  • 22. On-Demand Personalization Broad Network *DPE – Device Profile Evolution RSS/Atom Blog search Aggregating server (search, mashup, etc.) *DPE Server Content and ACCMD Device, User Agent, Environment, ACCLIP
  • 23. On-Demand Personalization Local Network RSS/Atom Blog search Aggregating server (search, mashup, etc.) Identity Broker Content and ACCMD ACCLIP ACCLIP
  • 24. Summary
    • Mashups are in the early stages of addressing accessibility
      • Like WAI-ARIA, IBM is leading to get us ahead of the curve
    • WAI-ARIA places usable access on equal playing field with desktop but Mashups could undo the good work
    • Reusable WAI-ARIA enabled toolkits, like Dojo, are on the rise – Use them
    • The advancement of the Web mandates an Open Accessibility Strategy
      • Open architectures
      • Open standards
      • Open Source
      • Leverage social collaboration!
      • Proprietary creates barriers!
    • The time is now to move to a more flexible, accessible web
      • Critical for content aggregation
      • Essential for addressing learning and cognitive accessibility
      • Addressing broader accessibility issue will generate significant business value
  • 25. For a copy of the presentation or more information, contact: Rich Schwerdtfeger at [email_address] Questions?