W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 2001

Re: 4/26 WCAG meeting minutes

From: Matt May <mcmay@bestkungfu.com>
Date: Thu, 26 Apr 2001 17:18:38 -0700
Message-ID: <011a01c0ceaf$ab298ec0$6601a8c0@sttln1.wa.home.com>
To: <w3c-wai-gl@w3.org>
My apologies for missing the call. I was busy getting laid off. :) (No
worries, folks. I'm smiling.)

----- Original Message -----
> GV: My problem is that we started off with guidelines for accessibility,
and
> now we are getting deep into usability, and I think we have no business
there.
> And for each item we add, we need to realize we are weakening every other
> item. I will be leading a movement to try to elimate about a third of the
> guidelines. I feel we've lost focus on accessibility issues. Or we need to
> divide this into two parts, one section for accessibility and one section
> for web design, good advice, etc. Our definition of priority 1 is that
without
> the guideline, there are people who won't be able to use the content. If
> we don't make pages targeted for people with an IQ of 40, they won't be
> able to use them. If we don't make these guidelines priority 1 for these
> people, they'll be excluded. Anytime a website isn't dead simple, there
> will be some people who won't be able to use it, but we can't make all
> websites dead simple. We are adding more and more checkpoints addressing
> usability issues that are only accessibility issues for people with
> cognitive disability. I worry about how providing more than one path makes
> information more accessible. It makes it more usable.

I'm of the school that accessibility is in a huge overlapping circle with
usability. I've chatted with Steven Pemberton, who's working on creating a
usability interest group, and I really think that should end up at working
group level specifically so we can feed off one another.

Recently, I've been thinking in terms of "free on board," as someone who has
dealt with shipping might. (It's the statement that we the shipper are
responsible for the delivery to you the recipient up to a certain
agreed-upon point.) The trouble we've been having, I'll suggest, has been
related to where the responsibility of the content provider to convey the
meaning of the content ends. When we've been dealing with vision, that
responsibility ends at the screen, the accessibility tool that reads the
words, or the braille terminal that renders them. If those things work,
irrespective of the recipient, we consider this success. Likewise, SMIL and
captions with the hearing-impaired, and device-independent events with motor
impairments.

In the cognitive realm, we're crossing the technological barrier between
hardware and person, and there's trouble lying that way. To extend my
metaphor, shippers have requirements as to the form and packing of a
package, but they're done once the package is signed for. Similarly, we can
instruct content providers as to the clarity and format of the message, but
we can't ever assure ourselves that the message will be processed properly
by the recipient. Worse, we can't be assured that additional work over and
above "write clearly and simply" will reap any quantifiable benefit when
applied to all content. Food for thought.

> GV: "Jump over a link" stands out as having been stuffed in here because
> it needed a home.
> JW: It goes under techniques
> GV: It used to go under group items.
> JW: The HTML checkpoint solutions is where it would live

I've captured this for the document.

> ??: If you have a big document, you need a summary and some way to get the
> information other than just reading a page at a time. You should provide
> a table of contents or index or search function.
> CS: There is debate in the accessibility community about whether it is
> better to provide lots of navigation functions or one simple option that
> is easy to use.
> GV: You ought to be able to do a boolean search on a book. But you put
> that functionality under an Advanced button, not right up front.
> CS: It has to do with organizing information. But I can't find the
checkpoint.
> GV: There is one in WCAG1.0
> CS: What about the checkpoint about the logical structure of content.
Maybe
> that's where it should go.
> JW: Things should be marked in pieces accordingly. The User Agent should
> permit you to manipulate the chunks for navigation.
> CS: Guideline 2 says provide interaction to suit users needs and
preferences.
[...]
> JW: What about issue of how complex the content needs to be. The
checkpoint
>  appears to apply to everything.
> CS: It applies to site, not to a page.
> JW: if your site is 2 pages, does it apply?
> CS: I know about two rules of thumb used by real world web designers.
Nothing
> should be more than 3 clicks from your home page. And no group should have
> more than 10 items. It is usually impossible to satisfy both of these for
a
> complex site.
[...]
> JW: How do we define the complexity at which this checkpoint comes into
effect?
> CS: 10 pages or more? 5 pages or more? It will be hard to define a hard
rule.
> But I know it when I see it. This decision must be based on professional
> judgment.

I think this is an issue where we're going to have to trust people's
judgement, and give suggestions as to how that can be done. Every navigation
system has benefits and drawbacks, including those that involve several
systems at once. There are also technical limitations, particularly in
search mechanisms, that prevent a lot of sites from producing good, solid
results (including synonyms and "hot" matches) the way we'd like them to.

> GV: These are the nuances we don't want to lose. This is where we see the
> difference between cognition problems and vision problems. We can't deal
> with complete cognitive disability. It becomes a questino of how much of
> the bottom we are going to chop off.
> KHS: We need to decide that question.
> GV: There will be a lot of flack when we do, but we need to do it. We will
> exclude some people. I don't know where it starts or stops, though. If we
> say we will only worry about people at a certain level of cognitive
ability,
> we are doing the same things as the marketing people who say that are only
> targeting customers without disabilities.
> KHS: We don't have to throw out the baby with the bathwater.
> GV: Consider amazon.com. How will we make this site accessible to someone
> with IQ of 60?
> KH: We need to define minimal required cognitive level.

I think numbers are really poor indicators here. Grade level or IQ don't
tell the story, because cognitive ability has several other factors
including form, quantity, quality and retention of education, socioeconomic
and cultural factors, and so on. It's possible for someone with a 130 IQ to
be functionally illiterate; all it takes is poor education. And we can't say
that for all people with IQ x or grade-level y, this content is suitable for
understanding.

I think that, instead, we should be stating what cognitive limitations each
checkpoint benefits, and ensure that the solutions are in the hands of the
content providers themselves. Which leads me to...

> GV: I suggest that we split the guidelines into 2 categories. The first
> category is those things you must do to comply (at priorities 1,2,3) that
> are expected of all sites. Another category contains guidelines that you
> should apply to the extent that you can, and especially if you want to
> target sites for a particular population. This proposal gets us around
> two points. A site can be fully compliant, down to level 3, without
> worrying about this last category. But we don't abandon the cognitively
> disabled. And we can identify who will be most aided by the second class
> of items.

As a counterproposal, I offer my guideline proposal of a few weeks ago: make
it a requirement to become well-versed in the technologies and practices
required to make sites accessible to people with the range of disabilities
we cover. Produce documents as required reading that tell people simple
language and structure benefits the cognitively disabled, for example.

-
m
Received on Thursday, 26 April 2001 20:19:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:10 GMT