E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 1 (In chronological order)

From: Jukka Korpela
Date: Thu, Aug 08 2002 11:17PM
Subject: RE: Breaking W3C WAI Guideline Checkpoints into a task list
No previous message | No next message

MacKay, Graham (JUS) wrote:

> Hi, I've been tasked at work with the project of breaking down the WAI
> guideline checkpoints into a sort of "step-by-step" task
> list/to-do list.

Quite a challenge, I would say, both positively (it's an important thing)
and negatively (it surely isn't easy).

> This information would then be used for other web developers
> within our department as a basis for an action plan with which to
> implement the W3C accessibility initiatives.

The checklist that Tim Luoma mentioned will surely be useful in creating
such a basis, and for designing criteria for success, but I guess you need
basically something else. Instead of individual guidelines or checkpoints
you need something to base a strategy on.

> These tasks will have to be somewhat vague (enough so that it
> can apply to a number of different types of sites) but provide several
> practical strategies for actually implementing each checkpoint.

I would pose the question as actually making the site accessible, rather
than implementing checkpoints. There is a definite danger of seeing the
tools as more important the goal here. Moreover, there's a danger of
overemphasizing that part of the guidelines that can be described
operationally and measured objectively. For example, saying things as simply
as possible has great impact on accessibility, for a huge number of people,
but it is far less measurable and checkable than, say, the question whether
all your <table> elements have summary attributes.

> I am wondering if anyone else has done this before?

I think - and I hope - that many of us have tried to do something in that
direction. What I have done is in Finnish, so it's probably rather
inaccessible to you. Others have probably sketched ideas on this, typically
in their native languages, and typically for specific sites or
organizations. But maybe we can find something we can share, and try to find
some common principles.

Here are some notes on creating a strategy for a move towards accessibility
within an organization:
- estimate the value of accessibility for the organization; the value varies
from one organization to another, and analyzing this will help you find ways
to motivate people (at all levels); for example, are there some particular
groups of people or modes of uses that are important to the organization and
would especially benefit from accessibility?
- estimate how bad the situation is now, considering both the current state
of the site and the tools used, people's attitudes and skills, and
restrictions implied by server technology etc.
- estimate how much you can realistically expect; at this point, you might
even try to decide whether to aim at A, AA, or AAA, within a specific
timescale, though that accessibility classification is probably less useful
than many people think
- evaluate how prepared the management is to require and support work on
accessibility, and consider what might be needed to improve this
- find a plan to improve the motivation and skills of the people who
actually create and maintain site structures and pages, covering _all_
people involved (though often with very varying requirements); many of them
might need a crash course that _motivates_ them, and some of them might need
a good course in creating Web pages in a reasonable way
- design how to make accessibility considerations part of the routines of
creating content and putting it onto the Web; you might run an accessibility
campaign (quite possibly you _should_) but the real question is what authors
do routinely, when in hurry and with various requirements pulling them into
different directions (as they/we usually are)
- try and find some ways to involve users, such as people with a disability
and with a great need to make use of your site; there's a risk of
overemphasizing some special needs (and software etc.), especially since you
can't realistically expect to get help from a wide range of users, but the
risk is worth taking.

Only after such considerations, I think, should we consider more technical
issues, like "where do we actually start?". You might need to start with
changing the authoring software and re-educating all people who write pages;
or with doing quick fixes that help an important part of the users
immediately; or (e.g. if the pages change very often anyway) leaving the
current pages as they are and setting up local rules for new pages, with
accessibility built in into the rules.

--
Jukka Korpela, senior adviser
TIEKE Finnish Information Society Development Centre
http://www.tieke.fi
Phone: +358 9 4763 0397 Fax: +358 9 4763 0399


----
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/