WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Bringing accessibility into the development process (request for feedback).

for

From: tedd
Date: Apr 16, 2007 3:10PM

At 7:00 PM +0200 4/16/07, Peter Krantz wrote:
>Thank you for your feedback. Maybe your experience is from smaller sites
>where you didn't employ a test driven approach?.

Peter:

I don't know what a large site is -- 100 pages, 200 pages, what?

The maximum site I've worked on had between 50 to 100 end-user "on
the fly" customized pages with calendar, news, and some other
functions -- I don't know if that qualifies or not.

However, large sites like that don't present much more of a problem
than a typical three page site in terms of accessibility -- provided
-- you are organized. The standardization of form and content
(layout) throughout the site coupled with a good navigational scheme
and focused css provides an excellent foundation for generating site
of any size -- it's just variations of a theme.

>If you have a large
>application and work with TDD you want to run all tests as soon as you are
>about to check in code (which may happen several times a day). Any
>disturbance in this process impacts available development time.

Understood, but understanding and applying "good practice" basics
when developing code will certainly cut development time. The real
cost in development time is spent fixing deviations from good
practice, no?

>Going through each view combination in your application will require you to
>run through the process manually, stopping and sending the resulting HTML to
>one of these online validators and then interpret the result. Manually
>stepping through just one of the scenarios in an application in a recent
>project I participated in took around 20 minutes.

That's for the first time. If you learn, then the next time it will be less.

>That's why many development projects use an automated test tool like
>Watir or Selenium.

I don't know those tools, so I can not comment specifically. However,
perhaps reliance on tools like that are part of the problem. I don't
think all of this can be automated -- at least not yet.

Keep in mind, that application developers to automate web development
created WYSIWYG editors that lead (or at least contributed greatly)
to the wide spread table abuse we have now.

>See above. If you need to run all tests (and interpret the result) for many
>pages it will take a lot of time.

If you use good practice in coding, then the test for many pages
should be no more than a test for the number of layouts you're using.
Every page of your web site (except content) should not be unique,
are they? If so, I would wonder why -- that's like like publishing a
book where every page has a different layout.

My advice would be to create internal standards for text, graphics,
links, forms and have your developers work from those standards. This
is not rocket science, it's just adapting good practice standards.

>There's no magical cure, no shortcut -- just plain hard work in
> > learning, understanding, and applying solutions.
>
>That's why I am looking into tools to make it easier for developers. It
>shouldn't be hard work to increase basic accessibility. Maybe that's why
>many modern software development projects still miss this point?

The hard work I'm referring to is learning the problems, figuring out
what to do, and then applying what you've learned. After knowing it
becomes simperer and easier. It's like learning anything -- like css
-- once you see what it does, then it becomes second nature to apply
it.

I am sure that you can put together a list of guidelines of things to
look for. There are even several books on the subject -- the two that
I purchased are "Building Accessible Websites" by Joe Clark and
"Accessible Web Sites by Thacher et al. Those will give you a good
introduction.

Of course, you could always out-source some of that work to me. :-)

Cheers,

tedd

--
-------
http://sperling.com http://ancientstones.com http://earthstones.com