In the US, and your audience is federal employees, or people sub-contracted to Government agencies, how do you deal with 508 compliance when you have a video-only course, or video in a SL (or other) course?
With 508 Compliance, lots of the current documentation is hung up on checklists that tend to separate the goals of accessibility from the actions taken to get there. I don't really like the checklists approach. Don't get me wrong, the checklists are useful for validation but they can remove a step of humanization that I think is useful in building a good experience for everyone. Here's what I use. It's a question varied multiple ways:
How can we provide a good experience for folks with...
limited or no vision
limited or no hearing
limited mobility
cognitive disabilities
One thing that applies across the board is control over the video. Is it easy to pause, replay, rewind? Another approach is providing options to take in the information.
Vision Impairment
For video, think about the meaningful stuff that's transmitted in the video that might not be described in audio. How can we bring these to someone who cannot see or see the screen as a blur unless they zoom into a 50 pixel square? If the voice track carries much of the meaning, you're probably most of the way there for those with limited vision. If it doesn't carry all of the meaning, one way to ensure these folks have good options is to provide a transcript with visual descriptions in addition to closed captions. Especially if there's a lot of information or if there's something with a voice track that doesn't pause or slow for visual descriptions. Since the UI elements can't be seen by this audience, it's important to provide navigation and video control with the keyboard. Also, be sure that color isn't the sole conveyer of meaning to see to it that those with a color vision impairment aren't left out.
Hearing Impairment
This one is a little easier than the visual component. Closed captioning is a universal practice for accommodating those that don't have the benefit of hearing. One thing here is to provide a good experience for those that can't hear. This might mean adjusting the captions to provide a clearer message synced with the visual presentation than the audio might provide. This is particularly important if there's a lot going on in the presentation. The transcript described under vision above can also be helpful for those with a hearing disability. In the presentation, there might be quite a bit going on. Add in reading and tracking closed captioning and it can quickly become too much. Providing a transcript with visual descriptions lets someone read ahead of time then watch the presentation or vice-versa. Everyone works a little bit differently.
Mobility Impairment
This is all about simple and easy controls and providing complete control to the user. If the video requires twitch (fast responses) controls or doesn't provide a simple way to rewind, pause, play - it's going to be a painful experience. If there are timed responses (you have 20 seconds to answer) and it moves on - it's going to be a painful experience. As with the previous two, some with limited mobility will appreciate having a text alternative to take in at their own speed. More options can provide a better experience.
Cognitive Impairment
Dislexia and other processing impairments make it tough to take some things in at a normal speed. This category includes learning disabilities. The text alternatives can help here and some users will prefer to have something they can touch and read to gather the message at their own speed, take notes, etc..
The best way to validate your compliance approach is by testing with real users. Not many folks have this opportunity or think that they need to. Others will laser focus on the vision impairment and "works with a screen reader" while ignoring the other categories of folks they might run into. I've seen some folks avoid adding audio to a program simply because they think that means they will need to caption it. This short changes a big section of the audience and provides LESS accessibility than if they'd added audio.
These are some things that apply to video across the board:
Give the user control and make these controls easy to see and easy to use.
Watch cognitive loading over the course of the video (compressing a lot of stuff in a short period of time makes it tough for those that need to multi-task to track with the video)
Break videos into topical pieces and provide easy access to segments with a TOC where it makes sense to do so. This helps folks with all abilities form a mental model for the structure of the presentation.
Provide closed captioning. I prefer captions that can be turned off rather than burned into the video. Some with cognitive disabilities might have a tougher time processing video when there's more going on. Options are better in almost all cases.
Provide a transcript with visual descriptions. These can be helpful for all four impairment categories and some folks without impairments really appreciate the option to read, copy a portion of the transcript, make notes, etc..
Think like a disabled user might and "drop a sense" if you can (mute the audio, turn off your monitor, disconnect your mouse). If it's painful for you to experience or you are losing some of the meaning, chances are it'll be painful for those with a real impairment.
Test with disabled users if you can. An experienced screen-reader user will test an experience differently than you will. I would have judged many things a failure, where an experienced user thought it worked just fine. Just like folks without impairments, you'll find things people like across the board and preferences that will appear as outliers.
Every client will interpret the rules a little bit differently and lay out different requirements based on this interpretation. Not many have actually read the law and, unfortunately, tend to think that accessibility is all about the screen reader. One root of the law that Section 508 compliance is based on (where it gets its name - Section 508 of the Rehabilitation Act of 1973) is here.
"(iii) a failure to take such steps as may be necessary to ensure that no individual with a
disability is excluded, denied services, segregated or otherwise treated differently than other
individuals because of the absence of auxiliary aids and services, unless the entity can
demonstrate that taking such steps would fundamentally alter the nature of the good,
service, facility, privilege, advantage, or accommodation being offered or would
result in an undue burden; "
For training components, the last sentence is important. We see folks really straining to make a practice activity compliant for tasks that require certain abilities. So much so that they short circuit the intent of the activity. Information should always be universally accessible. It's not so cut and dried in the case of practice activities that support training. In some cases, attempting to make an activity universally accessible can completely change the nature of the service. If we tried to make a flight simulator completely accessible, it would no longer be a realistic simulation. It would be something else entirely Stuff to keep in mind.
This is very helpful, thank you! But it leads me to my question: How can users control the video in Storyline? On YouTube the space bar automatically pauses/plays the video, but that doesn't seem to work here. And I've tried adding triggers to pause or play the video based on the user pressing a key, but this seems to only work well if the video is on the base layer, and mine is not. When the video is in a different layer, it seems that the keyboard triggers only work if the user tabs to the video itself first, which I think is a deal breaker for me because it's not intuitive enough. I can't help but wonder if this is a bug, because it seems that the trigger should be enough to play or pause the video without having focus on the video (and again, it seems to work if it's on a base layer). The other alternative is creating objects on the screen that are hidden from sighted users for pause and play controls. It works, but it's clunky. Am I missing another option?
Ok, a colleague of mine figured out the keyboard issue! I was adding the shortcut keys as slide triggers, bit you have to select the video as the object. I would still love to see better 508 c controls for the video and audio players...
Many thanks for sharing your discovery, Kristen! And if you would like to share your thoughts for functionality you'd like to see made available, here is the form you would need to connect with our Product team.
This thread is a bit older, but I wanted to point you to the updated Storyline 2 information on accessibility and you may also want to review Storyline's Voluntary Product Accessibility Template (VPAT), see this article. As often certain elements to adhere to the guidelines are controlled by the author (presumably you) so you may want to review that.
As a Instructional Systems Specialist for the federal government I design and develop courses that must be 508 compliant. In your post you reference the updated Storyline 2 information on accessibility. When I read through the post it mentions:
" Storyline supports JAWS 16 and later with Internet Explorer 11 and later (Flash output only)."
Google, has announced they will no longersupportFlash by the end of the year and will only offer support for HTML 5.
Our agency utilizes Chrome as the standard browser for all of our courses.
Does Articulate plan on offering an update or an alternative for the flash output to handle accessibility issues that may no longer work in Chrome?
As I understand it JAWS only offers support for Internet Explorer (latest version), and our current support for screen readers is limited to JAWS. Although the NVDA screen reader will work with many aspects of Storyline content, it isn't officially supported at this time.
Additionally our current 508 support is for Flash only content. So although we support Chrome as a browser for Flash and HTML5, it's not currently supported with Jaws. We've heard a lot of talk about Chrome disabling Flash, and although that makes for a big headline you'll still be able to see Flash content in Chrome, just by default the browser will disable it. You can test out how your content behaves now by turning off Flash (you'll see some discussion of that here).
Although I can't offer a timeline or share our product road map, our team is well aware of the concerns and need for additional HTML5 support across multiple browser and enhanced accessibility support. We'll let you know once we've got news to share!
Hey I have a question about referring to videos. With 508 I know that they expect us not to use the wording, "Click on" or "Click here". How should we refer to a video on a slide? Should we say, "Select play to start the video." Or something else?
11 Replies
One thing that comes to mind is using "Descriptive Video" combined with Closed Captioning in SL.
See: http://en.wikipedia.org/wiki/Descriptive_Video_Service
and http://community.articulate.com/forums/p/14677/231662.aspx#231662
Hey Bruce -
With 508 Compliance, lots of the current documentation is hung up on checklists that tend to separate the goals of accessibility from the actions taken to get there. I don't really like the checklists approach. Don't get me wrong, the checklists are useful for validation but they can remove a step of humanization that I think is useful in building a good experience for everyone. Here's what I use. It's a question varied multiple ways:
How can we provide a good experience for folks with...
One thing that applies across the board is control over the video. Is it easy to pause, replay, rewind? Another approach is providing options to take in the information.
Vision Impairment
For video, think about the meaningful stuff that's transmitted in the video that might not be described in audio. How can we bring these to someone who cannot see or see the screen as a blur unless they zoom into a 50 pixel square? If the voice track carries much of the meaning, you're probably most of the way there for those with limited vision. If it doesn't carry all of the meaning, one way to ensure these folks have good options is to provide a transcript with visual descriptions in addition to closed captions. Especially if there's a lot of information or if there's something with a voice track that doesn't pause or slow for visual descriptions. Since the UI elements can't be seen by this audience, it's important to provide navigation and video control with the keyboard. Also, be sure that color isn't the sole conveyer of meaning to see to it that those with a color vision impairment aren't left out.
Hearing Impairment
This one is a little easier than the visual component. Closed captioning is a universal practice for accommodating those that don't have the benefit of hearing. One thing here is to provide a good experience for those that can't hear. This might mean adjusting the captions to provide a clearer message synced with the visual presentation than the audio might provide. This is particularly important if there's a lot going on in the presentation. The transcript described under vision above can also be helpful for those with a hearing disability. In the presentation, there might be quite a bit going on. Add in reading and tracking closed captioning and it can quickly become too much. Providing a transcript with visual descriptions lets someone read ahead of time then watch the presentation or vice-versa. Everyone works a little bit differently.
Mobility Impairment
This is all about simple and easy controls and providing complete control to the user. If the video requires twitch (fast responses) controls or doesn't provide a simple way to rewind, pause, play - it's going to be a painful experience. If there are timed responses (you have 20 seconds to answer) and it moves on - it's going to be a painful experience. As with the previous two, some with limited mobility will appreciate having a text alternative to take in at their own speed. More options can provide a better experience.
Cognitive Impairment
Dislexia and other processing impairments make it tough to take some things in at a normal speed. This category includes learning disabilities. The text alternatives can help here and some users will prefer to have something they can touch and read to gather the message at their own speed, take notes, etc..
The best way to validate your compliance approach is by testing with real users. Not many folks have this opportunity or think that they need to. Others will laser focus on the vision impairment and "works with a screen reader" while ignoring the other categories of folks they might run into. I've seen some folks avoid adding audio to a program simply because they think that means they will need to caption it. This short changes a big section of the audience and provides LESS accessibility than if they'd added audio.
These are some things that apply to video across the board:
Steve - that is wonderful, thanks buddy
Not exactly sure of the requirement yet, the client is checking, but this is VERY useful.
Thanks again.
Every client will interpret the rules a little bit differently and lay out different requirements based on this interpretation. Not many have actually read the law and, unfortunately, tend to think that accessibility is all about the screen reader. One root of the law that Section 508 compliance is based on (where it gets its name - Section 508 of the Rehabilitation Act of 1973) is here.
http://www.law.cornell.edu/uscode/text/29/701
Another is here. This describes the discrimination elements.
http://www.law.cornell.edu/uscode/text/42/12182
Specific reference:
42 U.S.C. § 12182(b)(2)(A)(iii)
"(iii) a failure to take such steps as may be necessary to ensure that no individual with a
disability is excluded, denied services, segregated or otherwise treated differently than other
individuals because of the absence of auxiliary aids and services, unless the entity can
demonstrate that taking such steps would fundamentally alter the nature of the good,
service, facility, privilege, advantage, or accommodation being offered or would
result in an undue burden; "
For training components, the last sentence is important. We see folks really straining to make a practice activity compliant for tasks that require certain abilities. So much so that they short circuit the intent of the activity. Information should always be universally accessible. It's not so cut and dried in the case of practice activities that support training. In some cases, attempting to make an activity universally accessible can completely change the nature of the service. If we tried to make a flight simulator completely accessible, it would no longer be a realistic simulation. It would be something else entirely
Stuff to keep in mind.
This is very helpful, thank you! But it leads me to my question: How can users control the video in Storyline? On YouTube the space bar automatically pauses/plays the video, but that doesn't seem to work here. And I've tried adding triggers to pause or play the video based on the user pressing a key, but this seems to only work well if the video is on the base layer, and mine is not. When the video is in a different layer, it seems that the keyboard triggers only work if the user tabs to the video itself first, which I think is a deal breaker for me because it's not intuitive enough. I can't help but wonder if this is a bug, because it seems that the trigger should be enough to play or pause the video without having focus on the video (and again, it seems to work if it's on a base layer). The other alternative is creating objects on the screen that are hidden from sighted users for pause and play controls. It works, but it's clunky. Am I missing another option?
Ok, a colleague of mine figured out the keyboard issue! I was adding the shortcut keys as slide triggers, bit you have to select the video as the object. I would still love to see better 508 c controls for the video and audio players...
Many thanks for sharing your discovery, Kristen! And if you would like to share your thoughts for functionality you'd like to see made available, here is the form you would need to connect with our Product team.
Hi Kristen,
This thread is a bit older, but I wanted to point you to the updated Storyline 2 information on accessibility and you may also want to review Storyline's Voluntary Product Accessibility Template (VPAT), see this article. As often certain elements to adhere to the guidelines are controlled by the author (presumably you) so you may want to review that.
Hi Ashley,
As a Instructional Systems Specialist for the federal government I design and develop courses that must be 508 compliant. In your post you reference the updated Storyline 2 information on accessibility. When I read through the post it mentions:
" Storyline supports JAWS 16 and later with Internet Explorer 11 and later (Flash output only)."
Google, has announced they will no longer support Flash by the end of the year and will only offer support for HTML 5.
Our agency utilizes Chrome as the standard browser for all of our courses.
Does Articulate plan on offering an update or an alternative for the flash output to handle accessibility issues that may no longer work in Chrome?
Hi Ryan,
As I understand it JAWS only offers support for Internet Explorer (latest version), and our current support for screen readers is limited to JAWS. Although the NVDA screen reader will work with many aspects of Storyline content, it isn't officially supported at this time.
Additionally our current 508 support is for Flash only content. So although we support Chrome as a browser for Flash and HTML5, it's not currently supported with Jaws. We've heard a lot of talk about Chrome disabling Flash, and although that makes for a big headline you'll still be able to see Flash content in Chrome, just by default the browser will disable it. You can test out how your content behaves now by turning off Flash (you'll see some discussion of that here).
Although I can't offer a timeline or share our product road map, our team is well aware of the concerns and need for additional HTML5 support across multiple browser and enhanced accessibility support. We'll let you know once we've got news to share!
Hey I have a question about referring to videos. With 508 I know that they expect us not to use the wording, "Click on" or "Click here". How should we refer to a video on a slide? Should we say, "Select play to start the video." Or something else?
This discussion is closed. You can start a new discussion or contact Articulate Support.