Re: Marking up alternative versions of content

At 11:23 +1000 UTC, on 2007-08-04, Jason White wrote:

> On Fri, Aug 03, 2007 at 07:07:12PM +0200, Sander Tekelenburg wrote:

[... <alt for=idref>equivalent</alt>]

> For flexibility, it would be best to allow it in both block-level and inline
> contexts, with a transparent content model, I think.

Yes, that might work.

[... help user decide which alternate to choose]

> I agree that MIMe types may be insufficiently expressive for this purpose.

Thinking about this some more, I suppose authors could use @title. Seems
appropriate, no?
con: no unified identifiers, so users will have to figure out what individual
authors mean with for example title="caption".
pro: no unified identifiers, so authors will have the freedom to describe
types of alternatives that the spec didn't anticipate.
pro: would allow authors to satisfy a user's need to know why an equivalent
was provided
con: does not solve the need to automaticaally dismiss certain types of
equivalents. But possibly, when @title is used, an additional type attribute
avdertising the MIME type would be good enough. A UA could then omit known to
be unwanted file types from being presented, and for all other file types
leave things up to the user to decide based on @title's advisory content.

[...]

>> 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.

FWIW, it seems far too early to me to go into that ;) However, if we would
have to end up with allowing only a single equivalent, it would have to be
marked up text. (Or else HTML would fail to meet the "universality" (or "base
accessibility") need and only satisfy specific ideal accessibility needs. See
<http://esw.w3.org/topic/HTML/AccessibilityConsensus#head-b7bd18ab096371248721e683b16207aef740373d>
for rationale.)

I'm also not convinced that multiple equivalents would absolutely have to
involve a cascade. While it would seem ideal, a flat list might be good
enough. If so, and if a cascade is not realistically implementable, a flat
list might be OK. (Think of how UAs let users select from alist of alternate
Style Sheets, or from a list of RSS feeds.)

> This proposal replaces @longdesc while providing explicit alternatives for
> <audio> <video> and <embed>.

I'm not sure why you name @longdesc and not @alt, nor <img>. I was thinking
<alt> could work for all those, and thus get us closer to a unified authoring
mechanism:
<http://esw.w3.org/topic/HTML/AccessibilityConsensus#head-5dfb39f27fc32ce627f52cbd17727188ecac300e>

[...]

> In legacy user agents, both the media element and its alternatives (or
> alternatives) would be presented "side by side".

Yes, it might satisfy the vackwards compatibility requirement in that
respect. OTOH, I imagine that during a transitionperiod where still many such
legacy UAs are in use, authors will be bothered by 'forcing' equivalents into
users.

I've been thinking that possibly CSS applies here. Authors (and users) could
set <alt> to display:none. But a HTML5 UA would then need to understand to
override in 2 ways:
[1] the existence of <alt> should trigger the indicator that an equivalent
exists, even when it is set to display:none
[2] when the user selects that equivalent, the UA should understand that to
mean that display: none must be overridden

This would appear to be similar to the user selecting an alternate Style
Sheet, so might not be that enormous a burden to implement in UAs.

> User agents implementing
> <alt> could be more flexible, however, in allowing the user to suppress
> alternatives in cases where the media resource is rendered.

I think I simply don't understand theat sentence :) Could you say it in
different words?

> 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.

Indeed.


-- 
Sander Tekelenburg
The Web Repair Initiative: <http://webrepair.org/>

Received on Saturday, 4 August 2007 23:30:39 UTC