I'm interested to learn more about creating 508 compliant (or as close to it as possible) courses. Anyone out there creating courses to meet these guidelines? Willing to share? Would love to learn more.
I found the document that Nancy recommended to be amazing. I recently built a course with accessibility in mind and after reading the 6 Best Practices document I realized I made a lot of mistakes:-) It was a great lessoned learned document.
Ok, so I do have a question...I did build in keyboard navigations for each slide, but did it on a slide by slide basis...I just figured out after poking around that an easier way would have been to build these triggers in the slide master. I just gave it a try (in a new project) and it doesn't seem to want to work for me. I added a Slide Trigger to each layout in the slide master that would jump to the next slide when the user presses the right arrow key. It only seems to work on the title slide.
Hi Christie, I realize the keyboard navigation restrictions, that's why I built my own triggers. My real question is can I build keyboard navigation into a slide master so the trigger is applied by choosing a layout as compared to adding the trigger to each slide individually?
Hi, Scott - Thanks for the clarification. You would be able to add a navigation button, like a 'Next' button into the Slide Master, but the trigger set up like "jump to next slide" will not be able to be changed on slide level, so you would only want to use that if all the slides' navigation will be the same. Does that help?
You can certainly control flow with the keyboard from the master slide. Even if the flow from the base slide changes beyond the logical next slide.
One caveat to keyboard controls. Screen readers will eat up a lot of the available keys. So be sure you look at the JAWS keyboard layout and adjust what you want to do accordingly.
Here's how I would use the keyboard capture from the master slide and echo that to the base slide. The advantage here is you can configure your keys in one place and change them in one place if you need to at a later time.
Setup number variables for each function you want to trigger with the keyboard (goNext, goBack)
Setup triggers on the master slide that increase these variable values by one whenever the selected key is pressed.
On your base slide, setup a trigger to "listen" for a change in your goNext variable. When the variable changes goNext, jump to slide X.
The neat thing about this "remote control" method is you can use the same variable through a button control, through a javascript trigger, pretty much from anywhere. The slide trigger doesn't care how the variable changes.
Hi Steve. Thanks for the insight on keyboard controls and their 0availability in JAWS. That tip alone was invaluable.
I think I'm still missing something. I'm testing this out on a new project and I've set up the two variables that you recommended. I set up a trigger on the top level Master slide the adds 1 to goNext when the user presses the Right key (I did the same for goBack...except for the left key). I closed the Master View, added a few slides and added a trigger to each slide "Jump to next slide When goNext changes". When I run through the preview the first slide pops up and I press the right arrow key and it works. On the second slide I have no luck. I went back into the slide master and added the same variable trigger to each layout option just incase that was the issue.
Any further assistance would be greatly appreciated. I feel like I'm close:-)
Generally, as nice as having keyboard control would be, we have found that using them only leads to problems with Screen-readers. Jaws will use most of the keys, NVDA will also take control of key input to a large degree. You're left with the option of using key-combinations; Alt+Shift+Next, etc. Far better to concentrate on clear navigation- specifically good use of Alt Text and tabbing order (thank you storyline2 update 5!!). Remember that you're not only catering for Visually impaired users when you add keyboard navigation but also those with limited motor skills or physical disabilities that would make key-combos quite inaccessible.
All that being said, there is no reason not to include keyboard navigation- I am certain that there are users who would benefit from it.
This has become even a more important topic than usual since the ADA Sect. 508 guidelines have been updated just recently (Mar/Apr 15') - the two most important changes are you now have to meet minimum WCAG (Web Content Accessibility Guidelines) 2.0 requirements, previously it was WCAG 1.0 which was much easier to comply with. The second problematic issue for us as developers/designers is now any digital document content you provide (resources, etc.) they MUST be in an accessible Adobe PDF format, so goodbye to word docs, or any other sort of "take away" materials.
I can't speak for ALL Government agencies effected by ADA 508, but at least from the DOD CIO office, they do NOT expect everyone to run out and redo their courseware products, but if it's not fully compliant with current guidelines, you MUST be able to provide an alternative accessible format document in its place. For us that has meant taking all the narration scripts, and storyboard content, converting it to an ASCII text format, add in appropriate long descriptions of images and media and call it a day. Is this the best solution, of course not, but when you have a highly interactive course or serious game/sim you're not going to be able to accommodate all the WCAG 2.0 guidelines, so just letting folks know that, at least as far as the DoD and OPM was concerned, in those instances if you provide a accessible alternative you've met the intent and spirit of the regulation. Hope that helps a bit. I will go find more links to the latest updates and post them for reference as well.
Good info, Kurt. I hadn't seen the accessible PDF in lieu of Word documents in any of the standard references. Do you have a pointer for that? Or is it just a DoD practice? It does make sense, in a way.
There's still a lot of conflicting info out there on how Section 508 maps to WCAG 2.0. Some references say WCAG 2.0 AAA is equivalent to Section 508. I haven't gleaned this interpretation. The closest are mappings I've found are A and AA. Some of WCAG 2.0 doesn't have a Section 508 mapping that I can find.
Here's the most concise comparison that I've found:
WCAG 2.0 is a good step forward both in clarity and focus. Section 508 tended to boil down to a checklist where folks looked at specific characteristics rather than applying insight to how folks would actually experience the content. A disproportionate amount of energy was usually placed on making content accessible to screen readers. WCAG 2 changes this focus a bit. A welcome change.
Yes and no, it isn't just DoD, it was like an addendum onto the ADA 508 change, but it still has the same power of law as Sect. 508 does. I'm at home now, at work I get all the "gee wiz" government message traffic, which is where all my information came from. As you mentioned in passing, it IS a good idea, and Acrobat Pro easily outputs the accessible format, and using PDFs for all take away resources is just good practice. I'll make sure to update these posts with the relevant links as soon as I get into work on Monday (Tomorrow). WCAG 2.0 is definitely more definitive, but that's the proverbial double-edged sword, for the ambiguities of WCAG 1.0 in some cases covered our butts. WCAG 2.0 is much broader in scope, taking into account many of the changes in technology that didn't even exist when WCAG 1.0 came out. As this change has more wide spread impact, I'm sure the vendors will follow suit to address it as well, but until then, we as developers have to make sure our clients or employers are covered, one way or another.
I just saw the message about update 5 to Storyline 2, and what do you know, it has WCAG 2.0 support and added accessibility features... it's great when a plan comes together....grin. So, all in this thread go get your release 5 version now, and appease the ADA 508 powers that be. (thunder crash, rumble, rumble....)
22 Replies
Hi, Annette -
While I am not an expert on 508 Compliance, I wanted to share information on a few different threads that may be of assistance:
Thank you!!!!!
You're welcome, Annette! Hope it helped! :)
Yes, thank you!
Hi Annette, Articulate has recently published an e-book on designing for accessibility which should be of help.
https://community.articulate.com/e-books/6-best-practices-for-designing-accessible-e-learning
Great addition, Nancy - thank you! :)
I found the document that Nancy recommended to be amazing. I recently built a course with accessibility in mind and after reading the 6 Best Practices document I realized I made a lot of mistakes:-) It was a great lessoned learned document.
Ok, so I do have a question...I did build in keyboard navigations for each slide, but did it on a slide by slide basis...I just figured out after poking around that an easier way would have been to build these triggers in the slide master. I just gave it a try (in a new project) and it doesn't seem to want to work for me. I added a Slide Trigger to each layout in the slide master that would jump to the next slide when the user presses the right arrow key. It only seems to work on the title slide.
Any thoughts?
Hi, Scott - As my knowledge of 508/keyboard navigations is limited, I will defer to the community here for assistance.
Hi Christie, I realize the keyboard navigation restrictions, that's why I built my own triggers. My real question is can I build keyboard navigation into a slide master so the trigger is applied by choosing a layout as compared to adding the trigger to each slide individually?
Hi, Scott - Thanks for the clarification. You would be able to add a navigation button, like a 'Next' button into the Slide Master, but the trigger set up like "jump to next slide" will not be able to be changed on slide level, so you would only want to use that if all the slides' navigation will be the same. Does that help?
Ahh..so objects in the slide master yes, keyboard triggers no. Gotcha. Thanks for the reply Christie.
Certainly, Scott! :)
Hi Scott -
You can certainly control flow with the keyboard from the master slide. Even if the flow from the base slide changes beyond the logical next slide.
One caveat to keyboard controls. Screen readers will eat up a lot of the available keys. So be sure you look at the JAWS keyboard layout and adjust what you want to do accordingly.
Here's how I would use the keyboard capture from the master slide and echo that to the base slide. The advantage here is you can configure your keys in one place and change them in one place if you need to at a later time.
The neat thing about this "remote control" method is you can use the same variable through a button control, through a javascript trigger, pretty much from anywhere. The slide trigger doesn't care how the variable changes.
Many thanks for your knowledge and input, Steve! :)
Hi Steve. Thanks for the insight on keyboard controls and their 0availability in JAWS. That tip alone was invaluable.
I think I'm still missing something. I'm testing this out on a new project and I've set up the two variables that you recommended. I set up a trigger on the top level Master slide the adds 1 to goNext when the user presses the Right key (I did the same for goBack...except for the left key). I closed the Master View, added a few slides and added a trigger to each slide "Jump to next slide When goNext changes". When I run through the preview the first slide pops up and I press the right arrow key and it works. On the second slide I have no luck. I went back into the slide master and added the same variable trigger to each layout option just incase that was the issue.
Any further assistance would be greatly appreciated. I feel like I'm close:-)
Generally, as nice as having keyboard control would be, we have found that using them only leads to problems with Screen-readers. Jaws will use most of the keys, NVDA will also take control of key input to a large degree. You're left with the option of using key-combinations; Alt+Shift+Next, etc. Far better to concentrate on clear navigation- specifically good use of Alt Text and tabbing order (thank you storyline2 update 5!!). Remember that you're not only catering for Visually impaired users when you add keyboard navigation but also those with limited motor skills or physical disabilities that would make key-combos quite inaccessible.
All that being said, there is no reason not to include keyboard navigation- I am certain that there are users who would benefit from it.
Your input is appreciated, Lewis! :)
Hi All,
This has become even a more important topic than usual since the ADA Sect. 508 guidelines have been updated just recently (Mar/Apr 15') - the two most important changes are you now have to meet minimum WCAG (Web Content Accessibility Guidelines) 2.0 requirements, previously it was WCAG 1.0 which was much easier to comply with. The second problematic issue for us as developers/designers is now any digital document content you provide (resources, etc.) they MUST be in an accessible Adobe PDF format, so goodbye to word docs, or any other sort of "take away" materials.
I can't speak for ALL Government agencies effected by ADA 508, but at least from the DOD CIO office, they do NOT expect everyone to run out and redo their courseware products, but if it's not fully compliant with current guidelines, you MUST be able to provide an alternative accessible format document in its place. For us that has meant taking all the narration scripts, and storyboard content, converting it to an ASCII text format, add in appropriate long descriptions of images and media and call it a day. Is this the best solution, of course not, but when you have a highly interactive course or serious game/sim you're not going to be able to accommodate all the WCAG 2.0 guidelines, so just letting folks know that, at least as far as the DoD and OPM was concerned, in those instances if you provide a accessible alternative you've met the intent and spirit of the regulation. Hope that helps a bit. I will go find more links to the latest updates and post them for reference as well.
Good info, Kurt. I hadn't seen the accessible PDF in lieu of Word documents in any of the standard references. Do you have a pointer for that? Or is it just a DoD practice? It does make sense, in a way.
There's still a lot of conflicting info out there on how Section 508 maps to WCAG 2.0. Some references say WCAG 2.0 AAA is equivalent to Section 508. I haven't gleaned this interpretation. The closest are mappings I've found are A and AA. Some of WCAG 2.0 doesn't have a Section 508 mapping that I can find.
Here's the most concise comparison that I've found:
http://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/background/comparison-table-of-wcag2-to-existing-508-standards
WCAG 2.0 is a good step forward both in clarity and focus. Section 508 tended to boil down to a checklist where folks looked at specific characteristics rather than applying insight to how folks would actually experience the content. A disproportionate amount of energy was usually placed on making content accessible to screen readers. WCAG 2 changes this focus a bit. A welcome change.
Hi Steve,
Yes and no, it isn't just DoD, it was like an addendum onto the ADA 508 change, but it still has the same power of law as Sect. 508 does. I'm at home now, at work I get all the "gee wiz" government message traffic, which is where all my information came from. As you mentioned in passing, it IS a good idea, and Acrobat Pro easily outputs the accessible format, and using PDFs for all take away resources is just good practice. I'll make sure to update these posts with the relevant links as soon as I get into work on Monday (Tomorrow). WCAG 2.0 is definitely more definitive, but that's the proverbial double-edged sword, for the ambiguities of WCAG 1.0 in some cases covered our butts. WCAG 2.0 is much broader in scope, taking into account many of the changes in technology that didn't even exist when WCAG 1.0 came out. As this change has more wide spread impact, I'm sure the vendors will follow suit to address it as well, but until then, we as developers have to make sure our clients or employers are covered, one way or another.
I just saw the message about update 5 to Storyline 2, and what do you know, it has WCAG 2.0 support and added accessibility features... it's great when a plan comes together....grin. So, all in this thread go get your release 5 version now, and appease the ADA 508 powers that be. (thunder crash, rumble, rumble....)
Thanks so much for the update, Kurt. :)
This discussion is closed. You can start a new discussion or contact Articulate Support.