Minutes for 27 September 2001 telecon

September 2001 WCAG WG telecon minutes (agenda at end of message)

Present
·       Loretta - LGR
·       Wendy - WC
·       Chas  - CM
·       Jason - JW
·       Andi - ASW
·       Matt - MM
·       Gregg - GV
·       Jo - JM
·       Judy - JB

Regrets
  Charles - CMN


------------------

JW- Difficulty of implementation should NOT be taken into account in 
setting the requirements? Sounds like it's agreed upon. No objections.
WC- Was this documented as consensus at the F2F? Checking notes from F2F.
[Bridge drops most participants.]
WC- 20th sept. "consensus revised" message does not include anything 
about ease of implementation. Message from the 19th indicates that we 
did not have agreement.
JW- Is there anyone on the call who would maintain that ease of 
implementation should be a factor in determining priorities or 
requirements?
GV- Ease of implementation is a scale that goes from easy to 
impossible. It should have an effect, but how much of an effect I 
don't know. Maybe only at the extreme end.
CM- Ease of implementation changes daily. Guidelines will go out of 
date rapidly.
GV- Agreed. But not useful for us to create a set of guidelines that 
no one can follow. Gets back to how we structure conformance and 
priorities. Don't think we can ignore it.
CM- Agree that things that are currently impossible to do (or 
impossible in near future) should not be included in the guidelines. 
But that's not the same thing as moving things around in priority in 
terms of ease of use.
WC- Underlying issue: what are we putting the priorities on? When 
we're thinking about priorities, it's hard to say unless we're having 
priorities on tech-specific checkpoints.
CM- We can't provide success criteria and techniques for what's 
impossible. So things that aren't possible aren't going to be in the 
guidelines. Working within the things that we can provide techniques 
for, difficulty should not be used to state priority. Effect, rather.
GV- What about something that requires 6-8 times the effort of 
putting the page together in the first place? Can we say something 
like "In the final structure we would like to be able to separate 
importance for accessibility from ease of implementation in all 
locations." Ease of use should not be part of prioritization scheme. 
But the way these are used, it breaks that spirit.
CM- Let's look at this issue at the time we're deciding, on a 
case-by-case basis.
WC- If we start that exercise sooner rather than later it might 
answer these other issues.
CM- Needs to be an interative process, which will make us return to 
general discussion, and we'll go back and forth. We can't just deal 
with the general and then deal with the specific.
GV- Let's drop this item then. The way it's worded is the reason 
we're not reaching consensus on it.
WC- Are we going to have priorities on tech-specific checkpoints? 
that's the question. We agreed that they'd be normative, but not that 
they would be prioritized.
CM- Right. It may moot the whole discussion. But anyway, not worried 
that we'll overlook this issue when it comes to deciding the 
priorities.
JW- The possibility of implementation should be taken into account 
and ease of implementation is such a subjective matter that varies so 
much, that it's not a useful concept. We need to put together some 
alternative proposals for priority and conformance and discuss the 
relative merits.
GV- Do we have consensus that guidelines that are impossible should 
not be in the normative guidelines?
WC- We have lots on this. Agreed that we shouldn't include anything 
as normative that we can't provide techniques and examples and 
success criteria for.
GV- The phrase "that cannot be applied generally" - the concept of 
generally is missing.
JW- We generally confine its application appropriately in the 
technique. We should make sure that appropriate qualifications exist 
so that the techniques are applied only under the appropriate 
circumstances.
GV- So: if our techniques for an item are not applicably generally 
across all websites, then the checkpoint needs to be qualified to 
apply only where the techniques would work?
WC- This is almost like success criteria for tech-specific techniques?
GV- What if we just added the words "generally applicable" to the 
consensus item we already have. "Items for which we have generally 
applicable techniques"
WC- There's probably some consensus items that need to be specific to 
tech-specific items and techniques. Not too concerned about the 
wording. We agree that we won't force people to apply something that 
doesn't make sense.

JW- Let's move on. Next: access for absolutely all, or how to draw 
the line? Isn't this reflected in priority scheme? As you move on to 
lower-priority items in the guidelines, the group for which access is 
provided grows larger.
WC- It won't ever reach 100%.
JW- Right. Not possible in the sense of everyone being able to understand it.
WC- Where is that line?
GV- Part of it gets to success criteria. Describe the line there. If 
you can't describe the line, it gets us back to it's not normative.
JW- We had a statement that if we couldn't provide success criteria, 
then it's not normative. If you can't determine whether it's being 
applied sufficiently or not, then it can't be normative either.
GV- "Best Effort" can't work - "I comply because I tried and failed." 
Best effort fine for non-normative.
CM- I thought we were talking about OUR best effort. GV's example of 
someone who was blind and deaf and mentally disabled, with CP.
GV- Three things. 1. No, we don't know how to make it accessible to 
ALL. 2. How to draw the line? Accessible to as many people as we can 
create techniques and criteria. 3. We are going to expand our best 
effort to identify techniques, examples, and criteria that would 
cover the greatest range possible.
JW- Seems to capture the foregoing discussion. Any objections?
CM- I think what we are concerning ourselves with here is trying to 
remove barriers and allow each individual person (not groups) to be 
able to get the most out of the web according to his or her own 
abilities and interests. So when you look at this from the 
perspective of REMOVING BARRIERS it's easier than "we're going to 
make these people understand everything on the web." The fact that 
the theory of relativity is not explained simply enough for the 
severely retarded person to understand is not really relevant. Remove 
barriers that are preventing people from doing what they want to do.
JW- If we can think of techniques examples and success criteria then 
it goes in, and in doing so we'll try to cover as many needs as we 
can. Recognizing that in the realm of comprehension.
JM- And "comprehensible" (the goal) is not necessarily the same as 
"comprehended."
GV- One of the conundrums we have is not wanting to throw away all 
items that are good ideas because we can't necessarily apply them 
everywhere. In this idea of normative and informative portions, we 
don't want to throw away other good advice about things that could 
make things usable by different groups.
JW- Summary: Good ideas for which we don't have adequate success 
criteria and techniques canot be normative, or which are specific to 
particular sites, will be included in non-normative parts supplied 
among deliverables, and that the normative parts will be such as to 
apply across websites, so that they're not specific to targeted sites.
WC- Charles's proposal: accessibility, navigability, 
comprehensibility. One problem with specialized sites. 
Comprehensibility a module on its own.
GV- There will be things in navigability and accessibility that will 
also fall in the category that they will have to be informative. We 
may wind up with more of the cognitive/understanding items in the 
informative section, but wouldn't want to say that module 1 is 
normative, module 2 is informative. Wouldn't want to take 
understanding and make it a separate module that you could opt in or 
out of.
JW- Whether people understood that statement as intended to preclude 
that kind of conformance scheme. "It should not be possible to make 
conformance claims that are specific to a disability."
WC- Comprehensibility- would you modify your content to be 
accessible. Site-wide issues or smaller-size issue. Part of it is 
related to do you need to change your content to make it accessible. 
If you force someone to modify their content, they are balking there.
GV- Text description can be machine processed into simpler language. 
Comprehensiblity has gotten into the area of "writing things 
differently on the site".
WC- There are people who do need images.
JB- Where are you on the agenda now? It sounds as though some of the 
discussion is on modularization, in which case I have a comment, but 
what is the agenda topic.
JW- 10, which led to the question of whether modularization proposal 
should be implemented...for site that caters to specific needs.
GV- Were we together on normative will apply to sites in general, and 
informative can include information that might not apply to all sites?
WC- I don't think you can separate it that way. Provide people the 
clues to ask themselves whether something applies to their site or 
not.
GV- Should we have something in the normative section that isn't 
applied generally?
WC- Think about longdesc, which isn't applied to every single image.
CM- Why are we even worrying about 10? If I'm doing a simple site, 
half the guidelines won't apply? How is this different from 
specialized sites?
WC- Has to do with server-side generation of things. We do have 
client-side and server-side solutions.
CM- Actually 10 was different from server side. This one is talking 
about sites that are specifically made for children, or some other 
group.
LGR- Browser assumptions?
GV- No, this one came out of sites that are targeted for cog 
disabilities if you wanted to create a site for them. Are guidelines 
for people who want to create special sites or not?
CM- Now we've opened a huge can of worms with questions of audience. 
Potential for deliberate misinterpretation.
GV- Our normative portions would as qualified apply to sites in 
general. Our informative portions can have information that might not 
be applied to all sites, but that can help sites in general or 
targeted sites. That we would provide information on how to make 
things more usable for specific groups in the informative sections.
CM- Fine, as long as it's clearly labelled.
JW- This is the solution that more or less comes out of the other 
consensus items.


GV- 12. Usability vs. Accessibility. If you look at the continuum of 
disability, what makes something more usable for one person is going 
to make it accessible to another. There's no line.
CM- This is often just a cloak for a concern about normativeness. 
Most of the accessibility things are easily made normative because 
they deal with code, most of the usability ones aren't, so this is a 
cloak for saying we don't have a way of finding accessibility 
criteria for these.
MM- Yeah. Everyone has a line for what they consider accessibility 
and what they consider usability, but for the purposes of the 
guidelines, this is a moot issue.
GV- Accessibility and usability are continuums that vary...
JB- Is there a way to reframe that so that it ties it more closely to 
the task at hand of writing the guidelines. This sounds interesting 
but abstract enough that it doesn't see how it impacts the guidelines.
GV- We don't think they should be defined as different terms in the guidelines.
WC- If we say that there's a continuum, where do we draw the line. 
There's a lot of usability stuff we could include in the guidelines. 
Important to draw concrete distinction.
MM- When we get to the normativity discussion. That's where the line 
gets drawn between accessibility and usability. There's more science 
to accessibility. More measurability. Usability is still more of an 
art. Becoming more scientific but not at the same rate.
JB- Would anyone be interested to go back to consensus statement and 
trying to tie it closer to the guidelines?
JW- I don't find the distinction between accessibility and usability 
particularly helpful and would prefer to find other terms. Better to 
say what are the underlying issues here that need to be addressed, 
rather than what do these two terms mean and how to you distinguish 
those.
GV- Accessibility and usability are a continuum that varies...we 
don't see them as different.
ASW- I do have a problem with saying they're not different.
JM- Greg, do you mean we don't see them as "separable"?
ASW- I still have a problem with that.
CM- We're using usability in a way that is not what we mean when we 
say it. The issue here isn't usability, it's comprehensibility. The 
ability to GET the information (accessibility) and then the ability 
to USE the info when you get it (comprehensibility). Part of the 
problem is that we have a faulty definition of usability. Can't 
separate, because accessibility is PART of usability (you can't use a 
site if you can't access it), and we're narrowing usability down to 
include only those parts of usability that don't include 
accessibility. We want people to get to the material, and to 
understand it once they get there.
MM- Isn't just an issue of comprehensibility but interactability. 
Extract the data that you're looking for. Overlaps. Issues are more 
than comprehensibility. There are also different opinions as to 
whether accessibility is a sub-set of usability.
JW- Can we separate out the dimensions that we're talking about? 
Perception as opposed to ease of interaction and locating 
information. Helpful to have terms to discuss and distinguish those 
w/o talking about usability and accessibility given that those terms 
have not been defined. Better to avoid the contrast between them in 
favor of discussing more definable contrasts.
GV- If accessibility is a subset of usability, and the borderline of 
accessibility varies among people and tasks. Our guidelines will not 
have an accessibility section and a usability section, but a 
normative and informative.
CM- Part of the confusion is that we use "accessibility" in different 
ways--a specific and a general sense. In the general sense, 
accessibility and usability are indistinquishable. in the more 
specific sense, we'd be better off using more specific terms like 
"device indepencence." Give more specific names to things so that 
then we can talk about them. We haven't come to a consensus on what 
we mean by accessibility. I'd like to combine them. 
accessibility=usability
JW- I would like to see more specific terms used and avoidance of 
ac/us contrast as anyting that we'll rely on in developing our 
document.
CM- We haven't defined the terms.
GV- Accessibility and usability are intertwined and vary between 
person and task.
LGR- Why do we care whether there's a distinction or not. What are 
the problems we're going to try to address, and is there a limit 
beyond which we will not try to deal?
JB- Cognitive issues were cast as usability issues. Somewhat of an 
error. The usability thing hit your fan by route of the cognitive 
questions that came up.
JW- The question. If it's an item where it can't make a difference in 
someone's ability to interact with content. We need to make clear 
which items alone or in combination with others will make the 
difference between being able to work with the content and not being 
able to work with it.
JM- When we're talking about items that make a difference in 
someone's ability to interact with the content, we need to rely on 
evidence rather than opinions, philosophy, emotion, best guesses. 
Sometimes the term "usability" is used as a shorthand to talk about 
claims that are based on opinion rather than evidence about what 
actually constitutes barriers, and for whom.
MM- when I say "usability," in usability consulting, generally it's 
something where I think "I need to go test this."
JW- One way of addressing it would say we are going to avoid 
distinction bt usability/accessibility, and we are going to discuss 
these things in different terms. We will draw other more specific 
distinctions on whether something makes a difference in someone's 
ability to work with content.
GV- Will post the consensus item as currently worded.

>From: Jason White <jasonw@ariel.ucs.unimelb.edu.au>
>Date: Wed, 26 Sep 2001 10:53:25 +1000
>Subject: Agenda
>
>Thursday, 27 September at 20:00 UTC (4 PM US Eastern, 10 PM France, 6
>AM Eastern Australia) on the W3C/MIT Longfellow bridge:
>+1-617-252-1038:
>
>The purpose of the meeting is to consider and, if appropriate, confirm
>the consensus items which emerged from last week and the face to face
>meeting, and to discuss more of the "big issues" (listed below) which
>were not examined at last week's meeting.
>
>These issues are:
>
>6. Implementation
>(Should difficulty in implementation affect priority.)
>
>9. Access for absolutely all?    - If not, how to draw line
>(one suggestion was  "BEST EFFORT")
>
>10. Guidelines for all sites vs. special sites
>
>12. Accessibility vs. usability
>
>13. Conformance - why do it? How to test?
>
>14. Author and user needs conflict
>
>15. User and user needs conflict

--
Jo Miller
jo@bendingline.com

Received on Thursday, 27 September 2001 17:54:17 UTC