- From: Jason White <jason@jasonjgw.net>
- Date: Sat, 4 Aug 2007 11:23:29 +1000
- To: public-html@w3.org
On Fri, Aug 03, 2007 at 07:07:12PM +0200, Sander Tekelenburg wrote: > Ah, right. I get it. <alt for=idref>equivalent</alt> would then remove the > need for the equiv attribute that I suggested. It would also not need @rel, > and thus remove the need to refine the definition of @rel. (Or am I > overlooking something?) No, I don't think you're overlooking anything; @rel is not needed in this proposal. > > Yeah, that would seem to be easier to author and easier to implement. > > A potential issue: thinking about the different types of situations in which > publishing of equivalents would need to be possibe, it would seem to be > necessary to allow <alt> as both block and inline. (Or not? I don't really > 'see' that yet.) For flexibility, it would be best to allow it in both block-level and inline contexts, with a transparent content model, I think. > > [...] > > > With all three proposals, there arises a need to specify how a user agent > > should treat multiple idrefs referring to the same element. As you suggested > > elsewhere, a type attribute could be introduced to distinguish different > > alternatives to the same media element. > > Right. But unless I'm mistaken, type is currently only for MIME types. It > might not be wise to start allowing other sorts of values. Or would > "application/video+caption" and such be appropriate? I don't know enough > about MIME types to judge that. I agree that MIMe types may be insufficiently expressive for this purpose. Furthermore, if one media element is used as an alternative to another, the task of deciding whether the alternative can be retrieved and rendered is the same as for the original, so I don't think additional resource type information needs to be disclosed in the proposed <alt> element. > > > All of the above proposals are > > compatible with a policy of allowing only one alternative to be associated > > with any given media element (the first alternative, in document tree order, > > would be treated as a fallback, with the remainder of such alternatives being > > ignored, i.e., as though @irrelevant were in effect). > > I can't follow. Why would multiple <alt> elements referring to the same id > through @for, not be possible? They are possible, and indeed I would prefer that they be supported; but I'm open to a more restrictive proposal that enforces a "one alternative per media element" limitation, for the sake of simplifying the implementation. Without such a restriction, we have a "cascade" of fallbacks as in <object>, and I can foresee that this may be criticized as unduly complex. This proposal replaces @longdesc while providing explicit alternatives for <audio> <video> and <embed>. It is also compatible with any attempt that may be made to simplify the content model of <object> on implementation grounds. In legacy user agents, both the media element and its alternatives (or alternatives) would be presented "side by side". User agents implementing <alt> could be more flexible, however, in allowing the user to suppress alternatives in cases where the media resource is rendered. Assistive technologies and voice browsers could alert the user to the presence of the alternative content in a uniform fashion, without relying on implicit associations in the content of the document. Finally, accessibility conformance checkers could verify the presence of the alternative content programmatically, furthering the widely held objective of improving the automated testability of accessibility requirements. There may be other advantages to this proposal as well; the above are not intended as exhaustive.
Received on Saturday, 4 August 2007 01:26:49 UTC