Re: [4.1] Overview and summary of guideline 4.1

Excellent summary!

>In a public comment on the public working draft of June 24, 2003 
>[4], Greg Gay wonders whether 4.1 includes non-W3C technologies as 
>well. He writes: "Does this include nonW3C technologies: Javascript, 
>Active X, Flash,... used according to specification? Can developers 
>use these technologies if they are designed with accessibility 
>features. How would an evaluator determine if Javascript or perhaps 
>Flash has been used to specification? Whose specification for 
>Javascript. I also would imagine Javascript can be used to 
>specification, but be innaccessible. In combination with the "device 
>independence" guideline, this might work"

and:

>In addition to the previous issue, Greg Gay emphasizes that in real 
>world situations, developers need to be able to use workarounds that 
>violate guidelines,
>provided they are necessary and they are documented in an 
>accessibility statement. He gives some examples (use of 
>target-attribute to spawn new windows, lack of support for font size 
>in EM in Netscape 4) to illustrate this necessity.

Those are weak examples at best, indicative of poor authoring 
experience. (Why not just @import a different CSS file to fool 
Netscape 4?)

The biggie is the <embed> element. It's the only *truly* dependable 
way to call multimedia in a page. The problem? It isn't official 
HTML. Use it in your page and you will never validate. (I now cannot 
find the page in which somebody tried to make <object> work across 
every browser he [sic] had, but found the only code that functioned 
without a hitch was <embed>.)

There are options, though.

* The best one is to custom-hack your DOCTYPE. It's XHTML, which is 
XML, which is eXtensible. Want to use <embed>? Write a DOCTYPE that 
makes it legal. (Same goes for other banned elements and attributes. 
I wish K10K would do this to get rid of their tiny invalidities, for 
example.

<http://K10K.net>

<http://validator.w3.org:8001/check?uri=http://k10k.net/&charset=(detect+automatically)&verbose=1&fussy=1>.

* You can also faux-write the <embed> element using JavaScript. The 
designer of OneTrueFit.com, a very nice compliant site, did that.

<http://www.webstandards.org/learn/interviews/rcarver/#q9>
<http://www.fivesevensix.com/studies/onetruefit/>

>Is validity an accessibility issue?
>
>The need to use technologies according to specification is a broader 
>issue than most of the guidelines in WCAG. In issue 572 as well as 
>on the mailinglist, people have wondered whether this guideline 
>should be in WCAG because they feel it's not about accessibility. 
>Others have argued that valid markup increases the chances of 
>correct rendering of the content which directly benefits 
>accessibility.

Correct. Looking for prior art?

<http://joeclark.org/book/sashay/serialization/Chapter05.html>


>Validition versus necessary violations
>
>There seem to be two camps in the whole validation discussion. One 
>camp says you should always require valid code, since only then can 
>user agents know how to render the content.

Yipper. That's even topical this week!

<http://weblogs.mozillazine.org/hyatt/archives/2004_01.html#004702>

>  Issue 472 is a comment from this side. The other camp says that 
>violations of the specifications are sometimes necessary to achieve 
>the desired result.

You can rewrite the spec or use other methods to achieve valid code.

>  Applicability to non-W3C technologies
>
>...Do we allow the use of proprietary technologies?

WAI needs to resolve that issue quickly, if only because PDF and 
Flash are two non-W3C formats with accessibility built in. (There are 
lots of those. DVD, for example.) WAI has flirted with these 
dangerous and alien technologies before in its guidelines:

<http://www.w3.org/WAI/GL/WCAG-PDF-TECHS-20010913/Overview.html>
PDF Techniques for Web Content Accessibility Guidelines 1.0 and 2.0

I know that document is orphaned, but it's important for WAI to 
decide if it's going to publish accessibility guidelines for other 
formats. *I* think it should.

>Transitional standards allowed?
>
>A certain level of backward compatibility is built in the 
>transitional variants of the HTML specification. It is not clear 
>whether 4.1 means you can only use the strict HTML specification or 
>if the transitional variants are allowed as well.

It's worse than that. The following are both Priority 2:

    11.2 Avoid deprecated features of W3C technologies. [Priority 2]
           For example, in HTML, don't use the [248]deprecated FONT
           element; use style sheets instead (e.g., the 'font' property in
           CSS).

   3.2 Create documents that validate to published formal grammars.
           For example, include a document type declaration at the
           beginning of a document that refers to a published DTD (e.g.,
           the strict HTML 4.0 DTD).

    11.1 Use W3C technologies when they are available and appropriate for
           a task and use the latest versions when supported. [Priority 2]

I think it should be clear to us in 2004 that valid code used 
semantically (a concept that's too new to have been included in WCAG 
1.0) trumps the avoidance of "deprecated" features. The fact is that 
a Web page containing deprecated features like bgcolor or my 
favourites, <small> and <big>, can still be a valid Web page and 
isn't hurting anybody.

The three guidelines above contradict each other. 11.2 says don't use 
deprecated elements and attributes, but you can pass 3.2 by 
validating your page even if it includes them. But 11.1 will flunk 
you if you dare to use anything but XHTML 1.1!

And as for "published formal grammars," for (X)HTML there's a 
handy-dandy list by the W3C's own Karl Dubost.

List of valid DTDs you can use in your document
<http://www.w3.org/QA/2002/04/valid-dtd-list.html>

Pick one and run with it! (Even HTML 2.0!)


>Improve description of benefits of the guideline
>
>With an improved descriptions of the benefits, it should be possible 
>to make it clear that following this guideline helps the 
>accessibility of web content, and that this guideline is an 
>accessibility issue.
>
>The current version of 4.1 includes a description of the benefit of 
>4.1 which says that it the benefits of following specifications are 
>primarily that assistive technologies and user agents can render the 
>content according to spec. This is not the only reason. If the 
>author does not follow markup specifications, it is left up to the 
>user agent to interpret this pseudo-markup. Since authors usually 
>only test their content in a few frequently used user agents, there 
>is no way to predict how other user agents (such as speech 
>synthesizers or text browsers) will interpret this data.

The problem here is how few Web pages there are in existence that 
explain the need for valid code. I know of *one*:

<http://www.pantos.org/atw/h-valid.html>

Even the Web Standards Project hasn't written a good explanation. I 
find it hard to explain, too, at least right away, though I had some 
success after I picked away at it.

<http://fawny.org/blog/2003/09/?GL#explain>

>This means writing valid code is a step towards making the web 
>content available across different user agents.

And for future user agents. When Safari came on the market, it worked 
adequately well with valid pages whose authors never knew Safari was 
in the pipeline.

>Add example with backward compatibility
>
>Since backward compatibility questions keep popping up, it would be 
>wise to include an example of how and when to allow for backward 
>compatibility.

I don't understand this whole concept. For a lark, I downloaded 
Netscape 1.1N on my Girl Power iMac here and tried a few XHTML pages. 
The program seems to be too old to understand virtual domain hosting, 
so even my own page called up my host, not me. But I got a couple of 
the Usual Suspects to load fine-- Zeldman, Mezzoblue, Alazanto, 
Webstandards.org. It crashed on Eric Meyer, oddly.

Now, how far back do we have to go for "backward" compatibility? 
Isn't this entire concept "backward"?

Aren't the people advocating invalid code for backward compatibility 
themselves simply out of date? Why aren't they familiar with the 
existing standards-compliant methods? (@import, for heaven's sake, 
has been around for a couple of years.)

>Clarify if transitional specifications are allowed or not
>
>W3C already made provisions for backward compatibility in the HTML 
>standards by creating the transitional versions of HTML 4 and XHTML 
>1. The requirement "depricated features are avoided" is interpreted 
>by somepeople as "Only use strict HTML" for HTML documents. Other 
>people, including myself do not think that this is the case, because 
>WCAG would not require a higher level of validity than the HTML 
>specifications. If the markup follows HTML specifications, whether 
>it's HTML 4.01 transitional or XHTML 1.0 strict, you pass.

Correct.

>Re-include requirement to follow specifications for non-markup content
>
>[...] What shall we require about non-markup content such as Java 
>applets, Javascripts etc.?

There *is* a standard for JavaScript, called ECMAScript.
<http://www.ecma-international.org/publications/files/ecma-st/Ecma-262.pdf>
(Google it for text version)

Now, it seems only Zeldman writes according to the ECMAScript spec, 
but in principle it exists.

>Since no open standards exist for these technologies,

I dispute that characterization. Do you mean "published"? The PDF 
file format is published. It's so well published that OS X supports 
it natively. IIRC the Flash file format is published, but don't quote 
me on that. And "open"? Even the development of WCAG 2, while 
*public*, is not something I would consider "open."

>Accessibility features
>
>The requirement to use accessibility features if present has some 
>relation with all the guidelines of the 'Operable' principle. If an 
>author does not use the accessibility features, the content may 
>become less operable.

Except some of the canonical accessibility features are either 
ill-supported or unsupported. tabindex, accesskey, longdesc-- they're 
essentially vapourware. So does WCAG WG propose to flunk authors 
because they leave those out?

We would need an exhaustive list of such "features," something much 
better than the current 
<http://www.w3.org/WAI/References/HTML4-access>. Then we could have a 
rational discussion about requiring them. Few accessibility features 
are truly required-- alt text is a prime example of one that is. (You 
must have it to meet Priority 1 and 2, for different reasons.)


>Using structural elements for presentation
>
>Using structural elements for presentation is not allowed by 
>guideline 4.1 because that's not using the elements according to 
>specification.

This is a fine line sometimes with new authors. Remember the 
distinction between valid and semantic?

<div>Today's headline</div>

<span>By Joe Clark</span>

<span>Today's news article</span>

is valid HTML, but not semantic HTML. Do we want "according to 
specification" to explicitly mean "do whatever you want as long as it 
validates," or do we want the vastly superior "Use elements and 
attributes according to their purposes as listed in the relevant 
specifications, and validate your pages"? You know which one I vote 
for.

(Sometimes there are ambiguities and you have to do your best. 
Simplebits discussions are full of these ambiguities. I trust you all 
read Simplebits, and the other sites I've mentioned.)

>I have assumed that the working group values validity, but 
>recognizes sometimes greater accessibility can only be achieved if 
>the specifications are broken.

I only see that as possible in the case of <embed>. If IE/Win didn't 
screw up <object> so terribly, we could forget about it.

>Rationale
>
>This guideline benefits accessibility in different ways:
>
>* Valid markup increases the chances of correct rendering of the content

Valid HTML virtually guarantees correct rendering without associated 
styles (using the browser's own style). CSS is the problem here.
-- 

     Joe Clark | joeclark@joeclark.org
     Accessibility <http://joeclark.org/access/>
     Expect criticism if you top-post

Received on Tuesday, 20 January 2004 18:49:52 UTC