25 April 2002 WCAG WG Minutes

Present

Regrets

Requirements document: N1 - delete?

N1 - Technology-specific checkpoints should be normative.

JW This was written before success criteria. Some people wanted technology specific statements to be normative. If so, then all techniques documents would have to go through complete W3C process, this would slow progress in general, specifically to make updates to those documents. Last week we touched on non-W3C technologies issue.

GV This does not talk about techniques documents but technology-specific checkpoints. Non-W3C techs issue is a good point. Those for non-W3C techs could be developed outside of W3C space with pointers to them. If not a WG doc, then less control over what we have in them. If a new technology comes out and they write a tech document, then an issue. If we don't have technology-specific checkpoints it doesn't make sense. If we do, then by nature the term "checkpoint" sounds normative.

WAC We showed an HTML Checklist at the F2F in March. The techniques dtd has "rules" that point back to a WCAG 2.0 checkpoint or even success criteria, whatever makes sense. I feel that these could be informative but are an important "view" of the HTML Techniques document. However, the basic quesiton is - can we delete the above statement?

JW Yes and discuss the rest of the issue later. WAC and I did an analysis of this last year. We found a nice separation and that technology specifics do not need to be normative. Can we remove this item and revisit it later?

GV I believe there is consensus that the item can be removed since it doesn't necessarily apply to the current structure.

Resolved: We will remove the N1 statement for now and discuss more later. In its place say "Removed due to circumstances" (or however the others are worded)

GV Instead of checklist, a list of techniques. Clearly say if they are required or extra.

Requirements document: N9 clarification

N-9 Our normative portions would (as qualified) apply to sites in general. Our informative portions can give information that may apply to sites in general or to special targeted sites as long as they are clearly labeled.

propose it should read:

N9 - Normative items (as qualified) apply to sites in general. Informative items give supplemental information that may apply to sites in general or to special, targeted sites. Normative and informative items are clearly labeled as such.

JS What does "as qualified" mean?

JW Try to put the qualifications in the success criteria and checkpoint so that it is clear when to apply it.

GV There is a difference between the two, "informative may apply to sites in general." when putting things in that are not in general use. In the rewording, it says no promise to cite special targeted sites. No way for reader to tell when switch between things.

JW Non-normative does not apply to all sites is noted.

GV Anything that you don't inend people to do on all sites should be noted. The concern is that there are things that you can do to a site but don't apply to all, don't want to not list (you do want to list so that people can be aware of). However, if they show up and it's not clear they are "above and beyond" people will baulk at things that might seem impossible. In general, this is what to do on all sites. If info for special sites, that would be clearly labelled.

GV qualified - if you have such and such on your site, do this. not all normative items apply to all sites. Normative items are qualified (if you x, then you must do y).

JS Normative portions of these apply to all...except where...

WAC Normative items...

GV Our may apply to special targetted sites as long as they are clearly labelled.

Resolved: N9 - Normative portions apply to sites in general. Most informative portions also apply to sites in general. However, some informative portions may apply only to specially targetted sites and those informative portions will be clearly labelled in the guidelines.

Requirements document: C7 clarification

C7 - The success criteria (for a checkpoint) must be sufficient. (i.e. if you do them you comply. You would not have to do anything not in the list of success criteria.)

propose it should read

C7 - The success criteria for a checkpoint must be sufficient; following the success criteria should be all that is needed to claim conformance to the checkpoint. An author should not be required to do anything beyond what is required in the success criteria.

GV Good up until the last sentence, since there might be other requirements.

JS Agree get rid of last sentence.

GV But the old one meant to say...sufficient...to do what? It used to mean sufficient to achieve the goal. In the 2nd to claim conformance. Perhaps the 2nd is not as nice, but more accurate. Probably always more that you can do.

JW Because we non-normative advice which is not part of the success criteria, it doesn't need to be done to conform but should be taken into account. Depending on what you are aiming for, you have done enough to claim conformance.

GV This was not a charge to people conforming but a charge to us. Do you actually solve the problem by following the success criteria. We need to make sure that we meet this criteria. They will do what it says and stop.

JS What I hear is that sufficient is good but we want an idea of completeness.

GV Sufficient usually means "enough." This says "we can't have a list of success criteria that don't guarantee success."

JS Success is accessibility not conformance.

Resolved: C7 - The success criteria for a checkpoint must be sufficient; following the success criteria should be all that is needed to claim conformance to the checkpoint.

GV I will agree to this, but I think we actually trying to express something else. This wording says the same thing as the original, but I don't think that's what we were aiming at originally.

JW If we want additional consensus statements, then those should be proposed in the next round of the requirements doc.

Abstract

Resolved: add the following Abstract to the Requirements document: This document lists the requirements for the Web Content Accessibility Guidelines 2.0 (WCAG 2.0). Appendix A lists a set of statements that the Web Content Accessibility Guidelines Working Group (WCAG WG) has agreed to while writing WCAG 2.0. These statements will help frame future decisions.

Introduction

Resolved: add the following as an introduction

Text of requirment 6

Resolved: change body of requirement 6

A number of other materials and tools reference WCAG 1.0, such as specifications, evaluation tools, authoring tools, and government and organizational policies. Therefore, WCAG 2.0 must not completely change the definition of accessible content but should clarify the guidelines so that they are easier to understand and apply across Web technologies.

Latest draft

GV We made lots of changes right before and since the F2F, we'd like to repost to the public. But we need to polish it up a bit. Lots of new pieces, like conformance. We have responsibility to the outside world to get this out.

PB I'm not sure if this is the most important issue - you list the 5 categories - it would be good to have them as the same part of speech. If you have "perceivable, operable" then you have "orientation and navigation." they are different parts of speech.

GV I spent a lot of time on that. Navigable but "orientable??"

PB We could reverse the other words: Perceivability, Operability, Understandability, Orientation, Navigability etc.

GV Comprehendable

JS Comprehensible

MM You could make them all nouns.

GV Better with "able" rather than "ility." In order to use, it has to be perceivable.

JW Change them all to adjectives.

PB If you can navigate, do you need orientation?

JS You can navigate, but not have any idea where you are. Interrelated. These are interdependent statements of the same phenomenon. These are shorthand ways of talking about those dimensions.

GV Navigable (including orientation)

PB It is better.

PB another issue: flicker changed the range.

GV Not sure where 55 came from. 50 is the refresh rate of all of Europe. U.S. when to 2. That's really slow. Our original was 4 and under, which was 3, now it is 2.

PB Just wondering where they came from.

GV 49 not trying to make all of Europe out of compliance.

PB Is 49 Hz perceivable?

JS I had to put refresh rate to 85 for a colleague.

MM I think a majority of real video are about 10-15 frames/second.

GV Not a problem unless every other frame is light/dark. It's not refresh it is flicker. We have the intent to explore if a tool can be created.

PB 4.3 - alternate approach - my initial reaction was that i like the alternate better than the primary.

GV In Israel screen readers can't read b/c vowels are not there.

JW A separate checkpoint under guideline 1.


$Date: 2002/04/26 04:29:06 $ Wendy Chisholm