Web Accessibility: Pitfalls, Gotchas and Solutions Mark Hale (moderator), University of Iowa Matt Barkau, Penn State Jon Gunderson, Illinois Hadi Rangin, Illinois Juliet Hardesty, Indiana Karen Kuffner, Michigan

Jon Gunderson, Ph.D. Coordinator of Information Technology Accessibility Disability Resources and Education Services University of Illinois

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

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)

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) Illinois Data (2010) National Data (2010)

State of Web Accessibility at Illinois (2010)

Scott Williams Web Accessibility Coordinator University of Michigan

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

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

Education Gateway web accessibility resource 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

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

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

Karen Kuffner Assistant Director – Student Administration Lead - Accessible Applications Project Information & Technology Services University of Michigan

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

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

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

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

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

Julie Hardesty User Interface Design Specialist Digital Library Program Indiana University

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

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

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

Hadi Rangin Information Technology Accessibility & Collaboration Coordinator Disability Resources and Education Services University of Illinois

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

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"

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

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

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?

Matt Barkau ITS, TLT, WebLion Group Penn State University

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

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

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.

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

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 consistent auditing & reporting for accountability

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

Questions or Comments?