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?
- MathNotermans-9Community Member
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.
- PhilMayorSuper Hero
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.
- KurikoACommunity Member
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.
- KurikoACommunity Member
I'm just posting my reply again, as it seems it was deleted by the Articulate team after it was published and received 'Likes' from other users... LeslieMcKerchie, would you care to respond to this message this time, rather than deleting it? An update on the feature roadmap would be much appreciated.
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.
- MathNotermans-9Community Member
KurikoAWow, they really deleted a reply ? Let's hope it was just an error and not intentionally.
Concerning the input field with 'Enter your name', when you publish to Scorm and put your course on a LMS, you never need an input field for that as you can get the username from Scorm. Nevertheless it is good to be aware of. A proper accessibility mode or accessibilty checker in Storyline that you can set to WCAG 2.1 AA or any newer or older version to highlight/define elements that are NOT accessible, becomes more and more a need.Hi MathNotermans! No reply was deleted. I think the new platform and threaded replies may have created a moment of confusion. I appreciate you popping in to help here and it reminded me that we DO have an accessibility checker on the public feature roadmap for Storyline.
Hi KurikoA! I assure you no reply was deleted. Your reply from 9 days ago is displayed with 1 like. I've attached an image of what I'm seeing.
We recently updated our platform, so replies are threaded. If you're looking for a recent reply, you may want to sort by the most recent. Here's a quick video (no audio) if needed.
In addition, you can click on your avatar in the top right, choose the profile option, scroll down under all activity, and see your most recent posts and replies.
At your original request, we added this limitation to the documentation in Storyline 360: How to Design an Accessible Course, and it is still listed in the conformance report.
Storyline 360 empowers you to create courses that support WCAG 2.1 Level AA. You can find detailed information on the success criteria in our Voluntary Product Accessibility Template® (VPAT®). However, please note there are exceptions: Storyline 360 doesn't support 1.3.5 Identify Input Purpose for data-entry fields or 3.1.2 Language of Parts for multiple screen reader languages in the same course. Despite these exceptions, Storyline 360 offers robust features to help you build accessible and engaging learning experiences.
The feature roadmap displays items currently in development but does not reflect all items that have yet to be prioritized.
- SandeepGadamCommunity Member
I concur with this and have the same inquiry. Does Storyline 360 now adhere to WCAG 2.1 AA standards?
- MathNotermans-9Community Member
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.
- PhilMayorSuper Hero
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.
- JohnMorgan-c50cFormer Staff
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!
- MathNotermans-9Community Member
A accessibility checker inside Storyline would be nice.
- KurikoACommunity MemberHi 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. - KurikoACommunity Member
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.- KurikoACommunity Member
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.