Web Application Accessibility Unleashed!

1. Web Application AccessibilityUnleashed! Peter Mosinskis Supervisor of Web Services, CSU Channel Islands Presentation: http://tinyurl.com/d467kt

2. Yes/No Multiple Choice Polling

3. Poll #1 • Do you test accessibility of web sites at your campus? • Yes • No

4. Poll #2 • Do you test accessibility of web applications at your campus? • Yes • No

5. Multiple Choice Poll #3 • What is your primary role at your campus? • A. Designer • B. Programmer/Developer • C. Accessibility Specialist • D. Instructional Technology Specialist • E. Other

6. Goal How to use existing resources to unleash improvements in web application accessibility

7. Agenda • Background • Process – Accessibility Testing Framework • Risks and Strategies • Q&A

8. Why & How? • CSU ATI requirements for web + purchasing • People, Skills, and Tools • Increase in web-based workflows

9. Principles • Easy = fast = simple • Something > Nothing • Accessibility NOT usability • Practice what you preach

10. Where? • In-house applications • Purchased applications • Open-source applications

11. Getting Ready • Tools • People • Skills • Application • Criteria

12. Cocktail of Tools • Tools: http://tinyurl.com/d467kt • Software • Text editor & spreadsheet editor • HiSoftware AccVerify (Windows) • Mozilla Firefox • Chris Pederick’s Web Accessibility Toolbar • UIUC Firefox Accessibility Extension • TPG Colour Contrast Analyzer (Windows/Mac) • Freedom Scientific JAWS (Windows) • Hardware: Desktop PC with Windows

13. Roles and Responsibilities • Key Application Stakeholder(s) • Tester(s) • Testing Manager • Web Developer(s)

14. Tech Skills Are Ready? • Excellent communication (verbal + written) • General computer & MS Office literacy • Basic business process analysis • Extra for testers, test managers, developers: • Semantic HTML/XHTML • Section 508 • CSU ATI requirements

15. Application is Ready? • Installed • Configured • Working

16. Test Criteria & Priority is Selected? • ATI Manual Evaluation • Contains 21 “must repair” checkpoints • Contains 33 “best practice” checkpoints • General priority strategy • How difficult? • How exposed? (all students vs. a few employees) • Who will repair? (in-house vs. vendor) • What about re-checks?

17. The Process Starts with the stakeholder

18. Step 1. User Stories • Stakeholder determines roles to be tested • Student, Administrator, General Public, etc. • Imagine/write a story for each role • “Jane is a student who will register for an event. She goes to the registration page, and enters her information. She submits the information, and receives a confirmation web page.”

19. Step 2. Test Tasks • Stakeholder breaks stories into sets of tasks • Test = set of tasks • Example • Go to https://webapps.csuci.edu/biologyEvent • Fill out the form • Submit the form • Read the confirmation page

20. Step 2. Test Tasks (cont) • Document application & test information • Application & Version • Name of test creator • Start URL for task • Notes about each test

21. Step 2. Test Tasks

22. Stakeholder To-Do • Write stories for each role • Complete Test Task Form • Submit form to Testing Manager

23. Step 3. Automated Test • Tester configures ATI automated check in AccVerify • Tester perform tasks using HiSoftware Interaction Builder • Use “Interaction Script” • Create one interaction script for each test • Each test results packaged as ZIP

24. Step 3. Automated Test (cont.) • Tester saves interaction (.HIBIS format) & automated report • Tester creates Manual Testing Summary • Add list unique URLs from .HIBIS files • Test Manager reviews automated report

25. Choose Your Own Adventure • If you’re out of time, go toStep 6 • If you won’t settle for less,continue to Step 4

26. Step 4. Manual Test • Testers complete ATI Manual Evaluations • Each unique URL gets an evaluation form • Perform “must repair” checks • Perform “best practice” checks (optional) • Manual Evaluation Summary Grid

27. Step 4. Manual Test (cont.) • Screen Reader Test using JAWS • Read page • Read headings • Tab through web page • Enter forms mode • Tab through form elements

28. Step 5. Summaries • Manual Evaluation Summary Grid review • Test Manager create Executive Summary

29. Step 6. Package and Distribute • Create electronic package (ZIP) • Executive Summary • Manual Evaluation Summary Grid • Test Task Form • HIBIS Files • Automated Test Results • Manual Evaluation Forms

30. Step 6. Package and Distribute (cont.) • Distribute to… • Stakeholder • IT and/or Procurement archives? • Campus ATI committee? • CSU VPATdb? • Vendor? • Source code repository?

31. Step 7. Repair • Review and finalize repair priority (joint effort) • How difficult? • How exposed? • How soon? • Go for low hanging fruit!

32. When It’s Can’t Be Fixed • Equally Effective Access Plan (EEAP) • Developed by stakeholder • Approved by ATI governance • Sample: http://tinyurl.com/d467kt

33. Step 8. Re-check • Determined by campus • All? • Only failed checkpoints?

34. CSUCI Examples • Biology Poe Symposium • Symplicity • OCH101 • Library A La Carte • R25

35. Risks & Strategies

36. Risks • Lack of awareness of process • Lack of time • Testing problems • Sessions & URLs with unique IDs • Tasks which add/change/delete • Pages with scripts

37. Make Your Life Easier • Create a SLA & testing plan • For new development • Use application frameworks (Dojo, Fluid) • Build your own (basic) framework • Train and gradually build awareness • Hire & train students

38. Prioritization & Repair • Web apps you already use… • Count ‘em! • Rank importance & exposure • Will you fix them? • Document your repairs • Choose low hanging fruit

39. Q&A Peter Mosinskis peter.mosinskis@csuci.edu 805-437-8587 http://staff.csuci.edu/peter.mosinskis/ Presentation: http://tinyurl.com/d467kt