20 Feb 2003 - WCAG WG Teleconference Minutes

Present

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

Regrets

Doyle Burnett, Lee Roberts, Roberto Ellero, Eric Velleman

Summary

Agenda and questions for this call.
User Agent Accessibility Guidelines 1.0 (UAAG 1.0) primary focus of discussion.

Ian Jacobs summarized:

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.
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:

What can we learn from UAAG 1.0 and the UAWG's experience?
How can WCAG 2.0 reference UAAG 1.0?
What user agent features does WCAG 2.0 assume are implemented?

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

We learned about the flexibility of UAAG 1.0 conformance claims and began to consider how we might make use of this flexibility in WCAG 2.0. Wendy took an action item to play with the UAAG conformance model to see how it might apply to WCAG.
We learned that to reference UAAG 1.0 we need to come up with a conformance profile based on the various axes and labels. Wendy took an action to work on this with Ian.
By creating a conformance profile and thinking about an example baseline, we will have a better sense of the assumptions we are making regarding support of user agent features. This has been discussed in the Techniques Task Force (ala [techs] messages to the mailing list and telecons on Wednesdays at 10 a.m. EST).

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:

"anarchy" - too hard for people to compare claims and no baseline. e.g., "absolute granularity".
DOM requirements relate to communication between browsers and ATs, some people didn't want to satisfy DOM requirements, so thought about class of conformance for interoperable vs non-interoperable. but major piece was comm. thus, have DOM requirement.
thought about other axes. (graphical, user interface, etc.)

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:

W.r.t. checkpoints 5.4 and 4.x, where we talk about baseline conformance, we can refer more specifically to a UAAG profile.
We've been talking about checkpoint 2.1 (keyboard input or a keyboard interface); that might be another place where we reference part of UAAG 1.0.
Applicability could help us get around some of our sticky issues, but it does make things more complex.
We have 3 axes already combined into one: important (that we already have), testable, applicability. Some things are important, but put at level 2 since not applicable (or sometimes not feasible).

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.

discussion:

to date wcag 2.0 puts those in level 2 and 3.
applicability emerged for UAAG because wanted it to be usable generically and could not predict all ways it would be used.
if 4.1 is the only checkpoint, then probably don't need.

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

scope of claims

brainstorming, collecting questions

are claims in machine-readable forms? (Claims could be done with EARL)
if not, how do you find and make sense of it?
where does the claim reside?
claim on home page and separate claims on other pages?
if do one thing more than level 1, can claim level 1+. do you have to say exactly what you've done?
if only do that one extra thing, and keep updating site, will you keep updating conformance claim?
how are people using claims? do people read them?
aside from a logo, how many sites will want to take the effort to create a conformance statement?

Responses ala the UAAG context

UAAG 1.0 distinguishes logo from claim metadata. You can't use a logo without an accompanying claim.
UAAG 1.0 claim requirements
uaag claims have to meet wcag? yes. to be a well-formed claim, at least one version must conform to wcag.

machine readable?

should not require machine-readable, but make it possible. benefit for discovery. require human-readable. easy to translate to machine-readable from human readable.
People don't read claims... only see the logo and - at least - check with machine-validators (like Bobby, etc.)
If the claims are machine readable it will be easier to compare different sites contents with some comparing tool.
machine-readable more important for wcag, for searching purposes.
who bother to do? many large commercial sites. whether machine-readable or similar to privacy policy, there are users who would find its presence to be nice.
when will google support this type of filtering? [dunno, but lisa's would probably support the 1st day. i.e., if i teach at a school for children with cognitive disabilities, i could set up the computers to use a specialized search engine so that all content they get is appropriate.]
w3c member organizations could lean on search engines to get quick uptake
today, you can search google for pages that link to the WCAG logo.
If EARL includes the same URL and indexed and did google w/that, you would come up with a page that describes conformance in some way.

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