Tips for Making a 508 Compliant Course
Dec 30, 2019
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.**
- 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.
- 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.
- 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.
- 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.
- 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
- 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.
25 Replies
Thanks, Kristin! This is a wonderful reference.
Happy new year!
Happy New Year, Kristin! Thank you for this fantastic information!
Thank you so much. Just starting down this path in state government. Unfortunately, we don't have a JAWS reader (yet) but it seems that advocating for one for our team would be a good idea.
Great information! Thank you for sharing
Kristin - 508 Guidelines are substantial in 'compliance'. The full 508 listings of the required features might run 4 pages. When you say 508 compliance, are you addressing every feature or did you (your agency) have a selected sublist of features? I don't believe that Articulate is 100% compliant so which features were lost or not used? Any pointers for 508 responsive design for the mobile? Did you develop and test for the laptop/desktop and then published for the phone or did you do a separate build? Thanks.
Hi David. You are correct about 508 guidelines. As a government employee I'm pretty familiar with them, but it seems there is always more to learn.
Articulate provides this VPAT that indicates how they comply with Section 508 and WCAG guidelines. https://articulate.com/support/article/Articulate-Storyline-360-Is-Compliant-with-Section-508-Accessibility-Guidelines?_ga=2.23274803.848968587.1579024393-117516447.1579024393
The article I've written here does not address every feature of Storyline and how well it complies with 508 or WCAG guidelines (if that is what you are wondering). These are just a few things I've learned along the way. I haven't yet tested the mobile version of the course, as I'm still working on completing a draft, however, Storyline output optimizes the very same course for mobile, so in theory no adjustments are necessary and a separate build of the course is not necessary. Hopefully it's as smooth as that, but we'll see.
thanks for your quick response. A suggestion - take your existing course, cut it down to one small module and publish it for mobile. See if your resulting course can still pass your 508. Please tell us your results. Thanks again.
This is very useful, thank you very much.
Another good option for testing is the NVDA screen reader - this is a free screen reader that is actually used by more visually impaired people than JAWS these days. Storyline doesn't officially support it yet, but it should in theory work just as well, and I'm told Articulate has plans to support other screen reader programs than JAWS in the near future.
Great reference! This was helpful for me to learn all about PEAT! I had a video in one of our courses at a background that was an issue. It would be great if we could flag videos in the content library for these types of issues.
Thanks for this. We are currently doing a lot of work on AT compliance for our main client. I have one question. I think this is a recent problem, as I haven't noticed it before. When I run my Storyline 360 files through JAWS, it adds "button" to almost everything - titles, text boxes, shapes. It doesn't distinguish between buttons with states and triggers and other objects. This is really confusing, as it will read the title, add button and tell the user to press space to activate... but there is nothing to activate. Is this a bug or have I done something wrong?
For those wanting to build accessible courses, who still want to use drag-and-drop interactions, there is a way to do so (though it requires some work). I have described the process here:
https://community.articulate.com/discussions/articulate-storyline/build-an-accessible-drag-and-drop-interaction-in-storyline
Have you found any resolution to this? I assume you're using Chrome as we're seeing that too. Course title on each slide reads either as a graphic or a button.
Hi Noel,
We fixed this issue in a recent update. Are you using the latest version of Storyline 360? Here's an article on how to update Articulate 360 authoring apps:
https://community.articulate.com/series/articulate-360/articles/articulate-360-user-guide-how-to-install-launch-desktop-authoring-apps#update
If you are, and you're still seeing this same behavior I would suggest reaching out to our support team: https://articulate.com/support/contact.
You can even send them a copy of your course, and they can help you troubleshoot what might be happening here.
I hope this helps!
Can anyone give insight into how much more time is involved developing a 508 compliant course compared to an equivalent course that does meet the guidelines? I know there is obviously a learning curve to understand the guidelines and how to use the tools, but I'm wondering how much more hands-on development time, if any, it takes for a developer with experience creating 508 compliant courses.
Hi Andrea. We usually estimate a 508 compliant course at 200 hours for 1 hour of completed course time. This is a low-end estimate - if the course needed extensive interactions, scenarios, videos, etc., then we would estimate more. I hope this helps.
Hi Andrea. I'm a little surprised by Kristin's response, but my guess is that she is talking about courses that are very complex. I find that to add captioning, alt text and to clean up the tab order on a 15 minute course with a couple of quizzes (but no videos) often takes me a full day. It always surprises me that it takes that long for a short course, but somehow it always does. I hope that helps.
My response is regarding creating the complete course, not just adding 508 compliance.
Thank you Joyce, that is helpful.
That insight is helpful Kristin, and thanks for the clarification on the 200 hours being for a complete course. If you don't mind me asking, what do you estimate for 1 hour of completed course time for a course that does not need to be 508 compliant?
My apologies for a slow response. I estimated about 20 hours for 508 compliance for the two-hour course I'm working on. Therefore, roughly 380 hours for the two-hour course without adding 508 compliance.
For context, though, there are a number of things that can extend the time in my organization. Sometimes there are a lot of people involved, which creates more review cycles and more changes.
I'm a member of the Association for Talent Development. A couple of years ago I know they estimated something like 140 hours for one hour of completed course time for a complex course. I don't think they included 508 compliance but I'm not sure. Also important to note that if you are not familiar with 508 compliance, it will take longer, whereas once you are familiar with it, things will likely go faster. I hope this helps.
Regarding e. -- I haven't tested on JAWS, but NVDA definitely allows up-down arrow navigation. I think it gives a cleaner read of the slide material.
I concur with Pierre about e., Kristin. Granted, Articulate has come out with changes for accessibility in the past two years.
These days, in my experience with NVDA and Storyline courses, the Tab key is only for navigating interactive elements, such as buttons, tabs, links, and so on (browse mode). Once virtual (not visible) focus lands on the slide (e.g., via the "skip navigation" button), NVDA announces the title of the slide, and then you can use the various arrow key combinations, such as Insert + Down Arrow in NVDA, to read all of the contents on the slide that are included in reading order (reading mode). As I understand it, this is expected behavior for keyboard navigation with NVDA. Not sure how this works with JAWS, but if Articulate has programmed the output correctly, it should work in a manner that JAWS users would expect.
One way to find out how a given screen reader is really supposed to interact with a web-based deliverable is to go to a website you already know is accessible, such as WebAIM or https://www.w3.org/WAI/ and attempt to navigate it using your keyboard and screen reader.
Hope this helps someone!
Hi Lisa and Pierre, thank you for the feedback. This article was written about two years ago, and at that time you couldn't use the arrow keys to navigate a course while using JAWS. That has since changed, and I should probably update the article to reflect all of the wonderful updates that have happened in Storyline over the last two years. I may also request that these posts have dates attached. I can't tell you how many times I've searched the forums to find an "answer" only to realize the post is from seven years ago. C'est la vie.
Screen readers read out specific instructions for radio buttons and checkboxes. Inform participants that the up/down arrow keys are disabled and explain how to interact with these elements using the spacebar. Ensure that the selected state of radio buttons is clearly indicated to avoid confusion.