Accessibility Considerations in Constructing eClass Courses

Article Last Updated April 2020

This article describes best practices for ensuring eClass course content meets accessibility standards and has been provided by Accessibility Resources.

Update April 2020: As a part of the transition to remote class delivery in response to covid-19, the Center for Teaching and learning has provided the following suggestions for accessibility considerations specifically for synchronous lectures:

  • Enable Automatic Live captioning: This is available in Google Meet (turn on the CC feature at the bottom of your screen) and Stream2
    • When using another video chat platform, You may wish to use Google Slides and enable the live captioning feature within Google Slides. If you share your screen using Google Slides, your voice will be captured and live captions will appear. See Present Slides with Captions for more information.
    • Note that Zoom can have closed captions but requires someone to type these as the class is occurring. 
  • For students who are blind or have low visibility, narrate the material that you’re displaying visually on the screen. Just as you might read materials aloud in class, read screen material that you share on-screen just in case students are not able to see essential text.

eClass General Accessibility Performance

Moodle, the application running eClass, has a strong focus on accessibility. The default standard for Moodle content presentation is WCAG 2.0 - an internationally accepted standard for web accessibility developed by the World Wide Web Consortium (W3C), an international team of experts (beginning January 1, 2021, all public websites and web content must meet WCAG 2.0 Level AA.) For more detailed documentation on Moodle accessibility, see here.

Beyond the Basics

Instructors constructing courses on eClass should also consider accessibility when creating their content. Web pages are fundamentally designed to work for all people, whatever their hardware, software, language, culture, location, or physical or mental ability. When the Web meets this goal, it is accessible to people with a diverse range of hearing, movement, sight, and cognitive ability. The W3C provides 3 examples of areas where web sites have accessibility barriers:

  1. Images without alternate text
  2. Interactive features that operate by mouse only
  3. Audio files without text-based transcripts

The W3C also delivers the Web Accessibility Initiative (WAI) which brings together people from industry, disability organizations, government, and research labs from around the world to develop guidelines and resources to help make the Web accessible to people with disabilities including auditory, cognitive, neurological, physical, speech, and visual disabilities.

WAI Guidelines

    • Color is not used as the only way of conveying information or identifying content
    • Default foreground and background colour combinations provide sufficient contrast
    • Text is resizable up to 200% without losing information, using a standard browser
    • Images of text are resizable, replaced with actual text, or avoided where possible
    • Users can pause, stop, or adjust the volume of audio that is played on a website
    • Background audio is low, or can be turned off, to avoid interference or distraction
    • Pages have clear titles and are organized using descriptive section headings
    • There is more than one way to find relevant pages within a set of web pages
    • Users are informed about their current location within a set of related pages
    • There are ways to bypass blocks of content that are repeated on multiple pages
    • The keyboard focus is visible and the focus order follows a meaningful sequence
    • The purpose of a link is clear, ideally even when the link is viewed on its own

WAI Resources

(1 vote(s))
Helpful
Not helpful

Comments (0)