Re: unifying alternate content across embedded content element types

On Jul 17, 2007, at 3:45 PM, Sander Tekelenburg wrote:

>
> At 14:30 -0500 UTC, on 2007-07-17, Robert Burns wrote:
>
>> On Jul 17, 2007, at 10:48 AM, Sander Tekelenburg wrote:
>
> [...]
>
>> I hadn't considered that before: that an image might have alt='' and
>> still have a longdesc. Would not the inclusion of longdesc be an
>> indication that some short fallback is necessary too? In other words,
>> a user might want some quick summary of what to expect in the long
>> description to know whether its an item of itnerest.
>
> 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? Unless I'm missing something here,  
I don't see how using @lat for summaries in this sense is an abuse of  
@alt.


> I'd assume the resource pointed to
> by @longdesc starts with an appropriate heading. That would  be the  
> long
> description's 'summmary'. If there'd be a need to provide users with a
> summary *first*, so they can judge whether it is worth the bother  
> to fetch
> the long description, we'd need yet another attribute for that. My  
> feeling is
> that this would be taking things too far.

Well this just raises a few questions? Based on the logic I developed  
above, how should @alt be used when a long description exists for an  
<img>? If we do not add another attribute for that purpose, then  
wouldn't it make sense to use @alt for this purpose? If we try to  
keep attributes at a minimum to such an extent that we leave holes in  
the accessibility mechanisms, I  don't think that kind of language  
simplification is at all useful.

Also if a long description should include a heading for summarization  
purposes, then the author conformance guidelines should make that  
clear to authors. We cannot just rely on authors to do this without  
making explicit mention of it.

> And anyway, I'd rather see <img> die a horrible death and have  
> authors switch
> to <object>...
>
> [...]

Agree, but some of these problems exist with <object> and other  
embedded content elements too. 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.

>> Again, I think these keywords I propose could be useful here.  These
>> keywords would help differentiate between pages where the author was
>> simply trying to quiet the validator and pages that had carefully
>> considered accessibility.
>
> Would authors not use any of those keywords just to quiet a validator?

I think they would be very unlikely to use those keywords to quiet  
the validator when simply using alt='' would be easier (this is why I  
raised the possibility of authoring by copying content where the  
error of misusing these keywords might be introduced).

>
> [...]
>
>>> 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.
>>
>> 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. It requires a good measure of artificial  
intelligence to determine whether those conformance criteria are  
being followed.

>> [....]
>
> [...]
>
>> A document may be valid and still not
>> be conforming: especially in the accessibility sense.
>
> HTML5 isn't SGML based so I try to avoid speaking of "(in)valid". With
> "conforming", I mean what we used to call "valid" in pre-HTML5 :)

Yes, but a document that adheres to all "must", "must not",  
"required"  conformance criteria may still be a poorly accessible  
document. I would imagine there is a large number of documents that  
will meet most machine detectable conformance criteria and yet still  
misuse accessibility features.

> [...]
>
>> [...] Several open source screen reader and
>> aural browser projects are beginning to mature .
>
> Are they? My impression was they still have a long way to go. (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.

Take care,
Rob

Received on Tuesday, 17 July 2007 21:38:03 UTC