- From: <bugzilla@jessica.w3.org>
- Date: Tue, 12 Jun 2012 11:51:40 +0000
- To: public-html-a11y@w3.org
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 on the CC list for the bug.
Received on Tuesday, 12 June 2012 11:51:54 UTC