- From: Robinson, Norman B - Washington, DC <Norman.B.Robinson@usps.gov>
- Date: Fri, 4 Nov 2005 11:51:11 -0500
- To: "Gez Lemon" <gez.lemon@gmail.com>, "WCAG WG mailing list" <w3c-wai-gl@w3.org>
Gez, I'll second (or third, or forth..) your concern. I'll add #5 as "The WAI doesn't have the responsibility for requiring validity; that is another W3C group's role." I think a few of the issues are related to terminology and semantics without understanding the ultimate goals. The WAI, separate from any other internal or external group, must make the statement that validity is a requirement. 1. Validity is essential for programmatically determined accessibility. When you rely on tools and technologies to generate code and content, you have to expect the tools meet some level of quality of accessibility. That can best be accomplished with a standardized approach to analyze the structure and content as much as possible without preventing new ways of creating content. When you validate the structure against a know standard you have a quality indicator that others can reproduce and scientifically test against to validate your results. They can invent new ways to reproduce the same results. When there are defects in their inventions we can better determine where the defect resides. It also encourages any new techniques to either use the existing standards or survive and be useful and drive changes to the standards. Which leads me to your second point about 'clever vs. accessible'. 2. Developers interpret what validity means, are creative, and are trying to create new tools. We owe it to them to provide the means through which they can be successful. They may have no clue what accessibility is! If they develop to a standard and can validate against that standard, they don't necessarily have to know about accessibility. Sometimes developers are cleaver and do provide an approach that is even more accessible than we thought possible. There is hope in their imagining. There is no hope if we don't help them plan. They should plan to validate their content and challenge us when validation is a hindrance to developing or creating; that means *we* weren't clever enough. 3. We don't really want anyone to be bothered with the specification. Well, we don't. That conveys the attitude that people have when they have to create content that validates but cannot. How do we get people to praise the specification as a perfect example of making their life easier? Tool developers should be outputting content from there tools that validates. Users that don't know about what that implies will rely on the tool and be happy when they are tested. Users that know all about the details of the specification can determine a vendor's implementation as a quality factor. The developers mentioned above can select the best tool. The more developers that implement technologies based on the specification, the more likely we'll correct the defects, the more likely the specification is to be useful. Let me tell you, this is an economy of scale issue. Have you used products that produce invalid code? They are a bother. Have you tried to view the content with a screen reader? It isn't just a bother, it makes the content difficult or impossible to USE. Guess what I'm trying to state is that I want us to think of ways people champion the specification. Think about the negative aspects only as ways to see where the specification is wrong, not as a reason to not take action and do what is right. 4. Legislation could result in people being prosecuted for invalid markup. Nope! People don't get prosecuted for invalid markup. People get prosecuted because they fail to consider their fellow man and ignore their needs as being equal to their own. As far as I know, any reference to legally enforceable policy maintains standards. If some person in an agency must meet those standards, then they can be prosecuted for not doing so. But that is for not following the decreed standard - whatever that standard may be - not because of the standard, but because they didn't follow management direction. That could be government management by-the-way. They could change the standards out yearly. But since we're on the subject, Section 508 is a good example. It has several technical accessibility standards, along with functional standards. If you meet the technical standards, you have a quality product. Doesn't mean you have a good product from a business need perspective, or that your product functions as advertised. And, if you don't meet the technical standards, but do meet the functional standards, then I'd say someone has been very clever, and they are probably Section 508 compliant. It could be done with invalid markup. The question is, can people be prosecuted for valid markup? Does validity support being accountable and best practices such that in a legal challenge it a justification of intent? Validity is a mark of quality. It really does make accessibility more likely, from making the time spent in a review more efficient and from the probability that tools that validate can reuse the same content. I'll restate: validity is required for accessibility. It should be a required statement in the WAI. It allows you to test CONTENT instead of finding defect in and having to test tools or applications for compliance. Regards, Norman B. Robinson
Received on Friday, 4 November 2005 16:51:21 UTC