Demystifying Accessibility Testing
•Download as PPTX, PDF•
2 likes•1,254 views
Everyone wants their election systems be usable and accessible. This is especially true for systems like online voter registration, polling place lookup apps, ballot delivery systems, and poll books — all the systems not covered by the VVSG. This presentation will discuss how to conduct accessibility testing in stages, starting with a simple inspection and ending with usability testing by voters with disabilities. Presented at the 2015 Conference on State Certification of Voting Systems
More Related Content
Viewers also liked
Similar to Demystifying Accessibility Testing
Similar to Demystifying Accessibility Testing (20)
More from Center for Civic Design
More from Center for Civic Design (20)
Recently uploaded
Recently uploaded (20)
Demystifying Accessibility Testing
- 1. Demystifying Accessibility Testing Whitney Quesenbery Center for Civic Design @civicdesign | @whitneyq State Certification Conference May 19-20, 2015, Seattle
- 2. Why accessibility testing seems hard Invisible Hidden Misunderstood
- 3. Usability and accessibility Twins separated at birth
- 4. Elections are more than voting systems Elections information Online voter registration Polling place lookup Sample ballots Ballot tracking And...
- 6. Accessibility testing in layers Principle Testing mode What it tests Perceivable Inspection Basic accessibility errors Robust Code review Use of code standards Semantic structure Operable Check AT Expert review Interaction using keyboard, screen reader, other AT Operable/ Understandable Usability testing Use by real people
- 7. Inspection Check for basic accessibility errors Quick checks that are perceivable without special technology Image "alt" text Text size and contrast Captions and transcripts Meaningful links and buttons Easy access to content (skip links) Keyboard navigation
- 8. Code review Check for accessible coding Look for robust code that meets standards. Forms coding Semantic markup for content structure Reading order with a keyboard Coded to W3C standards Appropriate use of ARIA and HTML5 elements
- 9. Use Check with assistive technology Check that it is operable and understandable with assistive technology. Use the technology with Screen readers: NVDA, VoiceOver or JAWS Magnifiers: Browser magnification and ZoomText Keyboard: Emulators, dual switches, Braille notes
- 10. Expert review Check with expert AT users Expert review by people who use assistive technology to be sure it is operable and understandable. Does it work well with a range of AT? Are there good cues for navigation and orientation through the task? Can they complete all basic tasks, from the start to finish?
- 11. Usability testing Check with voters with disabilities Test again with a diverse set of "regular voters" to be sure it works for non- experts. Can they complete all basic tasks, from the start to finish? Does it work with their own AT, with their usual settings? Are there good cues for navigation and orientation through the task?
- 12. Summing up Test in layers Inspection Code inspection Use with assistive technology Expert review Usability testing Test entire tasks Can they be completed from start to finish Test every template For informational sites, test every feature or template
- 13. Designing accessible election websites and applications 1. Make sure information about accessible voting is easy to find 2. Code forms so they are accessible 3. Allow users to change text size and appearance 4. Structure the content with headings 5. Write specific, meaningful links 6. Make it easy to jump to the main content on the page 7. Provide alternative descriptions for images, audio, and video 8. Keep alternative formats together, so voters can choose 9. Make sure everything works with a keyboard 10. Test the site with voters with disabilities Coming soon
- 14. Get in touch! Whitney Quesenbery whitneyq@civicdesign.org @whitneyq civicdesign.org @civicdesign
Editor's Notes
- People with disabilities are often invisible. Because despite large numbers overall, they are under-represented in our daily work and lives Accessibility is often hidden. That is, the things that make digital products accessible are often below the surface in how they are structured. Or they are things like ramps and curb cuts that have become main stream Misunderstood, because we tend to learn a few rules, but not really take the time to see the big picture. And, it's hard to test things that we don't really understand.
- We think we understand usability because we can think about our own experience. But, we have few instincts for what we are testing, when we test for accessibilty. For example, I still find people who are amazed that someone who is blind can use the web, or that people who are deaf might want to have access to a podcast. So we have to fall back onrequirements to know what makes something accessible. And, because accessibility is a legal requirement, we get standards, checklists and rules.
- Just to be clear, we need to think beyond voting systems and the VVSG, although the core requirements in the VVSG are a good start, just as the requirements in the Web Content Accessibility Guidelines are relevant to voting systems and other applications. So many of the new systems in elections are on on the web, or use web technologies as their base. Everything we know from the 15 year history of WCAG is applicable to all of them, and we can draw on the four base principles of WCAG
- We've been talking a lot about basing election system requirements on principles, so you'll be happy to know that WCAG 2.0 is based on just four. Although not quite in the same order, we can also think about accessibility testing by using these principles.
- The order of these layers is arranged from the simplest tests to conduct to the hardest. After all, if there are simple, basic accessibiity errors, why bother going further. Get them fixed.
- Almost all of the most common – and basic – accessibility problems can be found through inspection. There are a few tools that are useful – accessibility testing tools can help automate the process, for example checking for alt text, and testing the contrast. One of the heuristics is that you can catch a relatively low percentage of a11y problems (about 20-30%) with automated tools. But that just makes it even more ridiculous that they exist at all.
- The next round of testing looks at the robustness of the code. Just as in web development in general, there is a strong movement towards standards-based code in a11y. Instead of catering to AT, we are starting to expect AT to meet code ina robust standard. These tests can also be done without using any special AT, by inspecting the code, or working through the pages with keyboard alone.
- Next, you need to actually check the site with assistive technology. In general, you can look at three basic types of AT. For bonus points, you might look at Braille note readers, because (a) they are common and (b) they are critical to the deaf-blind (and they might be one of the more common types of personal AT we might see at a polling place)