W3C home > Mailing lists > Public > public-html@w3.org > July 2007

Re: unifying alternate content across embedded content element types

From: Sander Tekelenburg <st@isoc.nl>
Date: Tue, 17 Jul 2007 22:45:02 +0200
Message-Id: <p06240650c2c2ced4e1c2@[192.168.0.102]>
To: <public-html@w3.org>

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

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

[...]

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

[...]

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

> What indicators would it use?

Whatever is useful. Have you never used iCab? <http://icab.de/>. That
implementation would be one possibility.

> 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 :)

Btw, besides validators there are other tools in existence and being built
that can check the quality of a document: we list iCab, various Tidy
implementations, and TAW at
<http://webrepair.org/strategy/development/tools#existingtools>.

[...]

> One final note on the issue of screen reader expense. I think we're
> starting to see changes in the expense of screen readers. Mac OS X
> now includes a screen reader at no extra charge.

Yes, much cheaper than Windows + Jaws. For most people to switch may still be
an investment though. We'll have to see how many braille readers will be
supported by Leopard. Having to replace a good braille reader is still costly.

Out of the box Voice Over only speaks english though. And AFAIK there is no
way to add other languages. Perhaps there will be in Leopard?

> [...] 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.)


-- 
Sander Tekelenburg
The Web Repair Initiative: <http://webrepair.org/>
Received on Tuesday, 17 July 2007 20:48:09 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:47 UTC