I am looking to get clarification from staff or community members who have used Storyline 3 or Articulate 360 to create accessible content.
My question is pretty straightforward and is being asked because I have a stakeholder who is adamant that SL3 and Articulate 360 cannot create WCAG compliant content!
I have read the articles and resources in the community and elsewhere but I would pretty much like it from the horse's mouth.
Are SL3 and Articulate 360 able to create WCAG compliant content?
SL3 and Articulate 360 are compliant. However the majority of compliance comes from the designer/developer making design decisions that are compliant-font type, color contrast, alt tags, left to right, top to bottom design, etc.
You've basically summed up what I explained to my stakeholder. Their position is even with the right design SL3 and Articulate 360 aren't able to output WCAG compliant content.
They are saying that Articulate is false advertising.
I will go back and reiterate to my client that SL3 and Articulate 360 are indeed WCAG compliant,
Have a wonderful day and thanks again for replying.
Great question, Ivan. Yes, you can create Storyline 360, Studio 360, and Storyline 3 courses that support Web Content Accessibility Guidelines (WCAG). See these articles for details:
Rise 360 isn't fully accessible yet. Our ultimate goal is to meet accessibility guidelines. So far, we’ve increased the contrast for built-in course features, added alt text for images, and added keyboard-accessible navigation. And we’re currently working on full screen reader support. Stay tuned!
At WCAG 2.0 level A, I suspect users are going to find Storyline output to be accessible. There are some problems with AA and AAA, however. Almost all of the items are entirely reliant on the developer taking specific actions. I'd try to have a specific conversation about where the client thinks it doesn't meet. Try to talk in specific terms -- "A user with a vision impairment will not be able to X in a Storyline output." This is MUCH easier to address than "Its not capable of complying." which is completely non-specific and could reflect 1) a bias, 2) unfamiliarity with the way Storyline works (no experience), 3) zealous interpretations of the requirements. Specific cases are rational and they could well be right. Generalizations can be wrong (a lot). The best, best, best accessibility testers I've ever worked with have been those that have an impairment. They totally get it (because they live with it) and when you get it right, it's amazingly satisfying. When working with real users, the targets are tangible and not whimsical interpretations of checklist items.
I'd also try to get specifics around expectations. There's a big difference between level A and level AAA. If the expectation is level AAA, things will be a bit more difficult for a few of the items. Not impossible, just a lot more effort, custom workarounds, and testing back and forth to get things just right.
Almost everything can be worked around. There are ways to get around some limitations but those should be specifically designed and built for audience needs and tested as such to make the experience as painless as possible. Here's what I have found in my review and comparison. The only place where it gets dicey is with the text reflow. SL doesn't publish to a structured web page. It publishes an application within a page.
There are some ways around this for various audiences that provide alternate "modes" of presentation. These aren't built in. These implementations should be based on user needs and tested by folks that have those needs. One such alternate I've built is an HTML version that reflected the media version. Screen reader and magnifier users tended to like this version better in testing. It was bundled into the SCORM file and launched by the reader user. This met all of the items below but it was really bare bones content. Same content and activities, just without the multimedia and simple navigation.
1.1.1 - Meets if the developer adds text alternative.
1.2.1 - Meets with transcript in the notes field and notes tab clearly marked as such.
1.2.2 - Meets with closed captions.
1.2.3 - Meets with description in captions and transcript.
1.2.4 - [AA] Does not apply.
1.2.5 - Meets with description in captions and transcript.
1.2.6 - [AAA] Could meet if sign language interpretation video is provided and synced.
1.2.7 - [AAA] Could meet if video and audio are designed well and description is provided in captions.
1.2.8 - [AAA] Depends on interpretation. Could meet with transcript in some cases.
1.2.9 - [AAA] Does not apply.
1.3 - [A] Limited. Can support by using text to convey information.
1.3.2 - [A] Meets using tab order customization.
1.3.3 - [A] Meets. Allows alternatives.
1.3.4 - [A] Limited. Slide content is displayed in a fixed orientation. Modern player can reorient player but proportions do not change. No reflow.
1.3.5 - [AA] Meets with alternate description.
1.3.6 - [AAA] Purpose can be added through alternate description.
1.4.1 - [A] Meets but requires developer to pay attention to design choices.
1.4.2 - [A] Meets with pause / play and volume activated.
1.4.3 - [AA] Contrast. Meets but requires developer to pay attention to design choices.
1.4.4 - [AA] Limited. Screen text size is fixed after publish. Can be edited within the authoring environment.
1.4.5 - [AA] Meets
1.4.6 - [AAA] Contrast. Meets but requires developer to pay attention to design choices.
1.4.7 - [AAA] Meets but requires developer to pay attention to design choices.
1.4.8 - [AAA] Does not meet. Text cannot be resized.
1.4.9 - [AAA] Meets but requires developer to pay attention to design choices.
1.4.10 - [AA] Text Reflow. Presentation area is fixed. Text will not reflow within the application.
1.4.11 - [AA] Meets but requires developer to pay attention to design choices.
1.4.12 - [AA] Meets but requires developer to pay attention to design choices.
1.4.13 - [AA] Limited. Requires paying attention to design choices.
2.1.1 - [A] Meets
2.1.2 - [A] Meets
2.2.3 - [AAA] Meets. Requires paying attention to design choices.
2.1.4 - [A] Meets. Requires paying attention to design choices.
2.2.1 - [A] Meets
2.2.2 - [A] Meets. Requires paying attention to design choices.
2.2.3 - [AAA] Meets. Requires paying attention to design choices.
2.2.4 - [AAA] Meets. Requires paying attention to design choices.
2.2.5 - [AAA] Does not apply to content.
2.2.3 - [AAA] Meets. Requires paying attention to design choices.
2.3.1 - [A] Meets. Requires paying attention to design choices.
2.3.2 - [AAA] Meets. Requires paying attention to design choices.
2.3.3 - [AAA] Could meet. Requires paying attention to design choices.
2.4.1 - [A] Meets
2.4.2 - [A] Meets. Requires paying attention to design choices.
2.4.3 - [A] Meets.
2.4.4 - [A] Meets. Requires paying attention to design choices.
2.4.5 - [AA] Meets. Sequential presentation reflects "step in process" and menu allows for page access when included.
2.4.6 - [AA] Could meet but not true headings. SL outputs are application within a web page. Not a web structure.
2.4.7 - [AA] Meets
2.4.8 - [AAA] Meets if menu configured in player.
2.4.9 [AAA] Meets if element described. Not exactly like a web link, however.
2.4.10 - [AAA] Limited. SL outputs are application within a web page. Not a web structure.
2.5.1 - [A] Meets. Gestures not used or required.
2.5.2 - [A] Meets. Requires paying attention to design choices.
2.5.3 - [A] Meets
2.5.4 - [A] Does not apply.
2.5.5 - [AAA] Meets. Requires paying attention to design choices.
2.5.6 - [AAA] Meets.
3.1.1 - [A] Meets. Single page. Language described.
3.1.2 - [AA] Does not apply. Subparts all the same language.
3.1.3 - [AAA] Could meet if developer makes specific choices. Nothing built in.
3.1.4 - [AAA] Could meet if developer makes specific choices. Nothing built in.
3.1.5 - [AAA] Meets. Requires paying attention to design choices.
3.1.6 - [AAA] Could meet if developer makes specific choices. Nothing built in.
3.2.1 - [A] Meets
3.2.2 - [A] Meets
3.2.3 - [AA] Meets
3.2.4 - [AA] Meets
3.2.5 - [AAA] Meets. Requires paying attention to design choices.
3.3.1 - [A] Meets. Requires paying attention to design choices.
3.3.2 - [A] Meets. Requires paying attention to design choices.
3.3.3 - [AA] Meets. Requires paying attention to design choices.
3.3.4 - [A] Meets. Requires paying attention to design choices.
3.3.5 - [AAA] Could meet. Not built in. Requires paying attention to design choices.
3.3.6 - [AAA] Meets. Requires paying attention to design choices.
4.1.1 - [A] Meets for purpose of tool. It's an application within a web page. Operates in application mode.
4.1.2 - [A] Meets. Role defined in markup.
4.1.3 - [AA] Possible using aria roles and javascript. Not built in.
6 Replies
Hi Ivan,
SL3 and Articulate 360 are compliant. However the majority of compliance comes from the designer/developer making design decisions that are compliant-font type, color contrast, alt tags, left to right, top to bottom design, etc.
Cheers,
Julie
Hi Julie,
Thank you for the quick reply!
You've basically summed up what I explained to my stakeholder. Their position is even with the right design SL3 and Articulate 360 aren't able to output WCAG compliant content.
They are saying that Articulate is false advertising.
I will go back and reiterate to my client that SL3 and Articulate 360 are indeed WCAG compliant,
Have a wonderful day and thanks again for replying.
Only the best,
Ivan
Great question, Ivan. Yes, you can create Storyline 360, Studio 360, and Storyline 3 courses that support Web Content Accessibility Guidelines (WCAG). See these articles for details:
Rise 360 isn't fully accessible yet. Our ultimate goal is to meet accessibility guidelines. So far, we’ve increased the contrast for built-in course features, added alt text for images, and added keyboard-accessible navigation. And we’re currently working on full screen reader support. Stay tuned!
At WCAG 2.0 level A, I suspect users are going to find Storyline output to be accessible. There are some problems with AA and AAA, however. Almost all of the items are entirely reliant on the developer taking specific actions. I'd try to have a specific conversation about where the client thinks it doesn't meet. Try to talk in specific terms -- "A user with a vision impairment will not be able to X in a Storyline output." This is MUCH easier to address than "Its not capable of complying." which is completely non-specific and could reflect 1) a bias, 2) unfamiliarity with the way Storyline works (no experience), 3) zealous interpretations of the requirements. Specific cases are rational and they could well be right. Generalizations can be wrong (a lot). The best, best, best accessibility testers I've ever worked with have been those that have an impairment. They totally get it (because they live with it) and when you get it right, it's amazingly satisfying. When working with real users, the targets are tangible and not whimsical interpretations of checklist items.
I'd also try to get specifics around expectations. There's a big difference between level A and level AAA. If the expectation is level AAA, things will be a bit more difficult for a few of the items. Not impossible, just a lot more effort, custom workarounds, and testing back and forth to get things just right.
Almost everything can be worked around. There are ways to get around some limitations but those should be specifically designed and built for audience needs and tested as such to make the experience as painless as possible. Here's what I have found in my review and comparison. The only place where it gets dicey is with the text reflow. SL doesn't publish to a structured web page. It publishes an application within a page.
There are some ways around this for various audiences that provide alternate "modes" of presentation. These aren't built in. These implementations should be based on user needs and tested by folks that have those needs. One such alternate I've built is an HTML version that reflected the media version. Screen reader and magnifier users tended to like this version better in testing. It was bundled into the SCORM file and launched by the reader user. This met all of the items below but it was really bare bones content. Same content and activities, just without the multimedia and simple navigation.
1.1.1 - Meets if the developer adds text alternative.
1.2.1 - Meets with transcript in the notes field and notes tab clearly marked as such.
1.2.2 - Meets with closed captions.
1.2.3 - Meets with description in captions and transcript.
1.2.4 - [AA] Does not apply.
1.2.5 - Meets with description in captions and transcript.
1.2.6 - [AAA] Could meet if sign language interpretation video is provided and synced.
1.2.7 - [AAA] Could meet if video and audio are designed well and description is provided in captions.
1.2.8 - [AAA] Depends on interpretation. Could meet with transcript in some cases.
1.2.9 - [AAA] Does not apply.
1.3 - [A] Limited. Can support by using text to convey information.
1.3.2 - [A] Meets using tab order customization.
1.3.3 - [A] Meets. Allows alternatives.
1.3.4 - [A] Limited. Slide content is displayed in a fixed orientation. Modern player can reorient player but proportions do not change. No reflow.
1.3.5 - [AA] Meets with alternate description.
1.3.6 - [AAA] Purpose can be added through alternate description.
1.4.1 - [A] Meets but requires developer to pay attention to design choices.
1.4.2 - [A] Meets with pause / play and volume activated.
1.4.3 - [AA] Contrast. Meets but requires developer to pay attention to design choices.
1.4.4 - [AA] Limited. Screen text size is fixed after publish. Can be edited within the authoring environment.
1.4.5 - [AA] Meets
1.4.6 - [AAA] Contrast. Meets but requires developer to pay attention to design choices.
1.4.7 - [AAA] Meets but requires developer to pay attention to design choices.
1.4.8 - [AAA] Does not meet. Text cannot be resized.
1.4.9 - [AAA] Meets but requires developer to pay attention to design choices.
1.4.10 - [AA] Text Reflow. Presentation area is fixed. Text will not reflow within the application.
1.4.11 - [AA] Meets but requires developer to pay attention to design choices.
1.4.12 - [AA] Meets but requires developer to pay attention to design choices.
1.4.13 - [AA] Limited. Requires paying attention to design choices.
2.1.1 - [A] Meets
2.1.2 - [A] Meets
2.2.3 - [AAA] Meets. Requires paying attention to design choices.
2.1.4 - [A] Meets. Requires paying attention to design choices.
2.2.1 - [A] Meets
2.2.2 - [A] Meets. Requires paying attention to design choices.
2.2.3 - [AAA] Meets. Requires paying attention to design choices.
2.2.4 - [AAA] Meets. Requires paying attention to design choices.
2.2.5 - [AAA] Does not apply to content.
2.2.3 - [AAA] Meets. Requires paying attention to design choices.
2.3.1 - [A] Meets. Requires paying attention to design choices.
2.3.2 - [AAA] Meets. Requires paying attention to design choices.
2.3.3 - [AAA] Could meet. Requires paying attention to design choices.
2.4.1 - [A] Meets
2.4.2 - [A] Meets. Requires paying attention to design choices.
2.4.3 - [A] Meets.
2.4.4 - [A] Meets. Requires paying attention to design choices.
2.4.5 - [AA] Meets. Sequential presentation reflects "step in process" and menu allows for page access when included.
2.4.6 - [AA] Could meet but not true headings. SL outputs are application within a web page. Not a web structure.
2.4.7 - [AA] Meets
2.4.8 - [AAA] Meets if menu configured in player.
2.4.9 [AAA] Meets if element described. Not exactly like a web link, however.
2.4.10 - [AAA] Limited. SL outputs are application within a web page. Not a web structure.
2.5.1 - [A] Meets. Gestures not used or required.
2.5.2 - [A] Meets. Requires paying attention to design choices.
2.5.3 - [A] Meets
2.5.4 - [A] Does not apply.
2.5.5 - [AAA] Meets. Requires paying attention to design choices.
2.5.6 - [AAA] Meets.
3.1.1 - [A] Meets. Single page. Language described.
3.1.2 - [AA] Does not apply. Subparts all the same language.
3.1.3 - [AAA] Could meet if developer makes specific choices. Nothing built in.
3.1.4 - [AAA] Could meet if developer makes specific choices. Nothing built in.
3.1.5 - [AAA] Meets. Requires paying attention to design choices.
3.1.6 - [AAA] Could meet if developer makes specific choices. Nothing built in.
3.2.1 - [A] Meets
3.2.2 - [A] Meets
3.2.3 - [AA] Meets
3.2.4 - [AA] Meets
3.2.5 - [AAA] Meets. Requires paying attention to design choices.
3.3.1 - [A] Meets. Requires paying attention to design choices.
3.3.2 - [A] Meets. Requires paying attention to design choices.
3.3.3 - [AA] Meets. Requires paying attention to design choices.
3.3.4 - [A] Meets. Requires paying attention to design choices.
3.3.5 - [AAA] Could meet. Not built in. Requires paying attention to design choices.
3.3.6 - [AAA] Meets. Requires paying attention to design choices.
4.1.1 - [A] Meets for purpose of tool. It's an application within a web page. Operates in application mode.
4.1.2 - [A] Meets. Role defined in markup.
4.1.3 - [AA] Possible using aria roles and javascript. Not built in.
Wow, thank you so much for your detailed response, Steve! You are indeed my eLearning Hero!
Again, thank you so very much!
I bookmarked this response with the knowledge that I would need this in the future! Thanks again Steve Flowers!
This discussion is closed. You can start a new discussion or contact Articulate Support.