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
John Morgan

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!

Eric Santos

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!

Kuriko A
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', and
b) 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, and
c) unpublish this webpage with the false claim that "Storyline 360 supports WCAG 2.1 Level AA" or redirect the link to the correct page.
Leslie McKerchie

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.

Kuriko A

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.

Kuriko A
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. 
Kuriko A

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.  

Kuriko A

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. 

John Morgan

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.

Kuriko A

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. 
Leslie McKerchie

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.

Kuriko A
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?
Leslie McKerchie

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.

Kuriko A
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.
Paul Glenn

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!

Math Notermans

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.