W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 2005

Re: summary of resolutions from last 2 days

From: Roberto Scano (IWA/HWG) <rscano@iwa-italy.org>
Date: Wed, 15 Jun 2005 08:43:09 +0200
To: <mcmay@w3.org>, <joeclark@joeclark.org>
Cc: <w3c-wai-gl@w3.org>
Message-Id: <20050615024031.SM01752@Inbox>

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 06:43:30 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 21:07:40 UTC