Accessibility testing-Gyani and Siddhanth
- 1. Web Accessibility Testing By Siddhant Chothe
- 2. I thought I’m here for
- 3. Then closer look at spelling indicated
- 4. Contents • Assistive Technologies • Demonstration of screen reader on the web • Guidelines and Laws • Accessibility Testing (automated and manual)
- 6. Assistive Technology Screen Reader Magnifier Braille Viewer Which means USERS of
- 7. Screen reader is a software that reads the screen and provides audio output enabling blind individuals access information available via electronic devices. SCREEN READERS
- 8. User using screen reader
- 9. SCREEN READER EXAMPLES Computer Screen Readers: Windows OS Linux OS Mac OS •JAWS For Windows •NVDA •Windows-Eyes ORCA Voice Over
- 10. SCREEN READER EXAMPLES Mobile Screen Readers: Symbian Android I Phone •Nuance Talks •Code Factory Mobile Speak •Code factory Mobile Accessibility •Talk Back Voice Over
- 11. MAGNIFIERS Magnifies the keyboard-highlighted and Mouse-focused objects enabling low-vision users operate computers.
- 12. BRAILLE DISPLAYS Provides braille output on a rubber screen.
- 13. Demonstration of screen reader with web pages
- 14. Couple of volunteers please?
- 15. Image example • Turn your screen off. • Press Control+Home to go to top of page • Listen using down arrow keys • Tell us what you hear.
- 16. Table example • Use tab to read form fields in the table. • Only header row identifies form fields in case of inaccessible example • Both header row and header column identifies form fields.
- 17. Accessibility Guidelines and Laws
- 18. The Idea being to create a POUR Website WAI provides 12 Guidelines under WCAG 2.0 organized under 4 P-O-U-R principles PERCEIVABLE Content presented in ways perceivable by all 5 senses of human beings OPERABLE A website must be device independent to be operable UNDERSTANDABLE Content presented and website behavior must be predictable And understandable. ROBUST Maximize compatibility with current and future user tools.
- 19. WCAG 2.0 talks about • Text alternatives for non-text content • Proper use of headings • Accessible Elements-Forms, Tables, sliders, etc • Device independent • Use of lang attribute • List just can go on
- 20. Other Accessibility Guidelines & Laws • WAI-ARIA (Accessible Rich Internet Applications) • USA Section 508 • UK-DDA (Disability discrimination Act) • GIGW (Guidelines for Indian Government Websites)
- 22. Automated Testing Tools • WAVE Accessibility Tool • Web Accessibility Toolbar for Firefox
- 23. How to choose a testing tool? • Tool itself needs to be accessible. • Tool must check for browser DOM. • Range of guidelines / laws it covers. • Guidance offered for further manual testing.
- 24. Manual Testing • Automated testing tools test less than 50% of WCAG 2.0 success criteria. • Whatever can be checked can be checked partially. • Manual testing allows to test all the 61 WCAG 2.0 success criteria. • Manual testers have knowledge of guidelines and laws. • Manual testing is thorough.
- 25. THANK YOU !!!
Editor's Notes
- #7: 6
- #8: 7
- #10: 9
- #11: 10
- #12: 11
- #13: 12
- #19: The Web Content Accessibility Guidelines (WCAG) are the most widely-accepted set of recommendations, and were developed over several years of collaborative involvement by a panel of experts and interested individuals. The rigorous process is purposefully slow and methodical, in an attempt to consider a wide variety of viewpoints and issues. Still, none of the participants in this process would ever claim that the guidelines are the last word on accessibility, or that conformance to the guidelines will guarantee web content accessibility. The guidelines are an excellent foundation upon which to build accessible Web content, but unless the developers understand the reasons behind the guidelines, they might apply the guidelines incorrectly or ineffectively. For example, one of the best-known guidelines is to provide alternative text for images in the alt attribute of the < > tag. If web developers learn only the guideline, but not the reason for the guideline, they may provide alternative text that is not helpful to users who need it. They may even create rather than solve accessibility barriers. (See effective alt text for more information.) When developers focus on technical specifications, they may achieve technical accessibility, but they may not achieve usable accessibility. To make a comparison, a large office building may be technically accessible to a person who is blind—meaning that this person may be able to walk through all the hallways, use the elevators, open the doors, etc.—but without an explanation (or perhaps a tactile map) of how the building is arranged, where the elevators and doors are, and which offices are on which floors, the building will be quite difficult to navigate, especially at first. The person may try to find locations through a process of trial and error, but this is a very slow and cumbersome process. The building is accessible, but not very usable. In a similar way, web developers can create web sites that are possible for people with disabilities to access, but only with great difficulty. The technical standards are important, but they may be insufficient on their own. Developers need to learn when and how to go beyond the technical standards when necessary.
- #26: 25
- #27: 26