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

2. Polling Yes/No Multiple Choice

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. Poll #3 What is your primary role at your campus? –A. Designer –B. Programmer/Developer –C. Accessibility Specialist –D. Instructional Technology Specialist –E. Other Multiple Choice

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 1.Go to https://webapps.csuci.edu/biologyEventhttps://webapps.csuci.edu/biologyEvent 2.Fill out the form 3.Submit the form 4.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 to Step 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