WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Creating Valid Code

for

From: Barry Johnson
Date: Sep 9, 2011 12:06PM

I have to agree strongly with Elle.

While valid code does not = web site accessibility, creating W3C valid code
helps make your site available to all browsers on all platforms, and this
means a lot less work has browsers and platforms change in the future. It
also allows the code to read more easily by the assitive technology, as they
only have the code standards to create their tools.
The fact that this get the developers up close and personal with the code
and helps them make the right decisions.

Code to the standards and your code will be available to any
technology/platform.

Barry


On Thu, Sep 8, 2011 at 11:25 PM, Elle < <EMAIL REMOVED> > wrote:

> I meant to add this small footnote:
>
> * we also used that opportunity to build in some usability requirements to
> get closer to the true goal for accessibility :)
>
>
>
> On Thu, Sep 8, 2011 at 11:24 PM, Elle < <EMAIL REMOVED> > wrote:
>
> > Ryan:
> >
> > If it helps, I can give you my perspective at a large company with over
> > 30,000 employees. Until just last year, we were struggling to justify
> the
> > effort to insist on W3C valid code. Most of the concerns involved
> increased
> > development costs, additional testing, and blowing up project time lines.
> > Keeping in mind that not all companies have the same challenges, most
> large
> > organizations also outsource a great deal of development to contracted
> labor
> > who may or may not be familiar with W3C standards. So, there's an
> undeniable
> > cost to establishing web standards like W3C valid markup. And what did it
> > really get us? That was the main question that needed answering.
> >
> > When we were building our web accessibility program last year, we decided
> > to use that moment to incorporate W3C validity* into our accessibility
> > requirements. As John said, "code validation, in-and-of-itself, may have
> > very little impact on true accessibility." But, it does represent a
> > paradigm shift for IT teams: semantic markup matters. Previously, like
> many
> > fast moving big companies, we would build (largely ASP.NET) web
> > applications rapidly with wireframes and visual mock-ups for agile
> > requirements. There wasn't much consideration or scrutiny over what was
> > "under the hood" when it came time to show our business partners what we
> had
> > created for them, as long as it performed as was requested. Web
> > accessibility changed all that, as it has a way of getting up close and
> > personal with an individual's source code. Accessibility requires
> > transparency. So, while we're under the hood, why not create a stronger
> > foundation for cross-browser operability and device independence? We
> figured
> > if we did it right, we wouldn't have to continually chase the latest
> browser
> > versions with code updates.
> >
> > Since that time, we've found that creating this base level requirement
> (all
> > code must validate through W3C with a testing artifact that's loaded into
> > our Software Development Life Cycle) has streamlined our development
> process
> > and reduced the pesky defects we used to encounter during user acceptance
> > testing. That's a quantifiable cost savings. Progressive enhancement and
> > MVC as a design pattern have made that easier to achieve and even
> cheaper.
> > We do have exceptions for third party source code (example: vendors who
> > supply scripts), but that's a different battle to fight.
> >
> > Hope that helps,
> > Elle
> >
> > --
> > If you want to build a ship, don't drum up the people to gather wood,
> > divide the work, and give orders. Instead, teach them to yearn for the
> vast
> > and endless sea.
> > - Antoine De Saint-Exupéry, The Little Prince
> >
> >
>
>
> --
> If you want to build a ship, don't drum up the people to gather wood,
> divide
> the work, and give orders. Instead, teach them to yearn for the vast and
> endless sea.
> - Antoine De Saint-Exupéry, The Little Prince
>