WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Well formed verses Valid code


From: Andrew Kirkpatrick
Date: Feb 26, 2007 2:30PM

I'll agree that valid code has benefits for the developer, including
ones you mention. I'll support it in a corporate or agency policy for
web development, but for reasons apart from accessibility. Validity
tests may find some issues that affect accessibility, but these issues
are covered elsewhere in accessibility standards (e.g. missing alt
attribute on an image). I have yet to see an issue where the code is so
mangled that it impacts the way assistive technologies render the
content but that doesn't affect the visual rendering for sighted users.
I agree that valid code should be a policy, just not an accessibility


> -----Original Message-----
> [mailto: <EMAIL REMOVED> ] On Behalf Of
> Robinson, Norman B - Washington, DC
> Sent: Monday, February 26, 2007 4:00 PM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] Well formed verses Valid code
> 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 approach.
> 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.
> Regards,
> Norman B. Robinson
> Section 508 Coordinator
> IT Governance, US Postal Service
> phone: 202.268.8246
> -----Original Message-----
> [mailto: <EMAIL REMOVED> ] On Behalf Of
> Andrew Kirkpatrick
> 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.