- From: Roberto Scano (IWA/HWG) <rscano@iwa-italy.org>
- Date: Sun, 19 Jun 2005 16:51:54 +0200
- To: <tina@greytower.net>, <w3c-wai-gl@w3.org>
An interesting article: http://www.456bereastreet.com/archive/200506/web_standards_vs_accessibility/ And a piece of interview to Judy Brewer (all text is interesting!): http://easi.cc/media/trans/tnbrewer.htm "If you are generating a sort of junk HTML, or if you are generating invalid markup, you are invariably introducing some accessibility problems with that because it is harder for the assistive technologies to work with the invalid markup. So we address how to try to get conversion tools to produce Web standards, standard Web specifications, whether it being HTML or XHTML, XML, or what ever. We also address database conversion tools. A lot of Web pages are generated on the fly from a database. And so we wanted to make sure that those with more often generate accessible pages then inaccessible pages. " ----- Messaggio originale ----- Da: "Tina Holmboe"<tina@greytower.net> Inviato: 18/06/05 23.10.05 A: "w3c-wai-gl@w3.org"<w3c-wai-gl@w3.org> Oggetto: Re: Re : Influence of valid code on screen readers On 18 Jun, Maurizio Boscarol wrote: > Still, that will not guarantee accessible pages. It depends on quality > of code, of textual equivalents, of structural and semantic markup, > and many other design solutions. Here's the catch. A valid document may, just as an invalid one, be accessible. However, an *invalid* one runs a much greater risk of having *poor* structure and mangled semantics. We all agree, I would presume, that structure and semantics are important pieces of accessibility. Valid code is essential: if the structure and semantics are coded *wrong*, then who knows what might come out in the other end of a random user-agent? Invalidity equals poor quality code, possibly incorrect structure, and the chance of confusing semantics. Whyever would we NOT want to make this a priority one checkpoint? > the problem about validation isn't always tag soup, but some little > implementation mistakes, that don't significatively affect the quality > of code. The pages can nonetheless be accessible. The problem we would need to accept is rather this: there is no way to tell whether the "little implementation mistake" is, or is not, a problem for accessibility. As you write: > a good indicator of quality, but even minor problems in validity > don't affect accessibility. Perhaps not. And perhaps they do. However, *major* problems with validity *do* affect accessibility. In reality, there is no way to tell which of these little mistakes might have an effect or not, without actual testing. The only sensible way of handling this situation is to state, clearly: validity issues that can be automatically tested, SHOULD be automatically tested as a priority one checkpoint and, in effect, gotten out of the way. Otherwise we need to add something to p1 which says: "Make sure any invalid code doesn't mess up accessibility". As has been pointed out - we cannot *know* that invalidity messes with accessibility. The flip side is that we cannot *know* that it doesn't, not without testing. Testing to see whether doing things incorrectly might create accessibility problems is somewhat illogical. > complain about validation, but only about real accessibility. > Validation should be encouraged, but at the top quality level, not at > basic level. [Messaggio troncato. Toccare Modifica->Segna per il download per recuperare la restante parte.]
Received on Sunday, 19 June 2005 14:52:19 UTC