Storyline 360 not compliant with WCAG 2.1 AA accessibility guidelines
Jan 19, 2023
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?
25 Replies
I concur with this and have the same inquiry. Does Storyline 360 now adhere to WCAG 2.1 AA standards?
When you only use default elements supplied in Articulate Storyline 360 i highly doubt it is compliant. Due to the fact that some elements ( eg. the slider ) even donot work properly on Mobiles/Touch without using workarounds. Please prove me wrong Articulate.
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. As time goes on more things will be compliant but some will never be or will be depracated.
Hello Kuriko,
I'd be happy to answer the questions that you have here.
Q: Could you please clarify if the report is now outdated and if any recent improvements to the software allow it to meet criteria 1.3.5 and 3.1.2?
A: The link to the pdf report you've shared is outdated. You can find the current version on our website: Articulate Storyline 360 Accessibility Conformance Report
We do highlight these two exceptions as you mention: Notes: Storyline 360 output supports or partially supports all applicable WCAG 2.1 Level AA criteria, except 1.3.5 Identify Input Purpose and 3.1.2 Language of Parts.
Q: Is Storyline 360 compliant with WCAG 2.1 AA?
A: Yes Storyline 360 meets AA conformance due to the details of these criteria. The first one would be a custom design, which we could not support, and the second one is a specific scenario that is not common.
1.3.5 Identify Input Purpose
Storyline 360 does not support programmatic input-field identification or auto-filling forms.
3.1.2 Language of Parts
You can set the course language, which can be programmatically determined. However, objects in the same course cannot be set for different languages.
As Phil indicated, authors make decisions to create courses to meet accessibility conformance and we are continuing to make improvements.
Thanks for reaching out!
A accessibility checker inside Storyline would be nice.
Hi Math,
An Accessibility Checker within Storyline that scans or reviews content for accessibility issues is an excellent idea for a feature request, and others think so too! A feature request has already been submitted for this. I have linked this conversation to that request, so if it makes it onto our feature roadmap, we’ll make sure to update you!
Thank you, Math!
a) advise users not to use text entry fields with a specific purpose, such as name fields, if they want their course to be fully accessible. I would suggest the best place to do this would be on your webpage entitled 'Storyline 360: How to design an Accessible course', and
Regarding Kuriko's post here... maybe it is a good idea to add a mode in Storyline that disables all not 100% accessible elements. So if a user builds in Storyline and he enables that mode...all building blocks that have issues with accessibility cannot be used.
This post was removed by the author
Hi Kuriko,
I apologize for any confusion, and thank you for the detailed feedback and suggestions.
John was referring to the link shared to the pdf report (where you mentioned page 11 in your original post), dated May 12, 2022. Our current conformance report is dated November 30, 2022.
Our Accessibility Conformance Report is based on the Voluntary Product Accessibility Template (VPAT). This document specifies the degree of conformance with the standards and guidelines, including WCAG 2.0, WCAG 2.1, and Revised Section 508 Standards.
The article, Storyline 360 Supports Web Content Accessibility Guidelines, provides an overview and links to our VPAT, design article, accessibility articles, and supported browsers for additional details.
For clarification on 1.3.5, using a text entry field for your user/learner to input information is a manual entry and is not considered programmatic or auto-filling.
I'm including the first slide from the download you referenced regarding using a text-entry field. Adding the expectation (Enter your name here, for example) in the text-entry field's placeholder will be communicated to your learner.
You are correct, we could provide more direct guidance and tips for authors, and we want to. Not only in the documentation but via examples as well. This project will be significant for Storyline 360, and it is already in the works. As an example, we've started with Rise 360. Inaccessible blocks are in our Rise 360 VPAT, but, as you suggested, we are now transparent about block accessibility in our Rise 360: How to Design an Accessible Course.
Again, I appreciate your feedback and suggestions, and I hope this further explanation clears up any confusion.
Hi Leslie,
Firstly, I understand which page John was referring to. The issue I raised is that the outdated page is still live on the web, claiming that "Storyline 360 supports WCAG 2.1 Level AA" which is untrue. Therefore it’s misleading for users who stumble on this outdated page when they do a web search for 'Storyline' and 'WCAG 2.1 Level AA'. Can you please confirm if this misleading page will be unpublished?
Secondly, could you please clarify how you came to the conclusion that criterion 1.3.5 does not apply to text entry fields requiring the user to enter their name? When you say “a text entry field is not considered programmatic or auto-filling”, this doesn’t really make sense to me, and it seems you may be misunderstanding what criterion 1.3.5 is about. So I’ll try to explain my understanding of criterion 1.3.5, and if your interpretation of it is different to mine, would you mind clearly explaining to me what you believe it is referring to instead?
I interpret criterion 1.3.5 as requiring that a text entry field be programmed so that its purpose is specified (for example, a name field, an email field, an address field etc), such that when the user double clicks on the field, the browser knows exactly what information is being requested by the field and can therefore autofill their name, email address or address, as appropriate. As an example of text entry fields that meet this criterion, think of an online store where you like to make purchases. When you reach the checkout page, you can double click in each text entry field to auto-fill your name, email address and delivery address. How does this magic occur, you may ask? How does a user’s browser know to put their name in the name field, and their address in their address field, and not the other way around? The answer is because the text entry fields have been programmed with their specific purpose. This tells the browser exactly what kind of data should be autofilled into each field. And this is what makes the form compliant with criterion 1.3.5.
Yes, as you mentioned, the instructions can be included on the slide in the form of text, such as ‘Enter your name here’. However, this is unrelated to criterion 1.3.5 in terms of accessibility, as per my explanation above. You can also learn more about this criterion by reading the information at this link: Understanding Success Criterion 1.3.5: Identify Input Purpose | WAI | W3C
As you’re aware, Storyline 360 does not have the capacity to declare the purpose of a text entry field, therefore browsers will not be able to automatically identify the purpose of the field and enable auto-filling. As such, my understanding is that any course that includes an ’enter your name’ text entry field in Storyline is not compliant with criterion 1.3.5.
As per my previous post, could you please confirm whether or not Articulate is planning to:
A) prioritise a feature to declare a purpose for text entry fields to enable compliance with criterion 1.3.5; and
B) include advice for users regarding the current not compliance of text entry fields on your webpage entitled 'Storyline 360: How to design an Accessible course', and
C) include the disclaimer regarding Criterion 1.3.5 not being supported—which is currently quite difficult to find—on your webpages that are promoting the use of the name field to personalise courses for learners, i.e. this page and this page, and
D) unpublish this webpage with the false claim that "Storyline 360 supports WCAG 2.1 Level AA" or redirect the link to the correct page.
Thanks, Kuriko!
A. Yes. I understand your specific request now, and we do have this submitted as a feature request.
B. Yes, this is a part of the project I mentioned above.
C. Great idea. This fits within the scope of the same project. I'll add it to the list.
D. I'll share this feedback with the team.
I’m glad we’re on the same page now and both agree that the WCAG 2.1 Level AA criteria not being met by Storyline 360 affect any user who has included a text entry field in their course requiring learners to enter their name.
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 @John Morgan, I have not heard back from you in response to my post from 12 days ago, in which I asked for an explanation of your statement that Criterion 1.3.5 only relates to “a custom design, which we could not support”. I'd like to find out exactly what you meant by this, and if my subsequent explanation of criterion 1.3.5 changed your mind about this? I note that you have deleted that statement from your post above, but you have still not responded to my question. This gives the impression that you are trying to pretend you never said it, rather than admitting that you made a mistake.
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:
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:
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.
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, 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.