WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Well formed verses Valid code

for

From: smithj7
Date: Feb 26, 2007 6:00PM

Good points. I went to the Web Master Jam Session 2006 which included
mostly private sector folks. Standard based coding was a theme that went
through out the program. I went back, worked on a style sheet for "front
page" and secondary pages, and discovered I did need to clean my code to
make the css style sheet work. I'm almost through cleaning up all the
folders and will be able to put up the new page (looks like old one, but is
now standard based - if I understood the term as it was used). I don't
understand why we all won't want to start with basic good (x)html, xml, css
standards and then work on accessiblity. Wouldn't it even be wonderful if
we had standards for (x)html, xml, css that included accessiblity issues as
part of those standards, kind of what the new building codes have, if I
understand how the new building codes work.

----- Original Message -----
From: "John Foliot - Stanford Online Accessibility Program"
< <EMAIL REMOVED> >
To: "'WebAIM Discussion List'" < <EMAIL REMOVED> >
Sent: Monday, February 26, 2007 5:27 PM
Subject: Re: [WebAIM] Well formed verses Valid code


> Andrew Kirkpatrick wrote:
>> 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 policy.
>>
>> AWK
>>
>
> Some thoughts:
>
> 1. Universal Accessibility should be (is!) about more than just adaptive
> technologies (Past, Present or Future) - I always thought the goal was
> that
> our content would render for *all* technologies - we're not building cars
> for the information highway, we're supplying the fuel. You can drive any
> vehicle you want, but the fuel I dispense will always be "pure" (valid).
> Valid code, as Norman Robinson pointed out, returns the responsibility to
> the user agents to process the information correctly to the end user - and
> this includes but is not limited to Adaptive Technology (which can assist
> users who do not fall into the "sighted" or "not-sighted" category). I've
> seen code that rendered fine on screen, that read fine to screen readers,
> but was functionally "broken" simply due to invalid code (I'm thinking of
> some .net crap that only works in IE browsers - I have no current or
> specific examples). If we (or at least I) keep talking about Universal
> Accessibility, but continually return back to Adaptive Technology "quirks"
> (or lack of), it somehow dilutes the message to me. It's almost a reverse
> discrimination.
>
> 2. Accessibility should be part of "The Policy" (full stop). That same
> policy should also include requirements for valid code, and can include
> other requirements as well - I spent a fair bit of time working within the
> Canadian Government's Common Look and Feel policy, which included
> accessibility, but spoke to much more, including the fact that Canada is
> an
> officially bilingual country (along with all that this entails), and other
> related items (email auto-responders for example - their usage, structure,
> etc.). I am troubled that we again want to marginalize "accessibility"
> and
> speak about specifics regarding Adaptive Technology - yet at the same time
> we preach that Universal Accessibility is foundational, and not something
> that you bolt on at the end of the day.
>
> Which is it?
>
> Just my $0.02
>
> JF
>
>
>