NYS Forum IT AccessibilityRefresher on Web 2.0

10/14/2010

–Anthony DeBonis–anthony@troywebconsulting.com

–Martin Navojosky–Martin_Navojosky@tax.state.ny.us

–Debi Orton–dorton@goer.state.ny.us

–Stephen Haynes–shaynes@goer.state.ny.us

Agenda – Overall

• Refresher on Web2.0 – Anthony DeBonis• HTML 5 and Jaws – Martin Navojoski• JQuery UI– Stephen Haynes• ARIA – Debi Orton

• Discussion…• Discussion...• Discussion…

2

3

Agenda

–Web 2.0 Refresher–Review of technology choices available–Some cool new tools to help guide decision making –Accessibility compliance. –Look at HTML5

– What we expect to look forward to– Changes/challenges accessibility.

4

4

Web 2.0 Refresher

Follow up from:

Accessible Web 2.0 Applications, May 15, 2008

Web 2.0 and Rich Internet Applications, Feb 2009

Accessibility and Web2.0/Social Media, Feb 5, 2010

What is Web 2.0?

• wikipedia.org says• The term Web 2.0 is commonly associated with web

applications that facilitate interactive information sharing, interoperability, user-centered design and collaboration on the World Wide Web.

• Examples of Web 2.0 • Blogs• Wikis• Social Media• video-sharing sites• Mashups • Crowdsourcing

5

Technology Choices

• Basic Web – HTML/XHTML• Moving toward HTML 5• Forward movement on XHTML has been halted

• DHTML w/Ajax• Rich Internet Apps (RIAs)• Online/Offline Modes – OCC• APIs – take advantage of social services

• Hooks into Twitter/Facebook etc…

• Mobile Applications

6

Tools

• Developer Tools-just to name a few• Dreamweaver – from Adobe• Aptana – Built on Eclipse Free OpenSource• Microsoft

• Visual Studio• SharePoint Designer• Expression Web

• Web Bases – authoring systems• WordPress• Blogs• Wikis • Content Management Systems (CMSs)

7

Tools Cont…

• BrowserLab• https://browserlab.adobe.com/en-us/index.html

• Site Catalyst - NetAverages• https://netaverages.adobe.com/en-us/index.html

8

HTML 5 – Are we there yet?

• Moving Toward HTML5

• Firefox Jaws Plugin – good to see • https://addons.mozilla.org/en-US/firefox/addon/235880/• An extension for users of the JAWS screen reader that

fixes incompatibilities when using it with Firefox to view HTML 5 web pages.

9

Screen Readers

• JAWS 11• Does well but some issues in FF3.6

• Window-Eyes 7.2• Does not recognize ARIA roles at all• Does not play well with IE8

• NVDA 2010.1• Does very well with the HTML5/ARIA with IE8 or FF3.

• SAToGo 3.0.202• SAToGo also does okay, and now even allows navigation

by ARIA landmark• Source - http://www.accessibleculture.org/research/html5-aria/

10

Accessibility Testing

• www.totalvalidator.com • Supports HTML5• Free website version does one page at a time (max. 5

pages / day)• Free desktop version does one page at a time (no limit)• Paid “Pro” version does single pages or batches (appox.

$40.00)• Windows, Mac and Linux• Tests Section 508, WCAG 1.0 AND 2.0

11

HTML 5 Shortcomings

• Video control missing q-points and captioning does not seem to be in spec

• Can’t record audio or video – still need plug-in• Let the browser wars continue

• Candidate Recommendation Phase - 2012 • Proposed Recommendation - ?• W3C Recommendation (REC) 2020-2012+

12

Accessibility Compliance

• DHTML… vs Server Side Redraw• Challenges with Video and Canvas • Video and Captioning

• The Canvas – more at demos• ADOM – Accessibility Dom Proposal

• “shadow DOM” for assistive technologies can hook into

• - Or – • Navsubtree Proposal

• http://www.paciellogroup.com/blog/misc/canvas-pie/pie.html#

• http://www.w3.org/html/wg/wiki/ChangeProposals/canvasaccessibility

13

Mobile Applications

• BlackBerry - supports• Hearing• Vision• Mobility• Cognitive• Speech

• iPhone• VoiceOver built into each iPhone• Hearing – closed captioning

14

Mobile Applications Cont

• Android Has Accessibility built right into operating sub system• Android operating system running on the Linux kernel.• Built in usable by blind and low-vision users• Android 1.6 included a built-in screen reader and text-to-

speech (TTS) engine• 2,235 Apps Related to Accessibility on Android Market

Place (last night)

15

Mobile Accessibility Videos

Sign Language on Phone4• http://www.youtube.com/watch?v=8_z4ra5B804&feature=related

• Android Voice Commands Example• http://www.youtube.com/watch?v=l2GBxwua0PQ

16

17

Questions

–Debi Orton–dorton@goer.state.ny.us

–Stephen Haynes–shaynes@goer.state.ny.us

–Anthony DeBonis–anthony@troywebconsulting.com

–Martin Navojosky–Martin_Navojosky@tax.state.ny.us

• Up Next• Screen Reader Review

• How is Jaws dealing with HTML5

• Martin Navojosky

18

jQuery Interfaces and Accessibility

• Web 2.0 Form Interfaces• jQuery Tabs• jQuery Accordions• Accessibility issues

• Stephen Haynes• Debi Orton

19

WAI-ARIA

• HTML not designed for applications• Limited set of interface controls• Based around sequential client/server communication

model• App developers created custom widgets with JavaScript

behaviors to emulate desktop widgets• Techniques usually didn’t support assistive technology

20

WAI-ARIA

• Custom widgets didn’t provide sufficient information to AT• Role• State• Equivalent to styling plain text to look like heading, rather

than using heading element: AT doesn’t know it’s supposed to be a heading

21

WAI-ARIA

• Page changes not available to AT• AT expects changes in the context of navigation (e.g., following link) or event (e.g., submitting form)

• Web apps often use techniques (JavaScript, AJAX, etc) to update content silently in background – change not made apparent to AT

• ARIA provides means of describing roles, states, and properties for custom widgets so that they’re recognizable to and usable by AT

22

WAI-ARIA

• HTML History• Originally hypertext only for linking, sharing documents• HTML 2 introduced images and forms• Small set of form interface components to create form

elements – barely changed through HTML 4.01

23

WAI-ARIA

• Communication model for HTML based on client/server• Client sends request• Server listens for requests• Server processes requests• Server sends result to client• Communication intended to be sequential• HTML has no behavior layer – all requests require

server mediation

24

WAI-ARIA

• Web apps try to emulate desktop apps• Problem: web apps already nested within another desktop app (browser)

• Two other differences:• Regular desktop apps have a behavior layer that’s

independent of server communication• Regular desktop apps have a far richer set of interface

components

25

WAI-ARIA

• Web apps use JavaScript to emulate behavior layer

• Example: background server requests• Javascript might be used to expand/collapse menu items• Data calls to server might use AJAX or iFrame for silent

communications

26

WAI-ARIA

• Emulating the desktop’s rich components• Examples: Tri-state checkbox or slider control• Usually a graphic and adds scripting to make them

behave like a native component – “look and feel” emulation

27

WAI-ARIA

• Accessibility issues with “look and feel” emulation• Widgets rarely keyboard accessible• Role – what widget does – not available to AT• States, properties of widget – not available to AT• Page updates, update discovery, not reported to AT

28

WAI-ARIA

• ARIA created to solve app/widget problems• Allows developers to create accessible, rich, Internet

applications • Enables developers, rather than restrict• Easy to implement

29

WAI-ARIA

• Keyboard Accessibility• One of the most basic accessibility provisions• HTML 4 introduced tabindex attribute, which allows

developers to direct AT users through interface• ARIA extends tabindex attribute so that it can be used

on all visible elements

30

WAI-ARIA

• ARIA Roles• Helps to define widgets• Role provided by ARIA trumps native role of the element• ARIA spec maintains a list of roles

31

WAI-ARIA

• Document Landmark Roles• Roles to help define the structure of the document (e.g.,

article banner, complementary, contentinfo, main, navigation, search, etc.

32

WAI-ARIA

• ARIA States and Properties• Provide further information about the widget to AT to help

the user understand how to interact• Examples: aria-valuemin, aria-valuemax, aria-valuetext,

aria-labelledby• Will not validate with HTML 4.01 or XHTML 1.0• May be added to the HTML 5 spec when it nears

completion

33

WAI-ARIA

• Live regions allow elements in the document to be announced if there are changes without the user losing focus

• Aria-live circumvents the problem of “silent updates” not being available to AT

• Aria-atomic provides info to AT on whether updates have occured

34

WAI-ARIA

• Using ARIA• No negative side-effects (aside from an inability to

validate)• Supported by JAWS 7.1+, Window-Eyes 5.5+, NVDA,

Zoomtext 9+

35

Facilitator: Estelle CouncilPanelists:

Anthony DebonisDebi OrtonSteve HaynesMartin Navojosky

Panel Discussion