1 / 36

NYS Forum IT Accessibility

NYS Forum IT Accessibility. Refresher 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.

lowri
Download Presentation

NYS Forum IT Accessibility

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. NYS Forum IT Accessibility Refresher 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

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

  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. 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 4

  5. 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

  6. 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

  7. 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)

  8. Tools Cont… • BrowserLab • https://browserlab.adobe.com/en-us/index.html • Site Catalyst - NetAverages • https://netaverages.adobe.com/en-us/index.html

  9. 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.

  10. 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/

  11. 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

  12. 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+

  13. 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

  14. Mobile Applications • BlackBerry - supports • Hearing • Vision • Mobility • Cognitive • Speech • iPhone • VoiceOver built into each iPhone • Hearing – closed captioning

  15. 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)

  16. 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

  17. Questions • 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

  18. Up Next • Screen Reader Review • How is Jaws dealing with HTML5 • Martin Navojosky

  19. jQuery Interfaces and Accessibility • Web 2.0 Form Interfaces • jQuery Tabs • jQuery Accordions • Accessibility issues • Stephen Haynes • Debi Orton

  20. 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

  21. 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

  22. 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

  23. 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

  24. 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

  25. 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

  26. 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

  27. 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

  28. 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

  29. 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

  30. 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

  31. 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

  32. WAI-ARIA • Document Landmark Roles • Roles to help define the structure of the document (e.g., article banner, complementary, contentinfo, main, navigation, search, etc.

  33. 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

  34. 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

  35. 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+

  36. Panel Discussion Facilitator: Estelle Council Panelists: Anthony Debonis Debi Orton Steve Haynes Martin Navojosky

More Related