E-mail List Archives

Re: Well formed verses Valid code


From: John Foliot - Stanford Online Accessibility Program
Date: Feb 27, 2007 11:20AM

Alastair Campbell wrote:

...a response I totally agree with. He said:

> We use valid code to be sure that various user agents render the
> content as expected. (Of course they don't in practice, but at least
> then we know it's a bug of that user agent and therefore their
> responsibility.)

(Pure petrol/gasoline vs. flawed autos)

> Since each of these assistive technologies could render non-valid
> code differently, the best thing you can do within a reasonable
> effort is ensure that you use valid code, and check common user
> agents.

I might also add that in the subjective realm of applying the WCAG against
your content (What *is* an appropriate ALT text? - we believe we know what
is *not* appropriate, but everything else is opinion; what is "blink"
exactly?) ensuring valid code is a binary check - it's valid or it's not.
When instructing or teaching new students to the concepts of accessible web
development, it's nice to have a solid foundation to build upon, and that
foundation is code standards.

Andrew, this is not a criticism aimed at or to you, but I am at a total loss
as to why so many developers dismiss valid (x)HTML as a non-issue, or not
critical to the accessible development process. Andrew may be right that in
practical terms, many pages that do not validate are still accessible to
mainstream users as well as the majority of users of AT. Does this then
make it right? I argue no - if it fails one person due to "bad code", then
we as developers have failed.

Setting valid code as a requirement for "accessibility" establishes the fact
that developers must take care, must think through what they are doing, and
must not rely on hacks, cheats, and trickery to appease one browser or the
other - a situation that is not as prevalent as it was 5 years ago, but
still persists. Forgiving large CMSes and other large-scale
platforms/developments for what should be trivial things to fix in essence
says "Do your best, but don't worry too much, it's not really that
important" - and if getting a basic markup language syntax correct is not
that important, why should other arcane requirements such as providing a
long description, or captioning to videos be any more important - hey.. They
tried their best, but Oops... Sorry. It's a mind set thing.

To the seasoned veterans of this list (and others) who have been banging
away at this for years, Andrew's points can have some credence - I simply
worry that the message it sends to the uninitiated or newer developers who
are beginning this journey may be confusing. Validation is simple, and
keeping things simple for beginners is not a bad thing - once you can
produce valid code all the time, every time, regardless of whether the pages
are hand coded in notepad, or churned out by a CMS, blogging tool or other
means, then you can relax your requirements slightly. Once you understand
the "rules", then when you break a rule, you know a) that you have, b) you
know why, and c) you have a good idea of the potential for problems it may
or may not be creating. But before you get there, striving for and
attaining code validation is a good start. I know that Andrew does not
disagree with the need/desire for valid code - that's not what he has said.
But I think that de-linking code validation from accessible web development
is the edge or a slippery slope, it in effect says that standards can be
secondary to results - a point that flies in the face of logic to me.

> It may be that an ampersand in an href is not going to affect any
> known user agent, but if you're going to provide a guide for
> developers, I'd keep it simple: use valid code.

EXCEPT... Earlier in this thread my good friend Derek Featherstone pointed
out a situation (rare, but real) where a fouled ampersand *DID* negatively
affect the outcome (http://webaim.org/discussion/mail_message.php?id=10177).

> I have been in
> situations where developers were reluctant to use valid code because
> it meant changing their CMS, so I don't think it will necessarily be
> caught by other parts of the process.

And see, that's the point. If they are reluctant to something as basic as
code validation, and it is accepted that this is OK, then what happens when
they must do something else in the name of accessibility?