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

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

Silvia Pfeiffer <silviapfeiffer1@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |silviapfeiffer1@gmail.com

--- Comment #1 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> 2012-06-12 03:14:36 UTC ---
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 03:14:39 UTC