How to Complain to a Webmaster
Bartlett's New Book
A terrific book on Cascading Style Sheets by one of the leading
experts in the field....
Constructing Accessible Web Sites
This is the most complete book ever published on the
subject!... Plus some others books that will help you build
exciting accessible sites!
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
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
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
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
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
- Replying with stronger language and outrage, including threats.
- Moving the complaint up the chain of responsibility, possibly even
trying to get the web developer fired, or at least writing to
- Public humiliation by posting complaints on mailing lists or web
sites, up to and including organizing a boycott of the site or a
- 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
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
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 firstname.lastname@example.org,
or give me a phone call at (XXX) XXX-XXXX (West coast U.S.).
Thank you for your time and attention to this!
This essay is © Copyright 2001 by Kynn Bartlett <email@example.com>,
and may be reproduced with the permission of the author.