web accessibility: pitfalls, gotchas and solutions mark hale (moderator), university of iowa matt...
TRANSCRIPT
Web Accessibility: Pitfalls, Gotchas and Solutions
Mark Hale (moderator), University of Iowa
Matt Barkau, Penn StateJon Gunderson, Illinois
Hadi Rangin, IllinoisJuliet Hardesty, IndianaKaren Kuffner, MichiganScott Williams, 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) http://fae.cita.illinois.edu
Illinois Data (2010) http://webaccessibility.cita.illinois.edu/illinois/
National Data (2010) http://webaccessibility.cita.illinois.edu/data/
State of Web Accessibility at Illinois (2010)
Titling
Sub Head
ings
Naviga
tion
Form
Controls
Data Tab
les
Imag
es
Layo
ut Tab
les0
102030405060708090
100
NationalIllinois
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 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
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 KuffnerAssistant 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 HardestyUser 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 Validators
Firefox Extensions Fangs HeadingsMap WAVE Toolbar AEFF (from Illinois)
Color Contrast Analyzers (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 RanginInformation Technology Accessibility & Collaboration Coordinator
Disability Resources and Education Services
University of Illinois
217 244-0518
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?
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
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
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
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?