Implementation and testing 508 Compliance standards of eLearning courses

Creating accessible eLearning content using ADA 508 Compliance & WCAG 2.0 Standards:

In the previous blog post, we discussed how to create a 508 compliant eLearning module. Here we will further look into how we can make the learning journey better for disabled users and check out some of the testing tools which we can use to test our eLearning content’s compliance.

This document lists all the steps and processes to create a 508 compliant eLearning module. We will walk through the steps by discovering what we did with an eLearning module to create it accessible and what we should know before converting or developing content to accessible standards.

Section 508 Testing:

The Department of Homeland Security (DHS) Office of Accessible Systems & Technology (OAST) has a mission to provide strategic direction, technical support, and training to ensure agency employees and customers with disabilities have equal access to information and data. Section 508 of the Rehabilitation Act of 1973, as amended (29 U.S.C. 794d), requires all federal departments and agencies to ensure that their information and communications technology (ICT) is accessible to people with disabilities.

Part 1: What you need to know before making your content accessible

There are two types of testing methods for 508:

Baseline tests:

In an effort to improve Section 508 testing across government, the “Harmonized Testing Process for Section 508 Compliance: Baseline Tests for Software and Web Accessibility” was developed as part of a collaborative project between accessibility teams at the US Department of Homeland Security (DHS) and the US Social Security Administration (SSA).(1)

There are 28 baselines tests to check conformance with WCAG 2.0 standards. View resources at the end to view them.(1)

Trusted Tester Process:

DHS used baseline tests to develop the Trusted tester process (version 3). Both the Baseline and DHS Trusted Tester test process were identified as best practices by the Federal Chief Information Officers Council Accessibility Community of Practice.(2)

Part 2: Creating accessible web content

Step 1:

For Lectora, click on DESIGN, then Project Options, then turn on the Use Web Accessibility Settings.
Selecting this will enable 508 compliance features in this project. This is the first step to create a 508-compliant course. 

For Captivate, click on Edit > Preferences > Project > Publish Settings and check Enable Accessibility.

For Storyline360, open your project player properties and mark the Accessibility controls box. It’s checked by default for new projects to encourage authors to have an accessibility-first mindset.

Step 2:

Use correct and identifiable names for the project, chapters, sections and pages/slides. Each object within pages/slides should be named correctly. 

Step 3:

Proper alt tags should be given to important media and images when it is required. Important media is the useful content of the slides. Images which only compliment the design and convey no information can be left without alt tags unless specified otherwise.

Step 4:

Create proper reading order of all items in the timeline within a slide so screen readers can access content in the correct sequence.

Step 5:

If there is any audio in the slides, it should have closed captioning. There must be buttons available to play/pause, show/hide CC, change volume and mute audio.

These are the basic steps required for creating accessible courses.

Part 3: Testing and reporting your 508 compliant course

We can test our web courses with multiple methods using multiple methods below but before we need to discuss main points of all testing methods.

  • Ensure all steps of Part 2 are completed. Test each module after completing to check if each step is covered. If all is correct, your main 508 compliance testing is done. Now we need to create reports. 

After making the content web accessible, we need to test everything before deploying content to LMS.

Testing and Reporting:

  • Use screen readers to check whether your text content is available to be read by a screen reader. Multiple screen readers are available for Windows and macOS. Windows even has a built-in screen reader Microsoft Narrator. Each screen reader performs the same function. Read screen text aloud and provide an auditory description of buttons and user interface material on your screen. Some of the screen readers you can check out are:
    • JAWS
    • NV Access
    • Google chrome’s Screen Reader
  • Check whether useful images’ alt text is available to a screen reader. Open a course slide, enable screen reader on chrome, click on any useful image. Check whether alt text is read out loud or not. 
  • Safari has its own built-in screen reader. Chrome has a built-in audio to Captions tool. Use both to check if course audio is detected.
  • DHS website has multiple reporting methods available on their site. Some of which are:
    • ACRT testing and reporting method
    • ANDI Accessibility checking tool
    • Trusted Tester v4.0 reporting pre-built excel file

Sources:

  1. https://www.dhs.gov/sites/default/files/publications/Baseline_Tests_for_Software_and_Web_Accessibility_v2_0_2.pdf
  2. https://www.dhs.gov/trusted-tester