web accessibility pitfalls gotchas and solutions n.
Skip this Video
Loading SlideShow in 5 Seconds..
Web Accessibility: Pitfalls, Gotchas and Solutions PowerPoint Presentation
Download Presentation
Web Accessibility: Pitfalls, Gotchas and Solutions

Loading in 2 Seconds...

play fullscreen
1 / 36

Web Accessibility: Pitfalls, Gotchas and Solutions - PowerPoint PPT Presentation

  • Uploaded on

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 Scott Williams, Michigan
. Jon Gunderson, Ph.D.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Web Accessibility: Pitfalls, Gotchas and Solutions' - andren

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
web accessibility pitfalls gotchas and solutions

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

jon gunderson ph d
Jon Gunderson, Ph.D.

Coordinator of Information Technology Accessibility

Disability Resources and Education Services

University of Illinois


web accessibility related laws
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
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
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/
scott williams
Scott Williams

Web Accessibility Coordinator

University of Michigan


web accessibility coordinator
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
  • 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
  • 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
  • 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
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


Karen Kuffner
foundational work
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
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
  • 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
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
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


Julie Hardesty
web accessibility as developer
Web Accessibility as Developer
  • Accessibility is usability
  • Consider from start of project
  • Test what you make, evaluate what you use
testing to guarantee accessibility
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
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
Hadi Rangin

Information Technology Accessibility & Collaboration Coordinator

Disability Resources and Education Services

University of Illinois


217 244-0518

vendors and accessibility
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
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
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
Power of Collaboration
  • Accessible design vs. accessibility repair
  • Accessible product globally
collaboration examples
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?
its tlt weblion group penn state university rmb46@psu edu
ITS, TLT, WebLion Group

Penn State University


Matt Barkau
set policies
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
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
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
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
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
work in community cic
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