Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Technology Evaluation and Meeting the Needs of People with Disabilities

3,342 views

Published on

June 17, 2015
NISO Virtual Conference: The Eternal To-Do List: Making Ebooks work in Libraries
Technology Evaluation and Meeting the Needs of People with Disabilities
Sue Cullen, M.S., Assistant Director, Accessible Technology Initiative, CSU Office of the Chancellor
Dawn Futrell, MA, Accessible Technology Specialist, CSU Accessible Technology Network (CSU ATN), Accessible Technology Initiative (ATI), California State University Chancellor’s Office

Published in: Education
  • Be the first to comment

  • Be the first to like this

Technology Evaluation and Meeting the Needs of People with Disabilities

  1. 1. Technology Evaluation Meeting the Needs of People with Disabilities Dawn Futrell, MA, Accessible Technology Specialist, Accessible Technology Initiative CSU Chancellor’s Office Sue Cullen, M.S., Assistant Director, Accessible Technology Initiative, CSU Office of the Chancellor
  2. 2. CSU Accessible Technology Initiative 2 • California State University (CSU) • Largest public baccalaureate degree-granting institution in the United States • 23 campuses; almost 450,000 students • About 13,500 students with disabilities registered with our campus disability services offices • Established Accessible Technology Initiative (ATI) in 2006
  3. 3. Overview • CSU System wide Library Platform Accessibility Evaluation • Software/Website common accessibility barriers • Simple accessibility evaluation checks • Procurement evaluation • Levels of evaluation • Read and Respond VPAT - Level I • Equally Effective Alternative Access Plan • Accessibility Roadmap
  4. 4. • Vendors • Ambrose • AMS • APA • ARTstor • CountryWatch • EBSCO • Elsevier • Encyclopedia Britannica • Infobase Learning CSU Systemwide Library Platform Accessibility Evaluation • Lyasis • Mergent • NBC • OCLC • ProQuest • Sage • Thomson Reuters
  5. 5. CSU System wide Library Platform Accessibility Evaluation Expected Outcomes • Fostering awareness and collaboration regarding accessibility awareness with the Vendors • Promoting product improvements and creation of Accessibility Roadmaps • Provide system wide training • Share findings system wide Completed by the members of the Accessible Technology Network
  6. 6. Common Barriers • Missing Alternative text description for meaningful images • Inaccurate or lack of captioning • Link text that is not meaningful (informs the user of what it is or where the link will lead) • Missing or inappropriately coded form fields • Lack of structure for document or web page Titles, Headers, Lists • Lack of color contrast
  7. 7. 3 Things to consider while choosing technologies Can individuals: 1. Access all necessary website or software application functionality via the keyboard only, such as accessing menu options and navigating between different screens? 2. Read the text easily? If not, try using different color combinations with a strong contrast to make the materials more perceivable by everyone. 3. Enlarge the screen without distorting the text? (e.g. “Ctrl +” keystroke)
  8. 8. Procuring Accessible Products
  9. 9. Evaluation Protocols for Compliance & Usability Testing Level I (Read and Respond) • Review VPAT information for confusing unclear remarks and explanation which may result in significant barriers. • Consider Campus or System Wide Impact of the product. • If significant issues found, consider conduct manual testing at Level II or III to validate claims or inconsistencies. • Always share VPAT with updated comments with vendor Level II (Spot Checking) • Limited criteria validation based on application type • Examples: • Web form applications (form fields labels, input mask, error handling) • Basic web page (link & semantic requirements, tab order and images) • Concurrently: Run Compliance Sheriff (C.S.) Use as a guide for manual checking. • Recommendations and resources provided within the resulting reports. Level III (Full Check) • Criteria validation - CSU ATI Requirements. • Comprehensive testing (Applications may have coding that requires additional research and reiterative testing of coding solutions validation.) • Detailed recommendations and resources provided in report. • Concurrently: Run C.S. level IV scan with manual testing. • As needed provide actual coding or work around for end users.
  10. 10. Level I – Read and Respond Common VPAT Discrepancies • Do any criteria that do apply to the product have status levels and/or comments that claim they don’t apply? – Example: Status level is ‘Not Applicable’ and comments state “CSS cannot be changed due to product branding” [1194.22(d)] – Example: A VPAT for a modern website with rich functionality claims “No scripting languages are used”[1194.22(l)]
  11. 11. Equally Effective Alternative Access Planning (EEAAP) 1. Description of the issue: What part of the system, software, or process has known accessibility barriers Further information on Section 508 and ATI standards can be found at CSU Accessible Electronic and Information Technology (EIT) Procurement
  12. 12. EEAAPS 1. Persons or groups affected: List the person(s) or groups who may/will be affected. Groups may be specific (e.g., IT employees, Engineering students, etc. or general (e.g., public, visitors, students only, CSU employees, etc.). 2. Responsible person(s): List the name(s) and titles of the campus employee(s) who will be responsible for providing equally effective alternate access.
  13. 13. Equally Effective Alternative Access Planning (EEAAP) 3. How will EEAA be provided: Describe in detail how the responsible department(s)/person(s) will provide equally effective alternate. For example, providing a real time captioning.
  14. 14. EEAAPS 4. EEAA Resources Required: List any resources required, including training, equipment, additional staff, etc. 5. Vendor timeline for remediation: A timeline to plan create, implement, and follow up on plans for the remediation of the product.
  15. 15. What can Librarians do? • Build vendor accessibility awareness • Drive accessibility improvements to library e- resources through market demand • VPAT Reviews – Steps 1- 4
  16. 16. Step 1: Gather Information • Request a VPAT • Search vendor website for an accessibility statement. • Ask questions about how accessibility is integrated in to the product development process. • Have developers received training in accessibility? • Is accessibility testing part of the QA process?
  17. 17. Step 2: Review Information • Review VPAT for contact info • Is the product information, vendor name present? • Is contact info (name, email, phone) provided for the person/group that completed the VPAT? • Are all applicable sections completed? • For most modern web applications sections 1194.21, 1194.22, 1194.31, and 1194.41 • Ask questions about how the information on the VPAT was gathered • Was in-house product testing done? • Was a third party accessibility evaluation company engaged?
  18. 18. Step 3: Review Product • Ask the vendor to demonstrate the accessibility features. • Request an Accessibility Roadmap that lists any accessibility barriers in the product and a timeline for remediation. • The Roadmap should include any VPAT entries where the Supporting Features are described as “not supported” or “supports with exceptions”
  19. 19. Step 3 (cont.): Review Product • Example: VPAT Criterion(section 1194.22) • Example: Corresponding Roadmap entry Criteria Supporting Features Remarks and explanations (a) A text equivalent for every non-text element shall be provided (e.g., via "alt", "longdesc", or in element content). Supports with exceptions Most images contain alternative text that clearly describes the purpose of image. Issue Description Current Status (Open, Closed, I/P) Disposition (Planned, Deferred, I/P) Remediation Timeline Available Workaroun ds Comments EXAMPLE: Images on the landing page lack equivalent alternate text. Open Planned Q3, 2014 release (v1.2) Functional images will receive descriptive alternate text; decorative images will
  20. 20. Step 4: Place Order • Include accessibility language in library e-resource contracts. Examples include: • ARL Model US Licenses • Contract Language included in CSU General Provisions • Reminder: Be prepared to provide accommodations if the platform has significant accessibility barriers • Equally Effective Alternate Access Plan (EEAAP)
  21. 21. CSU Contract Language – General Provisions Americans With Disabilities Act (ADA) Contractor warrants that it complies with California and federal disabilities laws and regulations. (Americans with Disabilities Act of 1990,42 U.S.C. 12101 et seq). Contractor hereby warrants the products or services it will provide under this Contract comply with the accessibility requirements of Section 508 of the Rehabilitation Act of 1973, as amended (29 U.S.C. 794d), and its implementing regulations set forth at Title 36, Code of Federal Regulations, Part 1194. Contractor agrees to promptly respond to and resolve any complaint regarding accessibility of its products or services. Contractor further agrees to indemnify and hold harmless CSU from any claims arising out of Contractor’s failure to comply with the aforesaid requirements. Failure to comply with these requirements shall constitute a material breach of this Contract.
  22. 22. What we can do together • The CSU has learned many valuable lessons while implementing accessible information and technology across our system. • We are happy to share what we have learned • We welcome opportunities to collaborate with others • We hope that vendors of educational technology are receiving a clear and consistent message about accessibility from all postsecondary institutions • We welcome your inquiries ati@calstate.edu

×