[Bug 17463] 'sign' and 'captions' as attributes

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17463

--- Comment #2 from Devarshi Pant <devarshipant@gmail.com> 2012-06-12 11:51:39 UTC ---
This is what I have in mind: Users who interrogate pages using commands like
the links list (say, on YouTube), will get something like, 'Video Name XYZ 1,
Signing available, Captions not available, Transcript available'; 'Video Name
XYZ 2, Signing Not available, Captions not available, Transcript not available'
etc.
I would like to know if such attributes can be exposed for video. Could AT
vendors use these values?
Can't it expose itself like the title attribute? The only difference here would
be that unlike the title, which a user can suppress, this use case will always
pass on the information. For example, on a control like an edit box, a screen
reader will always voice 'Edit' regardless of whether a label is present or
not; or when there is a read only field, it will say 'Unavailable.' 
Coming to your proposed use case, yes, making the video tabfocusable would
work, but isn't that already happening? Wouldn’t it help when assistive
technology could announce / convey information regarding these attributes
(discussed above) when the video has keyboard focus?

Thanks,
Devarshi

(In reply to comment #1)
> What are you trying to achieve with 'sign' or 'caption' attributes? They won't
> help you in exposing a video or audio element better to a screenreader.
> Right now, indeed, the way to consume video is through its controls.
> ==
> In a related note: I've been thinking about video interaction for a bit and I
> think we have some problems in our spec.
> Firstly, the "video" element is not regarded as "interactive content" when
> there are no @controls, see
> http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#interactive-content
> .
> It would be better to assume that video is always interactive content. Then,
> when there are no controls, we would have click interaction on the poster frame
> for play/pause. This is the most fundamental interaction that we need for these
> elements and it should always be possible.
> Secondly, as a consequence of making video interactive, we also need it to be
> tabfocussable, which it currently isn't:
> http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#focus-management
> .
> Thus, the interaction I am after would be to be able to find the video element
> during normal tabbing and be able to hit "enter" to toggle between play/pause.
> Would that satisfy your use case?

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Tuesday, 12 June 2012 11:51:51 UTC