This module will describe the fundamentals of who uses screen readers and how a screen reader works.
Reading 1: Who uses screen readers? (5min)
Someone who is blind might use a screen reader and listen to audio output.
Someone who is both deaf and blind might user a screen reader and recieve output via a refreshable braille display.
Someone who has limited mobility might use a screen reader for content shortcuts (such as jumping to the next heading).
Someone who has low vision might use a screen reader to augment their experience.
Someone who has a cognitive disability (such as a reading disability) might use a screen reader (or something like a screen reader) to hear content, which can help with processing and understanding.
Reading 2: When to implement accessibility
It is very common for companies to only consider accessibility at the quality assurance state or after release. This approach is costly and not sustainable. Instead, the goal should be to push as much accessibility as far left in the development process as possible, closest to requirements gathering, design, and development.
Activity 1: Discussion
Discuss the following questions within your group and prepare answers for the larger group. You might have to do a little research.
Do I need to be blind to use a screen reader?
When testing with a screen reader, do I need to close my eyes or turn off the screen?
Is a screen reader an input or output device, or both?
Do I need to install a screen reader on my website?
What can my team do to move accessibility further left in the development process?
What are some other kinds of testing that I must perform when testing for accessibility? Is screen reader testing sufficent or do you have to do more?
When you are ready to report your answers to the wider group, say "beep beep boop" very loudly or otherwise do a silly thing that your instructor will notice.
Reading 3: How a screen reader works (10min)
A screen reader reads information about the active window by using something called the Accessibility API that is provided by the operating system.
A browser will look at your HTML, parse it, deterimine each element's semantics and send that information to the Accessibility API. Semantics include the element's name, role, value, state, and properties.
Developers define the semantics by using HTML elements and attributes, or by using WAI-ARIA. A few notes on ARIA:
When should you use ARIA? Answer: as a last resort?
A screen reader can also send commands to the browser (or other application) by sending commands to the Accessibility API.
Some screen readers will only use the Accessibility API, others will use the Accessibility API and supplement that information by using a browser extension or another technique. This can result in more robust (and sometimes strange) support.
What are the semantics?
Name: What is this element? It distinguishing between elements of the same role.
Role: How does this element behave? When you use a role, you are making a promise that the element will do a certain thing and support certain keyboard and screen reader behavior. Expected keyboard behavior is documented for many patterns and roles in the ARIA Authoring Practices.
Value: What is the current value? Think a text input.
State: What is the state of an element? Think aria-expanded.
Properties: What are other properties that describe this element? Think something like aria-controls (note that aria-controls is not well supported, so probably don't use it).
Generally speaking, a screen reader will announce an element's name, role, value, state, properties, and description, as well as any changes to those items while the element is in focus.
Activity 2: Semantics
Look at the following code and predict how a screen reader will announce it.
<button aria-expanded="false">What is the average speed of a swallow</button>
What are the semantics (name, role, value, state, properties, and description) of the above element?
How might a screen reader announce it?
What behavior does the button role describe? How do you know this?
When should you use ARIA instead of HTML?
When you are ready to report your answers to the wider group, say "beep beep boop" very loudly or otherwise do a silly thing that your instructor will notice.