22 May 2003 - WCAG WG Teleconference Minutes

Present

Phone: Andi Snow-Weaver, Ben Caldwell, Greg Vanderheiden, Gian Sampson-Wild, Jason White, Avi Arditti, Loretta Guarino Reid, Bengt Farre, Jibari Simmons, Cynthia Shelly, Kerstin Goldsmith, David McDonald, Michael Cooper, Roberto Scano, Doyle Burnett, Matt Mirabela

IRC: Roberto Ellero, Michela Capelli

Regrets

Wendy Chisholm, Matt May, Lee Roberts, John Slatin

Summary

The current draft was reviewed to see if there was group consensus on whether each checkpoint belonged in Core or Extended.

Action Items

All: Read new draft when posted and raise issues related to whether checkpoints should be core or extended
All: Review Guideline 4 in the new draft and prepare to discuss it
CS: Develop a proposal for Guideline 4
JW: Post several alternative rewordings of checkpoint 1-C3 [1.3]; be sure to clarify that this checkpoint covers the use of CSS to control presentation

New Draft

The new draft isn't ready yet; Ben expects to post it tomorrow.
JW: What do we need to address first?
ASW: We need to come to agreement as a working group about what is in core and what is in extended
LGR: What about Guideline 4 (previously 5)?
BC: Consensus on the conformance section
JW: What about the issues on the open issues list? We need to determine which still carry over.
JW: Core vs Extended could be dealt with by reviewing the next draft and raising items which people think are mis-classified. We probably won't have time to review this in detail during our meetings.
CS: I wouldn't be surprised if we don't agree on all of them. We may have some where we note that there is not consensus.
JW: We'll add any that can't be resolved on the list to next week's agenda.

Guideline 4

CS: Where did we leave this?
JW: The last time it was discussed was at the F2F meeting. There was a proposal that most of Guideline 5 was unnecessary under the new structure. Of course the new structure has changed considerably since then.
CS: At the time, core was about interoperability requirements and extended was about direct accessibility and items that were not universal. I'm not sure that is true in the current reformulation.
BC: Most of Guideline 5 stayed in, but with nothing in the extended category.
CS: I thought we could delete Guideline 5 because we had sorted the checkpoints based on technology considerations that Guideline 5 was intended to address
JW: So the argument was if you fulfilled the remainder of the guidelines, Guideline 5 would be automatically satisfied. I had some problems with this argument at the time. I don't think it operates under the current reorganization.
CS: (reviewing her proposal, linked from the agenda): this was from before the F2F , so some of this is out of date.
CS: Greg combined 5.3 and 5.4
CS: We aren't ready to discuss this on a call. We need to go off and read this before we can discuss it.
Action item, all: read this section of the new draft and prepare for a discussion
CS: I'd like to hear about the criteria used for core vs extended in the new draft, since we need to think about this wrt Guideline 5
JW: Those definitions need to be in the draft
CS: So people who are reviewing the draft can argue about those, too
JW: They used to be in the conformance section.

Conformance

JW: The basic conformance was that minimal conformance involved implementation of all core checkpoints by implementing the minimum level success criteria. Extended conformance also included additional checkpoints and/or success criteria.
CS: Do we need to address conformance for this draft?
JW: Ben and I have been discussing including the parts of the conformance section that are uncontroversial, and then include editorial notes where there are outstanding issues that haven't been resolved. Is this a reasonable approach?
GV: Core criteria are things that can be done without prescribing how the information is presented in default mode, and that are applicable to "all" sites and contents. It doesn't have to do with importance, since there are some things that are very important but don't fit these criteria. Lisa's suggestion last week for the flicker checkpoint was an important addition, that you provide a way for users to avoid problems.
CS: In the F2F, we were also saying core was about interoperability with AT, and extended was about direct access and freedom of speech issues.
GV: Freedom of speech implies that you don't dictate the form. There is a high correlation between core and the need for some people to use assistive technology.
CS: Have you sent out a description?
GV: No, because we needed to get feedback from the group about how it wanted to define the criteria.
CS: So the best course would be to decide that now, then look at whether we agree about where things were put.
GV: Proposal for criteria for core checkpoints: 1) It doesn't prescribe the default presentation. (Note that it can still *affect* the default presentation.) 2) It applies to all types of sites and content.
GV: change to "default expression or presentation of the content."
CS: I'm not sure people are going to get that distinction.
GV: We can explain it, but I want to write something short.
ASW: I think it is a good way to proceed, but in the end, I'm not sure we'll end up with hard rules like this.
GV: Perhaps these are guiding principles rather than rules? It takes human judgment to apply them.
GV: Let's walk the checkpoints and see if we have consensus on whether they are core.

1-C1 [1.1] All non-text content that can be expressed in words has a text equivalent....
Consensus: core

1-C2  [1.2] Synchronized media equivalents...
CS: I'm not sure the technology is there yet.
GV: Is this a required vs best practice issue? Does this checkpoint violate the criteria that it applies to all sites and content?
Consensus: TBD

1-C3 [1.3]: All content and structure are separate...
GV: Change to "separate or separable from" instead of "available independently"
CS: I like that change; it is less ambiguous, too.
MC: Do we just need "separable from"?
JS: "all content and structure" implies that content and structure belong together?
GV: Both content and structure are separable from presentation?
JW: I don't like the use of content and structure. I'd like to find a way to reword this avoiding those two terms.
GV: What is it that you want separated from presentation? Structure isn't a problem, but content is problematic.
CS: "defined meaning"? "text"? neither is quite right
GV: Meaning is better. I was also thinking of semantics. But we don't have a word for what we are talking about...
BC: information?
DM: I'm going through the thesaurus...
GV: substance vs information? (information seems to prevail)
DM: My problem with information is that it is used so often in so many ways
JS: gist?
CS: let's just say it needs to be rewritten
Action: JW to put out a range of alternatives to the mailing list for how to phrase this checkpoint.
GV: Do we agree this is core? (yes)
Consensus: Core

1-C4 [1.6] All characters and words can be unambiguously decoded
CS: as long as it stay Unicode, this is core
JS: what about alt text?
GV: Alt text would clearly fulfill it,
GV: I'm trying to write what the user needs, rather than getting into what today's technology expects
ASW: Are we using content in the way we have defined it?
GV: Yes.
Consensus: Core

1-E1 [1.4] Structure has been made perceivable...
Consensus: extended

1-E2 [1.5] Foreground content differentiable from background
CS: usually I see this having a minimum piece, to be able to turn it off, and an extended piece, to avoid it in the first place. I'm assuming the first one is covered by separating presentation and information?
GV: no, because you may have illegible contrast but alt text
CS: where is the use of CSS indicated?
GV: under this checkpoint, but still unclear whether it is required
CS: I think that is core.
GV: but for some technologies, there is no CSS
CS: "make it so users can change the colors"
GV: Whether they can get the text out separably from the colors is covered by 1-C4. But the fact that they can't read the default presentation, that is extended
CS: So this technique would be under 1.3, not under 1.4? But this checkpoint sounds like it is talking about this, and we don't want people to make that mistake
GV: This requires that if you don't make any adjustments at all, the text is differentiable from the background.
CS: This needs  a rewrite
MC: and 1.3 needs a rewrite so that it is clear it covers this
GV: add the word "default"?
GV: core vs extended?
CS: extended
JW: extended
BC: extended,but only if 1.3 is clarified based on this discussion
DM: instead of "default", could you say "defined so that"?
CS: you could use CSS to achieve this as well.
Consensus: extended

2-C1 [2.1] Ensure keyboard access
Consensus: core

2-C2 [2.2] Allow user to control time limits
CS: in a perfect world, this would be core, but I'm concerned about whether the technology is up to it
GV: mark this ? on a reality check basis
Consensus: TBD

2-E1 [2.3] - User can avoid experiencing screen flicker
ASW: does this get us into the definition of "avoidable"
GV: leaving the wording aside, is this core?
Mostly yes, but CS thinks there is work we need to lay to make Lisa's idea work
Consensus: Core/TBD

2-E2 [3.1 and 3.2]  - Navigation mechanisms
Consensus: extended

2-E3 [3.5] - Minimize errors and provide graceful recovery
Consensus: extended

3-C1 [1.6 partial] - language of content unambiguously determined?
GV: Should this be "programmatically", rather than "unambiguously"?
JW: and it doesn't necessarily require markup
Consensus: core

3-C2 [4.3] - meaning of words, abbreviations, acronyms can be unambiguously determined
GV: should this be programmatically rather than  unambiguously?
CS: for abbr and acronym, but not words
JS: it is the people who need to understand, not the computer
GV: should we remove "word"? and just leave abbr/acronym
BC: then it would be core
DM: I don't think it is programmatic.
GV: Unambiguously?
GV: use "expansions" instead of "meaning"?
CS: "definition of abbr/acr"
ASW: abbr and acro are defined?
GV: "The definition of abbr/acr  can be unambiguously determined"
ASW: If I use "St." for street, do I have to define that?
MC: context and expectations of audience come into play
JW: if we eliminate "word" we have nothing in core to make meaning as unambiguous as possible without changing the presentation. At some point we'll have to come back to this issue.
GV: There are so many abbr and acr. Will every document that uses XML or HTML have to define it when first used? IBM can't really be expanded.
JW: we are failing to make the distinction between what can be determined and what has to be provided. If the dictionary lookup works, that is good enough. If it is ambiguous, you need to indicate which is appropriate.
GV: libraries could never put books on line
DM: the checkpoint has to include audience's expected knowledge
JW: don't confuse core vs extended and required vs not required
Consensus: TBD

3-E1 [4.1 and 4.2] Content is written to be no more complex...
Consensus: Extended

3-E2 [3.3 and 3.4]  Layout consistent...
Consensus: Extended

4-C1 [5.1] - Technologies are used according to spec...
Consensus: Core

4-C2 [5.2]  - Technologies are declared and widely available
JW: declaration can be in metadata
GV: is this really practical?
CS: "widely available" is very subjective
GW: if I use flash, do I have to say I use flash? Can I suggest this is open?
CS: this is still subjective and probably can never be core
ASW: may be in conflict with the previous
MC: not really comfortable with making this extended
Consensus: TBD

4-C3 [5.3 and 5.4]- Technologies support accessibility or alternative versions of content are provided
CS: There is lots of work needed on Guideline 4. It either needs to be rewritten or deleted.
Consensus: TBD

GV: Suggestion - pull all items that say "you have reviewed..." and put them someplace else. Some of these read like techniques, and this doesn't seem like the place for techniques
MC: people fear that they will be missed in the techniques process. We need to move them into a techniques document
CS: Aren't some of these technology independent?
GV: cross-technology techniques should go into a common document
GV: Should we color code these for now, so they are easily identifiable?
 
 
 
 
 
 

$Date: 2003/05/27 14:48:20 $ Loretta Guarino Reid