W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > July to September 2004

[w3c-wai-gl] <none>

From: Gregg Vanderheiden <gv@trace.wisc.edu>
Date: Fri, 10 Sep 2004 09:26:28 -0500
To: "'wai-gl'" <w3c-wai-gl@w3.org>
Message-ID: <auto-000089586807@spamarrest.com>
A recent posting – on a blog.

 

It is interesting though at as we look at our guidelines.


Gregg

 

 

 

 

 

Web accessibility litigation: it’s not what we want

 

(Web, accessibility, Mon 23 Aug 2004 17:03 PDT [532]) 

 

 

 

Accessibility by litigation: it’s not just a British-and-Australian thing
anymore. New York Attorney General Eliot Spitzer settled on Thursday with
Ramada and Priceline, setting out rules based on the W3C Web Content
Accessibility Guidelines 1.0 to make their sites accessible to “the blind
and visually impaired.” (<sarcasm>Because they’re the only ones who really
matter, right?</sarcasm>) For people in the field of accessibility, this is
a victory; users of the updated sites, though, may find the war is far from
over. What follows is a long, long explanation of what just happened, what
it means, and why Web designers need to wake up quickly before they get
owned.

 

How we got here

 

Here is a brief history of Web accessibility policy. (I am not a lawyer.)

 

There are two dominant policy documents in the field of Web accessibility:
WCAG 1.0 and Section 508 of the Rehabilitation Act of 1974. Section 508
relates to Federal agencies and their purchasing rules; it is more objective
(though not entirely: I sat on one “objective measures” task force for 508)
and more limited in scope than WCAG 1.0. Some states have used 508 for their
accessibility guidelines, some have used WCAG 1.0, some have used a hybrid,
and some have no guidelines at all. What each state’s guidelines apply to
also varies widely.

 

Additionally, the Americans with Disabilities Act of 1990 (ADA) requires
services provided “by places of public accommodation” to be accessible,
though what that means for the Web is the subject of much litigation. The
preliminary ruling in Access Now v. Southwest Airlines was that the ADA does
not apply to the Web, while the ruling Martin v. MARTA was that it does.

 

In the Ramada and Priceline settlements, Spitzer comes down on the does
side, citing ADA as the reason the companies have to comply. This does
little, as far as I’m aware, to advance that decision, since no judge has
ruled on it, but it does show that companies are likely to see more of these
cases.

 

If ADA does in fact apply to the Web, the next question needs to be asked:
by what standard do we define accessibility vis--vis ADA? At some point,
this question will need to be answered, by the court system, Congress, or
both. 

 

In these cases, the answer was WCAG 1.0. Or some subset thereof, according
to the filing. Both Ramada and Priceline agreed to subsets of double-A
conformance to WCAG, but each company won concessions which could have a
negative effect on the actual accessibility of the updated sites. I’ve
compiled a list:

 

Priceline

 

Having read the settlement, I have to say that Priceline’s culture of
haggling served them well. They avoid having to conform to three Priority 1
checkpoints, along with some twenty-one Priority 2 checkpoints. This is what
Priceline doesn’t have to do. (WCAG checkpoints as listed are summaries of
the original checkpoint text.)

 

1.3: Audio descriptions of multimedia (Priority 1) 

 

1.4: Synchronized alternatives in multimedia (Priority 1) 

 

Priceline says they don’t use multimedia now, but apparently if they do in
the future, nothing in this settlement is to stop them from doing it
inaccessibly. 

 

2.2 Contrast between background and foreground (Priority 2 for images) 

 

A head-scratcher: what’s so hard about decent contrast? 

 

3.2 Valid documents. 

 

3.3 Style sheets for layout and presentation. 

 

3.6 Mark up lists and list items properly. 

 

3.7 Mark up quotations. 

 

5.4 If a table is used for layout, do not use any structural markup for the
purpose of visual formatting. 

 

5.3 Do not use tables for layout unless the table makes sense when
linearized. 

 

7.2 Avoid causing content to blink 

 

11.1 Use W3C technologies when supported and appropriate 

 

11.2 Avoid deprecated features of W3C technologies. 

 

Priceline steadfastly refuses to comply with two requirements of WCAG
conformance: they will not make their site valid, and they will not use
style sheets for presentation. Lots of this appear to be tied to their
1997-esque design: they use tables for layout extensively, loads of FONT
tags, the antediluvian CENTER, and precisely three lines of CSS total on
their homepage. Would it take some time to bring their homepage into this
decade? Yep. Would it kill them? No. Does this have an impact on overall
accessibility? You bet. Most of the resulting accessibility problems in the
final product will hinge on Priceline’s unwillingness to produce
standards-compliant, semantic code. 

 

6.4 Device-independent event handlers 

 

6.5 Ensure that dynamic content is accessible or provide an alternative
presentation or page. 

 

8.1 Directly accessible applets and objects (Priority 1 for important info,
Priority 2 otherwise) 

 

9.2 Device-independent interface widgets 

 

9.3 Logical, device-independent event handlers 

 

And here’s where most of the rest of the problems will come from. No
applets, Flash movies, or other media will be made directly accessible. It
appears Priceline will be relying heavily on WCAG’s major loophole,
Checkpoint 11.4 (if you can’t do it after your best effort, make a separate,
accessible version), which is tragic. As I’ve said before in On “separate
but equal” design, this is segregation, and it’s almost always the wrong
answer. 

 

7.4 Do not create periodically auto-refreshing pages. 

 

10.1 No popups without informing the user 

 

These are both well-known accessibility problems that Priceline does not
attempt to resolve. Somehow, in both Priceline’s and Ramada’s settlements,
the checkpoint preventing popups has somehow turned into a requirement of a
“Close Window” link on the popup after it’s been fired, which does nothing
for the actual problem of stealing the user’s focus without permission. 

 

12.2 Describe frame relationships 

 

There’s no reason not to agree to this, that I can think of. Especially
since Priceline says it doesn’t use frames. 

 

12.3 Divide large blocks of information where appropriate. 

 

This deals with simple things, like grouping related controls using the
FIELDSET element. Again, not hard, no real reason not to do it. 

 

12.4 Associate labels with controls. 

 

The LABEL element is laughably simple to implement. 

 

13.3 Site map 

 

Another easy one. 

 

13.4 Consistent navigation 

 

This requires navigation systems to operate similarly across pages. Failing
to do this means that users, including those using screen readers, cannot
rely on links doing what they say they do. 

 

Ramada

 

2.2 Contrast between background and foreground (Priority 2 for images) 

 

Hmm. What’s so hard about this that both Ramada and Priceline flagged it? 

 

3.3 Style sheets for layout and presentation. 

 

7.3 Avoid movement in pages 

 

11.1 Use W3C technologies when supported and appropriate 

 

11.2 Avoid deprecated features of W3C technologies. 

 

I think Ramada wants to use the FONT tag. And MARQUEE, too. 

 

3.4 Relative units in CSS 

 

In an effort to preserve their extensively pixel-sized site, Ramada has
hard-coded into its settlement a workaround that will please nobody: they
will create an alternate style sheet, put it in a “Change Font Size” link,
and – get this – instruct users with disabilities to download it and set it
as their user style sheet. What, they couldn’t even let them set a cookie to
request usable fonts? To me, that would be the bare minimum to conform to
this requirement.

 

Even if you’re the type who likes to argue that “px” is a relative unit, the
fact is that Internet Explorer renders it inaccessibly, and that means that
for the foreseeable future, it’s broken. If your designers can’t design
around that simple constraint, you need to get new ones. 

 

10.1 No popups without informing the user 

 

Shock of shocks: Ramada’s site uses them now. Still no recognition that it’s
an accessibility problem. 

 

13.1 Clearly identify the target of each link. 

 

Another curious one. This was intended to prevent links that say “click
here", which – ooh! look! – Ramada’s site has in spades. Why is this a
problem? An exercise: pull up a page like Ramada’s in a screen reader.
Listen to it say “click here. click here. click here. click here.” in links
mode. Shoot yourself before the pain gets unbearable. 

 

14.1 Clear and simple language (Priority 1) 

 

Here’s one that Priceline didn’t bother with, but Ramada takes offense to.
And it’s not a hard one, per se. It’s just subjective, and to marketing
groups, it ranks somewhere between garlic and a silver bullet. Nobody wants
to be told you can’t communicate in a certain way, but the more you deviate
from simple communication, the more people you’re going to confuse. The
biggest problem with this checkpoint is that there’s no objective measure
possible for it, even though clear and simple communication is critical for
larger populations than many of us are willing to admit to. 

 

Conclusion

 

A new chapter is being written on this side of the pond on the topic of Web
accessibility. How it turns out is anybody’s guess, but my guess is that the
outcome will not be satisfactory to anyone. In other words, this is not the
road we want to go down. 

 

Accessibility by law is always going to be inferior to accessibility by
conscience. I would rather see accessibility happen as the result of
thousands of smart, responsible Web designers, rather than thousands of
pages of legalese.

 

And while I’m at it, let me say this to the folks who are demanding
bulletproof, objective, testable criteria from the next version of WCAG:
this is not what you want. You do not want any authority to state that
accessibility is as easy and clean as a mathematical formula. You do not
want to be forced to test your writing against Fog indexes, or have entire
technologies circumscribed, just for the sake of your own convenience. Any
normative test suite for Web accessibility would stifle the creative process
of every designer by its very nature, and that’s a worse fate than you could
ever imagine. (And much worse for users, as well.) Web designers are much
better off using tools that help them create accessible content, and
learning the problems and solutions involved in accessibility. WCAG 2.0 is,
in my opinion, a step in the right direction. 

 

 

 

(See also: Kassia Krozser’s view on alt tags.

 

 

 


Gregg

------------------------

 

Gregg C Vanderheiden Ph.D. 
Professor - Depts of Ind. Engr. & BioMed Engr.
Director - Trace R & D Center 
University of Wisconsin-Madison 
< <http://trace.wisc.edu/> http://trace.wisc.edu/> FAX 608/262-8848  
For a list of our list discussions http://trace.wisc.edu/lists/

 

 <http://trace.wisc.edu:8080/mailman/listinfo/>  

 <http://trace.wisc.edu:8080/mailman/listinfo/> 

 

 

 

 

 
Received on Friday, 10 September 2004 14:26:32 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:17:58 UTC