Re: Methodology

On  3 Jan, Mike Baker wrote:

> Can anyone share a methodology for testing and analyzing existing sites for 
> accessibility? I'm curious as to which specific steps you feel are 
> essential and where the majority of your focus lies.

  What we (ie. the company I work for) do when faced with testing a new site
  is basically the same as we do when testing any item[1]: establish a
  'baseline', ie. a set of needs which the - in this case site - needs to
  furfill to 'pass'.

  For a generic site unless otherwise told, we usually list thing like:

   - HTML, specific version (default HTML 4.01 Transitional). Test with
     W3C or WDG SGML-based validator. This eliminates 'creative' markup
     which fuddles up browsers, but also typos which can fuddle up anything.


   - CSS used for layout (default Level 1). Test with W3C or WDG 'lint'.
     This - atleast tries to - helps with separating content and layout, It
     also helps with classical CSS typos which mess things up in even
     supporting browsers.


   - Good alternative content (ALT, NOSCRIPT, etc) suitably tested with
     Lynx (what goes for Lynx very often goes for braille and screen readers
     for natural reasons). This ensures that even beefed up, hot, cool,
     kewl, whatever content actually works when the kewl-factor ain't there.


   - Run it trough the W3C (yep, guys, we do do this) WAI checklist. This
     helps making it more humane, if nothing else.


  etc. YMMV, of course, but covering these bases tend to eliminate a very
  large quantity of (silly) errors which impede accessibility. IMnsHO, and
  all that. One could add

   - IF layout is done trough non-CSS means, have a closer look to see if
     it degrades (lets not be subtle) gracefully. This is though a point
     which is also often covered by the alternative content bit above.

  And Bobby can be useful, yes. I just like to know exactly what I'm doing
  when I do this ... add to that that Bobby and I don't always see eye to
  eye, and voila. My 10 NOK >;)

  If you want to do something with your time until next New Year's Eve, I
  suggest formalizing your own methodology. The trick is to *have* one, and
  to follow it (when practical) ...



 [1]
  Website, project, product, program, etc, etc, etc. And yes, the things
  we check for DO change from 'program' to 'website'; sheesh! :)

-- 
 Tina Holmboe     [ka`ira@IRC]  [tina@elfi.org]  [tina@htmlhelp.com]

$_ = <<'-- '; s/../pack("c",hex($&))/eg; eval;
7072696e7420224a75737420616e6f74686572205065726c206861636b65722c22
--

Received on Wednesday, 3 January 2001 15:28:32 UTC