(1.3) Validation and semantics recap

So... yesterday I made it through the WAI hazing ritual of defending 
a proposal in a teleconference. It was OK, actually-- and besides, 
hazing is totally *hot*, isn't it?

Here are a few more ideas about the purpose behind my rewrite of 1.3, 
"Ensure that information, functionality, and structure are separable 
from presentation."

<http://lists.w3.org/Archives/Public/w3c-wai-gl/2005AprJun/0248.html>

(By the way, I really admire you folks who can keep one million 
guidelines all nice and tidy in your heads purely by their reference 
number, but I can't, and neither will a lot of people be able to. So 
I quote the guideline slug whenever possible.)


CATCHING YOU UP WITH WEB STANDARDS
The proposal attempts to catch you up with Web standards. Since 
approximately 2000, many dozens of intelligent people have been 
reading the specs diligently and fine-tuning ever-more-accurate ways 
of creating Web sites that meet every known specification, very much 
including WCAG. This has been going on while most commercial 
developers and nearly everybody on the Working Group has been asleep 
at the switch.

My rewrite of 1.3 could be headlined "Use Web standards." If we 
couple it with a tightened requirement to use valid code at all times 
(for technologies that have a concept of validity, as HTML does), 
pretty much overnight we raise the bar from eBay- or Amazon-style tag 
soup to something much, much better.


VALIDATION IS TRICKIER THAN JUST PASS OR FAIL
Now, over those four years, we've learned a few things about what 
"standards compliance" really means. At root your code has to make it 
through the validator, <http://validator.W3.org/>. But while that 
step is necessary, it is not sufficient. Your document must not only 
be valid, it must be *semantic*, a term that is not in dispute among 
standardistas. It doesn't refer to the meaning of the words marked up 
by HTML, nor does it refer to Tim Berners-Lee-style "semantic Web."

Check this article by Molly Holzschlag:

	Integrated Web Design: The Meaning of Semantics (Take I)
	<http://www.informit.com/articles/article.asp?p=369225&rl=1>

Semantics are necessary, but the validator cannot check for them. 
That problem resembles the problem in accessibility of correct usage 
of alt text. Hence our guidelines, techniques, success criteria, or 
whatever else must require not only valid use of markup but valid and 
*semantic* use. This is somewhat hard to get across to neophytes.

Technically it is true that writing to spec requires semantics. But 
the reason why I keep bringing up semantics is because the same 
people who think passing Bobby means their site is accessible will 
think that passing the validator means their markup is good. 
Semantics is *hidden inside* validation and needs to be explicitly 
required.


EDGE CASES
I cannot say I really care whether or not the following is 
"testable." Nonetheless, we will have to find a way to explicitly 
permit authors to use less-structural or less-semantic markup in the 
exceptional case where no highly-structural and -semantic element 
will work.

Classic examples include <i>/<b>/<u> instead of <strong>/<em>, and 
<big>/<small> instead of something else. In XHTML 2.0 and tagged PDF, 
there is also the concept of unenumerated heading elements, such that 
a sequence like <h> <h1> <h2> <h2> <h2> <h3> <h> <h> <h> <h4> <h> 
could be viable and permissible.

There are people who use these elements inside documents that 
otherwise use all the other expected elements correctly. They are the 
most advanced authors, and they know what they're doing. (This group 
can initially be hard to differentiate from know-nothings who use 
HTML as a "visual" markup language-- at least until you view source 
on their pages.)

Again as a result of years of developing standards-compliant sites, 
we now know that some usage of these hillbilly elements inside our 
Buckingham Palace markup is necessary from time to time.

Have a look at:

	Categories of semantics
	<http://blog.fawny.org/2005/05/01/categories/>

	i let u b u
	<http://blog.fawny.org/2004/05/16/ubu/>

	Well-tagged weighted lists
	<http://blog.fawny.org/2005/01/23/weighted/>


UNSTRUCTURED FORMATS
Unstructured formats like plain text, images, and audio will continue 
to be used. The Working Group has historically disliked, opposed, and 
tried to make illegal anything that makes a Web site pretty or 
appealing to a person with taste. And thus the Group *may* be tempted 
to ban those formats-- even, in a circular fashion, the plain text 
that some in the Group thinks every Web page should look like. In all 
fairness to my esteemed colleagues, the fact that we're even talking 
about this indicates that you've all grown up a little, and perhaps 
you are like me and my friends-- you want compliant and accessible 
pages that look good and function well.

In any event, I specifically left the following out of my proposal so 
I wouldn't have Gregg or somebody leaping on this as a pretext to ban 
anything that wasn't on the Web in 1995. But we need some kind of 
language that says structured formats are preferable to unstructured 
ones wherever possible, yet unstructured formats can still be used in 
appropriate cases. Typical examples:

* The plain text of an E-mail or software release notes whose 
original and underlying format really is plain text.
* A code listing.
* A full-size version of a photo whose thumbnail is marked up in HTML 
and has an alt text.


AND SPEAKING OF WORDING
In retrospect, I got suckered into writing my proposals in the same 
hard-to-understand passive voice that the Working Group uses. Could 
somebody please link me to the portion of the W3C or WAI Charters 
that requires us to sound like Brussels bureaucrats writing in 
translation?

I am not picky about how we manage to accomplish the goals I have 
explained here. You can do them in guidelines, success criteria, or 
techniques, or some combination. And I am not wedded to my own 
terminology. I am open to friendly and even hostile amendments. I 
just want it all in there, and I want it readily understood by any 
standardista. (A tag-soup developer is going to have to upgrade his 
or her skills anyway, and I am not really concerned if he or she is 
confronted by the shock of the new.)


-- 

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

Received on Friday, 6 May 2005 19:50:28 UTC