- From: Ben Canning <bencan@microsoft.com>
- Date: Wed, 31 Oct 2001 09:42:02 -0800
- To: <w3c-wai-ig@w3.org>
- Message-ID: <60A2A60977EC0744BF7A9FEC4417261D01176013@RED-MSG-14.redmond.corp.microsoft.com>
Kynn, I agree with (as usual) about 90% of what you say below. It's
important that we recognize that the problem is one of ignorance and
misunderstanding on the part of designers rather than malice, and
provide as much help as we can to correct the problems we see.
The one quibble I have is one your last point about 'escalation'. I
don't think there's anything wrong with going public about the
inaccessibility of a major site provided it's done with tact and without
ad hominem attacks on the webmasters. In fact, I think it's crucial that
escalation in one form or another does occur.
Clearly the ultimate goal of communities like this is to make
accessibility something that designers naturally take into consideration
when building a site, just as they do browser compatibility today. The
only way that's going to happen is if the lack of accessibility at key
sites is publicized. When web designers (and the people who hire them)
read articles on CNET, SlashDot, MSNBC, etc. about high-profile sites
having massive accessibility problems, they'll not only become more
aware of the existence of the problem and the resources available to
solve it, they'll want to make darn sure they aren't the next site to
get profiled.
Of course, I'm not arguing for this community to becomes a band of
crusading harpies denouncing evil webmasters for building inaccessible
sites - we both recognize that the problem is more a lack of awareness
than malice - but it's only by making the public aware of these
problems, 'escalating' to use your term, that we'll avoid designers
building inaccessible sites in the first place. It's great that you're
willing to provide free accessibility consulting to the SLC site, but
that's not really a scalable solution in the long run, is it? We need to
prevent these sites being built this way in the first place.
- Ben Canning
-----Original Message-----
From: Kynn Bartlett [mailto:kynn@idyllmtn.com]
Sent: Wednesday, October 31, 2001 8:46 AM
To: w3c-wai-ig@w3.org
Subject: How to Complain to a Webmaster
Recently on the WAI interest group mailing list there was a discussion
based, in part, on the reaction of a web developer to an accessibility
complaint about the Salt Lake 2002 site. Context was provided later,
in the form of the original complaint letter to which the developer
was responding -- and I quickly labeled that as an example of "how
NOT to get a good reaction."
Therefore I thought it would be useful to provide the following general
guidelines about how to write an initial web accessibility complaint.
1. Be Friendly and Polite
Ultimately, our goal is to enlist the site operators as allies in
our quest to make the Web accessible to everyone. We can't
afford to alienate anyone who could make a difference, and the
old saying tells us that "you attract more flies with honey than
vinegar."
2. Write to the Web Developer
If you can identify who the actual technical developers are,
it's usually much easier to get the message across to them than
to go through the policy-makers. Web developers are the ones
who can make the changes, with minimum of paperwork and red
tape -- and often the webmaster mentality will be resentful of
"push-down" from above, causing internal friction as they're
"told how to do their jobs."
3. Compliment the Site
It may be seem like flattery -- and to some degree that's
appropriate because we're trying to persuade someone, and we
know that people respond well to criticism if you give them a
compliment first. But it's also true that if the site were
wholly
uninteresting, we'd care a lot less about the accessibility of
the site -- so at least consider saying how much you enjoy the
content or concept of the web site. Expressing interest is
always
a good strategy.
4. Give Three Examples
Don't just give vague statements about "inaccessibility", and
alternately, don't provide them with a laundry-list of WCAG
checkpoints that they've missed. Find exactly three things that
are wrong with the site, no more, no less, and state what those
are in clear and simple language.
5. Give Three Fixes
Explain in a sentence or less what is necessary to fix those
three accessibility barriers. Technical detail isn't necessary;
all you have to do is show that these problems are actually
solvable without requiring a complete site overhaul. Emphasize
the ability to add accessible information without removing site
features.
6. Take the Designer's Needs Seriously
We're asking for the web developer to take our concerns and
needs seriously -- that same respect has to be extended to the
designer as well. If we don't, and we walk away with both sides
shaking their heads, what have we accomplished? The web site has
not become more accessible. So don't insult the web developer's
"worthless bells and whistles", don't act as if "presentation is
meaningless, only structure counts", don't look shocked if the
developer doesn't consider CSS a viable solution.
7. Don't Point Them Directly at WCAG
The Web Content Accessibility Guidelines are overwhelming and
very technical, even to those of us who understand the concepts
of
web accessibility. They are not actually written as an
introduction to web accessibility, and are unsuitable for that
purpose. The checkpoint nature of WCAG also means it's easy
to get the impression that web accessibility is all about
legalistic checking of long lists -- those are a resource, not
the be-all, end-all of the process.
8. Provide Useful Beginner Resources
Instead of sending them to WCAG, point them to resources
specifically meant to be a good introduction to the issue. Good
sites for this include WebAIM, Bobby, and the essays at the
AWARE Center.
9. Establish a Dialogue
Offer to help, basically. Give your email address, and your
phone
number if you feel comfortable with doing that. Offer to test
pages or help explain WCAG checkpoints. Invite the web developer
to write back to you.
10. Don't Threaten
Don't make any threats -- legal or economic or otherwise. Your
goal is to persuade, not to frighten, and the moment you make
a threat, that's when you put the web developer on the defensive
and he has to justify and defend accessibility errors, rather
than
learning from what you have to say. Threats include unstated
ones
such as "you know this is illegal under Section 508" as well as
"I'm going to boycott your site unless it's more accessible!"
A threat will not accomplish what you hope to accomplish.
11. Escalating Rarely Works
It's possible that you might not get a response you like -- for
example, the web developer might write you off as a crank and
never reply to you. Or you might get a response which dodges the
issue entirely. You could find yourself the recipient of a flame
from a particularly overworked designer. There's no divinely
granted right to complain and be taken seriously.
If you don't like the response, you COULD escalate. Examples of
escalation include:
a. Replying with stronger language and outrage, including
threats.
b. Moving the complaint up the chain of responsibility, possibly
even trying to get the web developer fired, or at least
writing to management.
c. Public humiliation by posting complaints on mailing lists
or web sites, up to and including organizing a boycott of the
site or a letter-writing camapign.
d. Filing a lawsuit or ADA/508 complaint.
Of these, few (if any) are reliable when it comes to increasing
the accessibility of the web site in question. Sure, it may make
you feel better -- "how dare someone treat me like that!" -- but
what's our goal, really? Some companies _will_ ignore complaints
of this sort, and short of having some authority to force them to
do what you want, you may have to simply live with it. Try
writing
again in a month or so, change your tone a little, stay positive
and hopeful, and maybe you'll get a better response.
Here's an example letter:
Dear SLC2002.org webmaster,
I recently visited your web site and found it to be a great
resource
of information on the upcoming games -- including the helpful
countdown script telling me how many days are left until the
opening -- at least, it's useful for people who can access it.
Unfortunately, some of the people who could get enjoyment out of
the site might not be able to use it -- specifically, people with
disabilities who use assistive technology (hardware, software) to
access the Web. The coding of the site means that they will be
shut out from getting at information about the Winter Olympics or
the Paralympics.
Most of these access barriers can be eliminated with minimal
recoding and without a need to change the appearance of the site.
For example, frames represent a challenge to users of assistive
technology, but by adding a set of no-frames links and descriptive
labels on the frame declarations, you can greatly reduce the
difficulty in using the site.
Accessing the site in a text browser, I get a message that the
site is only accessible with JavaScript enabled -- but many web
users with disabilities (or those conscious of security) may have
JavaScript turned off. Instead of such an unwelcoming message,
you could provide no-script content conveying the same information
as provided by the scripts.
Many of your images are unlabeled with ALT text -- that simple
change alone makes the site much more accessible to those who are
not able to view images.
Other advice along these lines, which make your site usable by a
broader audience without a need to dismantle your design, can be
found at the Web Accessibility In Mind site, located at
http://www.webaim.org/ You might also be interested in Bobby,
an automated accessibility tester that can identify some key
access problems -- http://www.cast.org/bobby/
I've been working in web design for over 7 years and in web
accessibility for over half that time, so if you have any
questions
I can point you in the right direction to get them answered. You
can send me email at kynn@idyllmtn.com, or give me a phone call
at (XXX) XXX-XXXX (West coast U.S.).
Thank you for your time and attention to this!
--Kynn Bartlett
--
Kynn Bartlett <kynn@idyllmtn.com>
http://www.kynn.com/
Received on Wednesday, 31 October 2001 12:43:31 UTC