By starting early and considering Accessibility as a core initiative of software development, organizations can develop software that is easier to use and makes information available to more people.

1. AGILE TESTING DAYS 2015 –
Potsdam, Germany
MAKING A WEB FOR EVERYONE
Designing and Testing for Accessibility
Michael Larsen
mkltesthead@gmail.com
Twitter: @mkltesthead

2. Special Thanks to Albert Gareev for
collaborating on this talk.
https://twitter.com/agareev
http://automation-
beyond.com/about/

3. What Does Accessibility mean to you?
Designed to allow as many people as possible to access information.
Open to allow people with disabilities a similar experience as their normative counterparts

5. Why Focus on Accessibility?
 It's the right thing to do
 It’s the law in many places
 Accessible sites are more usable for everyone
 It’s good business

6. Disabilities
 Visual
 Auditory
 Mobility
 Cognitive
 Any or all of the above.
Images from "A Web for Everyone",
S. Horton and W. Quesenbery,
Rosenfeld Media, 2013

7. Normative Disabilities
Hearing – in a loud environment
Cognitive – when stressed or distracted
Visual – web on a mobile screen
Language – ESL, or any 2nd
language

8. Ten Principles of Web Accessibility
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.

9. Ten Principles of Web Accessibility
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.

10. Ten Principles of Web Accessibility
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.

11. Accessibility Testing Heuristic
Be “HUMBLE”

12. 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.

13. HUMBLE (cont.)
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

14. There’s a bug here.
Can you see it?
What if you “heard” it?

15. Inclusive Design
Two “arguable” definitions:
Accessibility
“The design of products, devices, services, or environments for people with
disabilities. The concept of accessible design ensures both "direct access"
(i.e. unassisted) and "indirect access" meaning compatibility with a person's
assistive technology.” (from Wikipedia, see
https://en.wikipedia.org/wiki/Accessibility)
Inclusive Design
‘The design of mainstream products and/or services that are accessible to, and
usable by, as many people as reasonably possible ... without the need for
special adaptation or specialized design.’ (British Standards Institute (2005),
see
http://www.inclusivedesigntoolkit.com/betterdesign2/whatis/whatis.html#p3
0)

16. Why Inclusive Design?
Populations are living longer, and striving to keep doing the things that
matter to them.
People are not “able bodied” or “disabled”. There is a continuum, and
all of us sit on and move along that continuum as we age.
Minimizing capability demands allows more people to use the product.
Greater population able to use product directly improves overall user
experience.

17. Personal Example: LoseIt
App to track calorie consumption, exercise output and weight loss.
Data intensive app, lots of values to display and calculate
Covers a range of targets and goals:
• Calories consumed
• Macronutrient breakdown
• Steps taken
• Challenges accepted

22. Recap
Make it highly structured - easier to learn, remember, navigate, and
operate
Make it consistent in terms of design, implementation, and communication
- for the same benefits as above, and product maintenance will be easier
Provide more than one way in function and navigation
Test your implementation!

23. Standards
WAI/ARIA:
 http://www.w3.org/WAI/intro/aria
Web Content Accessibility Guidelines 2.0:
 http://www.w3.org/TR/WCAG20/
Inclusive Design Toolkit (University of Cambridge)
 http://www.inclusivedesigntoolkit.com/betterdesign2/

24. Some Tools
W3C HTML Validator: http://validator.w3.org/
W3C CSS Validator: http://jigsaw.w3.org/css-validator/
WAVE Web Accessibility Validation Tool: http://wave.webaim.org/
WAVE(Firefox): http://wave.webaim.org/toolbar/
Accessibility Inspector for Firebug: https://code.google.com/p/ainspector/
Web Accessibility Toolbar (WAT):
http://www.paciellogroup.com/resources/wat
Accessibility Evaluation Toolbar (Mozilla): https://addons.mozilla.org/en-
us/firefox/addon/accessibility-evaluation-toolb/
FireEyes (Deque): http://www.deque.com/products/fireeyes/

25. Further Reading
Black Box Accessibility Testing: A Heuristic Approach
by Albert Gareev and Michael Larsen
http://www.associationforsoftwaretesting.org/wp-
content/uploads/Black-Box-Accessibility-Testing-A-Heuristic-
Approach-.pdf
A Web for Everyone: Designing Accessible User
Experiences
by Sarah Horton and Whitney Quesenbery (Rosenfeld Media, 2014)

26. Thank you for attending this session!
Michael Larsen
Email: mkltesthead@gmail.com
Twitter: @mkltesthead