Forum Discussion
Storyline 360 not compliant with WCAG 2.1 AA accessibility guidelines
Hi, Kuriko! Thank you for asking these questions and pressing the issues in a public forum. The information here has been very useful as I research accessibility in Storyline. I've been digging into the subject and wanted to provide some additional information for anyone else who comes across this page.
You mentioned that the issues you've outlined above mean Storyline 360 does not, in fact, support WCAG 2.1 Level AA. If that's true, this is helpful and important information to pass along to our clients.
But I find conflicting information at the W3 Understanding Conformance page, specifically the first three notes under Technical Definition of "Accessibility Support":
Note 1: The WCAG Working group and the W3C do not specify which or how much support by assistive technologies there must be for a particular use of a Web technology in order for it to be classified as accessibility supported. (See Level of Assistive Technology Support Needed for "Accessibility Support".)
Note 2: Web technologies can be used in ways that are not accessibility supported as long as they are not relied upon and the page as a whole meets the conformance requirements, including Conformance Requirement 4: Only Accessibility-Supported Ways of Using Technologies and Conformance Requirement 5: Non-Interference, are met.
Note 3: When a Web Technology is used in a way that is "accessibility supported," it does not imply that the entire technology or all uses of the technology are supported. Most technologies, including HTML, lack support for at least one feature or use. Pages conform to WCAG only if the uses of the technology that are accessibility supported can be relied upon to meet WCAG requirements.
Unless I misunderstand the above information, Storyline 360 does, in fact, "support" WCAG 2.1, Level AA, even if it does not provide specific conformance to criteria 1.3.5 (Identify Input Purpose) and 3.1.2 (Language of Parts).
If your understanding of this information differs, could you elaborate? This discussion has been illuminating overall, and I appreciate any additional perspective.
Thanks!
I do think the keyword in the WCAG statements is relied upon. Meaning that when producing a page or course when using something that is not accessible... a slider for example, you need to ensure that the functionality used by the slider is accessible in some other way. By buttons, keys or whatever. So in the end the responsibility is for the designer and developer to ensure a course is fully accessible. That said, the best would be if Articulate either added a accessibility checker that can test and check a course and/or a mode in which non-accessible elements are disabled, so you cannot use them from scratch.