- From: Anne Pemberton <apembert@erols.com>
- Date: Thu, 26 Apr 2001 21:35:06 -0400
- To: w3c-wai-gl@w3.org
- Cc: kshea@apollo.fedworld.gov
A thought on separating normative guidelines from usability guidelines ... Will there be a normative guideline to call for an ALT tag, and a usability guideline to say that the alt tag should "describe the function of the graphic" ????? Anne At 03:33 PM 4/26/01 -0700, Loretta Guarino Reid wrote: > > >In attendance: >Loretta Guarino Reid >Andi Snow-Weaver >William Loughborough >Greg Vanderheiden >Cynthia Shelly >Jason White >Paul Bohman >Gregory Rosmaita >Katie Haritos-Shea >Charles McCathieNevile > >Action Item: >GV,JW: Divide guidelines based on Greg's proposal to divide normative >accessibility guidelines from recommended usability guidelines. > > >JW: Checkpoint 2.1 (provide more than one path or mechanism to find content) >is still listed as an open issue. How do we decide under what circumstances >it applies? >CS: Is there a doubt about it? >JW: It doesn't seem to apply universally. There is some content that isn't >so long or complex that it needs links, search mechanism, etc. Is there a >complexity threshhold for this? What else can we say about it? How can it >be stated so it is clear it doesn't apply to every page. >The second issue is whether the checkpoint can be defined more exactly. >GV: I'm uncomfortable with this. >JW: So am I, but probably for different reasons. >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. >JW: My problem is that this guideline looks, not technology specific, but >specific to a certain way that web content can be organized. The examples >seem strongly oriented towards the mixture of UI and info that you get with >contemporary HTML and don't know if this is what the web will be like >over the next several years. >CS: Are we being too specific with these examples? because over time these >solutions will change as technology changes >JW: These examples are things that characterize HTML very well but may not >charcterize other technologies very well. >CS: Some examples seem like they apply more generally. >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; it is also going >to become obsolete. >CS: But that is not a reason not to address it. It won't be become obsolete >for a while. >JW: But it still belongs under HTML techniques. >WA: What are we addressing with this guideline? >CS: This is mostly a cognitive issue, to make it easier for people to >get where they need to get as easily as possible. I understand what Greg is >saying about usability, but there is a lot of crossover. It is advantageous >to get some usability in. >WA: I'm not sure this gets us usability. I don't understand. >??: 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. >GV: This should be a priority 2, and it should permit the user to move >efficiently between different parts of document. Guideline 2.1 should be >"provide mechanism to permit user to move efficiently through the content". >JW: We are dealing with several issues: 1) the broader question of where >this guideline should go, and whether it falls into the class of >accessibility-related requirements, 2) what should the complexity threshhold >be for this requirement, and 3) is it sufficiently clear what it means? >The examples help clarify. >CS: This checkpoint is understandable, achievable, and measureable, more than >a lot of other checkpoints. This checkpoint doesn't seem particularly vague. >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. >GV: How to you group states with these rules of thumb? >CS: alphabetically? geographically? >GR: Most sites organize states geographically. >CS: or in a list, in alphabetical order. >JW: A long list >CS: in English >GV: If someone arranged the list of countries by continent, and even the >UN wil have trouble finding some countries. >CS: Almost no one with a real site achieves those rules of thumb. >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. >GR: In the User Agent guidelines, we had a similar issue with the time >on refreshes and pauses. If you choose any number, it will be arbitrary. >It becomes an area for scenarios rather than requirements. >CS: Help people to exercise professional judgement. >GR: On optional parts, you can only give guidance. >JW: I think we have a proposal that for this guideline, we help people develop >judgment by giving examples in the techniques documents. >CS: and links to usability documentation. There are web sites and books on >these topics. Providing info is useful >JW: Examples of application scenarios should be provided. "This applies >to complex content only". Example will help to develop reasonable judgement. >This solves the threshhold problem for the moment. I think of this as one >among a number of cehckpoints that individually may not make a difference >between accessibility and inaccessibility, but jointly they are likely to. >GR?: A comment on demarcation. The User Agent Guidelines has content types. >A checkpoint is marked with which content types it applies to. Don't divide >the checkpoints into 2 classes (object, subjective). Rather than grouping >checkpoints, label checkpoints. >GV: Flagged with attributes, not sorted into categories. This is important >since we already have 3 attributes. >CS: And there are person-to-person variations in ease to use. >JW: I find that anything that requires reading through lists of menu items >or links is useful initially but becomes a nuisance thereafter. I tend to >use search. >CM: This is a feature of graphical browsers, e.g., ICAD, Opera. >JW: What dimensions will we use for labels? A set that is supposed to make >it cognitively easier to work with content. >GV: I made an initial cut at labeling the guidelines as priority 1, 2, and 3. >A couple are hard to decide. I came up with 9 priority 1, 5 priority 2, and 7 >priority 3 of 21 items. >JW: Please send your categorization to the list. >GV: It will provoke interesting discussion. >GV: First we need to address when usability is accessibility. For people >on the edge, any usability problem pushes them over the edge. This means >that every single usability issue becomes an accessibility issue. But we >really can't go there. For example, for a ramp, 1 in 12 is defined to be >accessible, but there are lots of people who can't push up that levelof >include.. >GR: Braille labels on elevators can't be used by many (most) blind. And they >introduce cognitive problems, too - which button goes with which label? >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. >GV: Will we require Amazon to make an alternative web site for those below >that level? >WA: And a site with a target IQ of 75 is useless to someone with an IQ of 175. >JW: I agree with Greg that that's the problem. The techniques for cognitive >disabilities should be written out. But I'm not sure how to deal with them >in this document. Should they be prioritized specially? tagged someway? >GR: If there is an application of WCAG to site in a legal juridiction, if that >site is challenged for not meeting cognitive needs, the courts will defer to >whatever is on the statute books. >GV: My problem is that I want to develop a site for teachng thermodynamics. >I can't create a version for the cognitively disabled. >GR: There will be different threshholds applied for government entities, etc. >GV: A university course has prerequisites. These should also apply to the site. >GR: We need to collect these factors. >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. >JW: This could be useful. We could try to apply this to guidelines. >GV: This last section would not be normative. They would just be >recommendations that you do if you can. >WA: Will Greg divide the checkpoints into these two classes? >JW: I'll help >GV: We have to figure out how to provide guidelines that can be applied >to all websites. But we also don't want to remove everything that can't >be applied everywhere. e.g. the Sesame Street site shouldn't require the > same cognitive level as an MIT physics course. >JW: This is a better characterization than objective/subjective. Let's >take an action to look at that division, see what comes out, and discuss it >at a future meeting. >JW: Let's discuss the face-2-face in June. We need to work out the details in >the next week or so. Jason and Greg aren't available, except maybe by >telephone. >CM: I'd be happy to chair the meeting if Jason and Greg can join by telephone. >As ATAG chair, I would like the HTML techniques to make progress. >GR: I want to make sure there is critical mass, unlike the AU meeting in Boston >JW: Wendy said she would be able to run this, if we go ahead with it. >JW: Any problem with no co-chairs present? >GR: Too good an opportunity to pass up >KHS: Please review the PDF techniques spec. We need feedback on what >techniques go with which guidelines. >PB: I have a question about Greg's proposal: are we reducing the priorities to >just priority 1 and 2? >GV: No, we would still have 3 priorities. There would also be another >category of items that are usability guidelines that are recommended but >not normative. (Advice) >JW: When there is a question as too how much to do something, as opposed to >whether it was done or not, that guideline probably goes into the second >category > > > Anne Pemberton apembert@erols.com http://www.erols.com/stevepem http://www.geocities.com/apembert45
Received on Thursday, 26 April 2001 21:47:48 UTC