Re: unifying alternate content across embedded content element types

At 16:16 -0500 UTC, on 2007-07-17, Robert Burns wrote:

> On Jul 17, 2007, at 3:45 PM, Sander Tekelenburg wrote:
>
>> At 14:30 -0500 UTC, on 2007-07-17, Robert Burns wrote:

[... summary fopr @longdesc]

>> Yeah, but given that @alt is for equivalents, not for summaries, it
>> wouldn't be appropriate to abuse it for summaries.
>
> @alt is for short equivalents (even more so with your proposal). When
> a long equivalent exists, then @alt is still required: presumably for
> a short equivalent. What else is a short equivalent in this case than
> a summary of the long equivalent?

Sure, if a good equivalent can be provided through @alt, it would probably in
effect serve as a summary of @longdesc, I suppose. I'm just saying that, in a
case where alt="" is what makes the most sense, then changing it to contain a
summary for @longdesc doesn't seem right. Or in cases where it does seem
right, probably alt="" was wrong in the first place.

[...]

> Making <img> go away alone does not
> solve these problems. There's still the problems of: 1) short summary
> fallback and 2) how to differentiate decorative media from
> accessibility neglected media from media that requires no fallback.

Yes.

[...]

>>> How would the UA determine whether a document was conforming or not?
>>
>> Through its  built-in conformance checker.
>
> The problem with that is that much of the accessibility criteria
> relate to "should" and "should not" or even "may" and "may not"
> conformance criteria.

I really didn't mean much more than what I wrote: "screen reader users
already keep certain useful things switched off always, because so many
authors abuse them [...] It would be interesting to try a UA that
(optionaly) presents all alt text, longdescs, @title @summary, etc. on
conforming documents, and not on non-conforming documents -- the  assumption
being that in a conforming document it is likely that those attributes aren't
being abused."

I meant syntactic HTML conformance. I'm well aware that it is far from easy
to programmatically judge the accessibility of a document. That was sort of
the point: given that problem, the assumption that a syntactically conforming
document is more likely to be authored accessibly seems interesting.

[...]

>> (We discussed
>> screen readers and such a few months ago. IIRC Maciej inserted
>> found data in the wiki.)
>
> Do you know which wiki page that is? I can't seem to fine it. Thanks.

<http://esw.w3.org/topic/HTML/UAs#head-7f6a7cde20a4f041307a387d854887c52c72b4af>

While there, I noticed that the chapters for CMSs and authoring tools were
still empty. I've added a pointer to the WRI's list of 300+ known systems.

Btw, IMO there is no reason to make the distinction between "HTML Content
Management Tools" and "Authoring Tools". At the WRI we take the view that if
it generates Web pages, it is an AWPS [Automated Web Publication System].
Maybe not the coolest abbreviation, but it's useful to have a single term
that applies to all such systems.


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

Received on Wednesday, 18 July 2007 01:28:07 UTC