1. Collaborating with Vendors Toward Improved Accessibility
Terrill Thompson, University of Washington Jon Gunderson, University of Illinois at Urbana-Champaign Ken Petri, The Ohio State University

2. Why Accessibility?
10% of students in higher education self-identify as having some form of disability (sources: nlts2.org,nces.ed.gov)
Individuals with disabilities (and others) can be affected by inaccessible design
Unable to see
Unable to hear
Unable to use a mouse
Unable to perceive color
Easily distracted

3. Our Legal and Ethical Requirements
To provide an accessible education to qualified students
Section 504 of the Rehabilitation Act (1973)
Americans with Disabilities Act (1990)
State laws and campus policies

4. IT Vendors & Accessibility
Section 508 of the Rehabilitation Act (1998)
Section 508 Standards (published in 2000)
Software applications and operating systems.
Web-based intranet and internet information/applications
Telecommunications products
Video and multimedia products 
Self contained, closed products
Desktop and portable computers
Voluntary Product Accessibility Template (VPAT)

5. Example VPAT #1: Uninformative

6. Example VPAT #2: Inaccurate

7. Example VPAT #3: Not Bad

8. Issues with Accessible Design
Design Patterns: Accessible coding standards
Quality Assurance: Do they include accessibility in internal software development testing?
Quality Assurance: Test with people with disabilities
User Interface Design and Testing: Include users with disabilities in usability testing

9. Issues with Accessible Design (continued)
Documentation: Are accessibility features documented?
Support: Is support system capable of responding to accessibility-related questions or bugs?

10. Examples of Existing Collaborations
Blackboard
Desire2Learn
EBSCO, other Library Bibliographic Databases

11. Questions to Ask Companies
What are the accessible coding practices used for development?
Do you include accessibility testing in internal quality assurance testing?
Do you include people with disabilities when testing the product?
What product features do you test for accessibility?
How do your product accessibility features compare to other products?

12. What Changes Companies
Purchasing policies: Approved Vendor Lists
Example: California State University system
Education: Helping companies understand accessibility
Accessible repair vs. accessible design
Coding practices for accessibility
Support services for accessibility issues
Documentation including accessibility information
Testing: Helping to test product features
Current product accessibility features
Next generation technologies

13. Working with Open Source Projects
Filing bugs in bug tracking systems related to accessibility
Join the Development Process
Allocate resources to modify code to improve accessibility
Develop design documents to help module developers use accessible coding practices
Develop accessibility QA procedures for accessibility
Recruit people with disabilities for testing
Example: Sakai--a "Community" Open Source project

14. Higher Education Making a Difference
Accessibility similar to Security
Both need to be managed and defined
Dedicate staff with both technical and accessibility knowledge to work with companies and verify accessibility
Institutional commitment to accessibility
Purchasing policies for accessibility
Verification of accessibility policy conformance
Internal vs External

15. Tools and Resources
iCITA Web Accessibility Best Practices
Firefox Accessibility Extension
Illinois Functional Accessibility Evaluator
UW Accessible IT: Tools and Resources
WebAIM WAVE online and WAVE Toolbar

16. How to Get Involved
IT Accessibility Constituent Group Meeting Thursday, 11/5, 4:55 - 6:10pm Meeting Room 608
EDUCAUSE Wiki: Collaborations on Accessibility:
Assistive Technology in Higher Education (ATHEN)
Accessing Higher Ground CU-Boulder’s annual conference in November
CSUN Conference in San Diego, March 2010

17. What did you think about this session?
Your input is important to us!
Click on “Evaluate This Session” on the conference program page.