Re: use of alt attributes in decorative images

since this doesn't seem to be developping into something we can use,
perhaps it should go private?

----- Original Message -----
From: "Kynn Bartlett" <kynn-edapta@idyllmtn.com>
To: "Bailey, Bruce" <Bruce_Bailey@ed.gov>
Cc: <w3c-wai-ig@w3.org>
Sent: February 05, 2001 3:46 PM
Subject: RE: use of alt attributes in decorative images


At 12:22 PM 2/5/2001 , Bailey, Bruce wrote:
>Please Kynn, if you think titles should be included everywhere,
please
>explain how they might be revealed in the graphical user interface!

I don't think I've said titles should be included _everywhere_, but
I don't agree with you that it's -incorrect- to include titles.

How should they be revealed in the GUI?  I don't think I've said
they should be revealed in the GUI either.  They're metadata, and
metadata shouldn't necessarily be revealed in all presentations.

>TITLE is largely superfluous, except on links and ABBR and ACRONYM.
Until
>user agents figure out how to handle the attribute, it should be
avoided.
>This IS a practical, real world, accessibility issue.

Why?  Most user agents either ignore it or make it a tooltip.
Tooltips
can be useful.

>Kynn, depending on the weather, you are frequently in favor of
backwards
>compliant coding and even minor code tweaks to make up for
idiosyncratic
>behavior of Assistive Technology.  I would argue that this belongs in
that
>category.  Unless you are certain of the resultant browser behavior,
avoid
>TITLE.

Depending on the weather?  If you're going to make personal attacks
on me like you made personal attacks on Anne Pemberton before she
quit the WAI IG list, you'd best stop right now, Bruce.

I think you are constructing a number of straw men -- such as the
two I pointed out at the beginning of this letter -- and I also
think you are making a number of incorrect assumptions which lead
to your apparent (and mostly inexplicable) confusion about "what
Kynn is in favor of" (as if that were worth anything; what matters
is access by people with disabilities).

You seem to be forgetting, most of all, that for the last year I
have been advocating the solution favored by my employer, first
Edapta and now Reef.  Lest you think I'm blindly following the
company line (which may be your next accusation, or perhaps someone
will post the accessibility errors on the Reef page, or whatever),
I'll add that I originally joined Edapta because I felt that
approach made the most sense and in fact fit in with what I had
previously independently arrived at as "the best solution."  See,
for example, the CC/PP page I posted during my tenure as the HTML
Writers Guild's member of that working group:  http://www.ccpp.org/

In short, the Edapta philosophy states that you deliver the best
presentation possible to the user based on all knowledge you can
gather about that user.  This means edapting pages dynamically (or
selecting the best from a pre-existing set), and that means that
you can indeed make the types of changes necessary to account for
problems with JAWS (assuming you know the user is using JAWS).

What you perceive as "Kynn changing his mind on a whim" (or "with
the weather" or whatever rather insulting terms you used) is merely
"Bruce unable to keep up with the complexities of edaptation", dear
friend.  Perhaps it's my fault for not explaining clearly enough,
but I think other people have been able to follow me and I've
recently gotten some private compliments on my posts.

>P.S.  One _could_ make the argument that the behavior of JAWS is NOT
broken:
>TITLE is a newer attribute than ALT and therefore an author is more
likely
>to put more thought into TITLE (if present) than ALT (especially
since we
>know how bad ALT tends to be).

This makes absolutely no sense, Bruce.

--Kynn

Kynn Bartlett <kynn@reef.com>
Technical Developer Liaison
Customer Management/Team Edapta
Reef North America
Tel +1 909-674-5225
___________________________________
BUSINESS IS DYNAMIC. TAKE CONTROL.
___________________________________
http://www.reef.com

Received on Monday, 5 February 2001 17:31:50 UTC