- From: Robinson, Norman B - Washington, DC <Norman.B.Robinson@usps.gov>
- Date: Tue, 8 Nov 2005 09:36:27 -0500
- To: "Maurizio Boscarol" <maurizio@usabile.it>, "Ineke van der Maat" <inekemaa@xs4all.nl>
- Cc: <w3c-wai-gl@w3.org>
On Tuesday, November 08, 2005 8:22 AM, Maurizio Boscarol responded to Re: Validity as a technique, with: "Most of all, there's a logical constraint not to put validity as mandatory: Premise: If validity is necessary, no invalid page should be accessible Observation: there is at least one invalid page that is accessible (already discussed). ergo... Premise must be false!" No. As mentioned previously on this list in more detail, it is not necessary. It is *REQUIRED*. Or more specific, it should be a requirement of this specification. I'll concede that required at a specific level is acceptable, since then I can require vendors to meet a certain specification level in their product. "I surely can't understand why some of you talk about things like "it's the difference between mediocrity and excellence".. that has nothing to do with web accessibility. Accessibility barrier there are or there are not. And we have three level of priority to assess increasing level of accessibility, from basic to advanced. So I can't see why this should be a problem." I may have offered that challenge. I still will argue the point that not requiring validation (at some level) is substandard. Conceptually you can state the accessibility barrier exists or it doesn't. The reasons why technologies fail is what I'm trying to address. There are ways to validate content programmatically. In the event that validation finds defects, the reviewers are aware that they: 1) aren't following the specification (a defect by accident or by design) or 2) have found a defect in the validation tool or process. If there is a defect they can fix it or know that they are outside the specifications (as in doing something new and innovative might require). If there is a defect in the tool or process it can be fixed, unless the content being tested cannot be determined by the tool or process, that is not a logically, machine testable process (e.g. programmatically determined). What you then have is quality content. Any defect from there on is a problem with the user agent or the assistive technology. To your point, is the accessibility barrier in the 1) content, 2) lack of concern by the creators in testing for valid content; either the creators, developers, or client during user acceptance, 3) in the user agent, 4) in the assistive technology program itself, or 5) in the individual wanting access to the content? Example: 1) content has no alt text, 2) not reviewed for validation by anyone, 3) user agent renders content, 4) assistive technology renders alt as blank, 5) user has no clue as to what is in the image content. Step 2, validation would have shown the alt text to be missing. or 1) content has nested tables, 2) not reviewed for validation by anyone, 3) user agent visually renders content by determining where to close tags based on programmer's best guess and looks fine, 4) assistive technology (screen reader) fails to render anything beyond the first table because it can't deal with the lack of tags (tag soup) in this event 5) user can't gain access because of invalid content. Step 2, validation would have required the tables to be coded properly and the assistive technology would have worked. Both of these are real world examples that I've witnessed. Validation was the ongoing solution after determining the nature of the problem. When in debate, one must be talking about the same items in the same way, or it isn't a logical debate. Hopefully we were talking about the same thing or through my example you understand where we are not referencing the same concepts. I appreciate your taking time to debate this issue. Respectfully, Norman B. Robinson
Received on Tuesday, 8 November 2005 14:36:38 UTC