ICDRI's logo

Translate this page automatically. 

Main Body

Google
 


 

 

Test your Site for Accessibility with Cynthia Says

 

 

Home
About Us
Donations
Accessibility
Technology
Calendar
Site Map
Register
Create
Activities
Sponsorship
Products/ Services
Books
Contact
Privacy Policy

 

 

How to Complain to a Webmaster

31 October 2001 
by Kynn Bartlett, <kynn@idyllmtn.com>
Advisory Board, ICDRI; 
Chief Technologist, Idyll Mountain Internet

 

 

Kynn Bartlett's New Book
A terrific book on Cascading Style Sheets by one of the leading experts in the field....

Accessible Technology in Today's Business

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 reaction."

Therefore I thought it would be useful to provide the following general guidelines about how to write an initial web accessibility complaint.

Letter-Writing Guidelines

 

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:

  • 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 management.
  • 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.
  • 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.

Example Letter

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


This essay is Copyright 2001 by Kynn Bartlett <kynn@idyllmtn.com>, and may be reproduced with the permission of the author.

 

 

 

 

Google Enter your search terms Submit search form
 
Web www.icdri.org

Copyright 1998

 

Copyright 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012 International Center for Disability Resources on the Internet Disclaimer and Privacy Policy