Closed Bug 882915 Opened 7 years ago Closed 7 years ago

[webvtt] Ensure that voice tags display the speaker on the subtitle

Categories

(Core :: Audio/Video, defect)

defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: reyre, Unassigned)

References

(Blocks 1 open bug, )

Details

Voice tags are currently being parsed and added to the DOM tree correctly, but for whatever reason the voice of the speaker is not showing up on the subtitles.
Rick or Ralph - the spec calls for the title on <span> to be set, which is what appears to be done.  In the browser, the span title gets turned into a tooltip; how are we expecting it to show up in the subtitle?  On a different part of the screen?  As a "voice: text"?  Is how things get displayed specified somewhere?
Flags: needinfo?(rick.eyre)
Flags: needinfo?(giles)
So, the voice tag has contents, the voice name annotation is used as the title, which I guess means that hovering over the text in the user agent will display the title as a tooltip, in most cases.

In theory, CSS3 allows the 'title' to be styled, which could allow for some customization of how the title's contents are actually rendered, but I think that the default expectation is that it gives you a tooltip when you hover the contents of the span.
I can't really find how it is meant to be displayed anywhere in the spec. This is one of those things that needs to be clarified. 

In regards to it being a tooltip I don't think this will work in the current setup of the media element. The media element, if I'm not mistaken, is meant to allow nothing to be able to be displayed within the Video frame, subtitles being an exception. Due to this mousing over subtitles will not be able to activate the event for a tool tip to appear.

To me it would make sense for it to be "Voice: Text" like you suggested Milan. This is the same thing that TV captions currently do when displaying the voice of the speaker. 

One of the other ways to distinguish voices being proposed is to have each voice have a unique colour. I don't think this has made it into the spec either at this point though.gbro
Flags: needinfo?(rick.eyre)
Chrome Beta doesn't display the voices for the subtitles from http://rickeyre.ca/2013/06/20/webvtt-cycle-collector-demo.html, do we expect it to?
I'm not entirely sure. It's hard to tell since tooltips don't work in the Video element.

Caitlin has made a good point on IRC. That currently just setting the title will allow for WebVTT authors to do many different things with it in the future through CSS like this:

http://jsfiddle.net/AxUQ5/1/

I'm not entirely sure if we want to make it this hard for them to get a display like this though.
I'm not up to speed on the schedules, so I'm not sure when "future" is, but naively, this sounds like "there is an implied CSS right now, and they can provide a different one in the future".  If we treat it that way, we can have the "implied" one be more useful, show the voices, and still not stop the web authors in the future providing an explicit CSS with whatever format/look they want?
I actually think we will want to communicate a bit with accessibility people on this, because, while we do probably want to use the basic title attribute behaviour for voices by default, this seems like not a very good strategy for accessibility reasons, in my opinion.

So, either it's a bug that we are not showing tooltips over the media element, or it's a spec bug that we're relying on the title attribute. I'm not sure how this would cause braille terminals, for instance, to behave. It kind of sucks for the visually impaired, and it's not really ideal for people who can't use, or have difficulty using pointing devices. Feedback from accessibility folks would be very helpful.
(In reply to Milan Sreckovic [:milan] from comment #6)
> I'm not up to speed on the schedules, so I'm not sure when "future" is, but
> naively, this sounds like "there is an implied CSS right now, and they can
> provide a different one in the future".  If we treat it that way, we can
> have the "implied" one be more useful, show the voices, and still not stop
> the web authors in the future providing an explicit CSS with whatever
> format/look they want?

I've just started a new discussion on the public mailing list for this so hopefully we'll get some resolution soon. I agree with you though, Milan, on having an implied one to get some kind of support into the tree if it takes a while to resolve.

(In reply to Caitlin Potter (:caitp) from comment #7)
> So, either it's a bug that we are not showing tooltips over the media
> element, or it's a spec bug that we're relying on the title attribute. I'm
> not sure how this would cause braille terminals, for instance, to behave. It
> kind of sucks for the visually impaired, and it's not really ideal for
> people who can't use, or have difficulty using pointing devices. Feedback
> from accessibility folks would be very helpful.

One of the problems with this currently is that screen readers only have access to text that is found in the actual HTML document. So currently it wouldn't even be able to have access to the subtitle text. One more problem to sort out... ;)
> One more problem to sort out... ;)

Don't worry, it would be the last of them. Especially once we start processing TTML, that is a real nightmare.
I don't think we have any responsibility to render the voice tag in our default styling. I wouldn't worry about this for now.
Flags: needinfo?(giles)
(In reply to Rick Eyre (:reyre) from comment #8)

> One of the problems with this currently is that screen readers only have
> access to text that is found in the actual HTML document.

Really? If you add the aria decorators to the anonymous content they're not exposed in the accessibility dom?
(In reply to Ralph Giles (:rillian) from comment #11)
> (In reply to Rick Eyre (:reyre) from comment #8)
> 
> > One of the problems with this currently is that screen readers only have
> > access to text that is found in the actual HTML document.
> 
> Really? If you add the aria decorators to the anonymous content they're not
> exposed in the accessibility dom?

I'm not too experienced in this area so I'm not sure. This is something I heard from an accessibility person at the last open-web open-mic night.
This lack of communication is just awesome and highly commendable
What I'm getting from the public-texttracks list is that right now it should be left up to the author on how to display the voice if they want it to be displayed. 

We can see if we can get a default style into the spec in the future if we really want to or if we see a need.
I don't think this is going to change to include a default style any time soon. I'm marking as invalid for now.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.