RE: Politics: Strict Guidelines Considered Harmful

Marti wrote:
"Suppose, for a moment, that I was somehow able to create pages based purely
on CSS for layout and presentation such that they looked 'right' in the
latest versions of IE and NN.  Further, by some miracle they are ok without
CSS too!  Now, what am I supposed to do about all those 'partial'
implementations of CSS?

"From the legal standpoint it appears,to me, that you could drive the
proverbial truck through the loophole(s) in 11.1. Can any checkpoint be read
as a stand alone element, or should they be viewed in the larger context of
the whole document?"

Reply:

I agree that 11.1 is written in a way that leads to misinterpretation
(largely because people *want* to misinterpret it, just as they do with the
tax codes). It can appear to be saying that all bets are off, i.e., that
everything else in the document is optional. And that is how some people
read it, unfortunately.

But let's take a closer look. If "Use W3C technologies when the are
available and appropriate for a task and use the latest versions when
supported" means use whatever you want to use, then what is the point? I
could argue that there will always be users out there with Netscape 2 or 3,
thus I will never need to abandon <font> and <b> and <i>, etc.

Is that really the intent of 11.1? I think not. Here's my interpretation,
and I don't think it is particularly "strict," "unreasonable," or a stretch:

"Use W3C technologies"

HTML, XML, SVG, SMIL, etc. as opposed to PDF, Flash, proprietary HTML, etc.

"when they are available"

When they are finalized as recommendations and the preponderance of browsers
support them. Note: this does not mean that you can't use bleeding edge
technology as long as it degrades gracefully.

"and appropriate for a task"

HTML for structuring text, CSS for style information, etc. Note: here is yet
more confirmation that <font> should be avoided if possible: It is not
*appropriate* for the task.

"and use the latest versions when supported."

Now that XHTML is out (and supported by all browsers), it should be used in
preference to HTML. Now that CSS2 is out, it should be used in preference to
CSS1 (checking to ensure graceful degradation, which should be no problem
except on a couple of "bad" browsers like IE3).

The big difficulty most people have with 11.1 is with the "when they are
available" part. A truly strict interpretation of this would be "as soon as
they are W3C Recommendations." I think we can all see that that
interpretation is a bit unreasonable. Implementation should occur as browser
manufacturers make them available in their latest versions.

But to read "when they are available" as "when every last browser on the
face of the earth supports them" is just as unreasonable.

Think about this: One of the biggest arguments used against accessibility is
the 80/20 rule. Design for the bulk of your audience and don't worry about
the rest. (Yes, I know that people with disabilities represent more than 20%
of the audience, that there are lots of other reasons to follow the WCAG,
etc., but this *is* a big stumbling block).

Now, with the 80/20 rule in mind, isn't it ironic how many web site
developers are whining that style sheets aren't supported by Netscape 2 or
3? I don't have hard figures, but does anyone really believe that style
sheet-enabled browsers (not counting IE3) do *not* account for more than 80%
of browsers currently in use?

The big difference here is that using the 80/20 rule to justify not making a
site accessible *LOCKS OUT* that 20% (or more), whereas applying the 80/20
rule (or even 60/40) to style sheets vs. <font> only means that that 20%
will see a plainer looking site. There is still, of course, the requirement
to ensure graceful degradation.

So 11.1 is no loophole at all. In fact, it is further proof that <font>,
<b>, and <i> are obsolete (as are Netscape 2 and 3 and soon [please, please,
please] 4).

But let's go one step further. Kynn argues that <font> does not impede
accessibility. I don't agree, but even if Kynn were right, the question
remains, is it needed for accessibility? Kynn seemed to imply in one post
that using <font> would increase accessibility on Netscape 3.

Frankly, I don't think ANY styling of pages is necessary to make them
accessible. In fact, styling often interferes. Images are useful, as Anne
points out, for increasing accessibility to those with learning
disabilities, but the basic structural elements of HTML, together with the
default formatting of the browser, are all that's required to make a
document understandable.

As Dave Woolley points out, <font>, <b>, and <i> are most often used to
avoid using proper structural markup. How many times have we all seen sites
where <h1></h1> is replaced by <b><i><font size="5"></font></i></b>? And the
reason for this is *always* because the user doesn't *like* the look of the
default h1 formatting. It has nothing to do with accessibility or usability
or cross-browser compatibility (in fact, it is antithetical to cross-browser
compatibility and accessibility).

What it all really comes down to is this: web site developers do not want to
give up *control* over the LOOK of their sites. They can't stand the thought
that their sites might not look flashy in Netscape 3, or might not look
identical in Netscape 4 and IE 5. It's not the customers who care. Customers
want sites that are functional, fast, easy to use and understand, and
attractive. But they don't care if those sites are green or blue, use Arial
or Verdana, have vertical rules or white space separation, etc.

That's what I mean when I say that it is the designer's EGO that creates
these problems. If the intent is only to make the site pleasing to the
consumer, it is not that difficult to come up with a simple, attractive
design that looks good on all CSS browsers and degrades gracefully on older
browsers. There is plenty of room, even within the narrow confines of
current style sheet implementations, for differentiation. But as I pointed
out in an earlier post, most sites *don't want* to differentiate their
sites. Look at all the Yahoo clones out there. The leader differentiates,
the rest copy.

In fact, my experience is that the closer I get to pure XHTML strict (with
the exception of the align and border attributes on images), the EASIER it
is to get my sites to look good on all browsers. It is when I start trying
to force browsers to display pages in ways they were never intended to
display them, and resorting to broken, workaround code, that I run into
difficulty.

Finally, the truth is, as I wrote more than two years ago on this very list,
that making sites accessible is NOT easy. It requires a commitment to
accessibility, a strong understanding of the underlying code and the
thinking that went into it, and an ability to set aside one's ego and to
embrace the idea that control of the user's experience is an illusion.
(Interestingly, Kynn disagreed with me quite fiercely then. Now he seems to
have run to the other extreme and is arguing for weakening the standards
because they are *too* difficult.)

This is the *real* reason that so many companies and people are resisting
accessibility. It is not because attractive, accessible sites can't be
built. Coding such a site is really quite simple. And it's not because those
attractive accessible sites won't sell the product as well as the current
inaccessible sites (often they will sell the product better). It is because
companies and individuals can't bring themselves to give up the idea of
total control over the user's experience. You can see this in many more ways
than just by their inability to let go of <font>. Look at the abuse of
cookies to track people, the obsessive gathering of personal information,
etc. Companies, in particular, want total control.

So, in sum, 11.1 is not a loophole unless it is twisted beyond all
recognition (until it makes the document effectively meaningless, because
you can then do anything you want and claim that the alternative is "not
available").

And as for bad implementations such as IE3, I would say that we should
consider IE3 "broken" and disregard it (unless you are serving pages
dynamically and can adapt to it). While I hate to say that any browser is
unusable, when you weigh the cost to accessibility of adapting to IE3's
problems against the meager benefits (does anyone still use it?), it makes
more sense to dismiss it. Hopefully, in the not too distant future, we will
be able to say the same for Netscape 4.

Charles F. Munat

Received on Saturday, 16 December 2000 16:22:16 UTC