Get Your Gandalf On For #a11y Testing - Live at #CAST2015

We spent the first part of the session framing the problem and encouraging the attendees to discuss the issues, now we are unleashing the hounds and letting them hear what a site sounds like as seen by a screen reader. To be brave, we submitted the AST web site to the #a11y treatment. Needless to say, we have some work to do to behave better with screen readers, but it made for a great way to discuss the challenges.

We have two angles we use to approach the acccessibility question. The first is to frame questions we can ask and principles we can discuss at the initial design phase. The ten principles I like to use come from Jeremy Sydik's book “Design Accessible Web Sites: Thirty-six Keys to Creating Content for All Audiences and Platforms (Pragmatic Publishing, 2007)":

1. Avoid making assumptions about the the physical, mental, and sensory abilities of your users whenever possible.
2. Your users’ technologies are capable of sending and receiving text. That’s about all you’ll ever be able to assume.
3. Users’ time and technology belong to them, not to us. You should never take control of either without a really good reason.
4. Provide good text alternatives for any non-text content.
5. Use widely available technologies to reach your audience.
6. Use clear language to communicate your message.
7. Make your sites usable, searchable, and navigable.
8. Design your content for semantic meaning and maintain separation between content and presentation.
9. Progressively enhance your basic content by adding extra features. Allow it to degrade gracefully for users who can’t or don’t wish to use them.
10. As you encounter new web technologies, apply these same principles when making them accessible.

From there, when we consider the design issues we want to discuss, if we want to be ready to discuss the requirements and do early testing on initial designs, we can use a heuristic called HUMBLE:

Humanize: be empathetic, understand the emotional components.  

Unlearn: step away from your default [device-specific] habits. Be able to switch into different habit modes.

Model: use personas that help you see, hear and feel the issues. Consider behaviors, pace, mental state and system state.

Build: knowledge, testing heuristics, core testing skills, testing infrastructure, credibility.

Learn: what are the barriers? How do users Perceive, Understand and Operate?

Experiment: put yourself into literal situations. Collaborate with designers and programmers, provide feedback

Both the design principles and the HUMBLE heuristic are useful early in the process of discussing Inclusive Design and overall Accessibility coding. What can we do when we are testing an existing feature, and we are evaluating it for Accessibility? We are working on a feature that is Dev Complete and has been delivered for testing. Do we have some suggestions for that situation? As a matter of fact, yes :).

Albert encourages testers to embrace "PaSaRaN". the word "pasaran" in Spanish means "They Shall Pass". If you say "no pasaran" you are effectively saying "you shall not pass"... and now my cheesy title should make a little sense ;).

PaSaRaN is a method of testing if a Page allows for Accessible Scanning, Accessible Reading
and Accessible Navigation.

It's entirely possible that you can go through your testing career and never get involved in an Accessibility project, but it's a very good bet that issues surrounding Accessibility will affect you at some point in your life, whether it be in a secondary or primary aspect. If you would like to evaluate products for Accessibility, PaSaRaN is a clever short-hand. If you find yourself getting into site design or web development, I'd like to encourage you to consider the ten principles and be HUMBLE in your designing and coding. Also, if you would like to talk about any of the stuff that we covered directly in the workshop, please feel free to contact either Albert or me and we'll be happy to answer any questions.