E-mail List Archives
Thread: Code Validation (was RE: spacing - versus clear images)
Number of posts in this thread: 7 (In chronological order)
From: John Foliot - WATS.ca
Date: Wed, Mar 08 2006 6:30AM
Subject: Code Validation (was RE: spacing - versus clear images)
No previous message | Next message →
Andrew Kirkpatrick wrote:
> It is a helpful, but not necessary, requirement in the development of
> an accessible web site.
>
WCAG 1, Priority 2, 3.2 Create documents that validate to published
formal grammars.
My single largest complaint of Section 508 is the failure to insist that
the "code" being created for the information delivery is not
Standardized, (read - compliant). Other countries and most large
institutions that even consider web accessibility generally set Priority
1 and Priority 2 compliance (at a minimum) as the benchmark.
If we are going to talk about Standards Based Development, then using
the standards as they have been authored should be the first and primary
requirement from the developers. Advocating or even excusing
non-compliant code development sets back Standards based development,
and by extension web accessibility, by at least 5 years. The best
guidance from the de facto web standards organization (W3C) is quite
clear - use only valid code! (As an interesting aside, if you want to
stray from the beaten path, you *could* always write your own custom
DTD, thus remaining within the "letter" of the guideline, although
browser support is another issue altogether.)
The following Wired Magazine article (2002) brings Standards Based
development into clear focus, and I still refer others so it today;
(http://www.wired.com/wired/archive/10.01/standards.html)
I can use the heal of my shoe to pound a nail into the wall, but we have
hammers for a reason...
JF
--
John Foliot = EMAIL ADDRESS REMOVED =
Web Accessibility Specialist
WATS.ca - Web Accessibility Testing and Services
http://www.wats.ca
Phone: 1-613-482-7053
From: Andrew Kirkpatrick
Date: Wed, Mar 08 2006 6:50AM
Subject: RE: Code Validation (was RE: spacing - versus clear images)
← Previous message | Next message →
> > It is a helpful, but not necessary, requirement in the
> development of
> > an accessible web site.
>
> WCAG 1, Priority 2, 3.2 Create documents that validate to
> published formal grammars.
Yeah, I think I've heard of that one! ;)
I'll still stand by my "helpful but not necessary" comment. Adhering to
WCAG 1.0 P1 and P2 doesn't make your site accessible, it makes it
compliant with those guidelines. You can still have a site that is
accessible to users even if 3.2 is not met.
This is recognized in WCAG 2.0, and there is no demand for valid code,
but rather that code can be "unamibiguously parsed".
> If we are going to talk about Standards Based Development,
> then using the standards as they have been authored should be
> the first and primary requirement from the developers.
We're talking about accessibility first and foremost. Standards based
development is a complementary topic, but doesn't fully overlap with
accessibilty.
> Advocating or even excusing non-compliant code development
> sets back Standards based development, and by extension web
> accessibility, by at least 5 years. The best guidance from
> the de facto web standards organization (W3C) is quite clear
> - use only valid code! (As an interesting aside, if you want
That's not my read on WCAG 2.0...
Again, I fully support standards, but first I support accessibility for
users in ways that work. If something is better, easier to implement,
etc. it is work looking more closely at even if it is not in a standard.
AWK
From: John Foliot - WATS.ca
Date: Wed, Mar 08 2006 7:30AM
Subject: RE: Code Validation (was RE: spacing - versus clear images)
← Previous message | Next message →
Andrew Kirkpatrick wrote:
> This is recognized in WCAG 2.0, and there is no demand for valid
> code, but rather that code can be "unambiguously parsed".
(For the Record to casual observers, Andrew and I have conversed many
times, and we are generally on the same side most of the time)
Andrew, When WCAG 2.0 surfaces as an actual "Official Guideline" or
"Recommendation" (in what? 2010 <smile>?), then that may indeed be the
position. However, as it stands right now, and for developers outside
of the US, the *requirement* for valid code remains in WCAG 1, which for
many, *is* the Standard (rightly or wrongly).
>
> We're talking about accessibility first and foremost. Standards
> based development is a complementary topic, but doesn't fully overlap
> with accessibility.
True, but we are also, in a very broad term, talking about technology as
well. How can you justify "hacks" or equivalent that "work" now, but
may not work later? This is a bad development position at any time, in
any technology, especially as it scales out to larger and larger
initiatives. Developing to Standards ensures that your content "works"
now and into the future, as it is based upon published Standards. By
their nature, Standards remain in effect, even if they fall from favor
or are superceded by newer technologies in the future. Non-Standard
constructs, on the other hand, may simply cease to be supported. This
can create a very real access problem for all users, not just those with
special needs.
>
> That's not my read on WCAG 2.0...
Right, and it appears to this humble observer that this exact type of
debate is precisely why we are still waiting on WCAG 2.0; the gap
between Standards advocates and the "ya but it works" proponents. Many
complain that WCAG 2.0 is long on theory, and still very short on
measurable outcomes. There is a large segment out there that requires
precise, measurable, predictable outcomes for verification and
validation (even though I personally agree that this is but a portion of
the total accessibility picture). Ensuring valid code is a simple
checkpoint to include - it's right or it's wrong. Authoring to standards
does not automatically make a site accessible, but I posit that if the
developer(s) have taken the time to ensure that their source code meets
validation requirements, that they have also taken a reasonable amount
of time to ensure other "accessibility" requirements have been met,
addressed, or at least considered.
JF
--
John Foliot = EMAIL ADDRESS REMOVED =
Web Accessibility Specialist
WATS.ca - Web Accessibility Testing and Services
http://www.wats.ca
Phone: 1-613-482-7053
From: ben morrison
Date: Wed, Mar 08 2006 9:20AM
Subject: Re: Code Validation (was RE: spacing - versus clear images)
← Previous message | Next message →
On 3/8/06, John Foliot - WATS.ca < = EMAIL ADDRESS REMOVED = > wrote:
> >
> > We're talking about accessibility first and foremost. Standards
> > based development is a complementary topic, but doesn't fully overlap
> > with accessibility.
>
> True, but we are also, in a very broad term, talking about technology as
> well. How can you justify "hacks" or equivalent that "work" now, but
> may not work later? This is a bad development position at any time, in
> any technology, especially as it scales out to larger and larger
> initiatives. Developing to Standards ensures that your content "works"
> now and into the future, as it is based upon published Standards. By
> their nature, Standards remain in effect, even if they fall from favor
> or are superceded by newer technologies in the future. Non-Standard
> constructs, on the other hand, may simply cease to be supported. This
> can create a very real access problem for all users, not just those with
> special needs.
Im in agreement with both of you, firstly I think standards are very
important and its the only way the web can improve from its awkard
beginnings - think browser wars/hacks and work forwards into the
future.
Although, as we know we need to be pragmatic about it - as the
longstanding accesskey/tabindex issues have shown.
I suppose the difference here is that we follow best practices and no
we should not be using <spacer>.
Ben
From: Andrew Kirkpatrick
Date: Wed, Mar 08 2006 10:00AM
Subject: RE: Code Validation (was RE: spacing - versus clear images)
← Previous message | Next message →
> (For the Record to casual observers, Andrew and I have
> conversed many times, and we are generally on the same side
> most of the time)
Absolutely. I don't think that we're far off here either, but I can't
look at the evidence today and say that valid code is _required_ for
accessibility, even if it is required for WCAG 1.0 P2 compliance.
> Andrew, When WCAG 2.0 surfaces as an actual "Official
> Guideline" or "Recommendation" (in what? 2010 <smile>?), then
Should we start a pool?
> True, but we are also, in a very broad term, talking about
> technology as well. How can you justify "hacks" or
> equivalent that "work" now, but may not work later? This is
Generally I don't need to but there does need to be decision making on
the part of the developer to determine whether a particular technique is
beneficial, harmful, valid, cheap, expensive, etc. in order to make the
right decision for the scenario at hand.
> Developing to Standards ensures that your content "works"
> now and into the future, as it is based upon published
> Standards. By their nature, Standards remain in effect, even
> if they fall from favor or are superceded by newer
> technologies in the future. Non-Standard constructs, on the
> other hand, may simply cease to be supported. This can
Standard constructs can also cease to be supported. No, I don't have a
good example on hand, but there is no reason that it can't happen...
> create a very real access problem for all users, not just
> those with special needs.
This is why testing is important, and keeping sites up to fate is also.
> Right, and it appears to this humble observer that this exact
> type of debate is precisely why we are still waiting on WCAG
> 2.0; the gap between Standards advocates and the "ya but it
> works" proponents. Many complain that WCAG 2.0 is long on
I can't take credit for all of the delay. This is a concern for Flash,
as you know. With Flash in a web page for example, you need to choose
between writing invalid code via javascript, writing static invalid
code, valid code that is incompatible with screen readers, valid code
that is incompatible with Mozilla, or writing valid code with an IE
hack. I don't care which you use as long as the users are able to
access the content. This is not a case of "ya but it works" but "hey -
this doesn't work!".
> developer(s) have taken the time to ensure that their source
> code meets validation requirements, that they have also taken
> a reasonable amount of time to ensure other "accessibility"
> requirements have been met, addressed, or at least considered.
That is a huge assumption and while it may be anecdotally supported, I
doubt that it is really statistically true. I'd be more willing to say
that those who take the time to validate their pages are more likely to
run a "Bobby" test, but not necessarily the manual tests. I wonder what
percentage of sites developed with valid code also use HTML headings and
explicit label associations - I bet it's less than you might hope.
AWK
From: Andrew Kirkpatrick
Date: Wed, Mar 08 2006 10:10AM
Subject: RE: Code Validation (was RE: spacing - versus clear images)
← Previous message | Next message →
> I suppose the difference here is that we follow best
> practices and no we should not be using <spacer>.
This is exactly what started all this - if someone says something is
better, it is worth finding out why, for the education of the list as a
whole. Maybe there is a good reason. In the case of <spacer>, I too am
skeptical of the value, but I know that the person suggesting it works
on pages that get more views than most of the rest of ours combined and
there may be reasons that are unfamiliar to some.
AWK
From: Karl Groves
Date: Wed, Mar 08 2006 10:20AM
Subject: RE: Code Validation (was RE: spacing - versus clear images)
← Previous message | No next message
> I don't care which you use as long as the users are
> able to access the content. This is not a case of "ya but it
> works" but "hey - this doesn't work!".
This sort of sentiment is fine - so long as what you START with is good
code.
Too often the "ya but it works" people are too quick to then follow the path
of accepting anything that works right now (and often on their favorite
browsers, at their favorite resolution).
They feel that any means toward their immediate end is fine, whether it is
8-deep nested tables, text in images, or silliness like <spacer> tags.
That's not to say that there aren't instances where invalid markup can (or
should) be used. For instance, using <embed> for placing Flash because
<object> support sucks. Such methods are fine, so long as it is done because
the method was *needed*, not because "well, it works in my browser".
Karl L. Groves
User-Centered Design, Inc.
Office: 703-729-0998
Mobile: 571-214-1714
E-Mail: = EMAIL ADDRESS REMOVED =
Web: http://www.user-centereddesign.com