Forum Discussion
Storyline 360 not compliant with WCAG 2.1 AA accessibility guidelines
I see that Articulate claims on this page that "Storyline 360 supports WCAG 2.1 Level AA, including screen readers, keyboard navigation, visible focus indicators, and more."
I'm confused though, b...
Hi Leslie,
I felt hopeful when I read your reply, believing that Articulate had finally made it clear to users that ‘Enter your name’ text entry fields are one of the elements you cannot use if you want your course to be accessibility-compliant. However, I was disappointed to see that this wasn’t the case. All I could see on the How to design an accessible course page was yet another vague disclaimer stating that “Storyline 360 doesn't support 1.3.5 Identify Input Purpose for data-entry fields".
Just in case you misunderstood, I was actually requesting that a helpful tip be added, advising users on how they can ensure their data entry fields are accessible. Given that you and your team did not understand what was meant by criterion 1.3.5 until I explained it to you, do you think it would be reasonable and appropriate to actually explain the issue to users, highlighting that they cannot use ‘Enter your name’ text entry fields (or any other text-entry fields requiring user information that should be declared to the browser) if they want their course to be accessible? This tip would logically sit within the section entitled Make Interactive Content Accessible. You mentioned this is "part of a larger project", however I can't see why you are delaying getting this important information to users. As you've demonstrated with adding the above 'statement' to the page, it doesn't take long to make an edit to the webpage content. And if it's how to word this tip that's causing a delay, would you like me to draft the content for you?
Thanks for sending the link to the Articulate 360 Feature Roadmap. I can see that it was last updated 4 days ago, however it still does not include this feature request, despite our discussion about the far-reaching impact of this accessibility issue. Does this mean that your engineers have evaluated the feature request (as in Step 2 of this link you sent through) and decided that it is not a feature that will "meaningfully improve the experience of working with our software" and that it will not "benefit a majority of users"?
Yes, I am passionate and committed to accessibility compliance. It’s a critical 'make or break' feature of an elearning authoring tool, so I would expect your team to be just as passionate and committed as I am. However, I’m not getting the impression that you are. Here’s a list of the requests in my previous posts which you have ignored/disregarded. I would appreciate if you could please address each of these in your next reply.
1) Please unpublish this obsolete article which misleadingly claims that "Storyline 360 supports WCAG 2.1 Level AA". You mentioned that the correct version of the article is this one (which does not make that misleading claim), so please redirect the obsolete article's URL to this one.
2) Please change the title of the feature request from "Add support for auto-filling or autocomplete text entry fields from browser" to “Allow purpose declaration on text entry fields (for accessibility compliance)”. The current title does not capture the actual functionality required, and sounds like a 'nice-to-have' feature.
3) Please provide the full description of the feature request here, so that we can ensure it is documented correctly (attach a file if it is too long to insert in your post). You can understand my need for clarification here, given that you (as the in-house Accessibility Specialist at Articulate) attempted to convince me that that there was no issue with ‘Enter your name’ text entry fields and that they had nothing to do with Criterion 1.3.5, before backtracking and admitting there is indeed a conformance issue.
4) Please confirm where this feature request currently sits within the feature request priority list, based on its impact on users and how many users are affected.
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.
