Accessibility issues

Feb 27, 2020

Hi guys,

I am looking for some urgent assistance with a project I am working on. I've specified the tab order for each slide, however, when I publish the course and view it in a browser, I am having issues with accessibility.

1. Using the tab button to highlight/focus on items. Most of the items that I have specified in the tab order are not being highlighted or recognised at all e.g. text boxes. 

2. The voice reader seems to be reading a lot of extra stuff before even getting to the slide content. e.g. on the welcome slide it reads 'welcome 3 times before it reaches the content'

3. I can't seem to be able to navigate to/open hyperlinks using just the keyboard/voice over?

 

Any help would be much appreciated!

Thanks,

Jess

7 Replies
Lauren Connelly

Hi Jessica!

I'm happy to help! I've answered your questions in this screen recording. Please let me know if I need to clarify anything!

These are also great resources to stay up to date with our recent Accessibility enhancements to Storyline 360.

Storyline 360: Slide Content is More Accessible

Storyline 360: The Accessible Player Makes Navigation Easier

Jessica Cheung

Hi Lauren, thanks for taking the time to make the screen recording.

The creation of hyperlinked buttons/shapes for us is not ideal as we have content-heavy slides with paragraphs of text and multiple hyperlinks within so there will be about 100 buttons to create. We'll give it a go if this is the only workaround.

Yes, I was using NDVA and coming across this problem of the slide detail/title being reread multiple times.

There were two other issues I've run into.
1. Because of the lack of semantic tags, all of our text is being read with no differentiation between headings paragraphs and lists, etc. I've read on the forums that people are having to use the alt text field to manually write the heading tags as if to mimic a screen reader. e.g. "Heading level 1: Welcome to the course" Is there a better solution to this?

2. The screen reader sometimes pauses after reading a few words of text and then you have to press the down key to get it to start reading again. I'm not sure if this is a screen reader issue or an articulate issue. The pauses are not natural, like it will stop halfway through a sentence and then read halfway through the next sentence before stopping. Have you encountered this issue before? I'm using NDVA screen reader.

I've attached a different project file which is experiencing the same issues here. Hopefully that one will work for you. Thanks,
Jess

Lauren Connelly

Hi Jessica!

Semantic structure is still a process we are developing. As you've noticed, without designated "headings" and "paragraph" a screen reader will read the content as the same heading style. I'm sorry you're running into this, but I can share that it is a process our team is still perfecting!

 Secondly, I completely understand what you're noticing with the pauses! I haven't seen this issue before and I see that we have a bug logged for the way screen readers pause/stop when reading a text box. I've shared your comments with our team to see if we have a workaround. Thanks for sharing this with me!

I truly appreciate you taking the time to share these comments with me. I hope to share a workaround soon!

Noel Sapp

Because of the way SL exports HTML, the standard tag structure that you (and screen readers) are looking for does not exist. The contents of a text frame are nested within a basic <tspan> tag set. There is no distinguishing headers, paragraph, lists, tables, hyperlinks, etc.

The workaround for hyperlinks is, unfortunately, to realize that because of the <tspan> nesting, screen readers cannot see the link within it. With that in mind, you can at least:

  1. create a rectangle shape around where your hyperlink would be in your text.
  2. Adjust it's normal state's transparency to invisible, then maybe adjust it's hover state to some contrasting color with opacity.
  3. Remove the URL from your text frame and apply it to this rectangular button's trigger to open the URL on click.
  4. In this setup, you now have a physically separate slide object that holds your link. Now you can adjust tab ordering to drop your linked object to read after your paragraph---or at least after the text frame the paragraph shares---and have your screen reader recognize it as a clickable button. Adjust your Alt Text accordingly.

To your question on  headers, Alt Text is all I've found. You might search those keywords here to find something though.

For whatever it's worth, I've had to roll back to the previous build (before the January v3.36 build, as that was the build that introduced all of your issues listed). At least then I could still control tab order, which is how our courses were developed and avoid all the JAWS/NVDA multiple reading of slide text and random other elements from the browser's HTML structure. If you have a test machine or a laptop different from what you're working from you might test to see if that helps.

Ultimately, you may need to have a conversation with your client, your compliance staff, and/or your clients' compliance staff to clarify the actual compliance support (and limitations) of SL projects.

Do search these forums for 508 and compliance keywords though, to see what other users are experiencing. In fact, the second pinned post on page 1 of these forums has two pages of users posting similar concerns and found workarounds that might help. The thread topic is about Accessibility in the new player updates, or something like that.

Jessica Cheung

Hi Lauren thanks for your response.

It's disappointing to see that there is a lack of semantic tags in SL. It's misleading as there is a lot of mention of WCAG and 508 compliance in the information that Articulate shares online (e.g. here) but it fails to mention this enormous Achilles heel that there are no semantic tags associated with the content. The decision-makers in my team made promises to our clients based on the WCAG compliance and it wasn't until it was too late that we realised these types of issues existed... which has created so much extra work for me to do at the 11th hour.

I want to provide feedback that Articulate should make this far more transparent to users.

Jessica Cheung

Hi Noel,

Thanks for your detailed response here. It's somewhat a relief to know that these are issues with Articulate rather than with issues with how I have built the course. It's frustrating though.

I ended up having to create invisible shapes for hyperlinks and manually typing in the 'semantic tags' into the alt text field... This took forever but fingers crossed it passes the client's compliance test. Otherwise, we have to turn to hand-coding our own files (which may have been a better choice from the beginning now that I think about it).

Yes, definitely taking on your point about having a conversation with the clients. With these two current projects I'm delivering that hasn't been possible, as decision-makers already made hard promises of WCAG compliance using Articulate. As I'd never used the software before I didn't discover the issues until it was too late. Will be having a conversation for any future clients though.

Cheers,

Jess

Katie Riggio

Good morning, Jessica!

Thanks for the candid feedback around semantic tag support, and I'm sorry for the tremendous impact this has had on your work. We feel your pain, and that certainly was not our intent.

The lack of semantic styling is an area of focus, as we look to make incremental improvements to our accessibility features.

While there is more work to do, we'll continue to collect valuable feedback like yours and make the tweaks we can. And of course, keep everyone looped in on all developments!

This discussion is closed. You can start a new discussion or contact Articulate Support.