508 Compliance Help

Hi Sarah, 

1. There isn't a way to change the color of this highlight box or remove it entirely as it's a part of the built in accessibility features. You may want to share your thoughts in regards to the color in the form of a feature request. 

2. I'm not sure I'm clear on the behavior here. Is there a hover trigger or additional element set up that is causing this behavior? Could you share this one slide so that we could take a look at it?

3. Tab order is not currently a feature of Storyline, but again another great feature request! 

1. Well, that's what I assumed the answer would be, but I think my client is going to be upset. 
2. There isn't a hover trigger or any other element set up that would trigger this behavior. It's not something that I experienced... it's something the 508 compliance officer at the client mentioned in his feedback on the course.
3. Sigh. Again, what I expected, but I'm afraid there's going to be a lot of backlash on this from the client. I may have to redesign the slides so that they're not tabs anymore.

Hi Sarah,

I'm sorry that these weren't the answers you were looking for - but hopefully other users can c chime in with ideas and suggestions of what they've done to deal with a similar set up. 

Sarah, for your #2 question is your concern that Jaws is not picking up your hover state?  Hover states are not accessible for people with disabilities, I would suggest that you just make them regular buttons with triggers, as long as you use the alt/text to identify it as a button, it will be accessible.

@ Sarah,

It might be helpful to get a complete checklist of what is required from your modules to be acceptable to your client. Unfortunately Storyline (or any rapid development tool that exists) can not build anything that will be 100% compliant. It will fall short of many of the requirements. But there is some good news. You can ask if you can provide the course in an alternate format. According to the Section 508 Compliance site Alternate formats "are usable by people with disabilities may include, but are not limited to, Braille, ASCII text, large print, recorded audio, and electronic formats that comply with this part." A company a worked for before provide the courses we developed in printed form and this met the 508 compliance requirement from the client. 

This is in the Section 508 Law:

§ 1194.5 Equivalent facilitation.
Nothing in this part is intended to prevent the use of designs or technologies as alternatives to those prescribed in this part provided they result in substantially equivalent or greater access to and use of a product for people with disabilities

Hi Sarah, this one is built in to the Flash player. It's been this way for around a decade. Higher contrast can be added to specific elements and controls within Flash but the default focus rectangle has always been this color yellow. It sure would be nice if it was quite a bit darker or changeable. I've worked with some really overzealous testers and this is one that has never come up. I guess I haven't worked with them all:)

Even so, I think it's important to look at the intent of the assist provided by the element. 

1. The visible focus rectangle is to help with keyboard navigation. It's really intended for those with motor control challenges. But it's convenient for a lot of folks, including myself, who like the convenience of using a keyboard. Keyboard controls are also really helpful for those with vision impairments, but not for visual reasons.
2. I can see how this might be an issue for some folks with color vision challenges on really light backgrounds. If that person also had a motor disability, I can see how that might be really frustrating. Couple of ways around this. One is to use a high contrast dark background so the focus rectangle stands out. Another is to take a look at the construction of your selectable elements. In the graphic below, I went into the state of the object and pasted in another shape (with the accessibility tag off) behind my normal state. This produces a more significant contrast around the element. Notice that it overlaps the outside of the element. Tough to tell without seeing your content:)
   
   
3. Those with really low vision probably will have trouble reading what's inside of the focus selection. So there might be a better solution for helping those with low vision than a focus rectangle. The assist most often used by those with really low vision is a screen magnifier. In that case, the focus rectangle isn't helpful at all.

Again, never seen this one come up in around 10 years of doing this. Might want to take another look and run some more testing with alternates to see if specific challenges (versus assumptions of challenges) can be helped.

2. When the user's mouse is hovering over an object, such as a button, it is not possible to tab to select that object. The highlight doesn't appear on the object at all. Is there a reason for this? Is there a way to turn this feature off, or will I simply need to add a note into the course so that users know their mouse can affect the tab feature?

This one is odd as well. I'm not seeing this behavior in my published output. Do you have a published output we might take a look at? You might also want to look at the hover state of your objects to make sure the hover state has "Object is available to accessibility tools" turned on.

As with #1, the tester really needs to think about the intent and function of the focus rectangle. I do think it's possible that an errant mouse cursor could play havok, but if someone is using their mouse -- that person likely don't need the focus rectangle... 

It's working in my output, so I believe it's supposed to. Perhaps it's an issue of the tester's configuration?

Ah. Noticed you're not using SL2. Just tested these in SL1 and both #1 and #2 are working as I described above.

#3... Yep. That's a pretty common beef and a reasonable complaint from testers. Only way we currently have around this is by carefully planning screens to make the tab order logical within the slide. Also make sure that decorative elements aren't set to be visible to accessibility tools and to setup off slide proxies for the screen reader. This is a pain but you can produce one set of objects that aren't set to be visible to accessibility tools on the slide itself and another that is off of the slide. So your tab order runs top to bottom. You have more control this way but need to be careful to make buttons / active elements work so that the focus rectangle will hit them. There's also a downside as some of the focus will be off of the slide. 

No perfect solution... yet:)