- From: Charles F. Munat <chas@munat.com>
- Date: Sat, 16 Dec 2000 13:28:06 -0800
- To: "'Marti'" <marti@agassa.com>, <jim@jimthatcher.com>, "'Kynn Bartlett'" <kynn@idyllmtn.com>, <w3c-wai-ig@w3.org>
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