Web Application Accessibility
Unleashed!
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.
2.
3.
4.
Go to https://webapps.csuci.edu/biologyEvent
Fill out the form
Submit the form
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: 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 Mosinskis
peter.mosinskis@csuci.edu
805-437-8587
http://staff.csuci.edu/peter.mosinskis/
Presentation: http://tinyurl.com/d467kt