Re: Kynn's WCAG Proposal

Jason White wrote:
>This is ground which has been well covered. Providing the practicing web
>site designer with guidance is only one of the purposes of the document.
>Its other functions include: (a) defining what it means for web content to
>be "accessible", more abstractly than can be achieved by a set of
>technology-specific requirements so that the guidelines can continue to
>apply as technologies evolve; (b) offering technology designers (including
>those creating, or extending, data formats) criteria with which to ensure
>that their technologies are accessible; and (c) providing input to other
>groups concerned with the design and development of accessible
>technologies, authoring tools, etc., associated with the web. These may
>include educational or policy-oriented groups--whoever finds a precise
>specification of what "accessible" design amounts to, in the web arena, to
>be valuable.

I must admit that when I first joined the Web Content and Accessibilty
Guidelines group, what I expected was to be working on was, more or less,
two documents. The first document would be explaining what something had to
accomplish to be accessible, and the second one would tell you how to do it.

As a web designer/content writer/web application programmer for the lion's
share of my professional career (not very long, mind you, as I'm only 29
years old), I know that what I want is something to tell me how to follow
the 'straight and narrow'. Ideally, we would have something like the HTML
validator, where a user can point to a URI and have an automated system
point out the problems. However, accessibility I feel like an
'Accessibility Validator' would feel like a grammar checker... it would
point out the glaring errors 'You didn't use an alt attribute', but could
only suggest in other places 'This alt attribute is only 3 characters long.
Are you sure it fully describes the 158kb image it is associated with?'


Because it's simply not going to be possible to have a foolproof validator,
the average web designer is going to need this list of checkpoints (what do
I *have* to do?) and techniques (how do I do it?). In my opinion, both of
these have to be accessible to the average web designer. We can't count on
the tools... vi, emacs, and notepad aren't going to be helping you, and
yes, a lot of web design is still dne by hand. And we can't count on
companies having a team, with one person specializing in accessibility...
we can't even count on companies having a person that CARES about
accessibility. As such, the documents we create, to fill the need that I
see, have to be accessible (ahem) to the average web designer... and by
this, I mean the freelancer who works for the local ISP in his community
and is responsible for half the local businesses websites. The single
webdesigner/programmer who works for the 200-person company. An awful lot
of content in the world is written by these types of people, and unlike the
major portals or the government sites, they don't have a global audience,
so accessibility isn't going to be something they are going to feel any
real pressure to conform to. 

Basically, the point of my statements here are:

An abstract, normative document, that explains what accessibility on the
web means, is important. However, it is important mostly as a backdrop for
which the actual usable documents we create will conform to.

The average web designer, when told that his code is not valid and is
pointed to the W3C validator and given some guidance, will gladly write
valid code from then on... it makes sense, and is relatively easy. We need
to provide the same thing for accessibility, if we want it to be bought
into. And that means a usable checklist that can be read and understood. If
we wait until the tools themselves do it all for you... well, let's just
say I'm not very optimistic on the time frame.

Having a three-tiered method, then, is admirable, and I think all three
portions are very important. But the third tier, the actual 'How Do I Do
This?' document is something that we need to have for the content
developers. Content developers DO go to the specs. The HTML and CSS specs
tend to be arcane to the user, but if you need to know how to do something,
that's one of the best places to find it... I'd like to see the WCAG
documents be something that we can use as soon as they are complete, and to
that end a checklist is what the web content developer needs. 

Marshall.


--
Marshall Jansen  //  marshall@hwg.org
Senior Web Developer
VP of Marketing and Outreach
HTML Writers Guild, Inc.  //  <http://www.hwg.org/>www.hwg.org

Received on Tuesday, 15 August 2000 09:12:07 UTC