I am not able to tab to text boxes after publishing lessons. This is critical for Section 508 Compliance. Does anyone have any suggestions? Thanks in advance.
I think this may be part of the new accessibility updates. The new updates mean that in published output, tabbing only brings you through interactive elements, but using a screen reader's navigation keys (often forward/back arrows), the text boxes can be accessed by screen readers. What is frustrating is that this is a default that can't be changed and makes it difficult to test accessibility, as well as design for certain specific access needs. To test whether this is the case for your output, you can download the free screen reader NVDA from nvaccess.org and test your course with it. NVDA also does not visually highlight where on screen it is reading, so it can take some getting used to as a sighted tester.
OK, thanks. We currently use JAWS and we have to be able to support this if the client ever comes back because they cannot "tab" to certain elements. It would be nice if the folks at Articulate can issue some sort of official documentation re: Section 508 C, in addition to what is already published, that states these things clearly. I am not the first person to post about this and it seems like the issues go back years...
Thanks for your time and input Sally! I really appreciate your advice.
Hi Glenna, this is part of the accessibility updates. Many people have been a bit confused by how a user using a keyboard and screen reader progresses through content. The good news is, content is now working more inline with what users are used to on the web. Using Tab keys and Arrows keys, users can navigate the content much easier. It was actually an unusual behaviour to Tab to text boxes. It was unnecessary for users who navigate content using a keyboard to Tab to a text field. The normal behaviour is to Tab to interactive elements only.
Rest assured the content is accessible (even more so now) using JAWS screen reader. Just be sure to use your arrows keys more than your tab key on your keyboard to navigating the content now.
Hi Sally, you should actually find that users who use a screen reader and keyboard to access the content will now find the content easier to access as it will now work how they expect a web page should work. If attempt to navigate any website using a tab key, you are only going to be taken to elements that are interactive. You'll find the arrow keys are the way to navigate content when using a screen reader, and users using a keyboard only can quickly access the interactive elements and not be taken unnecessarily through the text fields.
I've seen some concern about the change, but it is a very positive change for accessibility.
Sam, I understand that this is how most websites work and that support for this is a step forward. But, taking away the previous version was also a step back - it should have been added as an option whether to include text items in tabbing rather than replacing the previous functioning - in fact, it should publish with both and allow end users the option to choose the preferred operation. Just because this is how screen readers generally work with websites, doesn't mean it's perfect accessibility. There are valid accessibility critiques of exclusive use of the interactive-objects-only format of tabbing interaction.
We'll have to agree to disagree on that one. Storyline was using something called applications mode, which forced a screen reader to treat the slides as an application. I think this might have been a legacy thing from how the Flash published content used to work. I'm not 100% on the reason Articulate went with applications mode.
In applications mode, when screen readers tab to the text, they can only read the text in one whole bite. They cannot pause the screen reader, rewind to re-read pieces of text etc. If they want to re-read a section of a text field, they have to re-read the entire text field. Applications mode is a negative experience for screen reader uses when it comes to reading text in text fields.
Applications mode is also a negative experience for keyboard navigation users. They do not need or want to have to tab through text fields, they want to tab to interactive elements. Tabbing through multiple text fields is pointless for people who use a keyboard to navigate content when they just need to get to the navigation.
I'd argue it is also a negative experience as it is not expected behaviour. For example, users using assistive technology to access their learning would have had a different experience in Storyline to content developed in other tools, or hand built. Storyline would stand out as the odd one out using applications mode.
Once everybody forgets how Storyline used to be navigated using just the tab key and people become familiar with how screen readers work on HTML pages, it will be a good thing. It's just a transition I think.
There's also more great stuff coming up soon such as semantic mark-up which is going to allow us to add some structure to slides using proper heading tags and list tags.
I think the software is moving in the right direction.
For section 508 it is required to list out all heading clearly, so that disabled person can go through headings and pick the one they wanted. We figured out a work around to it by incorporating a invisible box around heading and giving it an alt-text.
With this new update we will not be able to do that. Is there a way to list our headings without using menu. FYI using menu is creating other issues for section 508 which requires adding ARIA attributes to HTML and in articulate storyline we cannot manipulate the HTML code.
I appreciate you sharing what your learners are currently experiencing.
Learners use their screen reader navigation keys, the Down and Up arrows, to move through all text and interactive objects on the slide, listening to each item along the way. The Tab key is for interactive things.
15 Replies
What version of storyline are you using, and what were your publish settings?
I was using v3.38.21779.0 then updated to v3.41.22450.0 and still have the same issue. Published to Articulate Review 360 as "HTML5 Only"
Thanks!
I think this may be part of the new accessibility updates. The new updates mean that in published output, tabbing only brings you through interactive elements, but using a screen reader's navigation keys (often forward/back arrows), the text boxes can be accessed by screen readers. What is frustrating is that this is a default that can't be changed and makes it difficult to test accessibility, as well as design for certain specific access needs.
To test whether this is the case for your output, you can download the free screen reader NVDA from nvaccess.org and test your course with it. NVDA also does not visually highlight where on screen it is reading, so it can take some getting used to as a sighted tester.
OK, thanks. We currently use JAWS and we have to be able to support this if the client ever comes back because they cannot "tab" to certain elements. It would be nice if the folks at Articulate can issue some sort of official documentation re: Section 508 C, in addition to what is already published, that states these things clearly. I am not the first person to post about this and it seems like the issues go back years...
Thanks for your time and input Sally! I really appreciate your advice.
Hi Glenna, this is part of the accessibility updates. Many people have been a bit confused by how a user using a keyboard and screen reader progresses through content. The good news is, content is now working more inline with what users are used to on the web. Using Tab keys and Arrows keys, users can navigate the content much easier. It was actually an unusual behaviour to Tab to text boxes. It was unnecessary for users who navigate content using a keyboard to Tab to a text field. The normal behaviour is to Tab to interactive elements only.
Rest assured the content is accessible (even more so now) using JAWS screen reader. Just be sure to use your arrows keys more than your tab key on your keyboard to navigating the content now.
Hi Sally, you should actually find that users who use a screen reader and keyboard to access the content will now find the content easier to access as it will now work how they expect a web page should work. If attempt to navigate any website using a tab key, you are only going to be taken to elements that are interactive. You'll find the arrow keys are the way to navigate content when using a screen reader, and users using a keyboard only can quickly access the interactive elements and not be taken unnecessarily through the text fields.
I've seen some concern about the change, but it is a very positive change for accessibility.
Thanks Sam, that makes sense!
Sam, I understand that this is how most websites work and that support for this is a step forward. But, taking away the previous version was also a step back - it should have been added as an option whether to include text items in tabbing rather than replacing the previous functioning - in fact, it should publish with both and allow end users the option to choose the preferred operation. Just because this is how screen readers generally work with websites, doesn't mean it's perfect accessibility. There are valid accessibility critiques of exclusive use of the interactive-objects-only format of tabbing interaction.
We'll have to agree to disagree on that one. Storyline was using something called applications mode, which forced a screen reader to treat the slides as an application. I think this might have been a legacy thing from how the Flash published content used to work. I'm not 100% on the reason Articulate went with applications mode.
In applications mode, when screen readers tab to the text, they can only read the text in one whole bite. They cannot pause the screen reader, rewind to re-read pieces of text etc. If they want to re-read a section of a text field, they have to re-read the entire text field. Applications mode is a negative experience for screen reader uses when it comes to reading text in text fields.
Applications mode is also a negative experience for keyboard navigation users. They do not need or want to have to tab through text fields, they want to tab to interactive elements. Tabbing through multiple text fields is pointless for people who use a keyboard to navigate content when they just need to get to the navigation.
I'd argue it is also a negative experience as it is not expected behaviour. For example, users using assistive technology to access their learning would have had a different experience in Storyline to content developed in other tools, or hand built. Storyline would stand out as the odd one out using applications mode.
Once everybody forgets how Storyline used to be navigated using just the tab key and people become familiar with how screen readers work on HTML pages, it will be a good thing. It's just a transition I think.
There's also more great stuff coming up soon such as semantic mark-up which is going to allow us to add some structure to slides using proper heading tags and list tags.
I think the software is moving in the right direction.
For section 508 it is required to list out all heading clearly, so that disabled person can go through headings and pick the one they wanted. We figured out a work around to it by incorporating a invisible box around heading and giving it an alt-text.
With this new update we will not be able to do that. Is there a way to list our headings without using menu. FYI using menu is creating other issues for section 508 which requires adding ARIA attributes to HTML and in articulate storyline we cannot manipulate the HTML code.
Thank you.
I have the same question as Sunitha....
I'm thinking that alt text can be added to the text boxes to identify what they are and a screen reader will pick up the alt text.
The reader is no longer reading the alt text on the screen. It is strange.
Any updates to this issue? My published courses are not allowing learners to tab to text using JAWS.
Hello Barbara,
I appreciate you sharing what your learners are currently experiencing.
Learners use their screen reader navigation keys, the Down and Up arrows, to move through all text and interactive objects on the slide, listening to each item along the way. The Tab key is for interactive things.
You can read more about accessible slide content in our documentation here.