1
|
- Mat Mirabella
- Principle Accessibility / Human Factors Specialist
- Melbourne – Australia
- Mathew.Mirabella@team.telstra.com
|
2
|
- 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
|
- 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
|
- 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
|
- 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
|
- 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
|
- 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
|
- 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
|
- 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
|
- 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
|
- 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
|
- 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
|
- 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
|
- 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
|
- 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
|
- 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
|
- 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
|
- 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
|
- 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
|
- 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
|
- 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
|
- 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
|
- 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/
|