Creating Accessible Content for Course Creators

updated 3 yrs ago

Creating Accessible Content

While the OpenLearning platform has been coded and designed with accessibility principles in mind, course creators have a responsibility to design accessible content.

When course creators are using tools outside of OpenLearning’s platform (which we recommend) it is imperative to consult the accessibility documentation of that tool and understand the limitations and trade-offs.

For course creators who are working within accredited education providers such as universities, colleges, and schools, we also recommend checking whether there are support staff, documentation, and policies that are there to support your course design process.

Images

The use of images can improve the accessibility of courses for all learners. Graphics, charts, illustrations, and graphs help learners make sense of concepts and serve an important communicative function.

For the purposes of accessibility, there are two categories of images:

Decorative images serve a presentational purpose or are used to improve the visual layout of a page. They do not convey essential information for learning.
Informative images are used to communicate content-related ideas that support learning.

For guidance on how to distinguish between decorative and informative images, the Web Accessibility initiative’s An alt Decision Tree article provides useful information and guidance.

Alternative Text

Blindness, low vision, motion sensitivity, cognitive disabilities, poor quality images, and very slow internet all impact how users interact with images. The impact may include: disabling images from loading, losing image quality when magnifying, and/or needing text-to-speech technology to understand the content.

Alternative text provides users with the information they need to understand the content. Text-to-speech technology, including screen readers, read alternative text aloud and web browsers display it when images do not load. The most common form of alternative text is the alt attribute, which is a label within the HTML code for an image.

The basic rules for creating alternative text are:

All images must have an alt attribute
Alt attributes should describe the purpose of informative images.
If an image is decorative, use an empty alt attribute so text-to-speech services will disregard it.
If an image is complex, like a graph, chart, map, or images with a lot of detail, write a long description.
Do not use ‘photo’, ‘picture’, or ‘image’ as it is redundant. Text-to-speech services will let the learner know it’s an image; and
Avoid images of text. If they’re necessary, the alternative text must contain the text verbatim.

For more information on writing effective alternative text, WebAIM’s Alternative Text article is informative. Refer to WCAG standard 1.1.1 Non-text Content to learn more about the requirements for alternative text.

Colour Contrast

Informative images cannot rely on colour alone to convey important information. For all maps, graphs, diagrams and instructions, colour cannot be the only way to convey meaning. Consider using shape, shading and descriptions in combination to support image accessibility. When colour is used, the foreground and background content within an image must have high contrast.

Refer to WCAG standards 1.4.1 Use of Color and 1.4.3 Contrast (Minimum) to learn more about the requirements for image colour contrast. WebAIM’s colour contrast checker is helpful for determining if the contrast is sufficient.

Images of Text

Whenever possible, the text should be presented as text, and not as an image of text. If it is necessary to use an image of text, the alternative text must match the text in the image. Additionally, use larger font sizes and solid or block fonts for legibility.

Refer to WCAG standard 1.4.5 Images of Text to learn more about the requirements for images of text.

PDFs

Portable Document Formats, or PDFs, are not very accessible, therefore it is important to incorporate accessibility features in PDFs and provide an alternative to PDFs that is accessible.

It is important to consider accessibility when creating PDFs as well as publishing them to the OpenLearning platform.

Creating PDFs

In order to create accessible PDFs, it is important to:

Tag them with accessibility features like headings and text, alternative text, tables and lists, bookmarks and links
Code forms with accessibility techniques
Specify the document language, document title, and page numbers
Ensure all text is searchable within the PDF; and
Use bookmarks to assist with content navigation

Publishing PDFs

In order to publish accessible PDFs to the OpenLearning platform, it is important to:

Create an accessible alternative, such as Text, Word, HTML or RTF, and;
The accessible alternative link must be adjacent to the PDF link

The link text for the PDF and the alternative link must:

Convey that the target is a PDF
Not use ASCII characters
Not use device-specific words like ‘click’
Not use ambiguous words like ‘more’ or ‘here’; and
Meaningfully and purposefully describe the content

The World Wide Web Consortium’s PDFs Techniques for WCAG 2.0 article offers helpful guidance on the requirements and suggestions for tools creating accessible PDFs. Adobe Acrobat’s documentation on creating accessible PDFs is also instructive.

Downloads

When creating content that you want learners to download, like Microsoft Word documents, PowerPoint presentations, Excel spreadsheets, MP3s, etc. it’s important to make an accessible alternative available.

Acceptable accessible alternatives include:

Text
RTF
Word; or
HTML

To ensure Word and PowerPoint documents are accessible include:

Alternative text for images
Pre-set heading styles
Active and descriptive links
Specified header rows in tables; and
Lists that use bullet points

Refer to WCAG standard 1.1.1 Non-text Content to learn more about requirements for accessible downloads.

Video and Audio

When creating accessible video and audio, it is imperative that a person with a disability is able to both use and understand the video and audio.

OpenLearning’s audio and video widgets are keyboard accessible so that learners can control them, including pausing, and has settings to allow course creators to give learners the option to skip over video.

Even though videos cannot be made fully accessible according to the WCAG standards, there are several things to consider when creating an accessible video:

How the video is filmed;
How the video is shared on OpenLearning’s platform;
Creating a video transcript;
Creating audio descriptions; and
Creating video captions.

Video Content

To generate accessible video content it is important to:

Consider colour contrast of the content;
Limit the size of the video files to no more than 2MB and break up larger files;
Do not use colour as the only way to convey information; and
Do not use flashing or flickering content.

Video Captions

Captions, or a text-based alternative to videos, is imperative for video accessibility. While YouTube’s closed captioning feature has improved a lot as of late, it does not consistently generate accurate captions. It is also worth noting that YouTube is not accessible in countries such as China.

Accessible video captions should:

Appear simultaneously to their relevant sound;
Convey the important audio information;
Appear on the screen for sufficient time for reading;
Have sufficient colour contrast between the background and text colour; and
Attribute text to a speaker, either descriptively or with the name of the speaker if they’ve shared it.

Video and Audio Transcripts

Transcripts are the result of the process of converting the video or audio to text and takes the form of a written document. When generating and providing video and audio transcripts it is important to:

Create a clear link to the transcript that is in an accessible format;
Place the link to the transcript adjacent to the video or audio;
Contains all speech content;
Includes information about the speech;
Includes pertinent non-speech audio; and
Contains graphical and textual information displayed in the video.

The World Wide Web Consortium’s Multimedia Accessibility FAQ article is a helpful reference for requirements as well as examples.

Refer to WCAG Guideline 1.2 Time-based Media to learn more about the requirements for accessible video.

OpenLearning has released an Accessible Video widget to allow course creators to add their own closed captions to videos. How do I use the Accessible video widget?

Audio Descriptions

Audio descriptions is a separate audio track created in addition to the audio in the video. It is an audio narration of the visual components of the video. When creating audio descriptions it is important to:

Appropriately describe the visual information in the video;
Be sure that the audio descriptions do not compete with speech or other sounds; and
Keep the descriptions short.

Refer to WCAG standard 1.2.3 Audio Description or Media Alternative (Prerecorded) to learn more about the requirements for accessible audio.

Page Titles

When naming pages, and even courses, in OpenLearning, it’s important to consider how people with disabilities will be able to understand the content of the page without additional context.

OpenLearning’s platform will consistently reference the site, which is a requirement for accessible pages, but there are best practices to keep top of mind while naming pages. These include:

Page titles should not contain full URLs or be in all-caps. Some screen readers will read each letter.
Page titles should be concise and descriptive.
Page titles should be unique. Repeating page titles, while convenient, can be extremely confusing; and
Page titles should not contain ASCII characters, with the exception of punctuation.

Refer to WCAG standard 2.4.2 Page Titled to learn more about the requirements for page titles.

Text Content

Writing accessible text content includes some obvious best practices, like correct spelling, but also imperatives like using inclusive word choice. OpenLearning ensures the DOCTYPE of pages is correct and that the default language is English. When producing accessible text content it is important to:

Avoid instructional information that uses visual descriptors, like ‘below’ or appearance like ‘circle’;
Avoid device-dependent terminology like ‘click’;
Spell all content correctly;
Create dates in a friendly format that is unabbreviated;
Make sure critical information isn’t conveyed with colour alone, shape alone or shading alone;
ASCII characters should not be used to convey meaning with the exception of punctuation; and
Avoid images of text. If they are imperative, use alternative text.

Refer to WCAG standards 1.3.1 Info and Relationships, 1.3.2 Meaningful Sequence, 1.3.3 Sensory Characteristics, 1.4.1 Use of Color, and 1.4.5 Images of Text to learn more about the requirements for accessible text content.

Headings

When structuring information on a page and conveying relative importance, it’s important to use Headings and not styled text, like bold, italic, etc. Using headings allows users to scan content effectively and understand the relationship between information.

When writing accessible headings it is important to:

Write headings in sentence case and spell them correctly;
Write concise and descriptive headings; and
Use next headings properly: H1, then H2, H3, etc.

Refer to WCAG standards 1.3.1 Info and Relationships and 2.4.6 Headings and Labels to learn more about the requirements for accessible headings.

Link Text

Writing clear and helpful link text is important for all learners, but is especially important for folks with disabilities. OpenLearning provides skip links for users to support accessible navigation. When writing accessible link text it is important to:

Use sentence case text;
Avoid using ASCII characters;
Write clear and descriptive text. Learners should have a clear understanding of where a link will bring them and why it matters;
Do not use just the URL;
Avoid device-dependent language. ‘Click here’ should not be used;
Avoid ‘more’ or ‘here’ without additional context;
Be careful not to style other text like link text; and
Test to ensure that links are not broken.

Refer to WCAG standards 1.3.1 Info and Relationships, 1.4.3 Contrast (Minimum), and 2.4.4 Link Purpose (In Context) to learn more about the requirements for accessible link text.