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.
Coordinator of Information Technology Accessibility
Disability Resources and Education Services
University of Illinois
jongund@illinois.edu
Web Accessibility Related Laws

Section 504 of the Rehabilitation Act of 1973



American with Disabilities Act (1990)




Applies to organizations receiving federal funds
Accessible format in a timely manner
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)



Section 508 Information Technology Accessibility Standards (2000)




4 Principles
12 Guidelines
61 Success Criteria ( 26 level A, 13 level AA, 22 level AAA)
Section 508 Information Technology Accessibility Standards Revision


14 requirements (based on Priority 1 requirements of WCAG 1.0)
W3C Web Content Accessibility Guidelines (2008)


14 Guidelines
65 checkpoints (16 P1, 30 P2, 19 P3)
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/
100
90
80
70
60
50
40
30
20
10
0
State of Web Accessibility at Illinois (2010)
National
Illinois
Scott Williams
Web Accessibility Coordinator
University of Michigan
swims@umich.edu
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 Kuffner
Assistant Director – Student Administration
Lead - Accessible Applications Project
Information & Technology Services
University of Michigan
kkuffner@umich.edu
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
jlhardes@indiana.edu
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 Rangin
Information Technology Accessibility & Collaboration Coordinator
Disability Resources and Education Services
University of Illinois
hadi@illinois.edu
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



Online Teaching/Collaboration



Elluminate
Talking Communities
Online Library Services



WebCT/Blackboard
Desire2Learn
Ebsco
Elsevier
What’s next


Unified Communications
Google Apps?
Matt Barkau
ITS, TLT, WebLion Group
Penn State University
rmb46@psu.edu
Set policies

Those who are proactive are at much lower risk


Penn State AD25 Policy:


marketing audio or video must be transcribed or captioned
Penn State AD69 Policy:


(have made a plan and are working that plan)
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:


Content authors & editors:



Need time to architect layers to separate concerns
Need time to test with real users
System buyers:




Need time to format content & craft navigation wording
System builders:


Make accessible IT a priority and hold staff accountable
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?