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

RE: Validity

From: Robinson, Norman B - Washington, DC <Norman.B.Robinson@usps.gov>
Date: Fri, 4 Nov 2005 11:51:11 -0500
Message-ID: <EAF95052690D174A833DC58B15AB6A8819E8C3@WADCHQSXM24.usa.dce.usps.gov>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:40 GMT