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

RE: Validity as a technique

From: Robinson, Norman B - Washington, DC <Norman.B.Robinson@usps.gov>
Date: Tue, 8 Nov 2005 09:36:27 -0500
Message-ID: <EAF95052690D174A833DC58B15AB6A8819E8DF@WADCHQSXM24.usa.dce.usps.gov>
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
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?

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.
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.


Norman B. Robinson
Received on Tuesday, 8 November 2005 14:36:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 16 January 2018 15:33:57 UTC