Making RIAs Accessible - Spring Break 2008

Slide 1: Making RIAs Accessible Andrea Hill Resource Interactive andrea.hill@gmail.com http://www.afhill.com/blog/

Slide 2: Making RIAs Accessible • The purpose of this session is to look at what makes RIAs a challenge to accessibility, and how these challenges are being addressed. • Feel free to add, edit or argue! 2 2

Slide 3: Overview • DOM-based vs Plugin-based • Regulatory compliance • Assistive technologies 3 3

Slide 4: What does “RIA” mean? “The promise of rich clients includes the ability to cleanly separate presentation logic and user interfaces from the application logic hosted on the network. Rich clients should provide a model for easily using remote services provided by back- end components, whether hosted in an application server or accessed as XML Web Services” (J. Allaire, 2002) [1] •A departure from the traditional “page refresh” to retrieve data 4 4

Slide 5: DOM- versus Plugin- based RIAs • DOM-based RIAs make changes directly to the Document Object Model (AJAX) • Plugin-based RIAs sit atop the browser (Flash, Flex, Open Laszlo, Silverlight) 5 5

Slide 6: How/why are they different? • DOM-based RIAs make changes to DOM. Assistive technologies simply need to recognize these changes. • Plugin-based RIAs are in a security sandbox. Need established interfaces to communicate (at an OS level). ATs also need to be aware thereof 6 6

Slide 7: Regulatory Compliance Section 508 and WCAG1.0 were drafted in the late 90s, really only apply to “traditional” web applications Guideline 1. Provide equivalent alternatives to auditory and visual content. > People’s Choice Awards Voting Module “The World Wide Web Consortium only documents techniques for non- proprietary technologies; the WCAG Working Group hopes vendors of other technologies will provide similar techniques to describe how to conform to WCAG 2.0 using those technologies.” 8 7

Slide 8: Establishing Standards/ Best Practices Best Practices • WAI (Web Accessibility Initiative) has a proposal for WAI-ARIA. WAI-ARIA involves adding additional semantic information to controls (roles, states, properties) that could be passed onto assistive technologies. • Major browsers have all pledged support: Firefox, Safari, Opera, IE8. 9 8

Slide 9: Screen reader considerations • DOM-based: WAI-ARIA is a proposed framework for making accessible RIAs. When a change is made to the DOM, this would trigger a response from the screen reader. There is also the ability to specify the “politeness” factor. • Plugins: Flash leverages MSAA (Microsoft Active Accessibility) and will notify a screen reader of changes.* • *yes, I said MSAA. Which means Windows only. Up until December 2007, it meant IE only, despite the fact that Flash has offered 11 9 accessibility features since Flash MX.

Slide 10: Screen reader considerations • Part of what makes RIAs more usable and engaging is the lack of a page refresh. A sighted user may perceive changes to the page. How do we introduce changes in an audible format? “Using a screen reader is a bit like reading a page through a  soda straw. You can only see one thing at a time and you can’t see anything else around it.” Bob Regan (Adobe, formerly Macromedia) 10

Slide 11: Politeness! aria-live="off" Any updates made to it should not be announced to the user. aria-live="off" would be a sensible setting for things that update very frequently such as timers that change every second. aria-live="polite" The region is live, but updates made to it should only be announced if the user is not currently doing anything. aria-live="polite" should be used in most situations involving live regions that present new information to users, such as updating news headlines. aria-live="assertive" The region is live. Updates made to it are important enough to be announced to the user as soon as possible, but it is not necessary to immediately interrupt the user. aria- live="assertive" should be used if there is information that a user should know about right away, for example, warning messages in a form that does validation on the fly. aria-live="rude" 11 The region is live. Updates to it are extremely important. In fact, the updates are so

Slide 12: Current accessibility “suites” • DOM-based RIA: Firefox browser, FireVox screen reader (proposed by Charles Chen) • Flash: IE browser, JAWS or other screen reader (proposed by Thea Eaton) 13 12

Slide 13: Can RIAs be Accessible? • Yes • No • And then what’s the next step? (Virtual space...) 13

Slide 14: Resources ✤ Macromedia Flash MX—A next-generation rich client. (March 2002) Allaire, Jeremy. http://download.macromedia.com/pub/flash/whitepapers/richclient.pdf ✤ Techniques for WCAG2.0 - Working Draft http://www.w3.org/TR/WCAG20-SCRIPT-TECHS/ ✤ Kirkpatrick, Andrew. “New Flash Player with MSAA on Firefox and H.264 Video” Retrieved from http://blogs.adobe.com/accessibility/2007/12/new_flash_player_with_msaa_on.htm on January 26, 2008. 15 14