Action GR: Try to make the delineation between potenail and kinetic.
Action GR: Post URI to input modalities section of UAAG to WCAG list.
Action GR: Post issue with improper use of the label element in HTML.
Action Wendy: Get all this into this next draft.
/* discussion about mailing list software and why gregg's attachments didn't come through. */
JW: What we want to add to checkpoint vs what to add after it (i.e. what is normative vs. examples). Adopt a format for how checkpoints look?
GV: Walk through them first. You will learn by doing this. Be careful of listing a rule and then minimum criteria, the rule is quite good. Examples is wonderful. Particularly, "in this case, X works." To say "here is rule and here exactly what need to comply..." problem is that we wander into technology-specifics pretty quickly, but some things are minimum but not sufficient.
GV: Don't want to limit to this list.
JW: If it displays graphically...
KHS: Virtual reality?
GR: VR is multimedia
JW: Add interactive
GR: Multimodal
GV: It says "non-text content". Wish that we could say e-text or something that would get across concrete identity. "text represented in coded form..." unicode.
JW: We need to decide if one of the problems...there is text under 1.1 it is an unordered list. It's not clear if it's part of the checkpoint or not. that's why we need a format.
GV: It's clear the way it is written. One reason I want to add "non-electronic text"...we could define non-text content here as well as text equivalent.
JW: If we have a clearer format with sections that label normative or not, then it makes the status of definitions clearer.
KHS: The format that they use in ATAG, "rationale," "minimum criteria" etc.
GV: We stuck in "non-normative" example.
WC: How about I label and put in next draft.
GV: It would clutter.
GR: I've been grappling with this issue with UAAG. Clutter could be avoided with Style - use display none - expose or not depending on style sheet. Then the plain text version is easier to read.
GV: Good point. But, would it be confusing if JW says "it says heading x" and those not using those would be confused.
/* discussion about ATAG Techs as example of text */
GV: Information is more than function.
GR: In that page where you have a graphical icon for search, it indicates search, the link function is follow to perform search.
GV: Right, same page. The function is unambiguous. The information presented is different than the function.
JW: If we had a section labeled clearly in the markup...
GV: Is this a defn of text equivalent or are these requirements? We need a comprehensive list.
GR: The ATAG model subtext: at minimum/base functionality, rationale, advanced suggested functionality (optional), see also.
GV: We'll have real trouble. In some the statement is fine but the minimum functionality, we don't have anything to say beyond checkpoint.
KHS: Then don't put it in that checkpoint.
JW: I don't think it is. If the checkpoint states it sufficiently then they don't have anything further.
/* Scribe missed resolutions for 1.2 and 1.3 */
Resolved: Add both of Gregg's suggestions
GR: Elegant, a must. Only implement it to the extent the technology allows. It forces people to make the analysis. Guides them to best practice.
GV: P2?
JW: Was in 1.0.
GV: If a must then absolutely required. Otherwise not use at all.
JW: The first criterian represented a part of it that qualified as P1.
/* scribe notes that GV, JW, and sometimes GR are only people participating */
GV: Tables can not be linearized. I'm not sure that it's always possible to linearize all content.
JW: Never run into a problem.
GV: A table?
GR: Clearly need to separate structure from presentation. Table is not a structural element, it is presentation. WCAG 1.0 techniques does a good job of debunking the myth.
JW: It is possible to define an ordering and present it. There might be more than one reading order. Must be enough structure to let you define one.
GR: What is being requested - enough markup so that a logical order can be generated. Leave open possibility that if have at least one, more than one are possible to generate.
GV: But, what is the logical reading order of the example /*didn't capture example*/.
GR: If I want to query for particular things, then those relationships should be defined in markup.
GV: I do not think ... if this said "there must be a logical reading order and it must be exposed" it says "a logical reading order, must have a data model that allows you to create one." For anyone person, who are the people connected to them.
JW: Person X is related A,B,C, etc. It would be reasonable. No problem with that example.
GR: Back end not front end requirement.
GV: Just need some mechanism to walk the whole tree.
GR: And discern relationships between nodes.
Conclusion: Both go in. Must language can stay since it is a P2.
GV: Skip until we get the checkpoint text cleaned up.
GV: Is this it?
JW: Not intended to be exhaustive.
GR: What you need to provide for interaction, whereas checkpoint says response to user actions. Delineate between potential and kinetic.
MM: It's hard to say, I'm not sure what the delineatio is.
Action GR: Try to make the delineation between potenail and kinetic.
GV: Perhaps "provide consistent interface elements." Let's put these in an example, if you can do them do them.
JW: Anythign apart from checkpoint text that are criteria.
GV: This is primarily usability, and there are almost inifinite number of things to do. However, if I make all of the items in your kitchen the same shape you'd be lost. We depend on differences, if everything is consistent then be a lot harder.
JW: Easier to have consistency within rather than between web sites.
Proposed change: Add to the end "or provide a clear indication of change." Follow with examples of sufficient solutions to the 2 items presented.
GV: Remove the word flicker.
WC: Tons of discussion on this.
GV: Should be a separate checkpoint for flicker (propose 2.6).
Note: Skip until we have the rewrite of this checkpoint.
GR: In UAAG considered an author problem.
GV: Generic always provided in addition to device-specific. Perhaps say, "everything achievable from the keyboard." Even voice keyboard, emulates keyboard.
JW: Speech, it should be possible to use rather than reading in characters.
GV: If you have speech recognition, if you have banana it types "b-a-n-a-n-a"
GR: Look at input modalities section of UAAG.
Action GR: Post URI to input modalities section of UAAG to WCAG list.
GR: Not sure if this belongs here or not, when intrinsic event handlers, don't define contradictory ones. In particular, the label element. By spec it passes event to form control, but people can use otherwise.
Action GR: Post issue with improper use of the label element in HTML.
GV: 3, I'm concerned with the whole set of them. It's all to make things more usable. Lots of good advice, but worried about them being rules. Some of the requirements in here, like language no more complex...our guidelines fail that.
JW: Under each checkpoint we will either have minimum or conformance criteria, examples, or one or the other.
GV: Clearly marked. Find a nice way of doing it so helpful to everyone. Rather than hiding stuff sometimes.
Will discuss next week
Thursday, July 19th, 2001 @ the usual time, on the Longfellow bridge +1-617-252-1038.
Telecon Details: All WCAG 2.0 conference calls are on the Longfellow bridge
+1-617-252-1038.
Meetings are held Thursdays from 4:00 to 5:00 PM Eastern USA Time (although may run
until 5:30 depending on the discussion).
Last Updated: $Date: 2001/07/14 13:15:51 $
by: Wendy
Chisholm or Katie Haritos-Shea