Accessibility: Screen Readers

Author: Phil Chambers | Screen Readers

I have worked in many places around the world and each one has had a different approach to ‘accessibility’. There are places that treat it as a ‘nice to have’, but not essential part of developing materials; those for which it does not even enter into the equation; and then there are places where accessibility is built in from the start (the best approach!) either by policy or legal requirements.

By approaching content and courses with an ‘accessible-first’ frame of mind, it really changes the way you design content and steer the decisions of the developers and SMEs with whom you work.

I feel that this could be an ongoing series of posts focusing on accessibility, and so I will begin this one on designing content for screen readers.

What is a screen reader? 

A screen reader is an application that runs on a person’s computer and reads text and other details that it finds to the user. It is most commonly used by people who have trouble seeing and need assistance interacting with digital content. The more common screen readers are:

  1. Jaws (for Windows)
  2. NVDA (for Windows)
  3. Voiceover for Mac and iOS devices
  4. Windows Built-in Narrator

How do they read content? 

Because there are several screen readers, there is no single way to answer this. The software will attempt to read aloud the elements of the page (text, images, and so on). A good thing to keep in mind is that people who use screen readers have a lot of shortcut keys that let them quickly jump around the page and to different sections so they do not have wait until the application reads everything. As an Instructional Designer, you’ll need to keep a few things in mind about how a course page is set up to make this as smooth as possible.

Headings 

It is all too often that I notice that documents I am given to work on have been, at first glance, split up nicely into neatly arranged sections using headings. Upon further inspection, however, it becomes clear that instead of using an orderly list of formatted Headings, like the following…

Heading 1

Heading 2

Heading 3

Heading 4

…the document is separated by font-size increased Bold text. This is a problem because more often than not, the older <b> tags in HTML, or font-weight styles (which are usually how bold text is generated) do not act as an anchor of sorts that the screen reader can ‘jump’ to using the shortcuts. Pressing the tab key while using these applications (or another bound key) will jump to the next important section. Headings make this easy - large, bold text does not. If the user is visually impaired, they may not see fonts or colors in the first place.

Note: The Canvas LMS seems to replace b tags, and Rich Content Editor 'bold' styling with strong. This may be a recent addition, but functionally they are supposed to be different elements.

How does it work with images? 

How would you describe an image of something to someone who could not see? You would probably try to make a short description that made it easier to understand what the image was showing. This is known as alternative text and it is fairly easy to add in - though more challenging to do well, as a picture being worth a thousand words does make the recommendation imposed by some Learning Management Systems of 2-3 sentences per image less than easy. Still, if you want your content to be accessible to all learners (and you should!), this is a vital step. Without the alt text, the screen reader will either not read the image at all, or announce there is an image and leave it at that. No context, no explanation, but one confused learner.

Briefly on Images and Alt Text 

Chances are pretty high that at least somewhere on your course, the Subject Matter Expert will want to use an image or two. Think about how a screen reader would interpret this. Would you want your visually impaired learners to know what the image is showing everyone else? It’s quite easy to overlook this part of course design if you are not thinking of accessibiltiy from the start. At the very least, you should add alt text for each of the images you use (or mark them as decrorative if they are not necessary to understand the content).

Note: Alt text is not just for screen readers! If the image link is ever broken or removed, the alt text becomes a vital part of explaining what is supposed to be there.

Adding Alt Text 

Your Learning Management System may have a built-in accessibility checker that specifically looks out for missing alt-text. Or, you may have the option to add this text when you upload or embed the image. The best way to get this information is by building it into the module or page template you would give the SME. Mark the information as required for every image. As you are likely not an expert in the course you are building, this will avoid guesswork on your part. You could also make this a part of your regular check-in meetings with SMEs as it is easy to forget this information if you are not used to including it.

Note: Alt text must be no more than 100-125 characters in the vast majority of cases. Make sure to use another attribute if you want to increase the size of the descriptive text - but also be aware that this will slow down progression through the page. See labelledby or aria-describedby attributes to provide this.

How do I design a course to work with screen readers? 

The most important thing is to start a course with accessibility in mind. Make it a part of the questions you will ask during the initial meeting with clients/faculty. What sort of content do they think will be the most challenging for visually impaired learners? I have created a set of questions about accessible materials design that I will go through during the first course meeting, and then return to them at various stages of the course development.

Here are some regular things to keep in mind when checking for accessible content as it is being built on the course site:

  • Are images marked with alt-text?
  • Are purely decorative images marked as such (and if using Canvas, have you removed the alt-text?)
  • Have you included a caption for all tables?
    • (This can be hidden by using the screenreader-only class, but still read aloud by the screen reader. Using visibility: hidden or display: none will cause the screen reader to ignore it.)
  • Have you thought about elements with highly visual requirements/contexts and provided a text-based version of these?
    Note: You can learn more about how to do this on Canvas using my quick tutorial on hidden content for screen readers
  • Use the aria-hidden attribute if you do not want a screen reader to read an element.
    Note: Only use this when it is to hide duplicate or redundant information.

Copyright © 2022 - Philip Chambers. Theme based on PaperMod for Hugo.