Using UDOIT to Increase Online Course Accessibility in Canvas LMS
By Shalin Hai-Jew, Kansas State University
Figure 1: The Open-Source UDOIT Accessibility Scan Tool in Canvas LMS at K-State
Those teaching online have long struggled with federal guidelines requiring that the courses that they teach be accessible. What this usually meant was a difficult review of the online learning contents and the necessary retrofitting work (or removal of the inaccessible digital objects).
- Were all audio and video transcribed with timed text or closed captioning?
- Do all images (in slideshows, in stand-alone usage, and others) have alternate text (alt-text) that is informationally equivalent to the image contents?
- Are HTML data tables properly labeled for clarify when read by a screen reader?
- Are all simulations and videos controllable by users in terms of pacing and replay?
- Are all learning objects controllable and learning sequences navigable by keyboard and keyboard shortcuts? And others.
The idea is to provide multi-modal approaches to all learning contents to reach the widest range of learners based on perception and symbolic processing (like reading). Further accessibility aspects may include designing for diversity and inclusiveness—by considering learning preferences, culture, language, and other aspects of the learning. A simpler version is available on Adobe Spark.
UDOIT (as in “you do it”)
UDOIT (Universal Design Online content Inspection Tool) is an open-source and free software that is an add-on to the Canvas LMS (Instructure). This was created by Jacob Bates (project lead), Eric Colon, Fenel Joseph, and Emily Sachs, at the University of Central Florida from 2014 – 2015. It was released to the UCF faculty in May 2015 and to the general public in June 2015 (Swenson, 2015). This tool enables an automated scan of all or any combination of the following: announcements, assignments, discussions, files, pages, syllabus, and module URLs. According to the in-tool documentation, the software is designed to identify the following:
- links without explanatory text
- missing alt text from imagery
- no image filename in the alt text (not the default)
- missing alt text from image (img) elements used as source anchors
- missing table headers
- missing row and column scope declarations from table headers (which are needed to make an HTML data table coherently readable using a screen reader)
- insufficient color contrast between a text and the background
- missing transcripts for multimedia objects.
Beyond those main focuses, there are suggestions in the in-software documentation:
- to avoid the uses of animated GIFs (particularly those with strobe effects),
- to limit content length to 3,000 words (for chunking),
- to ensure that text equivalents should update when contents change,
- to avoid using multimedia that requires plug-ins (digital objects that play natively in web browsers are preferred because they involve less hassle),
- to use headings and other explicit and defined elements to create document structure (vs. using styles for document structure), and others
To run UDOIT, one generally has to find it in the left menu. Select the desired content to be scanned. (The default is “all.”) Then, click “Run scanner.” Do not navigate away from the page while the scan is being achieved. Once the scan is done, there is a short report about what the system found…and then it is time to use the UFIXIT.
Figure 2: Calling out Internal Features of Canvas LMS
One early and unwelcome surprise is that various elements of the Canvas LMS itself have been called out as being inaccessible. Certain glyphs and buttons have insufficient or no alt texting. This is not something that is particularly helpful to those teaching online because this means that the system itself is not considered accessible. It would be easier to have the system set to be accessible…and the UDOIT set to not deal with the innards of the Canvas LMS.
Also, at least in our local install, the PDF report printing does not work.
Ideally, the UDOIT would provide clear analysis and a one-stop place to fix the issues. After all, there can be a master course created that can be used again and again…as long as it is to quality and updated.
Another shortcoming is that the updates are to Canvas contents. While the courses are easy to download and re-upload and to transfer, if the learning objects are used in other contexts, they will not necessarily have the included updates. For example, if there is work on alt-texting a PowerPoint slideshow, the original PowerPoint would benefit by having the alt-texting available at the image level or the slide level. Inside the LMS is the HTML version of the slideshow, and any changes are made to the HTML code there. Ideally, accessibility should ride with the lowest common denominator, at the object level.
What the Scan Does Not Cover
It is important to note that UDOIT does not capture whether the writing is in simple and clear English. It does not capture information accuracy. It does not capture whether videos hosted elsewhere have transcription. It has no capability to ensure that live events are accessible.
It is important to note that the developers of the tool and the open-source developers who’ve come alongside them are working on other features. There is work on an “updated color picker,” more UFIXIT features, reporting statistics, and others (Swenson, 2015).
Building Accessibility in at the Beginning
In terms of an instructional design point-of-view, it is better to build accessibility in at the beginning, from the planning phases onwards. It helps to budget the time and expertise for accessibility work (whether the model is a universal design one or not). It is critical to develop accessible learning—alt texting images, auto-transcribing videos (with Google’s YouTube and downloading the .srt files), and so on—from the start…and head off the potential cost of retrofitting later. Often, when accessibility is a requirement early on, this does not feel like extra work.
Accessibility Guidelines advisement at K-State:
- File contents in digital files and websites should be keyboard accessible for access and navigation. (Non-keyboard input devices require the uses of keyboard shortcuts to interact with the computer.)
- Use course file types in universal product formats. (Ideally, many are going to open-source formatting for the highest level of access. Proprietary software formats may be affected if companies go out of business or change ownership, etc.)
- Ensure that digital files are human accessible and machine-readable.
- Properly name digital documents for informational value. Structure text documents; show which texts are headers, subheaders, body text, and so forth. Structure indicates how a text document should be understood.
- Use clear, simple English. (Online-accessible language translators do best with simple language, especially given the polysemous nature of language.)
- Label informational graphics with “alt text.”
- Transcribe and label audio and video. Ensure that those who have hearing issues or visual issues can still access contents.
- Make accessible PowerPoint™ slideshows. Use the inherent text structure in PowerPoints. Add alt texting to images included in PowerPoints. Add transcription to included audio and video.
- Use color in an accessible way. Use text labels in addition to color.
- Summarize and label data tables. This is to ensure that data tables keep their coherence even if they are being used through screen readers.
- Support user control of automations and sequenced actions, as much as possible. Allow user control of time. Use time limitations reasonably and possibly even sparingly for assignments and assessments.
- Plan live, online events to be accessible. Enable access through lead-up and lead-away activities. If possible, include live transcription, narrated drawing, and / or notetaking.
Having the ability to find relevant issues within a Canvas course…and being able to address them intelligently is important. In the current state, though, UDOIT would require a fair amount more work to make it sufficiently nuanced and finessed to be relevant in this critical endeavor. This tool may benefit from feedback from users, so the tool does not evolve in isolation. Some of the accessibility settings seem somewhat arbitrary (3,000 words per page only, alt text at 100 words minimum?).
The acronym for this tool is well conceptualized, with the tone understood as an encouraging one, full of self-efficacy and get-up-and-go! However, UDOIT can also be read as: “I don’t feel like it. You do it!” Ideally, this tool should lean towards the first tone and not the latter. Right now, based on functionalities alone, it may sound more like the latter.
Swenson, N. (2015). UDOIT – Instructure Canvas Course Accessibility Checker. University of Central Florida – Center for Distributed Learning. http://accessinghigherground.org/wp/wp-content/uploads/2015/05/AHG_2015_Swenson_UDOIT_virtual_thurs.pdf.
UDOIT. (2017). GitHub. https://github.com/ucfopen/UDOIT.
UDOIT Canvas Community. (2017). https://community.canvaslms.com/ideas/3651.
About the Author
Shalin Hai-Jew works as an instructional designer at Kansas State University. Her email is firstname.lastname@example.org.
|Previous page on path||Cover, page 16 of 26||Next page on path|