- Making products, apps, and software accessible means that they can be used more efficiently and effectively by more people
- Depending on context, “normal, healthy” people can function on the same level as people with a recognised disability
- There are design guidelines and design patterns to support people with accessibility issues
- Definition of accessibility
- Design patterns
- Inclusive design
Find and choose appropriate heuristic evaluation guidelines for evaluating a web site or an app
Preparing for the lecture
Accessibility means that people with disabilities can use the product, app, software, or IT system that you have developed properly. What this means for the internet, more specifically web browsing, was outlined by the World Wide Web Accessibility Initiative.
Our definition of what accessibility is depends on our definition of disability. Disability, at its core, relies on a detailed study of what can be considered normal function. However, normal function can vary substantially. To what extent are short people disabled? To what extent are tall people disabled? Would you consider dwarfism a disability? Would you consider an actor who is as tall as Danny DeVito disabled? What is the psychological, anatomical, or physiological impairment? What tasks can a person not do due to their impairment? To what extent does this handicap their daily life? (see World Health Organisation definitions).
So, it is actually more useful to think of accessibility in terms of inclusion. What kinds of people are included in the user base of our product, what kinds of people are not? The business case for accessibility is that the more people are included, the more people will be able to use and purchase the product.
This approach to design is called Inclusive Design. Revisit the resource we already looked at in Week 2 and see how the principle of Inclusive Design relates to different levels of function.
If you want to go from principle to practice, it is a good idea to work with personas. A persona is a fictional person that stands for one of the intended users of your system.
Once you know what the person can and cannot do, you can put them into scenarios where they will need to use your technology. So, imagine that Freyja and David need to review government reports for their work. While Freyja can see, she may find it hard to hold sheets of A4 in front of her eyes for long periods of time. The effort required may make it hard for her to concentrate (see Week 3, multitasking). Thus, she might benefit from a tablet that is angled so that she read easily. David can’t see with his eyes, but presumably he can read Braille. If the document was prepared using a computer, it can then be sent to a Braille printer. Alternatively, both of them can use speech synthesis software to have them read texts to them.
Core Readings and Resources
The textbook chapter is Chapter 3. You can find more about personas in this very practice oriented set of resources, or you can ask a friendly classmate who has taken HCI, as this course has an extensive unit about personas and their construction.
For designers, I recommend delving deeper into the framework behind the Inclusive Design toolkit. A great example of how people with disabilities see the technology that helps them function is this article by Freyja, “I love my wheelchair, Kylie Jenner.”
For those of you who have already taken the HCI course, which had web design as one of the course work components, I recommend taking a good look at the WWW consortium’s guidelines.
If you are interested into delving into the thinking and theory around accessibility and disability, have a look at these Dialogues on Disability, which may also inspire some personas for you.