Re: summary of resolutions from last 2 days

Joe Clark wrote:

>> They can just as effectively make inaccessible content from a tool 
>> that produces valid output, despite all claims to the contrary.
>
>
> If you're imagining the case of alt texts that are present (as 
> required by spec) but incorrect, that's actually very hard to find in 
> the wild. What are the other cases, and what sites can you point to 
> that exhibit those cases?


No, I'm talking about poor table markup; use of <font> in place of 
headers or other semantic code; failing to express important 
accessibility information found in implied attributes; incorrect 
encodings; and all manner of things you can do to break accessibility 
within valid code. We're still battling the meme that valid code is 
accessible code, and that's not strictly true. Valid code is often 
_more_ accessible code. But it's neither necessary nor sufficient for 
the purposes of accessibility. One missed end tag or incorrect entity 
does not ruin a screen reader's parsing. Therefore, it follows that a 
pass or fail on validity is not a direct indicator of overall accessibility.

> But that is not the real world of invalid markup. It is rather a 
> banquet of tag soup with serious consequences for interpreting the 
> document tree.



Which is something few ATs do on their own, anyway. Many of them rely on 
the host browser and the DOM tree it exposes, which is often more broken 
than the code. In a lot of cases, ATs don't even _know_ whether code is 
invalid. If parsing in standards mode over quirks mode helps that, then 
that's worth specifying. But you can have invalid code that parses in 
standards mode, too.

> The decision by the WCAG Working Group members with expense accounts 
> who met, wined, and dined in Brussels essentially appeases producers 
> of crappy CMSs. It takes as a natural state of the world that CMSs 
> should produce invalid code, and that the only realistic way to 
> produce valid code is to type it out by hand, a skill the Brussels 
> crowd lacks in any event.


It's hard to appease parties that not only aren't asking for 
appeasement, but have never been and never will be at the table. Crappy 
CMSes will still be around when all that's left are cockroaches and 
spammers.

> It says not only "We never meant what we said about valid HTML all 
> along"; it says "Keep up the good work!" It also contradicts wide 
> swaths of the rest of the W3C, from the HTML and CSS Working Groups to 
> Quality Assurance.


WAI doesn't exist as a Trojan horse for the rest of W3C. We're chartered 
to develop guidance on Web accessibility to people with disabilities. 
And we, unlike those who specified the formats, have to deal with 
real-world incompatibilities. QA has been trying to clear up the 
problems with user agents[1], but they're not done.

> And indeed piece-of-shit content-management systems like Vignette will 
> never be updated for valid-code output until there's pressure. There 
> won't be pressure until there are requirements. And-- go ahead and 
> prove me wrong here-- the WCAG Working Group seems rather too chicken 
> to set a requirement.


Congratulations on a new low in WG discourse. Perhaps you'd like to fold 
up your arms and flap them at us?

The WG _did_ set a requirement on validity, after really thinking about 
the problem. They said it's a level 2 requirement. Then, of course, they 
all bathed in Perrier and met later in the evening for caviar and 
Cristal, as customs dictate. But they made a reasonable decision, given 
the state of the Web. We cannot change the state of validity on the Web 
on our own with one decree. We _can_, however, ruin our own chances of 
increasing the accessibility of the billions of documents that are 
already on the Web by overreaching.

-
m

[1] http://www.w3.org/TR/cuap

Received on Friday, 17 June 2005 01:32:59 UTC