W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > January to March 2000

RE: About ABBR

From: Kynn Bartlett <kynn-hwg@idyllmtn.com>
Date: Fri, 18 Feb 2000 18:47:33 -0800
Message-Id: <>
To: Ann Navarro <ann@webgeek.com>
Cc: Dick Brown <dickb@microsoft.com>, lake@netscape.com, WAI Interest Group Emailing List <w3c-wai-ig@w3.org>, thatch@us.ibm.com, "Gregory J. Rosmaita" <unagi69@concentric.net>, pjenkins@us.ibm.com
At 10:19 AM 2/18/2000 , Ann Navarro wrote:
>Without any disrespect to Dick or Lakespur, this is pretty disheartening
>coming from usability and program manager staff at the major browser vendors. 

Without any disrespect to my esteemed colleague on the HTML Writers
Guild board, I must disagree with her at least in part.

>I'll happily hold up the HTML Writers Guild site as a site that a: makes
>money (and we're not talking pennies here), appeals to a diverse audience,
>is visually appealing, and fits in with our corporate image. It's valid, it
>has some fun design elements (a few that work better currently in IE than
>NN (though that's not an endorsement :) )), and it's single-A compliant. 

As the person responsible for the HWG site, site design, site templates,
site CSS, and site accessibility standards, I need to correct a few
points here myself.

>It *cost us* no more to produce the site in that manner than it would have
>to leave off ALT attributes, not include a doctype, and rely on color alone
>for meaning, etc (see the checkpoints for priority 1 guidelines). 

This is a specious argument because all of the work on the HTML
Writers Guild web site has been done via volunteer labor.  (Most of
it mine.)  It would *cost* no more to produce the site inaccessibly
than accessibly because it *cost* us nothing in the first place.

Also, most web sites do *not* have the luxury of having (in all
modesty) one of the top experts in accessible web design as their
primary web site architect.  It may not have cost the *Guild* any
money to gain the services of a web accessibility expert, but it
did cost -me- a commitment of time, energy, practice, and learning
to reach the point where I am now.

If the Guild -did- have to pay for the web site, it -is- possible
that it -could- cost more, for certain accessibility considerations.

>If *we*, as people who are interested in accessible design, and as people
>who are in a position to influence other designers say 'well, it can cost
>money, and often that's just asking too much', we've skewered our own
>efforts before even beginning. Lead by example. 

Again, I have to respectfully disagree with Ms. Navarro.  It
-can- cost money in some cases to make sites accessible, and at
times that -is- going to be asking too much, depending on the
site.  In my estimation, in most cases it will NOT be asking too
much, and most sensible accessibility considerations are worth
the cost and should be done.

HOWEVER, this points out what I consider one of the biggest problems
with the Web Content Accessibility Guidelines as they stand now --
they present an incomplete view for making business decisions, and
they propose unworkable implementation plans (in the form of
the single-A, double-AA, triple-AAA priority-based checkpoints).

How is it incomplete?  Most businesses will do some variant of a
cost-benefit analysis when considering actions to take.  How does
it benefit the company -- or benefit our users (which really should
be the same thing) -- if we take some action?  And how much does 
it cost to achieve that benefit, in terms of work, time, effort,
knowledge, and money?

The WCAG only offers the "benefits" part of the equation -- not
the costs.  This leaves anyone trying to create an implementation
plan in the untenable position of having to judge for themselves
how much each will "cost" and thus, in effect, requires them to
be accessibility experts (or hire me *grin*) in order to figure
out what to do.

The fact that we have three compliance levels that equate to VERY
poor implementation plans compounds the problem and leads to even
less sensible accessibility plans, and CAN turn web accessibility
into a burden instead of a benefit to the company.  One size does
not fit all when you are talking about companies!  Each one has to
consider their own needs and benefits.

Now, I'm not trying to say it's all doom and gloom, or that every
company should feel free to ignore accessibility if they feel it
is inconvenient.  Why do I say that?  Because I feel that there
are very many WCAG checkpoints (and techniques) which will produce
benefits which far outweigh the cost, and are worth doing from
purely a business standpoint.  ALT text, for example, is a no-
brainer if you're a business.  The benefits, versus the costs, are
so much greater if you can understand -- if you're AWARE of --
the rewards you reap from appropriate ALT text on images.

Other things are not so cut-and-dry.  ABBR can be -hard- to use,
and hard to know when to use, on most web sites.  And if you know
already that nothing uses it, it's even more difficult.  LONGDESC
attributes are another example -- even fewer user agents utilize
LONGDESC (and are there any elegant ways to use this attribute?)
than implement ABBR.  (I -think- pwWebSpeak uses ABBR.)

As a data point, the HTML Writers Guild makes -very- minimal use
of the ABBR element (I think it's only on the HWG homepage, which
I spent slightly more time on, and likely nowhere else on the
site), and it's not part of the Guild's policy requiring our sites
(and our partners' co-branded sites) meet at least a minimal
standard of accessibility.

The HWG's homepage uses ABBR inconsistently.  The W3C's homepage
uses it three times at the very bottom of the page and not on
any of the very technical terms such as CSS, XML, SVG that
could USE some expansion -- just on the copyright notice to
tell us what "MIT" stands for.  The WAI homepage doesn't seem
to use ABBR at all, even though terms such as ATAG and W3C
are used before being introduced.  The Idyll Mountain Internet
homepage doesn't use ABBR (although some IMI client pages do, 
when my wife, who tests on pwWebSpeak, feels it's necessary).
The WebGeek homepage doesn't use ABBR at all, and it could for
terms such as W3C or XHTML.

So, maybe it's -not- so trivial to use this particular tag, and
maybe the benefits are -not- worth the cost.  I don't know.  In
theory, I'd like to go through the HWG site and mark up all the
abbreviations we use, and train our volunteers who maintain parts
of the site to use ABBR.  In practice, there are far more pressing
things to use my own time and the HWG's resources on, and when we
have to make a cut somewhere, an element such as ABBR that does
not do much to affect the accessibility of the site -might- be
left behind on the cutting board.  

It's not as simple as saying "we must use everything that we can
to make a site accessible."  Business considerations -will- be
incorporated into the decisions of what should and should not be

The role of the WAI and other web accessibility education groups
(such as the AWARE Center) is to give those business decision-makers
the ability to make INFORMED decisions -- including telling them that
most accessible web techniques are not a huge burden.


PS:  I mentioned before that Idyll Mountain Internet doesn't price
accessibility as an "optional add-on package."  This doesn't mean
that I don't think it's worth something -- it -does- have a cost that
we pass along to our clients.  Building an accessible site for a
client is a VALUE-ADDED SERVICE that Idyll Mountain provides,
thanks to our experience and expertise in the field, which few other
companies -can- provide.  We -do- consider it a selling point; we
just don't price it separately.  It's part of the package, and it's
figured into the prices for work we do.  It's -not- valueless and
there -is- a cost to our client; that's because you pay for quality
and we are quality web designers.

Kynn Bartlett                                    mailto:kynn@hwg.org
President, HTML Writers Guild                    http://www.hwg.org/
AWARE Center Director                          http://aware.hwg.org/
Received on Friday, 18 February 2000 22:10:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 13 October 2015 16:21:07 UTC