[Bug 10642] No alternative text description for video key frame (poster)

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10642

Brian Huisman <bhuisman@greywyvern.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bhuisman@greywyvern.com

--- Comment #35 from Brian Huisman <bhuisman@greywyvern.com> 2010-10-01 15:38:53 UTC ---
(In reply to comment #32)
> I'd like to add that this bug is a solution with search for a problem. This
> isn't the best approach. We should start by enumerating accessibility problems
> of video and then evaluate which of the possible solutions can solve them best. 

This.  This feels to me like "tacked-on" accessibility, when really what we
need is to re-evaluate the accessibility of the <video> element from the ground
up.

As for the jump-rope example in comment #30, devil's advocate here... If the
webmasters of that particular school chose a key frame from a different part of
the video to use as the poster (a key-frame which did not contain an image of
your daughter), then you would be just as lost *with* an alternative text
attribute as without.

Regardless, the poster is "content", and content must be equipped with channels
to describe it to users who are not capable of viewing the original.  However,
the addition of a new element (eg. <poster>) is always going to be resisted by
the Editors, at least initially, because of the danger of syntax creep and the
need to provide new documentation for each which will inevitably delay the
recommendation of HTML5 even longer.

I've read the specification page, but I'm still not sure how fallback works for
the <video> element wrt flow content (like <object>?), but if you are moving
the poster attribute into a child element of the <video> element, would it not
make sense to use <img> rather than a newly named element?  <img> already
requires the alt attribute, and no new documentation (or at least not much)
would be needed.

Again, the way fallback flow content display works for <video> would be a
factor.  Just thought I'd suggest a possible solution that does not require as
much "work" for the Editors. ;)

-- 
Configure bugmail: http://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 Friday, 1 October 2010 15:38:56 UTC