Notes
Slide Show
Outline
1
Accessibility Of AJAX



  • Mat Mirabella
  • Principle Accessibility / Human Factors Specialist
  • Melbourne – Australia
  • Mathew.Mirabella@team.telstra.com


2
Overview

  • What is AJAX – Why is it good - Who uses it?


  • Accessibility issues and possible solutions
    • XmlHttpRequest and JavaScript
    • Data can be sent without need for user interaction
    • AJAX can update UI “on the fly”

  • Accessibility and usability of XmlHttpRequest


  • DHTML and JavaScript Accessibility


  • Browser/AT meta-UI interaction model
    • Web sites = collection of linked web pages/documents
    • AJAX = web application like OS GUI, not collection of pages

  • Responsibilities of Key Players
3
What is AJAX?

  • Asynchronous Java And XML


  • Not a range of abrasive cleaning products


  • A programming paradigm not a language


  • Arrived in the 1990s - not a new idea


  • Uses a collection of open technologies
    • XHTML, CSS, JavaScript, DOM and XmlHttpRequest

  • Straddles the worlds of client-side and server-side scripting


  • Developers need to understand both worlds  to use AJAX properly
4
AJAX – What’s it used for?

  • To create rich interactive web applications


  • Can look-and-feel like native OS applications


  • Competitive advantage due to enhanced customer experience


  • What’s good about it?


    • Before AJAX:
      • Submit/wait/redisplay paradigm
      • Whole page Refreshes - big downloads

    • With AJAX:
      • Data persistence - asynchronous communication with server
      • No request/response cycle needed
      • No need to refresh the entire page - smaller downloads
5
AJAX – Applications… Who uses it?

  • Apps that need to refresh data on a cyclical basis
    • e.g. table showing stock prices that update every minute

  • Apps that change the UI on response from users
    • e.g. online chat clients, maps that can be dragged

  • Apps that need to use rich widgets
    • e.g. an audio mixer with many slider controls

  • Examples:
    • Google maps
    • Google mail
    • New Yahoo! mail

  • But what about Accessibility? …


6
A.  AJAX needs JavaScript and XmlHttpRequest

  • Some browsers do not support these technologies
    • PDA and mobile phone browsers - no XmlHttpRequest
    • Most text browsers and older browsers - no JavaScript

  • WCAG requires that all web content works  without JavaScript


  • Possible solutions:


    • 1.  Provide functionality without JavaScript, maybe using NOSCRIPT

    • 2.  Alternative accessible site that provides an equivalent app
      • e.g. Google Mail's basic HTML view

  • But these solutions don't afford you the benefits of AJAX


  • And it is unlikely that all the same functionality would be supported without AJAX
    • e.g. Google Mail settings

  • Are there better solutions?



7
A.  AJAX needs JavaScript and XmlHttpRequest
  • Cont…
    • 3.  Combine data abstraction with progressive enhancement

      • Build apps using standard server side technology and web site UI technology
      • Data abstraction is used to ensure that functions on server side can be reused in AJAX
      • Then progressively build JS and AJAX capabilities on top.

  • Means the app will degrade gracefully when JS/XmlHttpRequest is not supported


  • “With a little bit of forethought, you can build an application that can be used by everybody whilst giving the majority an enhanced experience”
8
B.  AJAX can submit to servers without user interaction

  • Possible to save/change data without user knowing it is happening
    • Can occur at any time, not necessarily on pressing "Submit"

  • Often very quick in processing data
    • Users may expect a short delay or page refresh when they submit data

  • Possible solutions:


    • 1.  inform the user at the top of the form how and when their data will be save and  used

    • 2.  provide some indicator (visible or audible) that data was saved

    • 3.  Allow user to explore UI and add or edit/undo data before it is saved
      • important "forgiveness" usability - may mean still using a "Save button"

  • But the problem is more general than this ...
9
C.  AJAX can update interface elements 'on the fly'

  • How can users know what is happening when parts of the UI are refreshed?
    • Screen readers typically read in a linear fashion - When UI changes happen, the user may not be aware of this and new content may not be read

  • to allow dynamic interface changes to be accessible, the application must:


    • 1. Alert the user that a change has occurred
    • 2. Allow direct access to the new content
    • 3. Then allow continued functionality of the web application.

  • Most AJAX applications can be designed to do this...
10
C.  AJAX can update interface elements 'on the fly'
  • Cont…
  • Some ways to improve AJAX accessibility:


    • 1. Inform the user at the top of the form that it requires JavaScript or detect JavaScript automatically and warn the user when it isn’t available.

    • 2. Inform the user that the page is updated dynamically. Important for screen reader users - it will help them decide when to trigger a re-read of the page.

    • 3. Make it possible to receive an alert when information was updated.
      • e.g. JS Alert boxes are read by the screen reader and are usually displayed together with a sound

    • 4. Highlight recently updated areas for a short period of time. Helps sighted users understand what just happened.
      • e.g. "The Yellow Fade Technique" and the "Fade Anything Technique" (FAT)

  • General theme - Design for your users rather than code for them
11
D.  Apps don't keep history or inform AT on UI updates

  • Conventional post/response creates “history” and provides data to AT by it's nature.  What about AJAX?


  • Browser history may not be meaningful in an AJAX app - so the means for users to go back/forth needs to be built into the app


  • How can AJAX apps provide information to screen readers that the UI has changed without doing it in the UI where they won't "see" it?


  • As well as XHTML/CSS techniques, consider:
    • 1.  XmlHttpRequest usability and accessibility
    • 2.  DHTML and JavaScript accessibility
    • 3.  Interaction model for AT and browser to provide meta-UI

  • Let’s consider these in turn
12
Accessibility of XmlHttpRequest

  • For XmlHttpRequest based scripts to be accessible, they need to at least:


    • 1.  Allow graceful degradation with JavaScript disabled
      • i.e. use server side methods when JS is not supported

    • 2.  Have a way to notify which parts of the page has changed.
      • e.g. "message area / key area" that lists what has changed on a page - much like a history log. accessible via an accesskey and/or high up on the tab order, and/or via skip links
      • e.g. Consider using DOM methods to write out the content instead of inner HTML.  AT such as screen readers should be able to access the DOM (e.g. through MSAA) - but AT vendors need to build in this capability

  • Also relates to usability of XmlHttpRequest …
13
Usability of XmlHttpRequest

  • Already discussed "forgiveness" and browser support, some other points ...


    • 1.  Know the difference between a web application and a website

      • Web applications - Richer, use AJAX, use XmlHttpRequest, comply to UI guidelines

      • Web sites - collection of pages, do not need extra richness, comply to web site guidelines

      • When you mix these - you confuse the user

      • User expectations - what do they expect to see?

      • Accessibility - needs to be true for both
14
Usability of XmlHttpRequest
  • Cont…
    • 2.  Do not break what the user is focusing on:

      • Don't pull the user away from their current interaction just because AJAX has the capability

      • Users will be confused if their focus is stolen before they are finished their task

      • Consider usability first before technical capacity to make things quicker

      • Sometimes a "go" button is still better than an automatic action and you can still do it in AJAX without page refreshes

  • On to DHTML and JS accessibility …
15
DHTML Accessibility

  • W3C, IBM and Mozilla are working together to build it into Firefox


  • Provides accessibility of desktop-style widgets such as tree views, menu bars and spreadsheets which are accessible both with the keyboard and AAT


    • 1.  Keyboard navigation - Extension to html tabindex
      • let's any element be  tab-indexable or focusable
      • e.g. tree views with arrow navigation

    • 2.  Assistive technology support with mark-up that uses namespaced attributes to describe widgets
      • e.g. tabindex, role, properties – all exposed to AT
        • <span tabindex="0" xhtml2:role="wairole:checkbox"
        •       property:checked="true"
        •       onkeydown="return checkBoxEvent(event);"
        •       onclick="return checkBoxEvent(event);">
        •   Any checkbox label
        • </span>
      • Currently only supported in Firefox 1.5 and above
16
DHTML Accessibility
  • Cont…
  • Currently limited support in user agents


    • Internet Explorer
      • Currently supports only keyboard navigation
      • No support yet for role and properties

    • Mozilla Firefox
      • Support in versions 1.5 and above
      • Most AT does not yet utalise this

  • AT vendors should be able to support DHTML widget semantics without changes in Internet Explorer by looking directly at the  DOM and DOM change events.


  • In practice – currently limited but improving
17
JavaScript Accessibility

    • 1.  Offer a non-JavaScript alternative - May not need to use NOSCRIPT at all

    • 2. Avoid "cute" tricks and flashing/moving content
      • e.g. scrolling/changing text may cause odd refreshing behavior

    • 3.  Don’t hijack the user’s browser, that is:
      • Never use un-requested popups!
      • Don’t resize or move browser windows.
      • If you use popup windows, alert the user first.
      • Don’t disable the resize or scrollbar features of popups.

    • 4.  Use logical event handlers instead of technology dependent ones
      • e.g. Avoid onMouse... events or use them in combination with onKey... events

    • 5.  Consider needs for a variety of disabilities
      • We should always be doing this

  • Recall the "until user agents..." checkpoints in WCAG 1.0?


    • Many user agents now allow users to control issues such as spawning/refreshing/redirecting

    • But scripts that hijack the browser are still unwelcome especially to users who don't know how to control them
18
Browser/AT meta-UI interaction model

  • Screen readers have an interaction model for navigating pages and history, and selecting items
    • e.g. use enter, tab, shift-tab, pgUp/pgDown and arrow and ctrl-arrow keys

  • Also for form entry and review – use of Jaws “forms mode”
    • e.g. Use of different “cursors” and “entry modes”

  • OnMouse… events – new interactions introduced into Jaws


  • AJAX – range of events – what should a screen reader UI “feel” like?


  • AT vendors have a responsibility to:
    • 1.  Utilize DOM information and other data (e.g. MSAA)
    • 2.  Provide a Usable UI to make the data effective for users

  • But user agent vendors have important responsibilities too…
19
Browser/AT meta-UI interaction model
  • Cont…
  • For web sites – collections of pages
    • Today’s browsers provide good flat UIs

  • If AJAX is about web apps – richer – not flat pages?
    • Browsers need to “deliver” the interface more like an OS does
    • Not flat, not “page based” and not without a cursor
    • Need to use a more dynamic interaction model on a fundamental level
    • Need to really be “apps” not “documents”
      • e.g. like JAVA, GUIs from wxWidgets, like a desktop in VNC

  • If this occurs, even more important that AT moves ahead to embrace this paradigm


  • GUI apps work differently to browser content but the line between them is fading


  • Other responsibilities – Who is responsible for what?
    • Much the same story as with standard web accessibility
20
Responsibilities of Key Players

  • User agent vendors
    • XmlHttpRequest, DHTML and JS accessibility
    • UI and interaction model

  • Web developers and authoring tools
    • Think across various technologies involved
    • UI design focus rather than code compliance focus when using standards like WCAG
    • Tools need to always deliver technically accessible solutions

  • AT vendors
    • Update interaction models for dynamic apps rather than flat pages

  • OS and application vendors
    • improvements to APIs such as MSAA to allow better rich application accessibility
    • e.g. Microsoft is updating MSAA for Windows Vista

  • Standards bodies
    • improvements to accessibility guidelines
    • accessibility within technology domains
    • UI paradigms for web and mobile web

  • Need consistency from positive working relationships between all parties
21
What else do we need?

  • Need a standardized approach to informing AT about events
    • i.e. Similar to the workings of MSAA and APIs for GUI apps in Ms-Windows

  • Browsers should have a cursor so AT does not have to implement one
    • e.g. screen readers need to have a “virtual cursor” in IE
    • Future versions of Firefox will have a cursor in the browser space

  • Need a standardized approach to the UI provided by browsers and the meta-UI provided by AT
    • There are differences across screen readers just as there are across browsers

  • Do we need an RFC on how AT should provide a meta-UI
    • Standards bodies might design this but AT vendors would need to comply

  • Authoring tools – another important story
    • Good tools can make it easy for you to get accessibility right without knowing the detail

  • A consideration of user needs – what do users really want from the future web?
22
Recap of Overview

  • What is AJAX – Why is it good - Who uses it?


  • Accessibility issues and possible solutions
    • XmlHttpRequest and JavaScript
    • Data can be sent without need for user interaction
    • AJAX can update UI “on the fly”

  • Accessibility and usability of XmlHttpRequest


  • DHTML and JavaScript Accessibility


  • Browser/AT meta-UI interaction model
    • Web sites = collection of linked web pages/documents
    • AJAX = web application like OS GUI, not collection of pages

  • Responsibilities of Key Players
23
Some References

  • AJAX - a New Approach to web applications - Jesse James Garrett
  • http://www.adaptivepath.com/publications/essays/archives/000385.php


  • Max Kiesler - How to Make Your AJAX Applications Accessible - 40 Tutorials and Articles
  • http://www.maxkiesler.com/index.php/weblog/comments/how_to_make_your_ajax_applications_accessible/


  • Web AIM - Accessibility of AJAX applications
  • http://webaim.org/techniques/ajax/


  • AJAX and Accessibility - Standards Schmandards
  • http://www.standards-schmandards.com/2005/ajax-and-accessibility


  • "The Yellow Fade Technique" - Matthew Linderman
  • http://www.37signals.com/svn/archives/000558.php


  • The :Fade Anything Technique" FAT - (Adam Michela)
  • http://www.axentric.com/posts/default/7


  • XMLHttpRequest Usability Guidelines
  • http://www.baekdal.com/articles/Usability/XMLHttpRequest-guidelines/


  • bestkungfu weblog » Ajaxessibility - Matt May
  • http://www.bestkungfu.com/archive/date/2005/03/ajaxessibility/


  • AJAX and Screenreaders: When Can it Work? [JavaScript & AJAX Tutorials]
  • http://www.sitepoint.com/article/ajax-screenreaders-work


  • Accessible DHTML - Mozilla Developer Network
  • http://developer.mozilla.org/en/docs/Accessible_DHTML


  • Accessible JavaScript Guidelines
  • http://cookiecrook.com/AIR/2003/train/jsguidelines.php


  • IBM Accessibility Center | Resources | AJAX Accessibility Overview
  • http://www-306.ibm.com/able/resources/ajaxaccessibility.html


  • Bruce Lawson’s personal site  : Ajax, accessibility and assistive technology
  • http://www.brucelawson.co.uk/index.php/2006/ajax-accessibility-and-assistive-technology/