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?
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.
I would like Storyline to highlight elements that are currently not accessible. Not sure how realistic an accessibility mode is as it depends on how you use them.
Apologies for the delay in replying to this thread, but I just want to come back and address the above points for the benefit of the wider Storyline user community.
PaulGlenn, you said “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).” My answer is: “Yes, as long as you do not insert any input fields that should be identifiable by the browser (e.g. ‘Enter your name’ text-entry fields) and as long as you are only presenting content in one language and that is the default language of your webpage.
The problem is that Articulate has widely promoted the use of ‘Enter your name’ text entry fields (e.g. here and here), and many Storyline users are inserting them into their courses in order to personalise their courses or give learners a personalised certificate of completion. If you're someone who has inserted an ‘Enter your name’ text-entry field into your course (or any other text-entry field requiring user information that should be declared to the browser), then your course will not be compliant with WCAG 2.1 (Level AA).
Reading through the notes you linked to on the W3 Understanding Conformance page, what they are saying is that if a course includes an element that is not accessible (e.g. an ‘Enter your name’ text-entry box), then it can be ignored in the accessibility assessment, as long as it is not relied upon (as highlighted by MathNotermans-9). That is, there must be an alternative way for the learner to access the same function/information in an accessible way. Since Storyline does not provide any way for you to identify the purpose of the text-entry field (i.e. specify that the field requires the user’s ‘name’ or the user’s ‘email address’ so that this can be identified by the browser), then there is no way to provide an accessible alternative to the text-entry field using Storyline alone. You could get creative trying to embed other technologies into your Storyline course (maybe using the web object feature), but you cannot achieve accessibility compliance with Storyline alone.
My purpose in this thread was to ask Articulate to make this limitation clear to its users, instead of misleading people with the false blanket claim here that ‘Storyline 360 supports WCAG 2.1 Level AA’. And although LeslieMcKerchie from the Articulate team confirmed above that a feature request has been logged which would enable criterion 1.3.5 to be met, it is still not appearing on the Feature roadmap, even after 2 years.
Am I disappointed that Articulate is not being transparent with its current and future customers about the software’s limitations? Yes. Am I annoyed that they are not taking this issue more seriously? Absolutely. Am I surprised? Not really. I’ve been wasting my time trying to help the Articulate team recognise and fix bugs for over 10 years now. As you can see from this thread, it takes enormous effort to even get them to recognise, let along fix any issue. But I just thought the community ought to know the truth, rather than assuming that Storyline allows them to create courses that meet all of the WCAG 2.1 (Level AA) criteria.
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 John,Firstly, you mentioned that this webpage with the false claim that "Storyline 360 supports WCAG 2.1 Level AA" is outdated. From your reply, I understand that it has been replaced with this page that which now simply states "we built Articulate Storyline 360 to support Web Content Accessibility Guidelines (WCAG) and Section 508 accessibility standards, as described in this report". I'm just wondering, in that case, is there any reason why the outdated/superseded webpage is still live on the web? If Articulate is attempting to retract its misleading claim, is it just an unfortunate oversight that this page has not yet been unpublished, given that it is leading people to come across that outdated, misleading claim when they do a web search for 'Storyline' and 'WCAG 2.1 Level AA'?Secondly, I can see Articulate’s disclaimer on this page that Storyline 360 doesn’t meet those two criteria. The disclaimer is quite hidden, only visible after you scroll about halfway down the very lengthy page content — essentially a needle in a haystack, as opposed to the eye-catching claim taking prime position at the top of the page which states: “we built Articulate Storyline 360 to support Web Content Accessibility Guidelines (WCAG) and Section 508 accessibility standards”. It would be nice if Articulate could be more upfront about the ways in which Storyline 360 does not meet the guidelines.You mentioned that, as Phil indicated, authors make decisions to create courses to meet accessibility conformance. However, would you agree that users and potential users of Storyline 360 should at least be made aware of the elements they will not be able to include in their courses, if they want them to be compliant with the Level AA criteria? I believe that Articulate has an obligation to make these conditions clearer to its potential users who are seeking to purchase an elearning authoring tool that is fully compliant with WCAG 2.1 Level AA, and to its already subscribed users who purchased the product believing that it allows for full compliance with accessibility guidelines. In other words, Articulate should include a clear and comprehensive list of things you cannot include in your course, if you want it to be compliant with WCAG 2.1 Level AA.Your reasons for why Storyline doesn't meet the first criterion was that it is a custom design, which you do not support. Could you please clarify in what way this is a custom design?In my particular case, many of the courses I’ve developed over the past 10 years contain an ‘Enter your name’ text entry field. Your team promotes this feature here, saying “Community members often ask how to add and display a learner’s name in their Storyline 360 courses. I love that feature because it’s a really simple way to personalize your project and boost learner engagement”. You also provide a template for this feature here in your article entitled '3 Ways to Personalize Your E-Learning Courses'.Unfortunately though, due to Storyline 360’s limitations, the text fields used to enter the user's name cannot be correctly identified as ‘Name’ fields and therefore cannot be appropriately auto-filled. Thus, having these text entry fields means that the whole course fails criterion 1.3.5: Identify Input Purpose and consequently does not meet WCAG 2.1 Level AA. Therefore, I now have to regretfully inform my clients that they cannot keep this feature in their courses, if they want them to be compliant with WCAG 2.1 Level AA. Can you please advise if Articulate is prioritising this feature for future updates?In the meantime, I think the very least that Articulate can do is:
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', andb) include the disclaimer regarding Criterion 1.3.5 not being supported—which is currently quite difficult to find—on all of your webpages that are promoting the use of the name field to personalise courses for learners, i.e. this page and this page, andc) unpublish this webpage with the false claim that "Storyline 360 supports WCAG 2.1 Level AA" or redirect the link to the correct page. 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 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!
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.
- Hi Leslie,
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.I would still appreciate a response from @John Morgan though, in relation to his statement in this thread that criterion 1.3.5 only relates to “a custom design, which we could not support”. I'd like to find out exactly what was meant by that statement, and if my explanation of criterion 1.3.5 in my previous post has change his mind about this?Regarding the feature request for text entry fields to allow purpose declaration, could you please provide a ballpark time frame for when this will be added to Storyline’s functionality? I know Articulate is known to leave bugs unresolved for years —and in some cases more than a decade—so I’m not getting my hopes up for something that’s classified as a ‘feature request’ rather than a bug. But, given that non-compliance with accessibility guidelines is a critical concern for many users, I’m hoping this will be taken more seriously by Articulate.As mentioned, in my particular case, where my clients require compliance with WCAG 2.1 Level AA, I need to now advise them to remove the ‘Enter your name’ text entry fields from all of their courses, due to Storyline’s limitations. This will be a time-consuming and costly undertaking, as I’m sure is the case for anyone else using this feature. And as you can imagine, they certainly won’t be happy that even though they trusted Articulate’s claims that it supports WCAG 2.1 Level AA, they now need to remove this personalisation feature from their courses, due to the software’s limitations.Following Articulate’s promotion of ‘Enter your name’ text entry fields to personalise courses, they appear to be quite commonly used among Storyline users. Some examples of users using this feature can be found in this thread, this thread, this thread and this thread. Therefore, I think we can safely say that there’s a large number of users out there who are also affected by this accessibility issue, and if they are, their courses are not compliant with WCAG 2.1 Level AA. It’s highly likely that these users may not even be aware of this (just as you weren’t aware of what was meant by criterion 1.3.5). And if these users happen to be falsely claiming to their clients or employers that their courses are fully accessible (given that Articulate promotes Storyline as supporting accessibility and buries the non-compliance notes in the ‘fine print’), then this is a potential legal issue for Articulate.An ideal solution would be for this feature to be included in the next update, so that we don’t need to remove all of the ‘Enter your name’ text entry fields from our courses.I look forward to your reply and John's reply.
