tutorial on 508 compliance?

Great idea, Jon -

I work for the government. We take a relatively sensible approach to accessibility. It's about respect and not leaving anyone out in the cold if we can help it. The most common assumption about accessibility is that it's about making sure those with sight or hearing impairments are accommodated. This is a really narrow focus - common but not quite accurate. Accessibility is about so much more than that. From learning disabilities (quite common) to a range of devices universal accessibility is a good thing for everyone. 

We have another level of accessibility in addition to universal called authentic access. This means that if an activity is critical for practice to acquire a skill and requires an ability, don't short circuit the activity. However, don't leave folks with a disability or device that can't see it in the cold. Lett'em know what the activity requires. The law supports this, as the federal requirement upon which it was built was never intended to change the nature of the service. Just to give everyone as fair a shot as possible

On the plus side, most of these requirements also improve the experience for everyone.

Hi everyone,

Storyline’s Flash-based output is 508 compliant.  However, content published for HTML5 and the Articulate Mobile Player is not.  Please review the following article for more information:

http://articulate.com/support/kb_article.php?product=st1&id=te6jcgjd47yv

You can also include alt text that will be read by the screen reading software:

https://player.vimeo.com/video/145579313

Although Storyline content is 508 compliant, you can take your content a step farther by adding on-demand Closed Captioning by using layers and triggers:

http://www.articulate.com/support/kb_article.php?product=st1&id=1keancorydu4

If you really want to understand accessibility, my advice is to install JAWS and take the content for a test drive:

http://www.freedomscientific.com/downloads/jaws/jaws-downloads.asp

Once you get a feel for how a person will actually use the content in a screen reader or JAWS environment, you'll be able to develop better courses.

Coming into this discussion late, but I recently saw a great presentation at ASTD TechKnowledge conference. For slides like drag and drop that just don't work with assistive technology, the presenter put an invisible hyperlink at the top of the slide that said "screen readers click here"  and branched it to a screen with a simplified equivalent. Only screen readers or people tabbing would even be aware of it.

That said, I too would love a tutorial or webinar on best practices when anticipating a course will be read by screen readers. Any update on that?  

Thanks, Steve. I guess we'll just have to agree to disagree on the how "sensible" the approach is. This isn't the forum to discuss it but I'll explain what I meant and then drop it.
Let's say I'm creating e-learning training for a specific task which requires good eyesight and excellent hand-eye coordination. I can see making the training accessible for those with certain disabilities, such as deafness, epilepsy triggered by bright lights, etc., but not for those with blindness or low-vision or for those with physical impairments which would render a person unable to ever perform the task for which the training is being provided. If the guidelines were written so that accessibility requirements were related to job requirements, I'd agree. It's easy to make a blanket rule...everything must be accessible to everyone...but to have to follow this in all instances takes more time and therefore costs more money, when no one with those disabilities will ever be able to perform the task in the real world. This imposes an unnecessary burden on those offering e-learning and those who create it.  Drawing the guidelines with a finer focus would be beneficial, in my opinion.

and...I'm off my soapbox.

Anyway, I do hope Jeanettte or Tom or one of the other Articulate gurus takes up the baton and offers us some tutorials on using Storyline to create accessible training.

Jon,

I'm glad you made this request!  I have high hopes that Storyline published content is accessible by all.  I love the Articulate products, but never could purchase because most of the e-learning content I've created had to be accessible.  Hopefully one of the Articulate folks can provide a tutorial and/or provide some sample projects that are accessible.

Sue

I agree - we need a tutorial and better guidelines.

Yep. I like Jeanette's expanation of the alt text, but it doesn't tell me if my text boxes will be automatically read by a screen-reader. I'd really like to see a full set of tutorials on 508 with Articlulate Storyline. I suspect that those of us who moved into training areas from healthcare or public health careers were thrust into the e-learning arena without benefit of formal training. These agencies, which receive Federal or state funding, many times require trainings to be 508 compliant so we are learning not only how to translate information, either from our own knowledge base or from SMEs, into e-learning courses but also how to make these courses compliant. I will be able to purchase Storyline if I can say for sure I'll be able to make compliant courses with it.    At this point, I'm not certain enough to guarantee that I can.

How about it, Jeanette? I think your explanations are great and would love to see a set of tutorials on this.

Here are a couple of postings that discuss the pros and cons of Storyline's 508 compliance.

http://community.articulate.com/forums/p/13607/80146.aspx#80146

http://community.articulate.com/forums/p/13607/80146.aspx#80187

There are a couple of minor annoyances with the screen reader and some organization's compliance checklists may have a problem with these items. The output is usable and most of the cons on Dianne's list can be worked around.

One thing to note, as I alluded to above with our 2 classifications of accessibility, is that perfect compliance isn't attainable - compliance is a balance. The rules are intentionally open to some level of interpretation and the ultimate test is 1) whether or not the target user can actually use the solution and 2) whether it was actually worth it.

A published output can completely meet each compliance requirement and still be completely unusable (inconveniently frustrating to the point of giving up) or useless (compromised to the point that a document would be just as effective).

Test it to see how it will work for your target population. This is also an early version of the tool, so if you find something that really doesn't work that well for your audience, report the issue so the folks at Articulate can take a look. 

________________________

Here's some verbiage from our internal operating procedures that explains what I mean by sensible accessibility rules. Sadly, very few folks actually read what the requirements say, very few take the rules all the way back to the root of law, and fewer still apply good sense to design decision-making. The rules aren't intended to circumvent good design as draconian law, merely to provide some semblance of autonomy and fairness for those that don't have the same physical advantage as the majority. This stuff doesn't need to be a difficult battle.

"Government agencies providing services and information through any channel are 

obligated to provide universal access to all citizens and employees. Policy, checklists, 

and guidelines exist at the agency level and shall be followed. This section defines a 

model for practice that provides usability while considering the task being trained.

Universally Accessible - Provides a positive experience and complete access to information

regardless of the physical abilities of the user. 

Principles of universal access apply to all ADL products. Much of the discussion 

surrounding accessibility is focused on narrow cases. This relegates Section 508 

compliance testing to “works in a screen reader” or “is closed captioned”. While these 

features are important, this narrow focus ignores a larger audience with disabilities that 

include color blindness, partial vision, motor control and learning disabilities. This 

focus can also lead to unnecessary compromises in the design of the experience.

42 U.S.C. § 12182(b)(2)(A)(iii)

(iii) a failure to take such steps as may be necessary to ensure that no individual with a 

disability is excluded, denied services, segregated or otherwise treated differently than other 

individuals because of the absence of auxiliary aids and services, unless the entity can 

demonstrate that taking such steps would fundamentally alter the nature of the good, 

service, facility, privilege, advantage, or accommodation being offered or would 

result in an undue burden;

The law indicates that a person with a disability cannot be excluded or treated 

differently than a person without the disability. The law also implies that fundamentally 

altering the nature of the service being offered is considered unacceptable. While we 

must pursue universal accessibility at each opportunity, we must also consider the task

represented in the training product. 

If the task requires abilities to perform a task, we must authentically represent these 

tasks in practice. In other words, making design compromises that alter the authenticity 

of the performance of a task defeats the purpose of the training tool. In such cases, 

partial compliance or exclusion from compliance is reasonable; but only for the 

activities that represent the task. All other elements of the product will be universally 

accessible.

This model of accessibility is sensible and considerate. The key to providing a 

sensible level of support for universal accessibility is in determining the performance 

requirements for the task being trained. For example, if a task requires sight or hearing

to perform, this activity will not, necessarily, provide an authentically accessible 

alternative. However, the solution will let the disabled user know that the specific task 

and associated activity require these abilities. The solution will also provide the 

opportunity to skip the activity. This is the considerate component of the model. This 

provides a best of both worlds experience for all users without making inauthentic 

compromises or confusing impaired users. This model for construction provides a clear 

set of principles that make products work for everyone, every time and should eliminate 

waiver requests.  This does not provide an excuse to make technology choices that make 

accessibility difficult. Nor does it provide permission for developers to avoid 

accessibility all together."

"The key to providing a sensible level of support for universal accessibility is in determining the performance

requirements for the task being trained. For example, if a task requires sight or hearing to perform, this activity will not, necessarily, provide an authentically accessible alternative. However, the solution will let the disabled user know that the specific task and associated activity require these abilities. The solution will also provide the opportunity to skip the activity."

Thanks for taking the time to explain the intent of the law, Steve. And I'm sure you're correct about people not taking the time to research the root and intention of the regulations. Maybe you can explain just a bit further to nail down a solution for me. Let's say I am creating an e-course which represents a virtual  Iaboratory, where the user will select tests, view colony growth and see images taken through a microscope to help determine the identity of a bacteria. While it may be true that a person with low vision could see with a properly adjusted microscope, there is much more to the entire task than this and such a disabled person could not perform this work. If the entire course is limited to this one task, i.e., identifying a bacteria ......or performing any other laboratory task for that matter, how would I provide the 'solution' you mention, of letting the disabled user know that certain abilities will be required for the specific task and also how do I 'provide the opportunity to skip the activity'? I can't see how or why such a person would  be accessing this course in the first place. Do I have to post a statement that notifies everyone who might find their way to the site, in a compliant manner, that this is the case?

It almost sounds like you're saying the law is intended to do what I originally mentioned, so that if a user would be unable to perform the task for which training is being provided, that training does not need to be accesible for those disabilities which would render the user unable to perform the task.

I appreciate any further clarification you can provide.

Thanks

I've been working on 508 compliance in a Captivate program and find there is a problem using the Tab key on the keyboard because when the next slide appears, the tab is at the bottom and the screen reader starts reading at the bottom of the page instead of at the top left, as would be expected. Can someone familiar with Storyline tell me if navigating from screen to screen using Tab causes the same problem?

Thanks!