RE: Introduction

PB: I think this is a concept worth exploring too. My concern with any
conditional statements, including my "Technology Type Specificity" and
"Disability Type Specificity" are that they add another layer of complexity
that has the potential of rendering the guidelines less usable. The more
difficult it is to understand or comply with the guidelines, the more
backlash we can expect, and the more difficult it is to convince anyone to
use them. I do agree that these conditional statements make the guidelines
more accurate. I always advocate for accuracy, but there is a point at which
simplicity needs to take preference over specificity. At some point we'll
have to draw that line.

CS:  We've been talking, on and off, about creating a database of
checkpoints and/or techniques so that an author could filter on the pieces
s/he cares about.  So, you'd be able to get a list of checkpoints and
techniques that are relevant if you're building a site in HTML with
JavaScript targeted at persons with ADD (for example).  IMHO, if we do this,
the guidelines will become more usable and easier to understand, because a
person trying to comply with them will only have to look the relevant
pieces.

-----Original Message-----
From: Paul Bohman [mailto:paulb@cpd2.usu.edu]
Sent: Friday, May 11, 2001 4:39 PM
To: w3c-wai-gl@w3.org
Subject: Re: Introduction


This is a summary of the conversation between Paul Bohman and Adam Victor
Reed that was held off-line:

PB: My introduction (to WCAG 2.0) can be accessed at
http://www.webaim.org/wcag/intro.

AVR: You may want to fix the following. Please let me know if you disagree -
1.2: "cognitive impairments" is too narrow. I suggest "processing
impairments", so that attention deficits are included.

PB: I understand what you're saying, but I wonder if there isn't a more
understandable way of saying it. "Mental processing impairment" maybe?
"Cognitive processing impairments"? And, to my way of thinking, although I'm
sure others would disagree, attention deficits can be included under the
term "cognitive", even without the word "processing." The act of processing
information is a cognitive act, isn't it? Even if the word "cognitive" seems
slanted away from attention deficits, I think that the word "processing"
slants too far towards it and away from other types.

AVR: The use of the same word - in this case "cognitive" - for both a
category and a sub-category within it - inevitably confuses the reader into
conflating the category with the sub-category. I don't insist on
"processing", but in practice, when content-makers are asked to address
"cognitve impairments", they almost always do it in ways that actually make
their content _less_ accessible to people with attention deficits.

PB: I'm not opposed to coming up with a better title for this category. I'm
just not sure what that would be.

AVR: After the third sentence in the paragraph below the list, add:
"Processing impairments include limitations in learning, cognition and
attention".

PB: I think a sentence such as this would be a good idea. In fact, it would
be a good idea to add a few more examples under each category.

AVR: Also, including only sensory deficits among examples of visual
disabilities may be misleading - I would add limitations in visual
perception and object agnosias.

PB: I would tend to place visual perception and object agnosias in the
cognitive/processing/mental category. Agnosias are usually the result of
brain damage which doesn't necessarily affect sight capabilities. What is
affected is the ability to process information that is precieved through
sight.

AVR: The effect, though, is that people with impairment of visual perception
and visual agnosias can't use pictorial presentation of content. In
addressing content accessibility it may make sense to group them with
"visual impairments".

PB: You may have a point there. Does anyone else have a comment on this one?

AVR: 1.4: I would like to volunteer to add techniques documents for
"attention deficits" and "impairments of visual perception".

PB: I think that would be great. The list of disabilities/conditions is
really almost infinite, but I think that documents for those disability
types would be appropriate.

AVR: 1.5: I would add the following after "Disability Type Specificity":
 Contextual Compliance
 Sites serving specific groups of individually identified users must meet
detailed compliance criteria, as enumerated in the Optimization Techniques
Documents, to assure accessibility for every identified user. For example,
the web site of a university seminar must be accessible to all participants
in the seminar.

PB: I think this is a concept worth exploring too. My concern with any
conditional statements, including my "Technology Type Specificity" and
"Disability Type Specificity" are that they add another layer of complexity
that has the potential of rendering the guidelines less usable. The more
difficult it is to understand or comply with the guidelines, the more
backlash we can expect, and the more difficult it is to convince anyone to
use them. I do agree that these conditional statements make the guidelines
more accurate. I always advocate for accuracy, but there is a point at which
simplicity needs to take preference over specificity. At some point we'll
have to draw that line.

Paul Bohman
Technology Coordinator
WebAIM: Web Accessibility in Mind (www.webaim.org)
Center for Persons with Disabilities (www.cpd.usu.edu)
Utah State University (www.usu.edu)

Received on Thursday, 17 May 2001 17:11:08 UTC