RE: (1.3) Validation and semantics recap

Joe Clark wrote:

<blockquote>
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?
</blockquote>

For the benefit of Joe and others who've recently joined the Working
Group, it should be pointed out that the WCAG 2.0 document contains
different types of text.  The two major divisions are normative and
informative.  The proposed normative portions will define what is
required for conformance-- in effect, the normative text will constitute
the standard.  The informative portions will do what the name implies,
providing additional information to help readers understand the
normative portions.

The proposed normative portions of WCAG 2.0 (normative=required for
conformance) include, at this time, four principles; 13 guidelines; and
something like 77 success criteria. (These numbers are subject to change
as the Working Group analyzes issues and works through new proposals.)

The statements of principle include the word "must," as in "Content must
be perceivable"; "Interface elements in the content must be operable";
"Content and controls must be understandable"; and "Content must be
robust enough to work with current and future technologies."  Note that
such statements in and of themselves are not testable.

Beneath each principle are one or more guidelines that apply the
principle to various aspects of Web content.  For example, Guideline 1.3
in its present form is concerned with ensuring that information,
structure, and functionality are perceivable.  

Guidelines are cast in the imperative moodd: "Ensure," "Provide," etc.
Again, the guidelines in and of themselves are not testable.

Under each guideline there are one or more success criteria.  These show
how to implement the guidelines.  One of our goals has been to ensure
that WCAG 2.0 is more reliably testable than many people find WCAG 1.0
to be.  To that end, the success criteria are cast as declarative
statements that may be either true or false when applied to specific
instances of Web content.   This produces sentences such as "Structures
within the content can be programmaticallly determined"-- the revised
text of GL 1.3 L1 SC1 that gained consensus on last Thursday's call.


"Good design is accessible design."

Dr. John M. Slatin, Director 
Accessibility Institute
University of Texas at Austin 
FAC 248C 
1 University Station G9600 
Austin, TX 78712 
ph 512-495-4288, fax 512-495-4524 
email jslatin@mail.utexas.edu 
Web http://www.utexas.edu/research/accessibility 



-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On
Behalf Of Joe Clark
Sent: Friday, May 06, 2005 2:50 PM
To: WAI-GL
Subject: (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 Monday, 9 May 2005 02:44:15 UTC