- From: Paul Walsh <paul.walsh@segalamtest.com>
- Date: Sat, 5 Nov 2005 02:18:14 -0000
- To: "'Gez Lemon'" <gez.lemon@gmail.com>, "'Gregg Vanderheiden'" <gv@trace.wisc.edu>
- Cc: <w3c-wai-gl@w3.org>
The amount of effort spent on this particular topic is incredible. IMHO, it's black and white (I'm sure my wife would say I think that of everything :)). I don't think it's the WAI's place to mandate the use of 'valid' code at any level. If it's possible to have a fully accessible website that contains invalid code, how can it be an accessibility issue? The fact is, it's not. A site that passes every guideline but fails a validity test will be accessible to all. This means assistive technologies won't be affected, otherwise another guideline would have failed. Therefore, validity is a 'nice to have' best practise that h_e_l_p_s eliminate accessibility issues. There are other good reasons for validity, such as reducing page weight for improved download speed. Again, this has nothing to do with accessibility if the download time is covered by another guideline. Perhaps validity could be placed in a 'how to validate' section somewhere. Nobody is going to be taken to court for having invalid code if the only way of detecting it is via a test tool. A user is not going to stand in front of a judge and say, I'm suing company x because their code wasn't valid, even though it was possible to access all of their products and services with easy and comfort. Kind regards, Paul -----Original Message----- From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf Of Gez Lemon Sent: 05 November 2005 01:37 To: Gregg Vanderheiden Cc: w3c-wai-gl@w3.org Subject: Re: Summary of arguements FOR validity -- and another against -- and a third of alternatives Hi Gregg, I've tried to be as objective as I can, but it would be helpful if people could go through the list and ensure that I've represented their viewpoint fairly and accurately, and ensure I haven't missed any important points - particularly as I am biased towards requiring validity in the guidelines. On 04/11/05, Gregg Vanderheiden <gv@trace.wisc.edu> wrote: > > > > 1) Can someone give me a list of the arguments FOR including validity. * Validity errors can and sometimes do result in accessibility barriers * Invalid documents are not testable, so it cannot be guaranteed that the final rendering will be accurate for AT * How can elements be programmatically determined if you can't be sure that the content is valid * It is doubtful, and not testable, that other guidelines catch all validity errors that could result in an accessibility barrier * The four principles on which WCAG 2.0 is based require valid code to be testable * Specifications are designed with accessibility in mind, so there should be no need for invalidity * There are always ways to work around issues validly * Invalidly addressing an issue could cause other issues * There is a deep fundamental flaw with a set of standards that proposes to use a baseline concept, but fully rejects embracing basic syntax checking available with the core technologies * Promoting robust and stable long-term standards, even if the face of known issues - which we have every reason to believe will be temporary - is being practical. * Validity is a stable target - if authors follow validity guidelines, OS / browser / plug-in / AT will all improve * Validity has been a requirement in WCAG 1.0, and no one knows of a case where someone has been prosecuted for invalid content * People get prosecuted because they fail to consider others, but for having invalid content * Disrespectful of other specifications, including w3C specifications * Validity offers a solid base on which to build accessibility, and encourages accessibility to be considered from the ground up, and helps safeguard against errors creeping in at a later stage if there is an effort to ensure validity through the project lifecycle. > 2) Now I need someone (else?) to send one of the arguments against. * Additional markup may be necessary to overcome problems that the specification authors were not aware of, and so is not part of the specification, but could improve accessibility * There are other level 1 success criteria that safeguard against accessibility barriers that could be introduced with invalid markup * Too difficult to achieve because of the tools that generate markup * Some developers think they're being clever creating accessible content, but they aren't (cargo cult) * Not all validation errors are of the same level of importance to accessibility * It is possible to have invalid markup that is accessible * It is possible to have valid markup that is inaccessible * The people who wrote the specification don't really want anyone to follow it * Having validity in the document means that the document will not be adopted * Testability is easily achievable with invalid content by running it through an assistive device (observe reality) * Legislation could result in people being prosecuted for invalid markup * Even though there has never been a case of legislation against validity, there could be in the future * Legislators can't reasonably be expected to read a document that they're using for legislation to determine which parts they intend to apply * We're shooting ourselves in the head > 3) Now if someone can summarize any alternatives or variations I wouldn't support them all, but for completion: * Validity at level 1 * Validity at level 2, with techniques that address validity in the techniques for appropriate success criterion * Watered down version of validity at level 1, with validity a requirement at level 3 * Validity completely removed from the guidelines (with a foreword in the document explaining the importance of validity), and address validity in the techniques for appropriate success criterion Best regards, Gez -- _____________________________ Supplement your vitamins http://juicystudio.com
Received on Saturday, 5 November 2005 02:18:18 UTC