IRC: Roberto Ellero, Michela Capelli
1-C1 [1.1] All non-text content that can be expressed in words has a text
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?
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...
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
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)
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?
1-E1 [1.4] Structure has been made perceivable...
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?
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.
2-C1 [2.1] Ensure keyboard access
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
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
2-E2 [3.1 and 3.2] - Navigation mechanisms
2-E3 [3.5] - Minimize errors and provide graceful recovery
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
3-C2 [4.3] - meaning of words, abbreviations, acronyms can be
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: 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
3-E1 [4.1 and 4.2] Content is written to be no more complex...
3-E2 [3.3 and 3.4] Layout consistent...
4-C1 [5.1] - Technologies are used according to spec...
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
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.
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