WebAIM - Web Accessibility In Mind

E-mail List Archives

RE: Code Validation (was RE: spacing -  versus clear images)

for

From: John Foliot - WATS.ca
Date: Mar 8, 2006 11:00AM

Andrew Kirkpatrick wrote:
> Should we start a pool?

I already stuck out my neck, but my *guess* is that we are still 2 years
out...

> 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.

Right, and those decisions are contrasted against... Standards.

>
> 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...

Well, here I will press you harder. (Much harder).

The whole point of Standards is that they remain "standard". As a
fundamental starting point, all future 'standards" are *supposed* to
degrade gracefully, or be supported by earlier Standards. That's the
point.

As an analogy, look at the lowly screw. Originally, most screws had
slot-top heads, and the blade screwdriver is *still* the most common
screwdriver out there. Yet in the world of modern manufacturing and
construction, the slot top screw has been superceded by either the
Philips (cross) or Robertson (square-tip), as, from an automated and
practical perspective these screws are easier to use. However,
regardless of the screw-top, they all share other common
characteristics, including lengths, thread sizes, etc., so that in the
absence of one type of screw top, a different, yet compatible solution
is readily available - that's Standards. PLUS, the tools (screw drivers)
are also manufactured to work with the screws, based upon standards.

As we develop web content "for the masses", we can often rely on
assumptions, however in the absence of a presumed scenario, what is the
fallback? If there is a Standards based solution, the fall-back exists,
and so the Accessibility perspective is addressed. It may not be as
pretty, as fast, or may miss some of the finer nuances, but the end goal
(access to the information) remains. Using non-standard "hacks"
potentially leaves open the door for total inaccessibility to some or
many users.

Finally, from a QA perspective, there is a generally held 'truth' that
hacks, workarounds and other 'non-standard' solutions have a nasty way
of reaching out and biting you on the behind at the least opportune
time. Look at all those poor souls who deployed various CSS hacks to
address IE 6's shortcoming, they now have to go back and repair all of
their work (http://blogs.msdn.com/ie/archive/2005/10/12/480242.aspx).
Developers who steered clear of hacks can read that article and smile to
themselves, as they continue to move forward, not having to go back and
rework existing stuff they spit out "back then".

>
> 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!".

And I will concede you this - I too have been forced to make compromises
based on browser inadequacies. But this is due, in part, to the fact
that the browsers (wait for it) do not also conform to the published
standards.

You mention an IE hack, and it is generally known that today IE 6 is the
least Standards compliant browser in current widespread usage (and yes,
I know the numbers, but they are shifting. Firefox in Canada has a
reported 25% market share, and I just saw an article last week that
claims that in the UK, Firefox has an 11% market share. And Microsoft
has release IE 7 as a beta, and one of their stated end-goals is to make
it more standards compliant).

So if we expect the browsers to be standards compliant, how can we
justify our use of hacks, work-arounds or other "solutions"?

>
>> 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.

Perhaps, but I am an optimist at heart. As well, we in the
accessibility field continue to preach to the uninitiated, and asking
for/striving for accessible code is one of the easier checks to grasp,
because even the beginner can read a validation report and correct their
mistakes. Valid code does not require the subtle nuances and experience
required to access other WCAG guidelines (what, exactly, is appropriate
alt text, for example?).

> 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.

Yes, I agree that there are a lot of wannabes and posers out there. It
is for this reason that I wish there were a more robust method of
holding these statements to the test. I anxiously await EARL's
ascension to a Recommendation (and which I had more time to be involved
in that initiative).

> 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.

Perhaps, but more than I suspect you think. The rapid rise of Standards
based blogging tools, the advances in SEO techniques, etc. have all
impacted on the 'force' of valid code development, especially the proper
use of headings. Explicit label associations may be harder, but the
current crop of WYSIWYG dev tools have at least made this a lot easier
to accomplish. There is no substitute for proper education however.

JF
--
John Foliot <EMAIL REMOVED>
Web Accessibility Specialist
WATS.ca - Web Accessibility Testing and Services
http://www.wats.ca
Phone: 1-613-482-7053