Web Application Accessibility Unleashed! Peter Mosinskis Supervisor of Web Services, CSU Channel Islands Presentation:

Polling Yes/No Multiple Choice

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

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

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

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

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

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

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

Where? In-house applications Purchased applications Open-source applications

Getting Ready Tools People Skills Application Criteria

Cocktail of Tools Tools: 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

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

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

Application is Ready? Installed Configured Working

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?

The Process Starts with the stakeholder

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.”

Step 2. Test Tasks Stakeholder breaks stories into sets of tasks Test = set of tasks Example 1.Go to 2.Fill out the form 3.Submit the form 4.Read the confirmation page

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

Step 2. Test Tasks

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

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

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

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

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

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

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

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

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

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

When It’s Can’t Be Fixed Equally Effective Access Plan (EEAP) –Developed by stakeholder –Approved by ATI governance Sample:

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

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

Risks & Strategies

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

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

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

Q&A Peter Mosinskis Presentation: