Web Application AccessibilityUnleashed!

Peter Mosinskis

Supervisor of Web Services, CSU Channel Islands

Presentation: http://tinyurl.com/d467kt

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: 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

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 https://webapps.csuci.edu/biologyEvent

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 toStep 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: http://tinyurl.com/d467kt

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 Mosinskispeter.mosinskis@csuci.edu

805-437-8587http://staff.csuci.edu/peter.mosinskis/

Presentation: http://tinyurl.com/d467kt