joeclark.org: Joe Clark

You found the original styled document here:
www.joeclark.org/glorious.html

The Glorious People’s Myth
of Standards Compliance

We are told that two browsers currently available fully meet the HTML 4 standard.

Growing up, we were also told there was such a thing as Father Christmas. The truth of how our presents arrived under the tree was rather different. So is the truth of standards compliance.

We hear so much about the HTML standards compliance of Netscape 6 and Internet Explorer 5 for Macintosh that the tone approaches propaganda. But there is ample evidence, much of it irrefutable, that neither browser actually does support the full HTML 4 specification.

It appears that the particular HTML tags unsupported or improperly supported – most of which deal with accessibility – are not important. Or at least they are not important to the people declaring these browsers standards-compliant. Evidently it is OK to claim a browser meets the standard if the parts it doesn’t meet are irrelevant to you.

It would of course be excessive to situate this phenomenon in a decades-old continuum of ignoring and devaluing accessibility in old media like print, television, and film. New media were supposed to be different, and better. So far, not quite.

Impassioned declarations

Netscape 6 finally came out, after enough of a wait to try Tutankhamen’s patience. The browser was hailed for its standards compliance. The Web Standards Project went so far as to declare:

The Web Standards Project... applauded Netscape for producing the most standards-compliant browser the Web has yet seen. Based on the open-source Mozilla project, Netscape 6 exceeds all previous browsers, including Netscape's own, in the scope of its support for W3C and other Web standards. The new Netscape browser supports HTML 4, XML 1.0, CSS-1, DOM Level 1, and ECMAScript (the standard successor to Netscape’s JavaScript), as well as key parts of CSS-2.

Back in the day, in March 2000, WaSP said much the same thing about Internet Explorer 5 for Macintosh.

Just what is “standards compliance”?

Technically, the HTML 4 (actually, 4.01) standard is published and set in stone by the World Wide Web Consortium (W3 or W3C):

This specification defines the HyperText Markup Language.... This document specifies HTML 4.01.... This... is a stable document and may be used as reference material or cited as a normative reference from another document.

Sounds nice and definitive. But if you look for a document that appears to address standards compliance, you will note a file called Conformance: Requirements and Recommendations. But that section merely explains how words like must and should ought to be interpreted in the standard. It does not list certain tags and attributes support for which is or is not required in order for a browser to call itself standards-compliant.

Indeed, there is no W3 certification process for standards compliance. Nor is there an HTML test suite akin to the W3’s test suite for cascading stylesheets. (Ian Hickson offers the so-called Evil Test suite, but it is homegrown and does not cover everything; it also lacks imprimatur.)

There may be an indirect or inferential method of standards compliance. The W3 HTML validator will tell you if your pages comply with HTML 4 or, if not, exactly how they do not. Your pages are not deemed incorrect or nonstandard if you omit optional tags and attributes. (There is some underground evidence that the validator actually does not test for full, micro-detailed compliance, an issue that needs investigation.)

You can thus verify that your HTML conforms to the spec. This does not certify a browser as compliant. If you do go to the trouble to add optional tags and attributes, it is quite possible that page will pass the validator only to have its features are ignored by a browser – even one that is allegedly standards-compliant.

Noncompliance

While it may be hard to prove a browser is standards-compliant, it’s easy to prove when a browser is not.

In the IE5 and Netscape 6 cases, support for HTML 4 is manifestly incomplete. If you, the page author, include certain tags or attributes, they are likely to be ignored.

Netscape, in fact, helpfully lists all the tags and attributes that are not supported:

HTML 4.0 – full support except for:

  1. Elements: BDO, BASEFONT
  2. attributes: shape attribute on the A element, ABBR, AXIS, HEADERS, SCOPE-ROW, SCOPE-COL, SCOPE-ROWGROUP, SCOPE-COLGROUP, CHAROFF, DATASRC, DATAFLD, DATAFORMAT, DATAPAGESIZE, SUMMARY, EVENT, DIR, ALIGN on table columns, label attribute of OPTION, alternate text of AREA elements, LONGDESC
  3. various metadata attributes: CITE, DATETIME, LANG, HREFLANG
  4. bidirectional text layout, which is only used in Hebrew and Arabic (IBM has begun work to add bidi support in a future release)

Astounding.

Netscape 6 acts like an insurance carrier: If your car gets stolen, we will cover all the costs to replace it. Except for a deductible. However, we'll only mention the deductible after you've bought the policy and sent us the first instalment cheque.

It’s really very simple, even with all the fudge factors in the HTML spec: The claim that Netscape 6 conforms to HTML 4 is false.

The DOM excuse

In the case of IE5 on Macintosh, it was purported that all HTML 4 tags and attributes were supported – if only through the DOM, the document object model. The DOM is an inscrutable abstraction. It refers to a standardized method of “exposing” the contents of pages and sites to programs, which can then act on those contents, in some cases altering the selfsame underlying pages.

Let’s take a real-world example from a Web site.

  1. You set up a page to display an image, using, surprisingly enough, the IMG tag. You comply with HTML 4, so you include an ALT text in case the image is unloadable or graphics are turned off. You include HEIGHT and WIDTH attributes so a browser can allocate onscreen real estate for the image.
  2. The visible manifestations, thus, are: The image. Or the ALT text. Or, while the graphic loads of if the image is missing, the ALT text plus a rectangle the same size as the graphic.
  3. Now, if you wanted to be really compliant with HTML 4, you would include the mysterious LONGDESC attribute, a reference to a separate long-description file that describes the image in much greater detail than the ALT can.
  4. That attribute is invisible. In the IE5 case, we are told that IE5 communicates the presence of the LONGDESC attribute through the DOM.

Intended devices and burden of proof

It is at best tenuous to argue that support for, say, LONGDESC, when provided solely through the DOM, really constitutes standards compliance. Long descriptions are intended for blind users. Typically, a screen reader will read out the long description on request.

But there is only one screen reader for Macintosh, Outspoken, and it does not support LONGDESC. Outspoken’s manufacturer tells you right up front not to use it with any Microsoft software for the Mac, including Explorer. (Microsoft software is notorious for incompatibilities with assistive technology.)

Furthermore, I received an E-mail from Outspoken’s maker stating that “Outspoken 9 for Macintosh does not interpret HTML. It will simply read from left to right the text that is on the screen. Web and HTML access will improve tremendously in Outspoken X which should be released in late 2001.”

Since no other assistive device looks for long descriptions, hiding “support” in the DOM amounts to no support at all. Remember, this is a browser that attempts to adapt itself to the real world, altering its interpretation of HTML based on DOCTYPE declarations: An HTML Strict document will look different from a document with no declaration at all, for example. You also have more control over font sizes and display than any other browser.

It is difficult to make the case that IE5’s lack of usable support for LONGDESC is irrelevant: Microsoft went to a great deal of trouble to recognize real-world use and overcome real-world compatibility problems. Sequestering LONGDESC support in the DOM constitutes no support at all.

Note that this distinction is not at all clear-cut, as the Netscape 6 omission list is, but that doesn’t make it unreal.

Or take another case: ABBR (for abbreviations) and ACRONYM.

  1. IE5 will not indicate, in any visible way, that an abbreviation is encoded with that tag. It will show an acronym in small caps, which usually will be unnoticeable because acronyms are typically in uppercase. (“WaSP” is a counterexample. Viewed in Mac IE5, the A is capitalized at a smaller point size.)
  2. In neither case does IE5 let you know that you can hover the mouse over the abbreviation or acronym and a tooltip will appear with the expansion. IE5 does not, for example, underline the entry.
  3. Support for these tags, then, is nominally in place but unnoticeable in nearly all cases.

Some tags used to mark up structure in tables, like COLGROUP, evidently are unsupported, because tables with and without such tags are rendered identically in IE 5.

And those are the difficult cases. Easier cases abound, like CITE “metadata” on BLOCKQUOTE, INS, and DEL. The citation lets you view the original document (in the case of BLOCKQUOTE) or documents describing the insertion or deletion. If there’s any kind of support at all for this metadata in IE5 (DOM or otherwise), I haven’t found it.

Other metadata remains unsupported, like the many LINK tags that can be placed in the HEAD of a document to show relationships with other documents.

Although Microsoft does not provide a list of unsupported tags, necessitating a greater burden of proof, it is evident that IE5 doesn’t fully support HTML 4, either.

A fair argument can be made (as was done in the MacNN discussion) that the exact method of implementing some tags and attributes is unclear or debatable for “visual browsers” like IE5. SUMMARY in TABLE, for example, should not be accessible to a visual browser by W3C suggestion: It is “for user agents rendering to non-visual media such as speech and Braille.”

But by the time IE5 came out, we already had precedent. There were already examples of how to handle such markup.

Puny iCab, puny Lynx

iCab, a tiny but miraculously useful alternative Macintosh browser, claims to support HTML 4 fully. (See iCab’s browser test.) iCab actually supports everything I’ve stated that IE5 does not support or supports improperly, and supports most of the Netscape 6 omissions list.

Meanwhile, Lynx, an old text-only browser, supports LINK metadata beautifully. So does iCab, giving you a convenient pull-down menu and a raft of icons in a toolbar. (Unlabeled icons, unfortunately.) Lynx barely handles tables at all, and, while it displays inserted and deleted text and block quotations, it gives you no access to the underlying citation.

Marginal examples?

“But,” you ask, “aren’t all these examples pretty marginal?”

Not really. Not if accessibility is something you actually consider important. HTML 4’s new access tags – yes, like ABBR, ACRONYM, and LONGDESC – need to be supported if anybody is ever going to use them. Support is the key to the castle: When early (and tacky and talentless) Web authors discovered what Netscape could do with MARQUEE and BLINK, vavoom! there they were on a million Tripod homepages.

If access tags are usable by nondisabled developers while composing pages, vavoom! suddenly they will actually be used in the real-world Web.

In other words, while the “missing” HTML tags are important for the purposes for which they were developed, it’s also important to support them visibly and openly. Justice must not merely be done; it must be seen to be done. HTML must be supported in a way that actual developers can witness, either visually or audibly.

It’s a feedback loop, to a certain extent. If we want people to code HTML 4–compliant pages, the full HTML 4 spec has to be supported, and openly so.

In fact – and this is a bit of an aside here – even brand-new “authoring tools” like BBEdit 6 force you to add access tags manually. In an IMG dialogue box, for example, there may be a nifty little field for ALT, but there won’t be one for LONGDESC. Or for CITE on BLOCKQUOTE.

In order for authors to write standards-compliant pages that make use of every nook and cranny of HTML 4 – and accessibility relies on those nooks and crannies – the tags have to be in your face every time you call up a dialogue box. You must explicitly choose to add or ignore access-related tags and other HTML 4 “marginalia”; sins of omission are actually the worst kind.

One part of the picture

Of course, the Web Standards Project considers HTML compliance only one part of the puzzle. And well they should. I am merely asking for more-tempered praise. Browsers should not be celebrated for complying with HTML 4 if we can show that even simple-to-implement attributes like CITE are overlooked. Nor should browsers be celebrated if their documentation lists all the ways in which they don’t comply with the standard.

My criticisms here specifically relate to the claims of standards compliance for two browsers. They have nothing to do with, as the Zeldman asserts, the standards noncompliance of “Netscape 4, IE5.5/Win, designers who don’t give a damn, and tools like Dreamweaver and GoLive that don’t even give users the option to create standards-compliant sites.”

I am simply asking for truth in advertising. Don’t say a browser meets the spec when it doesn’t, even if the tags unsupported are tags you consider expendable.

Request for help

I am by no means an expert on how the document object model works, so if I am unfairly criticizing IE5 (or Netscape, in fact) on that criterion, please let me know. (If you want to test LONGDESC and the like yourself, try the Break This Page! experiment.)

Correction history: Removed “errors” regarding IE5 and ABBR and ACRONYM, then put everything back when the errors were proven not to be. Updated Outspoken compatibility. Added iCab as a device sensitive to LONGDESC.

– 30 –