New Guideline proposal was: Re: Some more thoughts re 3.3 etc.

(The proposal's down there. You'll have to read my diatribe first. :)

The issue we're having here is related to the desire of the WAI to produce a
guidelines document that prescribes normative, objective requirements that
can be verified as aiding people with disabilities in using the Web. This is
because the WAI education and outreach group pitches its standards to
governmental bodies and other organizations in order to get them to come
along and support accessibility worldwide, and those organizations want
standards to which they can authoritatively claim compliance. (A
complication has been in the realm of cognitive disabilities: as I
understand it, Section 508, which adopted a number of checkpoints from WCAG
1, did strip out everything relevant exclusively to those with cognitive
disabilities.)

I don't think any of us are saying "write clearly and simply" is not a
fundamental part of accessibility. The issue that is being raised is whether
or not we can craft a checkpoint which:
a: can be objectively verified as having been done; and
b: can be objectively shown as aiding all or the vast majority of those with
a given type of disability.

As important as this principle is to accessibility, I have to say that 3.3
can't satisfy either of the above statements. Language cannot objectively be
evaluated in the same way as the presence of ALT tags or device-independent
event handlers. What's more, content is rarely controlled by web developers,
who are the likely implementers of this document: indeed, in many cases,
it's not even controlled by the same organization. I'll add to that a lack
of tools (including the Flesch-Kincaid analyzer in Word) which can
quantifiably show that content designed for the Web, including things such
as microcontent and structure which differ between business documents and
Web pages, is more readable (which still doesn't necessarily guarantee it's
more _accessible_).

Okay. Proposal time.

Something I've proposed before has been a design practices document,
delineating rules we know are relevant to accessibility and need to be done,
but can't be declared in a normative fashion. I want to propose something
larger: a guideline which places certain levels of responsibility on
everyone involved in the process to become and remain informed about what
they should do to keep things accessible. The checkpoints under this
document would direct everyone with a role in making sites accessible to
read and understand what part they play. There would be one document for
"business owners" (those who control site development), one for content
authors, and one for technical support personnel. Organizations can claim
compliance with this guideline by making a policy of requiring role players
to read the support documents (W3C Notes) and adhere to their principles in
their ongoing development. The result is a guideline with normative
checkpoints, implementing ongoing commitment to accessibility among all
involved parties, communicating the principles everybody needs to understand
to effectively design accessible sites. That is, instead of handing them the
proverbial fish, we require them to go fishing for proverbs. :)

The guideline would look something like this:

Guideline X: Education: Learn how to write and maintain accessible content
X.1: Read the document on Web Content Accessibility for Executives
X.2: Read the document on Web Content Accessibility for Content Authors
X.3: Read the document on Web Content Accessibility for Web Designers and
Developers
(optional) X.4: Read the document on Web Content Accessibility for Testers
and Quality Assurance Personnel

A practical example of why there need to be documents for each role is
automobile documentation. You don't get a mechanic's manual when you're
browsing the showroom floor, and you don't keep one in your glove
compartment. When you're shopping for a car, you want to assess benefits and
risks, and when you own one, you need to know basic information about the
design and maintenance of the vehicle. In fact, you may never see a
mechanical manual at all. Similarly, 95% of all HTML authors have probably
never read the HTML spec. I think that it's important to communicate the
principles of WCAG through the eyes of everyone with a hand in the process.

-
m

----- Original Message -----
From: Jeff Isom
To: WCAG
Sent: Friday, March 30, 2001 6:56 AM
Subject: Re: Some more thoughts re 3.3 etc.


I'm new to the group so forgive me if some of my thoughts have already been
expressed.

I agree that it makes sense to design pages for tools rather than specific
disabilities. But this leads to the question of what are the tools.  It is
obvious that people with visual disabilities use screen readers or screen
magnifiers.  People with motor impairments use assistive keyboards or other
input devices.  It is easier to create guidelines and checkpoints for those
tools.  But what are the tools used by people with cognitive impairments.
In my mind, they have tools too, only their tools aren't hardware or
software solutions.  Instead their tools are the things that were debated
during the call yesterday.  They use the tools of redundant navigation
mechanisms (2.1) and clear and simple writing (3.3).  Without these tools,
the pages are not accessible to them.  So I don't see how those items can be
removed from the Guidelines.

Just my thoughts on the matter.

Jeff

-----------------------------------
Jeffrey Isom
Instructional Designer
Web Accessibility in Mind (http://www.webaim.org)
Center for Persons with Disabilities
Utah State University
Logan, Utah   84322-6800
(435) 797-7582

Received on Friday, 30 March 2001 14:16:12 UTC