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.
CMN: 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.
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.
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.
CMN: 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
Thursday, May 3rd, 2001. @ the usual time.
$Katie Haritos-Shea 05-04-2001$