Storyline Tab order for Accessibility.

I’m currently working on a compliance module, trying to convince the Powers that Be at my agency that Storyline will produce accessible trainings, so we can buy it and use it (so I don’t have to keep using SoftChalk).  I’m on a trial version.

I need help with tabbing.

I'm attaching a zip file that has a storyline .story that has the slides in question.  Since I wrote this originally a few days ago to Articulate support, I've tried some twists on my original slides to try to improve their usability.  Those trials, with some descriptions in the Notes section, are also included in the attached .story.

I’ve got a page of interactions, for example, that has 3 tabs on the left.  You click each one to view info on that subject (borrowed from a downloaded template).  Works like a charm for mouse-and-sight users.  Sort of works OK for a sighted keyboard user (3 tab example.png attached). The problem is with JAWS.
 
Problem is, for a screen reader, to read what’s in the big explanatory text field that's on the layer that opens when you click the tab, you have to tab to that object/text box.  Ideally it would be the next thing that came up when you hit TAB.  Is it?  No.   I improved things a LOT by unchecking the “visible to screen reader” checkbox in Size and Position for all the colored shapes, etc., but it’s still problematic.  The text that the user needs to read, and logically should come next, is 6 tabs away.
 
It’s even worse on this other slide, where there are 10 circles, each with a name of a group protected from discrimination (Race, Religion, Disability, etc.), and every circle opens a different layer containing info on that group (screenshot in word doc). 

Sometimes you have to tab 12 or more times to get from the original circular button to where the JAWS user can actually "see and read" the text on the new layer.
 
Any suggestions? 

So, one enhancement I want to suggest or +1 is to make the tab order adjustable by the developer.  I've submitted this as an enhancement request.  But this is beyond that I think – I need to dynamically adjust tab order (and/or visibility to screen reader) as part of a trigger.
 
With the Protected Groups slide (the one above with the circle of circles), one of the alternate versions for JAWS is where all other group circles are disabled except the next one that you will click.  This reduces the total number of tabs to “get to the goodies” but is involving a TON of triggers.

This work (with a dozen triggers for each of a dozen layers) causes me to want another enhancement: macros that allow me to bundle multiple triggers.  What I came up with is to put dozens of triggers on an invisible layer and call it up every time someone clicks on a button.  A numeric variable ultimately tells that invisible "macro layer" where to go next after it's done its work.

I'd really like some feedback about how other people are handling tab order, or how specifically you would modify these slides so they're not frustrating for a JAWS user.

92 Replies
Phil Mayor

The tab order is normally the order they appear in the timeline so this is adjustable in some way, you can also right cl;ck and remove some items from the screen reader.

We are restricted by the tools we use, if you are buiding for accessibility then that will affect the way you need to build your interactions

Luke Stollings

Phil,

Thanks for writing.  I got a response a few days ago from John Say in Articulate support.  I was asking if re-naming objects (1textbox, 2oval) would help tab order. 

His response:  The naming of the objects does not affect the tabbingorder nor the layer order of the objects. By default, when you use the tab key, the yellow box will travel throughyour objects from the upper-left corner of the slide to the lower-right corner.

I had tried re-ordering in the timeline and that didn't seem to help.

Phil Mayor

Thanks for posting back, that would explain why it sometimes doesnt seem to work.

But it doesnt explain why if you stack three data entry fields on top of one another that sometimes the bottom data entry field tabs first.

Not sure why it was decided to read the screen like that, would be much better if it had some form of user control

Luke Stollings

Looks like I hadn't uploaded the .story.  Here it is.

I just discovered with this morning's Articulate email that I can set the initial state of an object to hidden.  I'd never seen that button/option, so I was setting that as a trigger when the timeline started.  Thanks Articulate for your great educational tutorials!

Nancy Woinoski

So far I have not been able to determine any logic in how the tabbing order works. It is a mystery. It would be great if someone could shed some light on this. I have tried reordering layers but it does not seem to make any difference. I wonder if certain types of objects take precedent over others?

Peter Anderson

Hey Nancy, 

It was designed to travel object to object from the upper-left corner of the slide to the lower-right corner. Is that not how it seems to tab for you? I'm curious if the yellow box maintains its original order of your objects even after rearranging them on your slide, thus making it seem to be random...

Nancy Woinoski

It seems more random than that but I would have to do a test.  I often use states that contain objects (text, symbols, images etc) and I find that the yellow box will highlight these objects as well - so if I have six states on an object (each with an image) the yellow box will highlight each of these before moving on -  I think that this makes it seem more random to me than it actually is.

Rebecca Fleisch Cordeiro

Thanks to all for this post. First, because I'd read before that tabbing is based on timeline position and when that hadn't worked for me I just figured it was user error (that is, me).

And when I DID try to determine what sequence the tab key was using, I hadn't seen anything consistent, probably mostly after rearranging items on a slide.

I just tested with a simple slide that has only 7 items. Initially, tabbing is "as designed": the image background is picked up first, then each of the other images on the slide, top left to bottom right.

I moved a few items around randomly. Now tabbing picks up

  • the image background first,
  • then jumps to an image in the top center of the screen,
  • then an image to its immediate right
  • next to an item on the left, but not left-most on the screen (2 images to the left of the one in the previous bullet)
  • then to a left-most item, immediate left of image in previous bullet
  • then to a right-most item
  • and finally to an item at the bottom center

I know that's probably hard to follow, just thought I'd throw it in. The more I move items around, the less the tab key follows the "as designed" pattern within the content on the slide.

It does, however, maintain consistency on the player, moving from Menu, to navigation panel, to volume icon, to prev, to next, to Resources (the only items I'm displaying in the player)

Luke Stollings

If you're curious, check out my .story I attached to the 4th reply down from the top in this thread.  Going with the idea that tabbing goes from L to R and T to B, I created hidden or disabled freeform objects that have a little "peninsula" jutting out so that when they are changed (by a trigger) to the normal state, then they should show up next in the tab order (so a JAWS user can read the text they contain right away).  It worked in the prototype slide, but went all to hell when I tried to flesh it out with 3 tabs and 3 freeforms (the NOTES section of each slide describes what I was trying to do).

Luke Stollings

OK, I sent mine.  Notes section has some notes on each slide.  This is a newer version of the .story attached above.  I added back in the "original" slide with the un-clickable bars.  They click wonderfully with a mouse but can't be clicked using the spacebar even when the focus is clearly on that object.

I fixed that problem by removing the extra objects (in this case, little triangles) that appear as part of the selected state. Don't know why it didn't work in the first place, but that fixes it.  Sort of.  The multiple tab foci for each different state is still annoying.

Steve Chorny

Having some serious concerns about using layers for accessible content.   Similar to Luke's examples ( I downloaded and player with his files), I cannot get very simple screens to tab properly.  Here's a simple example:

I want the following content to appear and tab in this order:

  1. Title
  2. Text box 1
  3. Text box 2
  4. Text box 3
  5. Button ( to trigger a layer with 4 text boxes
  6. Layer with Text Box 4, 5, 6 and 7.

The tab order I want is basically the same as the order I presented above.  

What is happening is this:

When I tab, it goes to the following

  1. Title
  2. Text box 1
  3. Text box 2
  4. Text box 3
  5. Button (user presses Enter on Keyboard)
  6. Text box 4 appears (with correct yellow box around it - which is correct tab order)
  7. Text box 5, 6 and 7 appears, one by one, but..... I cannot tab to any of these.  The next tab item is Menu etc.  
  8. After tabbing through several other items on the screen, it then arrives at Text box 5, 6 & then 7. 

What is needed is a methodology to set tab order, as needed, not some random order or an order from top to bottom, left to right.  This is not a good thing.  

At this point, if I cannot get the tab order to work, the addition of layers is a totally useless feature --- when it comes to creating content that can be read by a JAWS reader .    

For non-accessible content, the layers feature is wonderful.  But this is definitely an issue and from what I can see, I don't believe it can be fixed ( at least in this version of Storyline).

Anyone have any similar issues and/or concerns?

L Keith

Hi, I am working on a module that should be compliant, but it can't be read by JAWS. I mean literally nothing, no text, no links, no images, and no buttons. When my JAWS user tabs through, it's as if only frames are included in the tab order.  Based on the threads that I have read, I rearranged my order and set up various triggers. I added alt text as well and still nothing.

Can anyone tell me how I can fix this issue so I can use this software for 508 compliance without the need to create a separate linear sequential course or a separate HTML course.

Any information is appreciated. Thanks. L. Keith

Peter Anderson

Hi L, 

We don't officially support, nor have we tested Articulate authoring environments with JAWS readers or other accessibility tools, but your results may vary. However, the published output is 508 compliant. With that said, we'd be happy to take a closer look at your course to see if there is anything unexpected occuring. Please submit a case, including your .story file, using this link so our support team can assist you further:

 

Thanks!  

Luke Stollings

L,

From one "L" to another, follow Peter's advice and submit the request.  The support people are very helpful and responsive.  Definitely upload your .story file so they can see exactly what's going on.  My guess is that once you figure out how to get the tabbing to work, the screen reader will work too. You might have to hit the down-arrow key to make it read the text in the text boxes once focus lands on that object.  Also, you should NOT have to add alt text to an object that already contains visible text (like a button that says "A. Everyone").  In Storyline, alt text should really just be needed for describing images without words.

Does the tabbing/screen reading work in "preview this slide"/"preview whole presentation"?  Does it work when published?  In my experience they don't always act exactly the same.  Also, at least once I previewed and the tabs worked but the screen reader couldn't read anything, but a different time that same day the preview worked fine with the screen reader.

If, as you say, you get "frames" that are being tabbed through when you navigate by tabbing, those are probably objects (possibly on a different layer) that you need to render invisible to accessibility tools.  There are at least 3 ways to do that:

  1. Uncheck the visible to accessibility tools.  This makes them visible to see, but not to tab to or read with JAWS.  This is the best for "decorative" items like the clip art of your "narrator" character.
  2. Change the state of the object to hidden (or some custom invisible state).  You can change the state with a trigger, so this is dynamic and flexible, but affects "visual visibility" as well as accessible visibility such as tab focus.
  3. You can hide any objects you want in the base layer whenever another layer is active.  You do this in the timeline, by going to the bottom of the list of objects and expanding the Base Layer Objects, and then "blinking the eye" of any object you want to hide.  Note they remain visible when the user returns to the base layer.  This also affects "visual visibility" as well as accessible visibility.
  4. I said there were just 3, right?  Too bad: you can do the OPPOSITE, which is have something visible ONLY to the screen reader by adding text that is the same color as the background.  For example, in the slide that has 3 tabs on the left (Why, When, Who) that I described in the post that originated this thread, I decided it would help the JAWS reader if the tabs were labeled "Tab 1 - Why," Tab 2 - When" etc.  It's obvious to the sighted reader it's a tab, but not to someone who has just landed on it and all they hear is "Why."  So I put the little label Tab 1 on a line above the "Why" on the same object, 1 or 2 point font, same color as the background.  I did the same on the text that pops up to explain the Why -- invisible tiny text saying "Why answer:" followed by the visible explanation of the why.

One thing I would try is opening the course in a different browser.  If you're using Chrome, try Internet Explorer and/or Firefox.  It might make a difference.  Also double-check that your Adobe Flash plugin for your browser is updated to the latest version.

I have to take issue with Peter's wording.  I think it's incorrect (and sounds almost arrogant) to say that Storyline's "published output IS 508 compliant (emphasis added)."  That's like saying "every document produced in Microsoft Word is 508 compliant."  Obviously, a lot falls on the developer to use any tool to create output that is compliant.  Granted, some tools are incapable of producing Section 508-compliant output, and I'm still clinging to the belief that Storyline isn't one of those.  Peter, I think it would be more accurate to say, "Storyline is designed to be capable of producing 508-compliant output."  Just my 2 cents.