Closed Captions being read by Mac OS X Voiceover on Chrome

[marguinbc]

Description

Closed Captions are being read by Chrome (and reportedly FF) when voice over is enabled on Mac OS X. They are not being read by Safari. This appears to be a regression introduced when adding basic description track support; specifically, the addition of including aria-live="assertive" aria-atomic="true" for text tracks to support descriptions.

Steps to reproduce

Explain in detail the exact steps necessary to reproduce the issue.

1. Using Chrome or FF on Mac OSX, open a videojs player with captions enabled
2. Enable Voiceover in the Accessibility options
3. Enable closed captions

Results

Expected

Closed captions will be displayed but Voiceover will not read them

Actual

Closed captions are displayed and read aloud by Voiceover

Error output

N/A

Additional Information

Please include any additional information necessary here. Including the following:

versions

videojs

5.10.8

browsers

Chrome: Version 52.0.2743.116 (64-bit)

OSes

what platforms (operating systems and devices) are affected?
Mac OS X 10.11.5 (15F34)

plugins

are any videojs plugins being used on the page? If so, please list them below.

[marguinbc]

@OwenEdwards, @gkatsev asked me to open this issue and ping you on it. I don't have a plain vanilla VideoJS sample yet but have confirmed it to be an issue using a player based on VideoJS.

[gkatsev]

Was added here: https://github.com/videojs/video.js/pull/3098/files#diff-8739f9458f7e3618b91c858677da1e44R86
I think what we'd want to do is only apply those aria attributes if descriptions tracks are enabled.

[OwenEdwards]

We can narrow it down so that only descriptions tracks are in an aria-live region. But there might be cases where a screen reader user wants to hear the captions!

@marguinbc I'd be interested to hear about a use case where a screen reader user actually wouldn't want captions read out (the old behavior), given that they could always turn the captions off?

[marguinbc]

My main reasoning was that captions are a visual tool for hearing impaired users whereas voiceover is an audible tool for vision impaired users so it kind of makes no sense to play an audible version of a visual tool.

This could also pose difficulty for vision impaired users if the audio track for the content is being played at the same time as the captions are being read - thus having two nearly identical audio tracks and forcing the visually impaired user to have to find and disable captions.

The problem is, I can't find anything in the WCAG specs that says captions should or should not be read by voice over; only that they should be available, in sync with content, provide sound effects, etc. and able to be turned on/off (closed captions).

It's totally a judgement call as to whether we want captions read by voiceover or not. To me, it's redundant and ads a step for vision impaired users to have to turn captions off once (if) they realize captions and content audio are playing simultaneously. It also provides no extra benefit to hearing impaired users who need to read the captions and descriptions to have them voiced over.

[gkatsev]

There's also a mismatch between previous versions of videojs, current versions of videojs, and what browsers do natively right now.

[OwenEdwards]

True, it's not what browsers do natively - that's a good point.

In general Screen Reader users would never have captions turned on. This default attribute in the HTML actually makes no sense from a UX perspective - it shouldn't be up to the page author whether captions are on by default, it should be up to the user. The same for whether a video auto plays but muted with captions, or doesn't autoplay. Or whether Spanish captions are the default rather than English captions.

</rant> That's an argument for a different venue.

Yes, this needs to be fixed so that only descriptions tracks are announced. I don't think any browsers support descriptions tracks natively, btw, but this is how they should support them!

[OwenEdwards]

One more note though - I can't imagine a situation where a hearing-impaired user would have VoiceOver (or any other screen reader) turned on! It does the exact opposite of what they would want - converting textual content into an audible form!

So yes, the real issue is if captions are on by default, for screen reader users. I'll look at a fix for this.