15 March 2001 WCAG WG minutes

http://www.w3.org/WAI/GL/2001/03/15-minutes.html

15 March 2001 WCAG WG minutes

Summary of resolutions, actions, and open issues
·       Action MM, GV, WC draft "checkpoint solutions" for XHTML based on 
today's discussion of the framework.
·       Resolved: for next draft, call Guidelines, Checkpoints, and 
Checkpoint solutions at least until can discuss again.
·       Resolved: we will meet next week. Those who can make it will 
attend, those who attending CSUN send regrets. Open issues from today will 
be moved to next week's agenda. Also potentially continue server-side or 
ECMA/Javascript discussion from F2F.

Participants
·       Jason White
·       Cynthia Shelly
·       Matt May
·       Annuska Perkins
·       Wendy Chisholm
·       Charles McCathieNevile
·       Gregory Rosmaita
·       Dick Brown
·       Marti McCuller
·       Bruce Bailey
·       Gregg Vanderheiden
·       Loretta Guarino Reid
·       William Loughborough
·       Katie Haritos-Shea
Regrets
·       Kynn Bartlett
·       Len Kasday

Terminology
JW List in the agenda, are there additional proposals?
·       Guidelines / checkpoints / technology-specific checkpoints
·       Categories / guidelines / checkpoints
·       Guidelines / requirements / checkpoints
GV Also: Principles/Guidelines/Checkpoints
JW Right, used in earlier drafts, an objected.
CMN I objected to it. At that time it seemed like the priority label and 
conformance would move from checkpoints to what was to be called 
Guidelines. One thing to keep stable is what you tick off for conformance 
test - those are checkpoints.
GV I agree. That's the 3rd level right?
CMN That's changed. That looked like 2nd level.
GV Not the princple/guideline lagnague, but that checkpoints you check. 
Does everyone agree that what we check off is technology specifics.
/* some no some yes */
GV Does everyone agree that what we check off should be called "checkpoint"
/* no disagreement */
GV Therefore we have to agree what level we check things off at.
CS Didn't we resolve this at the F2F?
JW Yes, we resolved that technology-specific requirements would be 
normative. GV raised the issue that if/when technology-spefici parts are 
not adequate or if someone has an alternative means to meet the needs as 
described in 2nd level, then possible to implement that and satisfy it.
GV In the TAAC and EITAAC was that we required both a functional and a 
technology-specific level. The technology-specific level by itself was 
insufficient. Therefore checkpoints at levels 2 and 3. Needed at both 
levels since sometimes know performance want to achieve, but sometimes not 
only one way to achieve. Technology-specific may not be sufficient or 
necessary. You need to achieve the goal, not the specific. A suggestion: 
level 1 and level 2in a document, under technology-specific we list...
CMN In AU we have the same situation. We have WCAG 1 guidelines/checkpoints 
model. Checkpoints are requirement level. At techniques we say, "these are 
the set of necessary thing. perhaps not the only set."
CS Not talking about techniques.
CMN In the AU example, a requirement that you do X. This expressed in borad 
termas. In Techniques
GV Which is non-normative.
CMN Right. One way we think you'll satisfy is to do this set of things. If 
you do all this, we agree it is satisfied.
GV Fine, but if you come back to techniques level...right, that's how in 
WCAG 1.0...going back to what is normative is you don't have objective 
being something checked off, get into mess if bunch of ways to solve. May 
not want to write all the ways of doing it. One suggestion: carry the level 
2 down so that in technology specifics, have objective, then any 
technology-specific ... under have technology-specific which you must do on 
your way to meeting the general level 2 objective.
CMN By not having that 3rd level, we are able to say "this is sufficient 
way of satisfying" and then "here is another sufficient way."
GV Not suggesting 3rd level was not normative.
CMN Problem arise if have 2 methods.
CS We have "use alt-text" it is technology specific. It is required. It 
needs to be normative.
CMN No, not normative.
GV why?
CMN It's an example.
GV This is why in the guidelines we had level 2 and 3 being normative.
WL The word "normative" and concept "technology-specific" there is an idea 
that these are mutually exclusive.
CS If you are using HTML, you must use alt on image.
CMN wcag 1.0 checkpoint 1.1. to satisfy, write about image somewhere else 
on the page. it's not particularly helpful or friendly. go down checklist, 
at p2 level, implement w3c specs. for html, says put alt in. If you havne't 
done it the right way pass Level A, not Level AA.
GV Should have failed Level A. That does help people connect image and 
description.
MM how apply to link image?
CMN Don't meet first level requiremnt of replacing the function. We might 
be complicated our lives.
GV The interesting thing you raise is...sometimes we make laws based on 
what we've done in the past. it anchors us in form over function. if the 
goal is to have info in alternative form, but that they know they have it.
WC /* reads from draft of technology-specific checkpoints */
CMN Need to be more explicit about binding between requirments and 
technologies. If we try to take a document through Recommendation process 
and say we have semi-normative requirements, it will have to be clear how 
you conform.
CS The technology-specifics make it more clear. "what do you have to do?" 
is not clear in WCAG 1.0. Our spec is different from the HTML spec. 
Techniques are not normative.
GV Two key words: necessary and sufficient. Checkpoint. List underneath: 
ways to satisfy. If alternatives not checkpoints. If I have these listed, 
some may be necessary, then be checkpoints. A dn Bwill satisfy but are not 
sufficient. It's not clear what is not necessary vs. what is sufficient. 
Can list combination. e.g. to meet "fruit cocktail" I can pick A or B or C. 
A is banana or pear, B is banana or raspberry. etc.
JW That's the structure that CMN has been sugesting. That each statement at 
the technique or technology-specific level should make clear which are 
alternatives and which are sufficient and which are ncessary. in addition 
to 1.1 of 2.0 guidelines, in HTML requirements it would have a vlid 
attribute of an image element is one alternative. if object it must 
containt text content. each is conditional and each sufficient. in other 
cases may have more complicated situations in which case need to implement 
A, or B, and C or somethig. Open questions, should that level of 
specificity be normative.
CMN The first alarm is that we say "do this by providing an alt attribute." 
There are other valid ways of doing it. Some of them come about by 
fulfilling other checkpoints. In writing techniques, is more explanation of 
why it satisfies it. The more I talk with people the more I think we are 
not going to create an exhaustive list...
BB Do people like the escape clause in 508?
CMN "You have to provide the function:
GV Equivalent facilitation says, you don't have to follow guideline if you 
provide the function.
CS Right, but I am arguing that technology level is normative, is that some 
developers only look at normative documents.
GV Sufficient aspect - make usable without hearing, vision, etc. don't have 
the slightest idea.
CMN There will always be another way to meet the erquirement.
JW In next technology-specific draft it should be clear that under each 
requirement, which is sufficient.
GV I'll describe what I think I heard people describing. We have level 1 
and level 2 items, in one document. Then 2nd document, contains all levels. 
have "ifs" ifs not requirments. "if you have an image, then you must do one 
of the following." underneath have a, b, and c. each is a sufficient 
package in that technology to meet it. the last item is always "or 
equivalent." Techniques doc could document other alternatives over time. At 
bottom end of list, "and anything else needed to achive the objective." in 
some cases we will not be able to name a specific technique.
CMN I feel like I"m at the same place as GV. As much I spend my life 
saying, "the last driver of this is law" i am coming at this from a 
legalistic point of view. We create as much info as can. The first run is 
"here is how we would do it with some explanation as to why this meets the 
technique." It might be the combination of 3 steps. Some people can say, " 
I just want to do it like they recommend." then they can be done. over time 
with WCAG 1, we've had a lot of questions, "does this meet the requirement 
or not?" we've had to agonize over some of those. As a WG,. an important 
role that we fulfill, when someone needs "is this enough or not." we say 
yes or no with reasoning. Then we write that down so that people can 
reference that in the future.
GR Middle of road proposal, similar to GV's. Add something to conformance 
structure that says, "in order to claim conformance you must explain how 
provided functionality, in a public place." show that it works.
GV You mean whenever someone claims "or equivalent" they must document it 
publiclly?
GR Yes. Feedback to the group will help us.
JW As public as the web site is.
CMN Important function of WG to either say "yes that's valid" or to include 
in list of techniques for others to use.
WL Should call techniques.
GV Call them sufficiencies.
WL That flies in face of normative.
JW Implementation strategies.
WL Agreed that checkpoints can't be there.
MM Strategies sounds great.
CS All of these are non-normative terms. Developers will ask where the spec is?
GV When generating a standard, defining a particular way, e.g. RS232. If 
create RS232 here is how you create it, but you don't have to create. 
However, don't always need to use a serial connection, could do B or C. 
Trying to get people one of several ways.
CS That's why divided by technologies.
GV If you do it, do a certain way.
CS Why can't that be normative?
GV says must do one way.
CMN no, you can have options in normative.
GV The trend is to get people to do things the same way.
CS It's the rule. It's the norm. Level 2 at managers, Level 3 at 
developers. They have to know what to do.
MM YOu have to think of the developers as an extension of the tools. They 
are not who bought into it (those are managers) they were directed to do a 
task. They could care or not if this helps people. But they need a document 
that says, "here is what you do." That's where having a normative document 
makes it possible for those who are providing the effort.
GR Then need a per element info. That will be large.
MM When I mentioned "Design principles" where we say "read this" if you 
tell them "this is what you should do, must do, to retrofit, to etc." if 
you tell them "learn this" it's the same as saying "learn XHTML by reading 
the spec." a compliance tester will not be able to do these things. 
techniques and rationale important to have in head of developer.
CS I'm not arguing shouldn't have but have at a different layer.
GR Deal with each language separately.
MM Yes. Take the things that can be defined for a compliance checking tool 
- that's a desired goal.
GR A lot of work.
CS It's work that we need to do.
CMN Necessary but not sufficient. Harder piece: do you do something of this 
nature? e.g. when talking about image maps, diff between image map and 
image button. in mind of developer who asked teh question, there is a clear 
difference as to what they do. We need to describe that in functionality 
not pointy brackets.
CS There are two levels here: click on image to make something happen 
(level 2), different ways to type angle brackets to do x. can't say image 
map, they'll think map element. need code examples for all.
CMN Testing is key. "This is the test we'll apply to your page."
DB We have taken "techniques" that were "strategies for meeting 
checkpoints" and saying that are required.
CS no. this is the terminology problem. We are taking technology-specific 
checkpoints that we have factored out of existing checkpoints for specific 
technologies.Making some set normative. NOrmative in WCAG 1.0 but included 
at top level.
DB Things in examples, none of those were techniques? those were checkpoints?
CMN We're building a 4th level. It seems that we are not sure if we want 4 
levels or if we want 3 levels and how many levels should be normative 
requirements and which informative. Top level don't effect final outcome, 
except help understand lower levels. Seem to make levels 2 and 3 normative.
JW We have agreed for a while that we would have technology-specific 
requirements that would be formulated in teh way we've been suggesting. 
Does anyone disagree that these levels should contain in relation to each 
technology and layer 2 checkpoints a specific indication of what is 
sufficient and necessary. e.g. if you use x you should do a b or c. Other 
issues: what levels are normative and what do we call them?
GR We grappled with this in UAAG. The UA has to expose things that the 
author puts in. The current term is "required optional content." We're 
trying to explain what is required, e.g. in the case of IMG it is alt="" 
what is required is what goes in there. Have a paint by numbers.
DB I want to see this in a draft.
WL Me too.
JW concerns regarding GV's proposal?
CS My concern is that it mixes data aimed at manager and data aimed at 
developer into same document. should split. what we currenlty call 
checkpoints are aimed at manager, level below is developer.
GV Level 2 are checkpoints. under those have conditionals and under that 
checkpoint solutions.
WL Doesn't that make it a checkpoint?
JW checkpoint solutions or implementation strategy or whatever you choose 
to call it.
CS Want to see conditionals and other below in a separate doc.
GR That could evolve.
JW Must be possible that some other means of meeting checkpoint must be 
availablve.
Action MM, GV, WC draft "checkpoint solutions" for XHTML based on today's 
framework.
Resolved: for next draft, call Guidelines, Checkpoints, and Checkpoint 
solutions at least until can discuss again.

Next week's meeting
Resolved: we will meet next week. Those who can make it will attend, those 
who attending CSUN send regrets. Open issues from today will be moved to 
next week's agenda. Also potentially continue server-side or 
ECMA/Javascript discussion from F2F.

$Date: 2001/03/15 22:45:32 $ Wendy Chisholm

--
wendy a chisholm
world wide web consortium
web accessibility initiative
madison, wi usa
tel: +1 608 663 6346
/--

Received on Thursday, 15 March 2001 17:47:13 UTC