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, because Articulate also highlights on page 11 of its Accessibility Conformance Report here that Storyline 360 is not compliant with WCAG 2.1 (Level AA), based on the fact that its text input fields do not support WCAG criterion 1.3.5: Identify Input Purpose. It also states that it does not meet criterion 3.1.2: Language of Parts.
Obviously, if Articulate 360 only supports most of the criteria for Level AA, but not all of the criteria, then it is does not satisfy the requirements of WCAG 2.1 (Level AA) compliance. Therefore, I have advised my client that their requirement of WCAG 2.1 (Level AA) compliance cannot be achieved if we use Storyline.
Could you please clarify if the report is now outdated and if any recent improvements to the software allow it to meet criteria 1.35 and 3.1.2? That is, is Storyline 360 now compliant with WCAG 2.1 AA, as per the claim on this page?
Is there a way in Storyline 360 to conform to 3.1.2 Language of Parts AA? I know you can set the course language in the player, but can you set the language of an individual passage or phrase if it is different from the main language? Thanks!
Hi Teresa! in an earlier reply to this thread, John Morgan from Articulate replied that the reason Storyline 360 does not support Criterion 3.1.2 Language of Parts is because it is "a specific scenario that is not common". (However, I note that he has now deleted this rationale from his post).
Perhaps if you can highlight why this feature is more common than the Articulate team believes it is, they may consider prioritising it for attention.
Hi Kuriko,
I apologize for any confusion. Since 1.3.5 is not currently supported, that would require a custom design (if possible) to meet conformance.
I do see that Leslie has linked this conversation to our feature request to support autocompletion in text entry fields.
No statements above were deleted, but I do hope this clarifies things.
Hi John,
Good to see that the statement I was quoting is back in your post now. Your explanation is indeed a plausible rearrangement of your original words, except for a few confusing elements:
1) In your explanation today, you said “that would require a custom design (if possible) to meet conformance”. I can’t say it was clear from your original post that you were talking about a custom design by the Articulate software engineers. However, if that’s what you meant, wouldn’t that also apply to the second criterion I mentioned (3.1.2 Language of Parts)? It’s just strange, in this case, because you gave a different rationale for not supporting that criterion, which was that it is “a specific scenario that is not common”.2) If the fact that it’s not currently supported is the explanation of why you originally said it “would require a custom design, which we could not support”, isn’t this also the case for each and every feature request submitted for Storyline 360? If so, why would you mention it in relation to this specific request? And I'm not sure if your statement intended to indicate that each and every feature request/"custom design" is something that you "could not support", but that is how your explanation is coming across. Can you please clarify?3) Your original post said "Yes, Storyline 360 meets AA conformance due to the details of these criteria". Could you please explain to me how Storyline 360 conforms to AA accessibility guidelines, when Storyline does not currently support Criteria 1.3.5 (Identify Input Purpose) and 3.1.2 (Language of Parts)? This is the critical part of your original statement that I am still confused about.Lastly, you mentioned that the feature request submitted by Leslie is to “support autocompletion in text entry fields”. As per my explanations above, the request is actually for Storyline 360 to support the declaration/identification of the input purpose of text entry fields (which in turn allows screen readers to determine their purpose and allows browsers to auto fill fields accurately). Could you please clarify the exact wording of the feature request that has been recorded at your end, just so that we are all clear on what is actually being requested? The reason the wording is important is because 'supporting auto-completion' sounds like just a nice-to-have, whereas identifying input purpose on text-entry fields is critical to WCAG 2.1 AA compliance.Hi Kuriko,
I am relatively new to Articulate and am in the process of learning more about accessibility. I collaborated with our in-house Accessibility Specialist, Leslie, for assistance. Leslie will continue the conversation in this discussion. I do apologize for any confusion.
Hi Kuriko,
It sounds like the option for a custom design was not helpful in this instance, and I'll take responsibility for that thought.
As John shared, the title of the feature request is "Add support for auto-filling or autocomplete text entry fields from browser." You are correct, the input purpose is required for auto-completion, and those details are included.
You can create Storyline 360 courses that conform to WCAG, as Phil explained above:
I believe the compliance depends on which elements you use, you can create compliant courses but cannot use some elements. Which is the same in most tools and even building a web page.
If you'd like to discuss this further, I'd be happy to connect with you directly. We can continue the conversation and lessen the confusion caused here.
- Hi Leslie,I believe it’s important for us to keep the discussion within this public thread, so that other Articulate users can benefit from the information, not just me.Thanks for taking accountability for the confusing statements provided by John earlier in this thread. If you advised him to write the statement “Yes Storyline 360 meets AA conformance due to the details of these criteria”, can you please clarify now what was meant by this?Yes, Phil Mayor’s response above made perfect sense! However, the key issue here is that Articulate has not made it clear to Storyline 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. In fact, Articulate’s approach is quite the opposite—by promoting ‘Enter your name’ text entry fields (here, here, here and here) and at the same time claiming that "Storyline 360 supports WCAG 2.1 Level AA" (in this obsolete article which I notice has still not been unpublished/redirected, even after I brought this to your attention 3 weeks ago). Can you see how these mixed messages from Articulate could be deemed misleading and unhelpful to users seeking compliance with Level AA accessibility?I understand that your team did not intend to mislead users. I understand that they were simply following your advice, as the in-house Accessibility Specialist at Articulate, and that you truly did believe that Storyline was meeting WCAG 2.1 AA apart from what you believed to be two rarely used scenarios. However, now that I have explained in this thread what Criterion 1.3.5 actually relates to, and highlighted that this accessibility issue does in fact affect a large number of users, I’m hoping you can take some positive action to put things right now, and prioritise this issue that has previously been minimised.Firstly, I would like to see the title of the feature request changed to “Allow purpose declaration on text entry fields (for accessibility compliance)”. As I mentioned in my last post, naming the feature request around auto-filling fields sounds too much like a ‘nice-to-have’, rather than the important accessibility issue that it is. Auto-filling is one outcome of implementing this feature, not the feature itself.Secondly, can you please provide the full description of the feature request here, as it’s recorded in your system? I’d like to confirm that it’s an accurate description of the issue—just since there's been so much confusion around the definition of this criterion from your team, including yourself.Thirdly, can you please explain your prioritisation system for feature requests, and clarify where this one sits within that priority list?Lastly, as an interim solution until this feature request is implemented, the very least Articulate can do is be transparent with users about the fact that ‘Enter your name’ text entry fields are one of the elements you cannot use in your course if you require compliance with accessibility guidelines. This can easily be done by adding this tip to your 'How to design an accessible course' page. Can you please confirm how much time your team needs in order to do this?
Thanks, Kuriko. I appreciate your passion and commitment to accessibility. We’re all works in progress and on this accessibility journey together.
Our feature request system is an internal tool for our engineers. All of your thoughts as well as the WCAG criteria, 1.3.5, are included. Here's our process for handling feature requests.
I mentioned above that including transparency in our Storyline 360: How to Design an Accessible Course article is part of a larger project we are working on. I'm happy to share that a statement has been added.
Please stay tuned to our Articulate 360 Feature Roadmap for features we're working on next and our Storyline 360 Version History for new features and fixes.
- 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.
