JW - Action Item: Rewrite of 2.1
:
WC: Focus on Change log, where issues are identified. Concern: length. But we have good info and can use stylesheets to hide unneeded info.
JW: Tried but failed to write XSLT stylesheet just to displayed Guidelines or Checkpoint. Couldn't find ways to identify them uniquely.
WC: Generated already using XSLT.
JM: Like what Wendy did with benefits, examples, etc. Was reading it on a Palm.
WC: Lots of work on introduction. Longer. May want to split it out into an executive summary. Now 5 pages of info. Really 2 types of info: - discussion of high level goals, what does it mean to be accessible - administrative stuff
Other issues: Paul has section on limitations - usability vs accessibility nothing on conformance. Technology specific vs disability specific. Only have intro text on 2 Guidelines. Had trouble trying to write something parallel for comprehension and technology.
WC: Every checkpoint has changed: definition, benefits, success criteria, examples. Checkpoints reworded. Combined 1.2.3 and 1.2.2. New checkpoints (language and flicker). Several checkpoints are weak - couldn't come up with good benefit or success criteria. 3.5, 3.6, 3.7 and all of 4 still haven't been done. Another draft tomorrow or early next week. Moved 1.0 vs 2.0 to the back. How shall we proceed?
JW: When next draft is done, get this into shape to distribute to wider audience. (Need to issue another public draft soon; last was in January. March draft is very similar to January.)
WC: What JW and GV called sufficiency criteria changed to "success criteria".
TL: Make sure there is enough referential information so that everything that is normative will be classed normative. (enough info in markup)
WC: Say in document that only Checkpoints and Guidelines are normative.
JW: Didn't do this last time, and it caused problems.
WC: In conformance, say what is normative and not, and also declare something in markup. I used benefits instead of rationale. *More agreement that this is good* Want to pull defs from glossary, instead of copying text.
JW: Something that implements xpointer would do the job nicely.
KHS: Every glossary item has ID and name.
WC: question: "data model". Isn't the data model inherent in the markup language? Author never manipulates data model directly only thru markup
JW: About terminology: didn't want to just say markup, because there are instances where the structure is labeled but there is no markup. See XML information set. Distinction between markup (syntax) and information items. In order to avoid narrow interpretation, we used both terms. Not limiting expression of structure to markup languages.
WC: This is an example of how vs what. This is an example of how (using markup) where we want to say "what" (use structure)
JW: The problem is quite interesting. You need to make it clear in the checkpoint exactly what is needed. What is needed is explicit structure, represented in a certain way. Used to be called generic identifiers: label, category name that characterizes what the data is. Identifying thing by semantics/nature. Needs to be clear that making structure explicit in this way in a machine-readable representation of content. I have no problem with "markup or data model".
LG: Can Jason capture this notion as definition of data model.
JW: Can't think of anything better than what we have
WC: Make the structure available for machine processing?
JW: In a sense. "make structure available for machine processing in markup or a data model."
WC: Still seems like this is how, not what
JW: The what/how distinction is dubious
TL: We will find cases where we can't split what from how. say "for machine repurposing".
JW: for this one, there is a specific requirement for what has to be done, and it includes the kind of mechanism through which it must be achieved
WC: will leave this for now. With 2.1, the benefit make sense, success criteria is weak, no good examples. Ann commented on 3.4.
JW: 2.1 is difficult. part of the issue is that it is one of those checkpoint which makes a significant difference for some people, but it isn't first priority. Might be dealt with in priority it gets. The other aspect is that no one has suggested a threshhold criteria for when it would apply that seems non-arbitrary and appropriate. Greg would identify this as "good to do but not essential". Should be taken into account in the design process.
KB: Good checkpoint in terms of advice, but uncheckable. There are a number of checkpoints in previous versions that give great advice but no way to know if it could be checked or how it applies. Might represent a problem with our structure of how we do checkpoints. One of those "do enough" checkpoints. How can you tell if you've done enough?
* This is where I dropped offline *
KB: Don't do less than is necessary. But defining what is necessary will be really hard. The best that we can say is that when you set your design or policy, form as intelligent a decision as possible.
WC: When you talk about checkable, do you only mean automated, or manual?
KB: Manual checks
WC: Success criteria believed to be testable
KB: Not good as a general rule, since it won't be applicable to all kinds of sites. Is success criteria meant to be normative? Does rule become "provide at least 2 navigation methods". BUt you might need more, or different
KHS: Give a scenario where we can't provide at least 2 different methods to get to content. Isn't this checkable?
WC: we want techniques that say "provide different types of search function" what do we mean by index, site map? etc? Some cases, the right way to find content is via search, but when is index or TOC ncessary or desired?
KHS: Doesn't require any specific techniqe. "provide at least 2 of these " leaves lots of flexibility
WC: Is this a general problem with success criteria?
KB: Haven't looked at many others. hardcoding rule as "do 2" is a one-size-fits-all compromise. Want to say "do enough to be adequate for info". There will be cases where you want more than 2 mechanisms. Certifying that it is ok to stop at 2 is a problem. (But no idea for how to change/improve checkpoint)
JW: 2 problems: first is that having 2 as a requirement suggests that is all that is necessary, second is that some sites are so simple that 2 methods for finding content is overkill
KB: What about original google search box, with one entry box for search. How can you provide a second mechanism for this huge "database"? Does a site that needs one page need both a search engine and an index? This is the problem with "do 2" instead of "do what is needed"
JW: The success criteria raise alarms with me because they seem very platform specific. If you achieve this thru another method not listed, it may not comply. This is a very desktop-brower oriented list of methods. What if you only have speech input? Valid solution may not qualify. As Greg has said, some checkpoints are really good advice rather than measurable checkpoints. Judgment is needed to decide if this is satisfied.
WC: Skip navigation link has been removed.
JW: It's a technique
C: But under what checkpoint? This is the only checkpoint we have for navigation.
JW: This one is seriously flawed. neds serious work. If we decide to separate advice from requirements, may help. Or maybe it gets a low priority.
WC: Can't move forward by saying it is flawed. What are we trying to capture. Search feature - what can you do to make search facility more accessible. Spelling problems, etc. Now this is just a bullet, "search feature". another problem is with skipping around content and navigating page. This is mostly a user agent issue. We did have a checkpoint specific to search features. It goes across checkpoints and techniques.
JW: Problem is not specific to search features but to text entry. Checkpoint related to text entry could encompass search as a special case. Another aspect: having lists of links and other ways to locating content quickly in a complex site. Besides hypertext links in document itself. Separate out those considerations and create multiple checkpoints.
KB: Agree with Jason. "Don't assume that the user knows how to spell." Be fault tolerant. Be able to recover from mistakes. "turn off" menu item is close to "sleep" menu item - can be selected erroneously. Assume users make mistakes and provide a way to recover.
JW: Graceful transformation?
WC: Not sure
JW: Doesn't have to be presentational
KB: Guideline 2 checkpoint. allow the user to recover gracefully?
WC: In some ways it falls under "provide consistent and predictable responses" but also kind of sits under ?? Good feedback. I'll write a proposal.
JW: Add to next draft, or submit separately.
WC: I'll focus on getting thru the rest of the checkpoints first
JW: the other part of 2.1, all the examples (TOC, site map, etc) are technology-specific instances of the same thing. This isn't the way one would explain in a checkpoint, but idea is if you have a significant number of cross references in the content, when it becomes useful provide list of links to make it easy to locate content without goin through hypertext links within content. Still not quite adequate since it doesn't capture speech input system example with input menus. If there is a significant number of cross references within content, either provide list of links or search function.
WC: Jason, could you please write this up?
ASW: Avoids requirements for list that is exhaustive
JW - Action Item: Jason - write this up
WC: Want to highlight specific requests for review. Paul and Katie and Lisa and Matt, look at issue from F2F on optimize presentation. One sentence based on Lisa's proposal. Katie and Paul, comments on intro. feedback on combining checkpoints. Issues are highlighted in change log.
JW: Given participation requirement for WG, reasonable to expect everyone to read through it.
WC: Interested in all feedback
JW: Everyone must read the draft or read the version that is coming shortly, and read up til 3.4. When next version comes out, read from 3.4 onwards. Separate comments into general issues and items to fix before we post a public draft.
WC: Goal to have new public draft by Tuesday. Want public draft posted on TR one month before F2F meeting. Get something up for Aug 10. Agree to move forward at Aug 9 meeting.
JW: If we don't find too many items that need change, can do it sooner. Aug 9 meeting is deadline for comments.
JW: If you are thinking of attending F2F in Australia, please respond ASAP to see whether this meeting is feasible.
WC: Can people on call give an indication of likeliness? matt - no tom - no andi - 50% kynn - depends on budget jo - no
WC: Would getting a group rate help people to be able to attend? (heard lots of budget concerns) What is success criteria for companies? if we can find cheap tickets, will that help?
ASW: All of IBM on travel restrictions for 2nd quarter. seems unlikely to be able to get approval
PB: That would help
MM: Need an employer first. Otherwise, answer is no
JW: 3 day meeting to make it more worthwhile. See if we get the attendance or reorganize for another time
KHS: If we are coming that far, why not do more than 3 days? burnout?
JW: Costs of staying
KHS: Cost is flying, basically
ASW: Dates?
WC: Week of Nov 12. also, the week before Thanksgiving. can't have it earlier because of an AC meeting in France. Major holiday in Australia on Nov 7. planning on staying around and will meet with folks doing accessibility work, see jason, etc. really want to see this meeting happen because so much is happening there. Good way to get people involved. But hard to keep them involved.
JW: If you are thinking of attending F2F in Australia, please respond ASAP to see whether this meeting is feasible.
WC: Can people on call give an indication of likeliness? matt - no tom - no andi - 50% kynn - depends on budget jo - no
WC: Would getting a group rate help people to be able to attend? (heard lots of budget concerns) What is success criteria for companies? if we can find cheap tickets, will that help?
ASW: All of IBM on travel restrictions for 2nd quarter. seems unlikely to be able to get approval
PB: That would help
MM: Need an employer first. Otherwise, answer is no
JW: 3 day meeting to make it more worthwhile. See if we get the attendance or reorganize for another time
KHS: If we are coming that far, why not do more than 3 days? burnout?
JW: Costs of staying
KHS: Cost is flying, basically
ASW: Dates?
WC: Week of Nov 12. also, the week before Thanksgiving. can't have it earlier because of an AC meeting in France. Major holiday in Australia on Nov 7. planning on staying around and will meet with folks doing accessibility work, see jason, etc. really want to see this meeting happen because so much is happening there. Good way to get people involved. But hard to keep them involved.
Thursday, August 02, 2001 @ the usual time, on the MIT bridge +1-617-258-7910.
Telecon Details: All WCAG 2.0 conference calls are on the MIT bridge
+1-617-258-7910.
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/28 21:53:13 $
by: Wendy Chisholm
or Katie Haritos-Shea