WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Well formed verses Valid code

for

From: smithj7
Date: Feb 26, 2007 5:50PM

Unfortunately, in Florida, it seems like folks don't want to do simple stuff
like have dtd. That's why I want to know if well formed is enough. Can you
even tell if code is well formed without a doc type?

Our agency uses dreamweaver and it will validate code. I also check with
the w3 validator. I just don't know if I'm getting valid code or well
formed when I take it through one of these.
----- Original Message -----
From: "Robinson, Norman B - Washington, DC" < <EMAIL REMOVED> >
To: "WebAIM Discussion List" < <EMAIL REMOVED> >
Sent: Monday, February 26, 2007 4:00 PM
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
>
>
>
>
>