Re: unifying alternate content across embedded content element types

On Jul 17, 2007, at 10:48 AM, Sander Tekelenburg wrote:

>
> At 00:21 -0500 UTC, on 2007-07-17, Robert Burns wrote:
>
>> On Jul 16, 2007, at 10:52 PM, Sander Tekelenburg wrote:
>>
>>> If there indeed is already a textual equivalent in the surrounding
>>> prose -if
>>> that text conveys the author's message- then the image is purely
>>> decorative
>>> and alt="" woud be appropriate.
>>
>> [...] I would never
>> consider an image that rightly belongs in the semantic document as
>> purely decorative. It may be true that there is sufficient textual
>> context provided by the surrounding prose. However, that does not
>> make it purely decorative.
>
> Yes, perhaps me calling them "purely decorative" in that context  
> wasn't
> correct; they're more like an equivalent of the surrounding prose.  
> Either
> way, alt="" seems appropriate to me.
>
> What I *can* imagine is that one would use alt="", and provide a  
> long and
> detailed description of the image through longdesc, in a case like  
> this.

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.


>> As a user confronting a page where I
>> cannot consume the images (for whatever reason), I would want to know
>> what I'm missing.
>
> Have you ever browsed the Web without images, plug-ins, javascript,  
> CSS? You
> go nuts dealing with all the indications of what you're missing,  
> especially
> because the indication refers only to a format. They don't tell you  
> whether
> you're actually missing *information*. The only way to judge that  
> is to,
> somehow, consume that information.
>
> So assuming Web pages that have been authored 'properly', I  
> wouldn't want to
> be bothered/distracted by such indicators.
>
> The problem in reality is that most Web sites are not authored  
> properly. When
> you need to use such a site, you'll need the indicators. But it's  
> still quite
> likely that they'll do you very little good.

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. Sure, some authors may simply copy an image  
from another page, and end up with the keywords misused. However,  
when writing HTML normally it would be unusual to add a "_prose" or  
"_decorative" keyword to @alt inadvertently. To me this would  
separate out those distinct cases and convey more information to  
users (I understand it would convey too much information in non- 
conforming UAs; though there might be ways to work around that).

> More practical might be if UAs allow users to toggle indicators on/ 
> off. I
> know some screen reader users already keep certain useful things  
> switched off
> always, because so many authors abuse them. If you can easily  
> toggle them on,
> that could be useful. Especially if the  UA would indicate that the  
> current
> document is conforming (or not). 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?  
What indicators would it use? A document may be valid and still not  
be conforming: especially in the accessibility sense.

> [...]
>
>> [...] Earlier had suggested adding some reserved keywords to
>> @alt to deal wit this issue.
>
> I must have missed that. Sorry.
>
> [...]
>
>> For reserved keywords, I think something like alt='_prose' and
>> alt='_decorative' would help
>
> Yes, I suppose that might be useful in theory. But I have the  
> feeling it too
> would probably be abused. And it wouldn't be backwards compatible.  
> (Pre-HTML5
> UAs would consider it a plain string.  And we know that upgrading  
> assistive
> technology is too expensive for many users.)

Well, perhaps we could only include those in our UA conformance  
criteria (to be made available to authors in the future, even a  
distant future). It is also possible that existing UAs might have  
certain preference settings, hooks, or hacks that could make them  
aware of a few keywords already.

One thought that arose from our discussion, I was thinking that the  
'_prose" keyword (thee is probably a better term than 'prose') could  
even be used as a prefix for keywords from the surrounding prose:  
something like alt='_prose_Fluffy'. would indicate that much of the  
context and textual equivalent for this image is in the surrounding  
prose and relates to the discussion of Fluffy. Aural browsers would  
eventually (or through configuration now) know to ignore these  
keywords the same as alt=''. However, these UAs would also have some  
indication that this page was a accessibility conforming document and  
that other information may be wroth speaking.

I understand that adding these keywords could be annoying, especially  
for a screen reader that blurts out all of these reserved and author  
keywords. However, if we could find workarounds or simply make it a  
UA conformance preview criteria, this would help deal with that  
problem. This is the first HTML update in nearly a decade now. It is  
hard to imagine how we can introduce vital new constructs without  
doing things like adding them to UA conformance now, so that they can  
be added to document conformance later on.

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. Windows is also  
adding this functionality. Several open source screen reader and  
aural browser projects are beginning to mature . There are even open  
source speech synthesizers. I would not be surprised to see aural  
browsing become a quick, easy and free download upgrade the way  
visual browsing is today.

Take care,
Rob

Received on Tuesday, 17 July 2007 19:30:59 UTC