This resource is intended to provide general recommendations on best accessibility practices for open textbook authors when creating open textbooks and other educational materials.
Please note: The author is an able-bodied, sighted, and hearing user. It is highly likely that there are barriers that will escape my notice due to my lack of lived experience with many disabilities. As such, it is vitally important to encourage and incorporate any accessibility feedback provided by any users with disabilities when creating and using these texts. If something in this guide doesn't fit with a user's lived experience, please let us know!
The MSVU Library will conduct an accessibility review of the [Open Textbook], and provide a report to the author(s) documenting any observed accessibility issues and recommending alterations or improvements where possible. Author(s) should allow a minimum of 20 working days for this assessment to be completed and for any recommended changes to be implemented prior to publication.
At minimum, the text should be submitted with:
The Library will assess the text further for additional considerations, including:
Any observed issues that cannot be changed or resolved must be listed in a ‘Known Accessibility Issues’ section in the beginning of the text.
A cohesive and logical flow of information is important, especially if the reader relies on assistive technology to navigate. A logical flow of information assists readers in making connections between concepts, and breaking down large ideas into chapters, sections, and subsections can make ideas easier to digest and appear less intimidating.
It is vitally important to use headers, and use them properly, when subdividing your sections. For sighted readers, this provides a visual cue when introducing information. For those relying on assistive technology such as text-to-speech or a screen reader, or navigating the page by keyboard, headers provide essential signposts. Screen readers can use keyboard commands to jump from heading level to heading level, or to migrate between headings of the same level. This makes it easy to locate and relocate information, the same as if one were skimming the page with their eyes.
Headings can be used at levels 1 to 6, with Level 1 generally being the ‘top’ level (such as a chapter title), and Level 6 being the most minor. Headings also should be organized in descending order, from highest importance to lowest (for example, it wouldn’t make sense to find a section title with heading level 4, then have a subsection labeled heading level 2). Information of similar importance should be given the same heading level. This chains the information together and makes the document flow logically and predictably.
Keep in mind that six levels of headings are a lot to keep track of. If it is necessary to use all six levels in a single chapter, it might be a good idea to consider splitting the chapter into two chapters.
Also remember that headings are navigational aids, and should never be used for aesthetic purposes, such as resizing text. Likewise, visual indicators such as changes of font or text size or colour is not sufficient for breaking up chapter sections – those things are not accessible to a user navigating via a keyboard and are generally invisible to screen readers (as explained in the following section, Text Accessibility).
However content is organized, be consistent. For example, if there is a glossary at the end of the chapter, ensure that it is always at the end of a chapter. If each chapter has a summary at the beginning or the end, put it in the same location every time. It is far easier to locate information if it’s arranged consistently, regardless of whether or not a user can see the screen.
It is impossible to write content that will work for every different screen reader and every setting and user preference. The follows are some best practice suggestions, as well as notes on writing conventions that don’t tend to work well with screen readers.
It is common in textbooks to see important words and concepts in a different font or emphasized by bolding or italics ; this guide follows a similar format. Unfortunately, those effects are largely undetectable by screen reader, and it will read these words in the same manner as the rest of the text, with nothing to highlight their importance.
For important terminology, the use of a glossary is strongly encouraged, either at the beginning or end of the chapter, with a descriptive link that makes it easy for readers to jump to the glossary and back to the main text. This way, both sighted and non-sighted/low vision users will know what terms to watch for/listen for, and they won't be lost in the constant chatter of narration.
Screen readers can generally interpret or announce many common symbols, such as @, %, *, and common punctuation (periods, commas, colons). They’ll either announce the symbol or interpret what it means and pause or change tone accordingly. However, some signs may be read in a way that doesn’t make sense or can’t be seen at all.
The correct interpretation of symbols can be increased by use of HTML to ensure the screen reader is being told exactly which character it has encountered, as opposed to the WYSIWYG (What You See Is What You Get) visual interface, and screen reader technology is constantly being affected by updates, improvements, and variations in user settings. Just be aware that special characters and symbols may not be recognized by a screen reader and may need additional clarification or tweaking if the meaning of the content is compromised.
Alt text (or “text alternative”) provides a description of an image, so that a reader can understand what the image contains and what information it imparts even if they are a) unable to see it and/or b) on low bandwidth and cannot load images.
All images require alt text, regardless of if they are considered informative, functional or decorative.
Informative/Functional vs. Decorative Images
An informative image is one that imparts information and is essential (or at least helpful) to understanding content. These may include things like:
These images always require alt text describing the important parts of the image, providing the information the reader would miss out on if they can’t view the image for any reason.
A functional image is one that can be used to perform an action, rather than convey information. Frequently, these are images that serve as links, such as icons and logos. In this case, instead of describing the image contents, the alt text should describe its purpose – what does clicking the image do?
A decorative image has no purpose other than aesthetic – it’s a design choice. It imparts no information essential to the content, and it doesn’t do anything functionally. These are often found in chapter headers or as supplementary images to make the content more visually appealing to sighted readers. Although they don’t contribute to the informational content, a screen reader will still detect and inform the reader of the image – unless alt text is used to tell it not to. This type of alt text is called ‘null‘ alt text.
Alt text for simple informative images should be kept brief (the suggested maximum length is 125 characters), but also contain an appropriate level of detail. Think of alt text as describing an image as you might to someone over the phone:
“Photo of a cat” is insufficient. What colour is the cat? What is around it? Is it inside or outside? Is it night or day? Instead, try something like, “A white short-haired cat sitting in the sunlight on a wooden step, in front of a red door.”
The idea is that a reader should not miss out on useful information that someone who can see the image would gain.
Alt text should never start with the words 'an image of’ or ‘a picture of’. A screen reader will announce when it encounters an image (unless it is marked decorative), so adding ‘a picture of’ to the description is redundant. Likewise, if a picture does not load, you can still see the outline and icon where it ought to be.
The alt text for a functional image should describe the purpose of the image (what it does) instead of describing the image contents. For example:
| Image or Icon | Yes | No |
|---|---|---|
| Search Icon (serves as button or link) | "Search" | "Magnifying Glass" |
| Website Logo (homepage link) | "Website Name Homepage" | "Website Name logo" |
| Printer Icon (commands current page to print) | "Print this page" | "[Image of] a printer" |
A decorative image, which imparts no additional information and performs no function, requires blank, or null, alt text (“ “). Encountering this will tell the screen reader to skip this image without announcing it to the reader.
Omitting alt text or leaving the alt text field blank will usually not result in a null alt text – instead, the screen reader will read out whatever information it can access, which is usually the image file name. In Pressbooks, clicking the box marked ‘decorative’ when uploading an image automatically applies null alt text to it. Even if an image is just window-dressing, it still requires some form of alt text!
There is another consideration when writing image alt text: redundancy. If a sufficient description is provided in a caption above or below the image, or if the information imparted by the image is available in nearby main text, that information does not need to be repeated in the alt text field. It is enough to identify the image, so that the reader can make the connection to the text, if the information appears close by. Remember, alt text should be considered alongside the main text, not treated as two separate methods of providing information.
Likewise, a very common item doesn’t need a description, unless it’s pertinent information. For example, the user likely knows what a banana is, so there is no need to describe an image of a banana as “an elongated yellow fruit”. It might, however, be pertinent to mention if an apple is green as opposed to red, as that gives information regarding the type of apple.
In every case, an image must have some form of text alternative to provide the necessary information. A file name (such as 'cat.jpg') is not sufficient alt text. It provides no information regarding the contents or purpose of the image and is just audio clutter to a listener. Even the ‘null’ alt text of a decorative image provides information – that the user can pass this image by without missing anything.
The amount of required alt text increases with the complexity of the image. While a simple image may have a single line, a complex image (like a graph, infographic, or diagram) requires a two-part alt text:
An infographic or diagram is intended to impart a lot of information quickly through a visual medium, but if the reader has difficulty seeing the image, they must be provided with another way to gain that same information. This can be done by providing a long description.
A long description is exactly what it sounds like: a longer, more detailed description that exceeds what could typically be provided by a simple alt text for an image imparting more information than usual. They are quite bulky and will likely disrupt the flow of the document, and some screen readers will cut off alt text beyond a certain length. For this reason, it’s considered best practice to place the long description in its own section and provide a link to it, usually just beneath the image. Three examples of long descriptions are given below.
As with simple alt text, a detailed long description is not necessary if the information provided by the infographic is also available in the nearby text. If the main text provides sufficient explanation, it’s not necessary to double-down in the long description as well.
|
Example 1: Infographic
Figure 1: Infographic Math and LDS - Brain Areas and Math Skills. [Long Description (3)]
Three simple drawings of the brain, each with sections labeled. First drawing: A left-side view, with the front of the brain facing left. Along the left-side frontal lobe, at the top, is the Supplementary Motor Cortex, involved with motor coordination and Calculation. Below this is Exner’s Area, which is involved in writing numbers and Calculation. Below this, at the bottom of the frontal lobe, is Broca’s Area, responsible for Expressive Language and Sequencing, and Word Problems. At the center of the brain, three areas are clustered together and are labelled as follows: 1. the Supramarginal Gyrus, responsible for Number-quantity association and Calculation, 2. the Angular Gyrus, associated with Sound-symbol association, Word problems and Reading, and finally 3. Wernicke’s Area, which is involved in Language Comprehension and Word problems. Second drawing: A right-hand view of the brain, with the front facing right. A single line points to the center of the frontal lobe, and is labelled Dorsolateral – Dorsal Cingulate, which is involved in Executive function/Working memory, Multistep problems, word problems, and quantitative reasoning. Third drawing: Another drawing of the brain from the left side, facing left. There are four areas identified along the back of the brain: the first is the top, rear area of the brain, labelled the Parietal Lobe. The right side of the parietal lobe is associated with spatial awareness and multistep problems/neglect; the Left side is involved with directional awareness and number reversals. Below this is the very back of the brain, labelled the Occipital Lobe (striate), which is involved in Number recognition and computation. At the bottom of the brain is the Cerebellum, which is responsible for Number recognition and Computation. Finally, folded between the frontal lobe and the cerebellum is the Middle temporal lobe, which is involved in Quantitative knowledge, and Computation/fluency/word problems. End of Long Description. [Return to Figure 1] |
Note that the word ‘infographic’ is used in the shorter description. This is because the screen reader will announce an image, but it cannot tell the user that it is an infographic, so that information must be provided via alt text or caption.
If the information provided about each labeled section is included in the main text, it does not need to be included in the long description; the simple alt text would be sufficient.
Writing alt text for complex images like charts and graphs depends heavily on the type of graph and intended context — how much detail does the user need? Is the general trend enough, or does the user need every data point described?
The following formula for chart and graph alt texts is suggested by Amy Cesal, a data visualization specialist in her video "Writing Alt Text for Data Visualization":
| Alt text = [Chart type] of [Type of data] where [Reason for including graph] |
See Example 2 below for a demonstration.
|
Example 2: Charts and Graphs Example 2a: Line Graph
Figure: Example 2a: Line Graph Using the formula suggested, the alt text would look like: “A line chart of YouTube video views per month that shows the video’s views peaked in March, three months after it was posted.”
Example 2b: Bar Graph
Figure: Example 2b: Bar Graph Alt text: “Bar graph of preferred soft drink by vote. The highest number of voters chose Coca Cola products as their beverage of choice. (Coke products – 9 votes, Pepsi products – 7 votes, No name/Other brand – 4 votes, Doesn’t drink soda – 3 votes).” The alt text for includes the number of votes for each option, providing the raw data in text form as well. Note that ‘votes’ has been spelled out each time, which avoids confusion as to what the numbers are referencing. |
When possible, include the source data for any charts or graphs — a screen reader can read text data to a user who is unable to see the visible representation of a complex graph, which can provide extra clarity.
You may also choose to include a caption for the graph, but providing all the requisite information for the graph to be understood may create some bulky captions, and the image would still requires alt text to identify it. A caption is optional; alt text is not.
It is also good practice to summarize any complex images in the nearby main text to highlight the important or relevant information that the image is meant to convey: “the following graph indicates…”, “the diagram below shows…”, etc.
When constructing charts, consider how best to make them clear and accessible to sighted users. It’s always a good idea to test colour choices for text and charts using a contrast checker (links to some contrast checkers available on the web have been provided in Additional Resources). No image, chart, graph, or text should ever rely entirely on colour to convey its meaning. Example 3 below demonstrates what it’s like to try to make sense of content that relies on colour alone to impart its information if the user possesses a degree of colour-blindness (or “colour vision deficiency”). An estimated 300 million people worldwide have some degree of colour blindness!
|
Example 3: Relying on colour to convey meaning The following passage uses colour to convey its information (Passage adapted from Kurt Vonnegut's 'How to Write with Style' (IEEE Transactions on Professional Communication, vol PC-24, no 2, June 1980, pp 66-67): Paragraphs are composed of a three-part structure with a beginning, middle, and end. These parts are the topic sentence, development and support, and a conclusion. "As for your use of language: Remember that two great masters of language, William Shakespeare and James Joyce, wrote sentences which were almost childlike when their subjects were most profound. “To be or not to be?” asks Shakespeare’s Hamlet. The longest word is three letters long. Joyce, when he was frisky, could put together a sentence as intricate and as glittering as a necklace for Cleopatra, but my favorite sentence in his short story “Eveline” is this one: “She was tired.” At that point in the story, no other words could break the heart of a reader as those three words do." Example 3a: Deuteranopia Now look at that same text with deuteranopia (inability to see green light):
Figure: Example 3a: Deuteranopia Example 3b: Achromatopsia The same sample passage, this time viewed with achromatopsia (colour perceived as shades of grey):
Figure: Example 3b: Achromatopsia As demonstrated, relying on colour alone for meaning may leave the user unable to obtain the information that the paragraph is trying to convey, and is therefore inaccessible. |
Returning to the bar graph in Example 2b, the bars of the graph are labeled with their names and values, so that they can still be differentiated if the viewer has difficulty seeing a certain colour (or any colour at all). Another option is to use patterns in place of colour, as shown in Example 4. For those with colour-blindness, patterns are often easier to distinguish visually rather than colours. It also allows users to print the chart in black-and-white/greyscale without losing its meaning.
|
Example 4: Using patterns instead of colour
Example 4: Using pattern instead of colour in a pie graph Using patterns instead of colours for identification means that the graph can be understood despite any degree of colourblindness, or if the graph is printed in black and white or grayscale to read offline. |
A table should never be an image. All tables must be created or imported properly, with headers, rows, and columns that can be navigated by keyboard, and read by a screen reader.
Pressbooks has a couple of tools for making sure tables are accessible when created:
When you create your table in Pressbooks, you can designate any table cell as a header cell under via ‘Cell – Table Properties’ and selecting ‘Header cell’ from the ‘Cell Type’ drop-down list.
Likewise, using the ‘Scope’ drop-down list will allow you to designate a ‘row’ or ‘column’, ensuring that your table’s structure can be clearly communicated to screen readers and making the information more easily navigable and understandable.
Avoid using split and merged cells. As a screen reader reads things left to right, down the page, split and merged cells can make it difficult to tell which header the cell lines up under.
| For an example of how the JAWS screen reader interprets merged cells in a table, check out the example video “Jaws Reading Combined Tables” from Chapter 21 of the Best Practices in Accessible Online Design Pressbook by Heather Caprette at Cleveland State University. |
Like graphs, tables should have captions summarizing the table, and/or a brief lead in sentence in the main text. A screen reader will announce a properly formatted table when it encounters one, but a lead in sentence (“In the table below…”) is also helpful, since the screen reader will just launch into “Column 1 header: ‘Name‘. ”
All audio content must provide a transcript, including all spoken content and any important non-spoken audio (sound description). Speakers must always be identified.
Auto-generated transcripts are insufficient; transcripts should always be reviewed and edited by a human for accuracy. If the content does not have a transcript provided, the Canadian Copyright Act (Part 3, Section 32.1) permits the reproduction of material in an alternate form (i.e., a transcript) for persons with perceptual disabilities, or for a person acting at the request of a person with perceptual disabilities.
Transcripts are also useful when the user is in an environment where they cannot listen to the audio, or for someone who struggles with processing auditory content, or in low-bandwidth situations where the audio will not load.
Video content requires captions of all spoken content, as well as any important or relevant non-spoken content. Where possible, providing a transcript is also a good idea (see above notes on Audio Content).
Any images or graphs shown in the video should be audibly described, even if it’s something like “[Name] holds up a diagram of a human brain”. Ideally, the person in the video should provide any relevant information about the image for those who can’t see it, but that information may not make sense to a listener who cannot see what the speaker is doing without a description.
Captions and transcripts should always be proofread by a human for accuracy, as auto-generated captions and transcripts (as of the writing of this guide) are rarely sufficient. As mentioned above, the Canadian Copyright Act has exceptions that permit the reproduction of material in an alternate form to make it accessible for persons with perceptual disabilities, or for a person acting at the request of a person with perceptual disabilities.
Other things to consider: WCAG 2.2 also stipulates that no content should contain anything that flashes (or flickers) more than 3 times in a one second period, which includes animations and transitions.
H5P.org provides a helpful spreadsheet of H5P content type recommendations based on their accessibility, most of which continue to be updated. However, some specific issues may still exist, even for activities deemed accessible: perhaps a screen reader can read the text just fine, but it’s too easy for a user navigating via keyboard to get stuck in a keyboard trap (when user cannot move focus away from an interactive element or control using the keyboard alone). For this reason, the activity should always be checked using a screen reader before being cleared for inclusion.
All H5P content should have a description of the activity before encountering it, as screen readers may not announce when H5P content is encountered. Test runs have shown that a screen reader might say “Activity: [Activity Title]”, or it might launch straight into the activity, saying something like “Drag and drop grabbable 1”. This doesn’t give a user any warning before throwing information at them or how the information should be used.
|
The lead in description provided should include:
…as well as any other pieces of information that might be useful to understand how the activity works and what is expected. |
Keep in mind that an activity’s design and controls and expected outcomes are not always intuitive, even for sighted users, so additional instructions are always useful.
An example of one type of H5P content that is considered ‘accessible’, but still requires a bit of extra attention is the “Fill in the Blanks” activity.
When creating fill in the blanks, a screen reader will not understand a vacant space. For example, if you construct a fill in the blank question like so:
| "The ________ is the powerhouse of the cell." |
The screen reader will simply pass over the space without reading or announcing it, making it sound like “The is the powerhouse of the cell”, and won’t give the reader any indication of where the blank is.
Instead, the question should be constructed to actually use the word “blank” in the sentence.
| "The [Blank] is the powerhouse of the cell." |
The question is still understandable to those reading by sight, and doesn’t suffer from loss of information if reading with the aid of a screen reader.
If an activity does not meet accessibility requirements, it must be listed under the ‘Known Issues’ section. Activities should always be supplementary, so any information it imparts (from a slideshow, or index cards, etc.) should always be available elsewhere in a different form (i.e., the main text, a sidebar).
Links provide other ways for users to view and interact with a page. A screen reader will announce a link when it encounters it. It’s also possible to command a screen reader to simply read a list of the available links on the page, and keyboard commands can be used to navigate from link to link. Users relying on speech-to-text software can also interact with a link by speaking the text.
However, if a link is not descriptive, interpreting page links and navigating the page this way becomes virtually impossible. Link text should always make sense on its own, even without listening to the surrounding sentences or content. If all a link says is “read more” or “click here”, that doesn’t give the user any information on what the link is, where it leads, or what it will do.
| To hear an example of using a screen reader with a page without descriptive links, check out this Youtube video "Write More Accessible Link Text" provided by Pope Tech. |
A link should never be simply a URL. Not only is this useless in terms of navigation, but a screen reader will also read out the entire URL rapid-fire, which is really just a bunch of babble without providing any information about the link.
|
For an example of what it sounds like when a screen reader encounters a URL, check out this Youtube video "Why Use Descriptive Links?" from Portland Community College. (Note: the relevant example is from timestamp 0.:33 - 0.51.) |
Best practice for links is to make the title of the item clickable, as opposed to the URL. A title is unique and should give enough information for the user to decide if they want to interact with the link. You can see examples of this in the two example boxes above.
This practice should be followed with citations as well; it is much easier to identify and determine a source’s usefulness by hearing the title announced, rather than the URL (the URL can still be provided as regular text; a screen reader will not pick this up as a link when navigating via link to link!).
Links should also include a description of where the link brings you and what will happen when you click on it. The two examples above take this into consideration, too: the screen reader will read out “Youtube Video “Title””, which tells the user what the link is about, that it is a Youtube video link, and that a video will play.
It is extremely startling and frustrating to click on a link and have an unexpected video or sound begin playing, forcing the user to figure out where the sound is coming from and why. It is also a nuisance for the user to have to navigate back to their content because they didn’t realize the link would take them out of it. For this reason, it’s considered best practice to include a description of what the link will do once clicked. Below are some examples:
“For more information on X, <link> watch this youtube video “Video Title” </link>. (Video opens in new window)”
“<link> A helpful infographic on the brain! (PDF) </link>.”
“Check out <link> John Smith’s Blog </link>.”
In each case, it is clear what the link is about and what will happen when it is clicked: it will play a video, or open a PDF file, or take the user to a new website.
It’s also important to indicate if the link will open a new window or tab, or otherwise navigate you away from your current page. Ideally, it’s better to avoid opening new windows and tabs (which can make it complicated to get back to your original spot), but if this is the case, you must indicate in the text that this is what will happen.
“Check out <link>John Smith’s Blog [New Tab]</link>”.
In this example, the user is informed that clicking on the link will open a blog page, and that it will open a new tab in addition to the tab they are currently on.
If there is anything else a user might need to know about the link or destination (i.e., that a file will download, or that sound will start automatically), include that as well.
Authors should keep in mind that it is virtually impossible to meet every single requirement for every possible disability. Some disabilities will require different aids or methods of access that may come to cross-purposes. What is important is to anticipate as many as possible, to seek user feedback, and to listen to users when they tell us what they need, and to communicate any known accessibility barriers clearly to minimize frustration.
Screen Readers:
NVDA (Non-Visual Desktop Access) Screen Reader
NVDA Screen Reader: Keyboard Commands List
Mac VoiceOver: General Commands List
ChromeVox (Built into Chromebooks or available as an Extension via the Chrome store)
Accessibility Checker Tools:
Wave – Accessibility Checker Extension for Browsers
WebAIM Colour Contrast Checker
Additional Resources and Information:
Web Content Accesibility Guidelines (WCAG) Ver. 2.2
Media attributions:
LD@School.(2023). Math and LDS: Brain areas and math skills [Infographic]. Retrieved from https://www.ldatschool.ca/document/brain-areas-and-math-skills/
Vonnegut, K. (1981) Power of the printed word: How to write with style. (1981). IEEE Transactions on Professional Communication, PC-24(2), 65-71. DOI: 10.1109/TPC.1981.6447837
