Summing up the debate about validity at Priority 1 or 2

As I see it:

1.
We already have validity as a requirement in WCAG 1-- at Priority 2.

<http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-identify-grammar>

Current "drafts" of WCAG 2 list valid code at Levels 1 and 3 (the 
latter of which will of course disappear).

<http://www.w3.org/TR/WCAG20/#use-spec>

Hence the null hypothesis is that it will stay there in WCAG 2. The 
only plausible change from WCAG 1 is upping the level to Priority 1.


2.
If we don't require valid code at Priority 1, we really will be 
saying that our guidelines (a W3C "Recommendation") are important but 
that other W3C Recommendations are not. We really will be hypocrites.

But we already are! We already have valid code at Priority 2. It's 
already optional.


3.
It's substantially less difficult now to produce real live Web sites 
with valid code. However, it's not easy all the time, particularly:

* with legacy content-management systems that are clearly broken in 
the first place but are too expensive to fix;

* on sites with content contributed by many users;

* on sites that pull in data from disparate sources that they cannot 
control (in one real case, that data arrives with tag-soup HTML 
already); or

* in the case of masses of legacy documents that simply could not be 
cleaned up without unreasonable effort (in one real case, 20,000 
documents; in another case, it took two people two months to make 620 
pages valid)

to give but a few examples.


4.
Validity and well-formedness *aren't* the same thing and WCAG Working 
Group really is trying to underhandedly redefine "well-formedness"-- 
even as it rejects a certain other term ("semantics") that everyone 
else in the industry understands.


5.
Validity and well-formedness can both be undone by a single 
character. It's all-or-nothing, hence precarious. My own pages have 
become invalid for small reasons behind my back. On really big sites, 
it's gonna happen even more often.


6.
Valid code is an excellent predictor of accessible code. But nothing 
in life is guaranteed.


7.
Adaptive technology and browsers themselves, through permissive 
interpretation of HTML, ensure that many or most cases of invalid 
HTML are still accessible-- but that applies only to HTML that uses 
basic accessibility features like alt texts. We all agree that tag 
soup that simply ignores any recommendations for accessibility is a 
problem for many people with disabilities.


8.
Adaptive technologies, on the other hand, are often too stupid to 
recognize and use standards-compliant methods (perennial example: 
longdesc; other example: advanced table markup). Then again, so are 
browsers (both examples apply).


9.
Requiring valid code at all times makes sense as part of ATAG. But 
that is proposed for ATAG 2, which doesn't exist yet. Nothing at all 
complies with ATAG 1 and I rather doubt anything will comply with 
ATAG 2, either. I'd like to be wrong, but let's not pin our hopes on 
compliance with a nonexistent successor specification whose 
predecessor nothing else complied with.


10.
The Working Group totally screwed up its presentation of this issue. 
It could have gotten most of us onside easily enough, but blew it. 
Plus Matt's been real cranky for the first time in living memory.

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

-- 

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

Received on Wednesday, 22 June 2005 21:48:36 UTC