Tips for Making a 508 Compliant Course

I recently made my first course for the US Federal Government using Storyline 360, who requires all courses be 508 compliant. Here are some things I learned about compliant courses that I thought others may find useful. I've attached a Word doc of this content as well. 

**Please note that although I am an employee of the U.S. Federal government, nothing in this article should be taken as government recommendations or mandates.**

1. Using a screen reader.

a.       If at all possible, download JAWS or another screen reader to test your course. I had never used a screen reader, and it makes a HUGE difference in understanding how someone who is visually impaired might interact with the course.

b.       Listen to every word the screen reader reads. Note that it may read out things you didn’t expect. For example, if I type “Department of the Interior (DOI),” JAWS reads “Department of the Interior left paren doy right paren.” It reads “DOI” as a word, and it also reads out that there are parentheses. This is distracting to a course participant, so if you can adjust your alt text to accommodate that, all the better.

c.       Storyline 360 places an invisible “button” on each screen, just prior to the “PREV” and “NEXT” buttons. That button is read by screen readers as “Skip Navigation,” and if clicked it will allow the participant to go back to the beginning of that slide and tab through it all over again. This is NOT clear in the title “Skip Navigation,” so when you are creating your course instructions be sure to add that information for anyone who is visually impaired.

d.       If you have a menu in your course, JAWS, and maybe other screen readers, will read the menu on every single slide. This is repetitive and annoying for a participant. It’s not a bug in Storyline, it’s just the way JAWS works, so keep that in mind. I’ve currently chosen not to use a Menu, but I may be required to change that in the future.

e.       Many JAWS users (and perhaps users of other screen readers) prefer to navigate through anything JAWS is reading using the up/down arrow keys on the keyboard. This allows them more control. They can have text read one word at a time, or even one letter at a time if they are struggling to really hear and retain what the reader is reading. However, Articulate (and as far as I can tell Adobe) disables navigation via the up/down arrow keys. They force the user to navigate via tabbing. This is less than ideal but can be worked around by ensuring your text is short and uses plain language. This article also has some good suggestions: https://articulate.com/support/article/Storyline-360-How-to-Design-an-Accessible-Course

f.        If you’ve got a quiz on the screen, or another interaction using radio buttons, JAWS will read out the content, and then “Radio button not checked, 1 of 3, to change your selection, use the up or down arrow” (If you’ve got 8 radio buttons on the page, JAWS will read 1 of 8, 2 of 8, etc.). JAWS does not know that the up/down arrow keys are disabled, so you have to tell your participants that at the beginning of the course. In my course, I have a graphic at the beginning that shows how to navigate the course, and the alt text contains all the instructions for anyone who is visually impaired.

g.       Along with the above, if the participant presses the Spacebar on their keyboard to select a given radio button, JAWS will read out “Space.” It does not indicate that the radio button has been selected, and so the JAWS user must tab to the next item, Shift+Tab to go back, listen to the radio button content again, and then JAWS will say “Radio button checked.” It’s deeply annoying for someone who is visually impaired. For whatever reason, this does NOT happen with checkboxes. For Checkboxes, JAWS will read the content, and then “Checkbox not checked, to check press Spacebar.” Once the participant presses the Spacebar, JAWS will read out “Space. Checked.” Not sure if this is because of the way I built the different interactions, or if it’s an issue with Storyline.

h.       JAWS will add the word “button” if the object it is reading is a button. So, your alt text could say “Continue” and JAWS will add “button.” If your alt text says, “Continue button,” JAWS will read out “Continue button button.” JAWS will also add the word “graphic” after any images, but my compliance expert (who is visually impaired) asked that I just remove any reference to images that are purely decorative. This reduces the “noise” while the visually impaired participant is going through the course.

1. The U.S. Federal government has a free accessibility and compliance checking tool called ANDI, and I think it’s available to anyone. It’s not a full software program, but a “favelet” you install in your browser to check compatibility on a web page. If you want to give it a shot you can find it here: https://www.ssa.gov/accessibility/andi/help/install.html. If you have trouble or can’t install it I’m afraid I can’t help you, but there is a help page you can refer to.
2. If you want to check the colors you are using in your course to make sure they are compliant, here is a handy free tool: https://webaim.org/resources/contrastchecker/. You just enter your foreground color (likely your text) and your background color and WebAIM will tell you what the contrast ratio is. The US government requires a contrast ratio of 4.5:1, but I shoot for 7:1, which is the WCAG AAA contrast ratio.
3. The University of Maryland has developed the Photosensitive Epilepsy Analysis Tool (PEAT) you can use if you’ve got flashing, animation, or video in your course. https://trace.umd.edu/peat. They are clear that this tool is NOT to be used for commercial purposes, so be aware of that.
4. The U.S. government has developed some guidelines you can use if you’ve got questions about section 508 accessibility. This link is to the Guide to Accessible Web Design and Development but will work for any online courses. https://www.section508.gov/content/guide-accessible-web-design-development
5. Drag-and-Drop and Hotspot interactions are not 508 compliant. I also had trouble when using a Marker as an interaction. What I experienced was that someone who is visually impaired and using the tab key to navigate the course could select each marker and read the content, but the state of the marker was not then changed to “visited” (or whatever you’ve set it to be). This was problematic for me because the NEXT button did not become available until you’d visited all markers on the screen, and so the visually impaired participant was stuck forever on that page. It’s possible there are ways to fix it, but I ended up changing the markers to buttons which had the same effect I wanted.

I hope this helps. If you’ve got your own tips, please add them! I’ve still got a lot to learn.