- From: Mike Barta <mikba@microsoft.com>
- Date: Wed, 15 Jun 2005 05:06:58 -0700
- To: "Roberto Scano \(IWA/HWG\)" <rscano@iwa-italy.org>, <mcmay@w3.org>, <joeclark@joeclark.org>
- Cc: <w3c-wai-gl@w3.org>
We currently have SC for that issue. 1.4 L2 SC1,2 -----Original Message----- From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf Of Roberto Scano (IWA/HWG) Sent: Tuesday, June 14, 2005 11:43 PM To: mcmay@w3.org; joeclark@joeclark.org Cc: w3c-wai-gl@w3.org Subject: Re: summary of resolutions from last 2 days if u declare a dtd and not respect it, it's a dtd violation: br is an example and if people said: "why it's wrong" means that they don't know what they are doing. As Joe said, we are in application/xhtml+xml era, and for application/xml markup conformance is required for correct representation. Web (html) is the only language that authorize representation of non-conformed content (except of mosaic). Moving to level 2 means make possibily inaccessible pages for all. I hope we don't make the same error of wcag 1.0 where colour contrast for text was level 3 and for images level 2: a well conformed page that respect all level 1 and 2 checkpoint with all text and background of the same text colour (eg. Black) is formally wcag 1.0 AA but inaccessible to the largest audience (people without disability/AT) ----- Messaggio originale ----- Da: "Matt May"<mcmay@w3.org> Yep. And it's the right call to leave it out at P1. If it's possible to create accessible content without forcing a validation process at the same time, that's a reasonable approach, if it gets more people to focus on making what they have more accessible. > Do you even understand what you're doing? If you maintain invalid > markup as a permitted option, CMSs will never be upgraded to produce > valid code. You've given them an escape clause. Accessibility is not the primary driver for valid output. Most companies are moving to standards-based output because their consumers are asking for it to increase browser interoperability and lower maintenance costs and development time. They can just as effectively make inaccessible content from a tool that produces valid output, despite all claims to the contrary. > Who in the room in Brussels is capable of using a manual editor-- > complete with macros and presets-- to produce valid code in the first > place? Do you even know how to do what you're saying is too hard to > require? Probably not, right? I'm not in Brussels, but I do know all that stuff, and I've evaluated enough authoring tools in my official capacity to know that a lot of them still don't have a grip on validity. And when considering older systems that are still in use, which we have to do, many may well be impossible to fix. They'd spend more time fixing validation errors (many of which wouldn't matter at all to ATs) than they would actually thinking about how to make their content more accessible. Yes, sites should be valid without exception. I pounded my fist on the podium at a W3C Advisory Committee meeting to drive that point home to authoring tool vendors. But validity is not a sine qua non for accessibility. And it's the wrong thing to lie down in the road over. If validity is level 1, somebody is going to ask us why adding a slash to the <br> elements in their XHTML document is going to make them accessible, and we're going to have to come up with an answer to that. Invalid code is highly correlated with inaccessible HTML, but to say all invalid HTML is de facto inaccessible is a hasty generalization fallacy. They're both symptoms of poor coding practices -- but we're concerned with content, and lots of it. While I think it's important to have valid code, I also believe the lowest level of WCAG 2 is the wrong place to enforce it. Level 2 is more appropriate, and reflects the amount of work involved in making many sites valid. - [Messaggio troncato. Toccare Modifica->Segna per il download per recuperare la restante parte.]
Received on Wednesday, 15 June 2005 12:11:13 UTC