20 Feb 2003 - WCAG WG Teleconference Minutes


Roberto Scano, Ian Jacobs, Gregg Vanderheiden, Ben Caldwell, Wendy Chisholm, Loretta Guarino Reid, Kerstin Goldsmith, Ken Kipnes, John Slatin, Michael Cooper, Bengt Farre, Avi Arditti, CynthiaShelly, Gian Sampson-Wild


Doyle Burnett, Lee Roberts, Roberto Ellero, Eric Velleman


Ian Jacobs summarized:

  1. How did UAAG 1.0 solve the problem of conformance flexibility?

    A very simplified answer is by modularizing the document and dividing the requirements along several axes. Developers can claim conformance using these different axes.

  2. How did UAAG 1.0 solve the problem of subjective requirements?

    By dividing general requirements into smaller, more precise requirements.

There were several questions about how much leeway developers were given and how easy it is for a developer to ignore major parts of the specification.

One of the axes that people found most interesting is "applicability." Ian explained that there are cases where UAAG requirements don't apply. Thus, a developer can say "we think the following checkpoints don't apply..." To diminish abuse, we narrowed it down to 3 scenarios where someone could use the applicability label. e.g., no tables in svg, thus svg viewer could claim those checkpoints are not applicable. There was interest in seeing how this might apply to WCAG but it wasn't clear how to apply it without inadvertently dividing some of the checkpoints by disability or ensuring that the clause couldn't be abused. There was also concern about making conformance too complex.

We raised lots of questions about scope of claims and discussed the benefits of machine-readable claims.

The discussion questions for this call were:

While we didn't resolve these completely, here is some headway:

UAAG Conformance summary by Ian Jacobs

WCAG 1.0 has 3 levels of conformance. 3 level was not sufficient for UAAG. We made it modular and have 5 axes. e.g., Checkpoints related to speech synthesis are grouped and have a label. To claim conformance to that group, use that label in the conformance claim. Wanted to allow conformance even if the person didn't do every checkpoint. We still have A, AA, and AAA, but also content type labels that correspond to output types: VisualText, Image, Animation, Video, Audio, Speech. For example, Lynx could claim conformance even tho it doesn't render Image, Video and Audio.

Also have another axis (and thus another label) for: events, selection, and input modality. Also, have a label for applicability: there are cases where uaag requirements don't apply. thus, a developer can say "we think the following checkpoints don't apply..." To diminish abuse, we narrowed it down to 3 scenarios where someone could use the applicability label. e.g., no tables in svg, thus svg viewer could claim those checkpoints are not applicable.

Another benefit of labels is that they are easily referencable from another spec.

Question: clarify "operable from keyboard"

There are optional ways to conform. for uaag 1.0, the target User Agent has a keyboard and that guided the development of requirements. A developer can get extra credit if they do extra things. They get that credit by including additional label in conformance claim. It still constitutes conformance, but not baseline conformance.These are all subsets of requirements.

Compared to wcag 1.0 - where there were only 3 subsets - in uaag 1.0 there are several. The cost of flexibility is complexity but the verbosity allows people to easily compare claims.

Some approaches to conformance that the UAWG rejected:

Question: How many user agents conform to UAAG 1.0?

As part of Candidate Recommendation, we created an implementation report. We needed 2 implementations of each feature. We assume modularity. For example, don't assume opera will implement speech synth requirements (assume reliance on a tool that does speech synthesis). We haven't listed the profiles for each, but we had 2 or more complete implementations of 95% of the checkpoints (when went to PR). We continue to do evaluations.

Our first time to CR, reviewers felt the requirements were too vague. We went back to WD for another year. In most cases, we transformed broad requirements into more specific requirements. With regard to subjective tests, we were able to make progress by dividing and conquering. Some are harder to verify than others. Precision is different than verification

With regards to WCAG checkpoint 4.1 (a fairly subjective checkpoint), in UAAG we would use the applicability piece of UAAG conformance. For example, if the content is poetry, then 4.1 doesn't apply. It could be based on the type of content.

The WCAG WG shouldn't predetermine what types of content 4.1 doesn't apply to, but allow people to decide whether it's ok for that person to claim inapplicability. However, have to be careful of creating loopholes.

Question: Are you suggesting that we say, "you can conform to whichever checkpoints you want to as long as you give reasons for why you didn't?"

No. That is the "anarchy" strategy that we did not follow. You should not allow to choose "any" checkpoint, but be very selective. If there is a group of checkpoints related to use of text, create a label for that. .As long as you announce what and why.

Question: How announce what and why in a meaningful way?

Question: How differ from level 1 and level 2?

You can currently op-out of level 2. It's a different slice. WCAG 2.0 has 2 axes: difficulty for user, difficulty for the author. Currently, these are combined. Perhaps they should be separated into 2 axes. UAAG has more than two axes....

Summary: A couple things to learn from UAAG 1.0 for conformance in WCAG 2.0:

Ian emphasizes: The applicability provision is independent of the precision of the requirement.

Some complexity coming from oversimplification. Fear unnecessary complexity, however an appropriate level helps the audience.

Might be easier to be clear if we allow more complexity. In the past we have said "if do x, do y" if don't do x then automatically conform. The idea of exceptions is in there.

Question: Can we have applicability related to content? Looking through existing checkpoints, not sure how this would work.

We'd have to find classes of content. e.g., poetry - writing styles, 3rd party content, audience (writing styles for grad students)...

Perhaps we don't need to define the classes. Might suffice to just say "Ok to claim that these 3 checkpoints (a/b/c) don't apply for your particular domain of content."

It depends on how introduced - "not intended to be applied to poetry..."

Issue: easy to slide from categorizing content to categorizing audiences. We don't want to do that.

It comes down to reasonableness. It leaves rooms for interpretation. One way to think about this is binary: "Is this general purpose content [to be defined]? If not, then you can claim that these 3 checkpoints don't apply."

At least some of our success criteria can contribute to profiles, something to explore.

Some background on UAAG 1.0 profiles from WCAG 2.0

action: wac draft example user agent profile (for html techniques)

proposal: premise - there might be things that are critical for some users in a general context, but reasonable for exemptions in some contexts.


difference between "don't have to conform" vs "automatically conform"

scope of claims

brainstorming, collecting questions

Responses ala the UAAG context

machine readable?

scenario: professional content developer will have the data. give them a mechanism for users to search against is a cool thing. shouldn't be required, however.

$Date: 2003/02/26 02:07:54 $ Wendy Chisholm