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:10:50 UTC