JW List in the agenda, are there additional proposals?
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.
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