Web Accessibility: Pitfalls, Gotchas and Solutions

1. Web Accessibility: Pitfalls, Gotchas and Solutions Mark Hale (moderator), University of Iowa Matt Barkau, Penn StateJon Gunderson, IllinoisHadi Rangin, IllinoisJuliet Hardesty, Indiana Karen Kuffner, Michigan Scott Williams, Michigan


2. Jon Gunderson, Ph.D. Coordinator of Information Technology Accessibility Disability Resources and Education Services University of Illinois jongund@illinois.edu

3. Web Accessibility Related Laws • Section 504 of the Rehabilitation Act of 1973 • Applies to organizations receiving federal funds • Accessible format in a timely manner • American with Disabilities Act (1990) • Applies to public spaces /buildings and companies over 50 employees • Currently no web accessibility requirements • DOJ considering addition by executive order (for example airlines) • Section 508 (2000) Information Technology Accessibility Standards • Apply only to federal agency websites and services • Does not apply to contractors or people receiving grants • Revisions coming soon

4. Web Accessibility Standards • W3C Web Content Accessibility Guidelines 1.0 (1999) • 14 Guidelines • 65 checkpoints (16 P1, 30 P2, 19 P3) • Section 508 Information Technology Accessibility Standards (2000) • 14 requirements (based on Priority 1 requirements of WCAG 1.0) • W3C Web Content Accessibility Guidelines (2008) • 4 Principles • 12 Guidelines • 61 Success Criteria ( 26 level A, 13 level AA, 22 level AAA) • Section 508 Information Technology Accessibility Standards Revision • Based on WCAG 2.0 A and AA success criteria (could be released at any time) • State Standards • Illinois Information Technology Accessibility Act (2007)

5. Auditing Accessibility • Illinois Functional Accessibility Evaluator 1.1 • Free tool • Next version will be open source • Open source OpenAjax Accessibility Rules and Rulesets (JavaScript based) • http://fae.cita.illinois.edu • Illinois Data (2010) • http://webaccessibility.cita.illinois.edu/illinois/ • National Data (2010) • http://webaccessibility.cita.illinois.edu/data/

6. State of Web Accessibility at Illinois (2010)

7. Scott Williams Web Accessibility Coordinator University of Michigan swims@umich.edu

8. Web Accessibility Coordinator • Report to Associate Vice Provost for Academic and Faculty Affairs, who is also Senior Director, Office of Institutional Equity • Funded by provost, work in HR • Work closely with central IT • Evaluating, training, consulting for 19 academic units and U-M Health System • Background in web production

9. Strategy • W3C Web Content Accessibility Guidelines • (WCAG 2.0 Level A, with elements of AA and AAA) • University Policy • University-wide audit • Central IT core processes with the assistance of ITS staff • Academic units and U-M Health System • Remediation of interfaces and staff training • Forward-looking; integrate with production

10. Education • Gateway web accessibility resource http://umich.edu/webaccess • Streamlined content with references to external sources with greater detail, e.g., WebAIM • Developing training classes for ITS, based on train-the-trainer sessions, to be used across campus • Web Accessibility Working Group • Small interactive training sessions with academic units • Hands-on labs including screen reader training

11. Evaluation • Keyboard • Firefox add-ons • WAVE • Juicy Studio • Accessibility Evaluator for Firefox • FireEyes • Local instance of Achecker.ca • NVDA, VoiceOver, JAWS • Investigating enterprise solutions for auditing, planning, and reporting

12. Future Challenges • Establish relationships with external vendors, e.g., PeopleSoft, CollegeNET, CommonApp, Google, Box, etc. • Rapid change. As technology evolves, accessibility often devolves (e.g., Kindle Fire) • Increasingly complicated web and mobile technology • Adverse economic climate, decreasing U-M budget

13. Assistant Director – Student Administration Lead - Accessible Applications Project Information & Technology Services University of Michigan kkuffner@umich.edu Karen Kuffner

14. Foundational Work • Coordinate central IT and campus-wide efforts • Effort approach options: • High effort / short term • Lower annual effort / ongoing commitment • Accessibility is not well understood – be prepared to start from scratch • Inventory applications & accessibility levels • Identify experts: IT and Adaptive Tech

15. Organizing the Basics • Evaluate/define institutional policy • Establish compliance targets & standards • Investigate vendor’s positions on accessibility • Engage with vendors to improve products • Consider procurement impacts: • RFI/RFQ/RFP templates and contract language • Goal: Enable accessible implementations • Goal: Mitigate existing application faults

16. Tools! • Explore tool options • Application & usability testing tools • U-wide tracking and planning tool • Tool distribution • Installation and access • Training & Assessment: • Defining the audience • Workshop approach? • Feedback mechanisms

17. Sustaining Accessibility • Training with long term goals in mind • Levels of information based on audience • Campus-wide vs. central IT training • Annual mitigation planning • Mitigation targets: • Application-specific gaps & standards • Highest impact processes & pages: • Self service; widely used; required use

18. Notes on University of Michigan Costs • Tools: Options vary from expensive to free • Pilot: 600 hrs, 22 app environments, 28 staff • Training estimates for 3 courses: • 800 hours course development • 500 hours training ~75 staff in targeted course(s) • Assessing balance of staff involvement • Mitigation: Set annual effort targets • Goal: Plan the work & work the plan

19. User Interface Design Specialist Digital Library Program Indiana University jlhardes@indiana.edu Julie Hardesty

20. Web Accessibility as Developer • Accessibility is usability • Consider from start of project • Test what you make, evaluate what you use

21. Testing To Guarantee Accessibility • W3C HTML/CSS Validators • Firefox Extensions • Fangs • HeadingsMap • WAVE Toolbar • AEFF (from Illinois) • Color Contrast Analyzers (JuicyStudio) • Your keyboard (no mouse) • Mobile devices • People

22. What a Developer Needs • Manager support to include accessibility as requirement • New/updated products • New developers • New skills for current developers • Connections with other developers • Connections with users

23. Hadi Rangin Information Technology Accessibility & Collaboration Coordinator Disability Resources and Education Services University of Illinois hadi@illinois.edu 217 244-0518

24. Vendors and Accessibility • Vendors know very little about accessibility • Vendors have no organized means to receive accessibility feedback • Developers are unaware about Universal Design

25. Engaging Vendors in Collaboration • Educate local IT staff & administrators about accessibility • Conduct & compile accessibility/usability evaluation • Share the result with vendors via IT admins • Vendors respond to those who write the "checks"

26. Collaboration:Working with vendors • Educating vendors about accessibility/usability • Goal is to incorporate accessibility in Design Spec • Help them actively during implementation and testing phases

27. Power of Collaboration • Accessible design vs. accessibility repair • Accessible product globally

28. Collaboration Examples • Course management systems • WebCT/Blackboard • Desire2Learn • Online Teaching/Collaboration • Elluminate • Talking Communities • Online Library Services • Ebsco • Elsevier • What’s next • Unified Communications • Google Apps?

29. ITS, TLT, WebLion Group Penn State University rmb46@psu.edu Matt Barkau

30. Set policies • Those who are proactive are at much lower risk • (have made a plan and are working that plan) • Penn State AD25 Policy: • marketing audio or video must be transcribed or captioned • Penn State AD69 Policy: • websites must meet WCAG 2.0 AA guidelines • Budget executives identify web liaisons • with primary responsibility for ensuring adherence to web accessibility policy

31. Sell the benefits • Risk reduction & compliance • Support of University goals • social responsibility • diversity • global / online • multisensory learning • Retention & comprehension for all students • Findability for all people • Findability for machines (including Google bot) • Mobile usability

32. Focus on people’s experience • Common blockers: • text descriptions of things which are graphical or visual • keyboard operability • Triage Process: • Analyze each unit’s top 10 visited pages over last year from Google Analytics summary. • Identify errors on those pages related to: images, content headings, navigation & page section headings, data tables, links, & form fields. • Investigate those errors with a screen reader emulator, a screen reader, & Firebug (reporting both code issue & fix). • Check for meaningful wording of titles, headings, & links. • Check for text equivalents to media including audio, video, animations.

33. Test systems *and* content • Only ~one-third of accessibility features can be tested automatically • FAE evaluator • Fangs screen reader emulator • Content & navigation needs meaningful wording • Learn screen readers • Real people test with assistive technologies • technical accessibility vs. usability for a person

34. Build your University’s skills • Managers: • Make accessible IT a priority and hold staff accountable • Content authors & editors: • Need time to format content & craft navigation wording • System builders: • Need time to architect layers to separate concerns • Need time to test with real users • System buyers: • Need to ask open-ended questions like, “What's your process for development & testing?” • Need time to test vendors’ claims • Need to educate vendors on accessibility needs of faculty & students • Policy makers: • Need consistentauditing & reporting for accountability

35. Work in community (CIC) • Many hands make light work • Possible areas of collaboration include: • benchmarking • help educate vendors of inaccessible software • help educate publishers of inaccessible purchased media • develop & refine training & reference materials • build on open source testing tools • share purchased system test results • assistive technology R & D • strategies for captioning • strategies for procurement • volume purchases of accessible software / services • To get involved in the CIC IT Accessibility Community of Practice • contact anyone on this panel

36. Questions or Comments?