David Singer wrote: > > I think if we had the clear designs for providing the description of > the video, we could easily decide; worse, that much of the current > discussion takes so much time because we don't have a clear solution to > the larger problem, and so a solution to the smaller has no foundation. I had proposed earlier the following "design" (and please do note that the proposed design acknowledges your point that there is *1* <video> object/element, thus the string of attributes (properties) of that element: <video controls longdesc="path to longer textual description which relates to the Media asset" aria-posterdesc*="path to longer textual description related to the @poster image" (formally firstframe=" path to longer textual description related to the @poster image") transcript="path to full transcript of the Media Asset" poster="path to static image used as a placeholder prior to the playing of the media asset" src="path to encoded media asset"> </video> (http://www.w3.org/html/wg/wiki/ChangeProposal/Issue203) There are dependencies there, which I pointed out to the Chairs - they rejected my idea as it was not specific enough. David, if we had @longdesc retained in HTML5 2 years ago, we could have looked to expand its functionality to be the means of a longer textual description of the video itself (the media) - but the Chairs fear @longdesc and cross the street to avoid it. It may be too late (or maybe not), but it represents a possible way forward, so don’t be too quick to judge it (we would have the added bonus that some screen readers today would already have support, so a quick and easy win for *users*). Continuing: I have proposed @transcript as a semantic means of associating the transcript file. (http://www.w3.org/html/wg/wiki/ChangeProposal/Issue194) I have proposed 2 different ways now of associating a longer textual description of the "junior" image - the @poster image - and they get dismissed as "crazy", or re-arranging deck-chairs, or wanting to cling to old ways and minutia of little relevance. Believe it or not, I have been stepping back and trying for a larger picture solution, while looking for reusable solutions that do not rely on the Accessibility APIs alone (which all of the ARIA attributes do today - but that is changing) Have I missed anything? I certainly agree we need a "whole" solution, and I have been trying in my own way to address that problem, but when we cannot get answers to a 2 year old question around a specific attribute (@longdesc) it creates a log-jam in other areas as well, this being one of them. I have tried to address this holistically, and welcome your feedback here or elsewhere. JFReceived on Wednesday, 21 March 2012 23:16:02 UTC
This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:50 UTC