E-mail List Archives

Re: Well formed verses Valid code


From: Robinson, Norman B - Washington, DC
Date: Feb 26, 2007 2:10PM

I'll chime in with some generalizations for all our 1+ million
or so internal pages at USPS.

Valid DTD's should be required by policy.

Before anyone can begin to determine what does or does not work,
you have to account for a variety of factors, including which screen
reader you are using, on which operating system, and which version is in
use. Rather than show specific examples to allow the reader to logically
find faults or assign validation versus accessibility issues, let me
offer you a scenario.

If the screen reader software itself is software and thus
subject to defects, interprets HTML markup (via the DOM or by accessing
the code) and you encounter a defect, is it the content or the screen
reader? We can point to "invalid code" or "code that will not pass
automated validation" that is accessible. That doesn't mean that the
screen reader _should_ be expected to make the content accessible. That
is, if the screen reader were to follow the HTML standards, we might
logically forgive the software for not providing access if the *code or
content* didn't follow the standards that exist. Part of establishing
that the content is standard is defining the DTD. This also brings
awareness to the content creator about DTD and a standards based

Add to that there is no "one browser". Just as in screen readers
themselves, multiple versions of browsers exist, all providing multiple
levels of quality to MSAA or DOM information, thus also impacting the
screen readers that relies on that information. Personally, I've
experienced the most issues with nested tables; issues where the screen
reader couldn't access the content where it was clear the table wasn't
coded correctly and it impacted accessibility. My point is, if there is
a standard and a way to validate you meet that standard, why would you
_NOT_ want to try and validate?

This isn't about whether software prefers valid code or not. It
is ultimately better if we follow a standards based approach so that
when we do find defects in (HTML) code or content, we can expect the
vendor to solve the defect. We wouldn't be able to do that with
non-validating code to any reasonable degree. Also, when we do validate
we reduce defects and errors, improving the general "quality" of our
code. We verify we coded correctly or the tools we used created valid
code, which is an indication of quality you cannot assume if you don't
test or validate.

Short version: Ensure you validate your code and you'll increase
your quality, increasing the ultimate likelihood for accessibility in
the process.


Norman B. Robinson
Section 508 Coordinator
IT Governance, US Postal Service
phone: 202.268.8246

-----Original Message-----
[mailto: <EMAIL REMOVED> ] On Behalf Of Andrew
Sent: Monday, February 26, 2007 1:43 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Well formed verses Valid code

> This might be of interest:
> http://blog.fawny.org/2004/05/13/screen-reader-code/

This ignores the fact that the two screen readers that are referenced in
this post don't parse the HTML themselves - they use MSAA or the DOM to
get their interpretation of the content. The question beomes whether
the browsers make errors in their interpretation of the HTML and
subsequent creation of the DOM or MSAA tree, not whether screen readers
prefer valid code or not.