1 / 39

Enhancing Web Application Accessibility at CSU Channel Islands: Strategies and Tools

This presentation by Peter Mosinski covers essential strategies for improving web application accessibility at CSU Channel Islands. It involves assessing existing resources, implementing accessibility testing frameworks, and understanding CSU ATI requirements. Key topics include conducting successful accessibility tests, identifying roles in accessibility processes, and utilizing various tools, including HiSoftware AccVerify and JAWS. The goal is to effectively engage stakeholders in enhancing web accessibility practices, ensuring compliance, and fostering an inclusive digital environment for all users.

ayanna
Télécharger la présentation

Enhancing Web Application Accessibility at CSU Channel Islands: Strategies and Tools

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related