Creating accessible content

Hi Nazely!

Welcome to the community! I am not an expert on 508 compliance, so hopefully other members will jump in with some ideas. I just wanted to note that Content published for HTML5 and the Articulate Mobile Player isn't compliant with Section 508 accessibility guidelines.

We only get a couple of complaints from folks on pretty much any e-learning package we push out:

• Those with limited vision have trouble with seeing presentation elements that move around the screen. It's harder for them to follow. Adding the transcript really helps for these folks and having images that carry meaning appear in a common location also helps. Ideally, we'd have a responsive output that allowed folks to narrow up a window to optimize their scan, but slide-based authoring doesn't lend itself to that. 
• The lack of consistent keyboard controls is a big inconvenience to those with limited mobility. This also hurts the experience of folks with limited vision. Adding a few keyboard controls isn't too tough. Arrow keys to advance and go back are easy. Adding custom "choice" selection for quizzes is a little more complicated but doable.
• Presentation audio / video that starts automatically can be a bummer for folks with vision or hearing impairments. We do tend to start stuff automatically on each slide as the next button does gate the start. There are situations where we pause media at the start with a cue to begin. It's a good practice but a balance. Some folks would like to have the training run from beginning to end as a passive presentation. Others want time to process. If we could provide choice and control for everyone, we would (we try but it's a resources game).

These are Storyline specific complaints:

• The screen reader doesn't pick up all of the player components consistently. Some slide elements are read funny. 
• Tab order isn't always logical for the participant. It runs left to right, top to bottom. 
• HTML5 output isn't accessible. The iPad and iPhone are among the best assistive devices on the market. Really well designed features for accessibility. Hopefully we see something on this soon:)

Thank you both very much for your informative responses! I will pass this along to my colleagues who are designing courses with AS2. 

What exactly is the HTML5 output?

I know our faculty don't intend to use the Mobile Player so I'm not too concerned about that. They plan on uploading short simulations onto Blackboard. 

The HTML5 output is a publishing option. It generates a package that will run on most modern devices including Android and iOS phones and tablets as well as on desktops that have Flash turned off. It's not yet accessible and, for the most part, runs inferior to the Flash based output. Performance and functionality are almost there but it's got some room to improve.

When run, the story.html file will detect the browser features available and will run the appropriate version for you:

1. Try to run Flash if not...
2. Try to run HTML5 (ask to launch in the AMP if it's on a device) if not...
3. Display a message that the content can't be run.

Can you elaborate on 'why' the HTML 5 content is NOT accessible?

That's a good question, Bob. I can't speak to why, I only know that both the documentation and my testing of the output both reflect that it's not very accessible (No keyboard accessibility).

As you probably know, there isn't a technical reason why HTML5 published outputs shouldn't be more accessible than the Flash counterpart. I suspect it's a balance of effort decision. Can't imagine making HTML5 published outputs accessible isn't on the road map.

Well, I hope so... it looks like we will be ditching using Articulate for 5 different government courses that are specifically requiring HTML5 output in the contract. This also means less money in Articulate's pocket as I can't justify buying the 8 additional software copies we would need for our folks. Bummer.... I really like using it. We're still checking the files out for a workaround, but I'm not sure its going to fly. Thanks!