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, b...
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.
