05 Jun 2003 - WCAG WG Teleconference Minutes

Present

Dave MacDonald, Roberto Scano, Wendy Chisholm, Jason White, Matt May, Loretta Guarino Reid, Gregg Venderheiden, Ben Caldwell, Lee Roberts, Bengt Farre, Jibari Simmons, Cynthia Shelly, Michael Cooper, Avi Arditti, Andi Snow-Weaver

Regrets

Ted Pibil, Doyle Burnett, John Slatin, Gian Sampson Wild

Action Items

ACTION: wendy capture issues related to conformance and draft note for review.
ACTION: gv, bc, wac write reviewer's note related to 1.2 and 2.3, summarize issues
ACTION: bc, wac, gv edit draft and publish new asap
ACTION: ben and andi compare andi's and ben's checkpoint mappings

conformance section of next draft

Draft conformance section - Wendy Chisholm 4 June 2003

Issues:

doesn't say anything about Best Practices. Since they aren't testable, they should not be part of conformance claim.
lots of discussion about core+. some people feel that it is not well defined and not necessary. others feel that it is a good carrot to give developers to encourage them to do more than core.
discussion about core+n. some feel that it gives developers a shorthand for saying how much more they have done and that the larger the number they can claim the more they are likely to do. however, others feel that "n" can not be compared since it says nothing about which checkpoints are satisfied. it also doesn't say n out of how many.
concern that if we have core+ that different countries or organizations might pick different checkpoints from the extended set and that it will increase fragmentation and make it harder for tool developers to determine which checkpoints to support in their tools.
some folks feel that if we allow someone to claim core+ that the claim must state exactly what that means (i.e., which checkpoints beyond core are satisfied). some people feel this must be in metadata, others feel that it could be expressed in a number of ways. other people don't seem to feel it should be required and that a plus is enough. there is concern that for legal reasons some sites can not use metadata.
depending on what we decide about conformance, we will need to discuss what the logos look like, will we have one for core and a separate for core+? what should the logo link to - a policy statement about what checkpoints are satisfied or metadata about which checkpoints are satisfied or an accessibility policy statement or ??
what are people likely to do if we do or do not give them incentive to go beyond core? here are some thoughts:
- if we don't have core+, people will stop at core
- if we do have core+, people will stop at core
- people will pick the easiest from extended and claim core+
concerns that if we require metadata that people won't keep it up to date.
what if we weighted the checkpoints and +n was some tally of the weights of the checkpoints that the content satisfies?
we currently have a consensus statement in our requirements document that incremental conformance claims should be possible. during this call there seemed to be disagreement about this statement, although most of the discussion was about "how" to make an incremental claim rather than "should we allow it.

thus the primary axes of discussion:

do we allow incremental reporting?
if so, how do we do it? core+ is one suggestion.
how do people state which items they have done beyond core? in metadata? in a site accessibility statement? some other method?
how do people state how many items beyond core that they meet? in metadata? with core+n (n=number of checkpoints from extended that they meet)? in a site accessibility statement? some other method?
if you can claim core+ are you required to state which checkpoints from extended that you meet?
is there a logo each for core, core+, and extended?
what does the logo point to?

Does checkpoint 1.2 belong in core or extended?

Checkpoint 1.2 Synchronized media equivalents are provided for time-dependent presentations

reason for ?? on this one, people were concerned that all of the current success criteria are core and that perhaps some should either be best practice or move to extended in some way. The concern is about trying to apply the success criteria to every web cam, newscast, and home broadcast.

Some proposals to solve this:

scope of conformance claim (i.e., all pages meet core except pages x, y, z)
exceptions for certain types of content (e.g., home movie) or sites (e.g., personal web site)
already a checkpoint about text equivalents in core (1.1). the text of the media be provided under that checkpoint, 1.2 says to synchronize. perhaps synchronize is extended but text equiv is core.

Arguments made against proposals:

if 1.2 is extended because 1.1 is core, people will accuse us of being "text-centric"
if set exceptions such as "this is important for government and public sites" that sounds a lot like policy and we are not here to set policy.
scope of conformance claim is a whole other issue that needs discussing. variety of problems and issues.

Resolved: for this draft we will mark as core but include a reviewer's note that says something like, "WG is discussing where this should be required and where it should be considered best practice." and summarize why we have questions.

Does checkpoint 2.3 belong in core or extended?

Checkpoint 2.3 User can avoid experiencing screen flicker

Discussed a variety of ideas to make this testable:

could we spec that if flicker exceeds a level the developer includes metadata that says, "this content flickers at a rate of X." this would be testable (since metadata). it doesn't change the content but allows the user to know that this content might not be good for them. it allows their agent to do some negotiation (i.e., I can only handle content that flickers at rates above X, is this content safe for me? similar to i only want content at resolution y by z or i am using device ABC, etc.) cc/pp? it would require knowledgeable UAs.
instead of building into the UA, have the user choose to start flicker or not. if the user doesn't say it's ok to start flicker, it doesn't start.
what about testing for flicker? tool under development but not sure if it will be successful. if not and therefore no way to test, then move this checkpoint to extended. until then, make it core but with a reviewer's note.

Resolved: include a reviewer's note that says something like, "still working on how to test for flicker. considering uses of metadata to report flicker rate." explain relationship to UA. "this is currently in core under the assumption that we will be able to create a mechanism to test for flicker and to provide a metadata label of the flicker rate. If either of these does not hold we will move this checkpoint to extended.

Does checkpoint 3.2 belong in core or extended?

checkpoint 3.2 The definition of abbreviations and acronyms can be unambiguously determined

Issues:

is an "unabridged dictionary" an international concept?
It says "the" unabridged dictionary. which one?
it's too subjective to be core.
1.4 All characters and words in the content can be unambiguously decoded, mentions abbreviations but in core. Thus if 3.2 moves to Extended there won't be anything required at Core for abbreviations and acronyms.
the note in 1.4 should move to 3.2 (If a standard format for doing it can be achieved, we might require that linkages to glossaries for all abbreviations and acronyms that are created by the author or site be provided. We could also recommend that linkages to any abbreviations, acronyms, etc. used by the authors also be provided. We could also have a weaker recommendation for acronyms and abbreviations appearing on the site that linkages to glossaries explaining all abbreviations acronyms, etc. that appear in any documents on the site be provided.)

Unresolved. continue discussion at next week's telecon

Timeline

Next week (12 june): tie up loose ends so can publish WD draft to TR the following week.

$Date: 2003/06/07 00:33:27 $ Wendy Chisholm