WC Today, walk change log again. Want to have some discussion about other checkpoints, particularly if we want to try to release something next week.
GV Not sure we can release next week. Concerned since so many changes.
JW We really need to get something published. We need to at least release what we've done.
GV Perhaps then go through and take controversial stuff out and release the rest.
WC A reason for releasing a draft is for wider review. We can release the draft that says "this is controversial. here are the points." We've had creative discussion on this checkpoint and think we can put in something that can be ok.
WC In intro, got rid of "non-normative" from labels.
GV Success criteria should be normative.
JW Agree.
CS Agree. Also, want to see the sections labeled as normative or not, I did not read the intro.
GV Someone said we're not doing policy, but we are. It is being referenced in policies all over the world. If some info is ignorable.
Action WC: look at other W3C specs for ideas on how to present normative vs non-normative info visibly. Pull normative stuff together, and non-normative together. i.e. pull the success criteria up after the checkpoint text, followed by definitions, benefits, and examples.
GV Examples could be normative. Perhaps informative is good enough. For common cases, it would be nice if we...we want to be general, but it can leave people wondering. Examples can be powerful in clearing things up. Informative would probably solve.
JW It can be used to interpret. If there is doubt what is meant, they can be used to help gain understanding.
WC I made changes before seeing Paul's.
PB I shortened up the intro and split it up w/short intro at top of each page. Added page breaks. Didn't edit words, just concepts.
GV Break up the intro and put it as headers for each section. I think it is useful where you have all the ideas together. It helps you put the pieces together. Not sure that putting them in separate section is a good idea.
PB As I read the intro, it spent some time talking about design principles. It seemed hard to transfer them to the guidelines. I understand the utility of grouping.
WC What about Executive Summary? I think we need both: the executive summary that combines and shows how the pieces fit together, but also an intro for each guideline.
PB Executive summary one paragraph.
GV executive summary should be 2 pages. Then in guidelines just one or two paragraphs.
WC Agree executive summary be 2 pages. Think it should be separate. I think that's what UAAG did.
GV But then you have taken that from the document.
JW We can discuss it when we get around to it.
Action WC:incorporate Paul's changes to intro in next draft. current design principles basis for exec summary, 2 sentences for each guideline that refer back.
GV the intro and executive summary are EO type of things, good to get their review on this.
WC Close to the mark or far off?
GV Completely different. People were talking about sites with different ways of navigate. Spelling is not navigation. Input error other than misspelling, not sure what that would be. Talk about them in general, but success criteria is only about spelling.
JW My understanding of last week's decision was that input errors had arisen and would be dealt with in a checkpoint. 2nd: the issue of navigation mechanisms dealt with by 2.1, still there but clarified by proposed revision which I would send, and did send. There was never proposal to delete the original 2.1 issue (navigation).
WC JW - missed your proposal will incorporate. GV - agree too general. Was hoping to cause people to bring up other input errors.
PB Links that are too small to click on with a mouse.
GV Selection boxes that cause action. Reversability. Keyboard interaction would take care of mouse error.
JW Yes. Reversability is good point. If cause significant process that can not be easily reversed. Providing informative error messages if someone makes a mistake. Many databases expect particular syntax, need to express precisely.
WC Forms problem - 3 fields for phone number. input error, but problem with labels but not input.
JW XForms will help with error detection.
GV Yes, add JW's 2.1. Leave 2.1 as it is, but say "this is a new item that is being explored. We are looking for input on wording, appropriateness, and possible pitfalls." Then we can take something that is clearly not ready for primetime, but we still have it in there and label it as such. It's a heads up that we are looking at it but labeled as different from others that we've beaten around for a while.
JW In ordering, I would put my proposal first. It speaks directly to the text of the guideline. I would put input errors later in the guideline.
GV Suggest put it at the end for 2 reasons: 1 it's new and 2 it doesn't cause everything else to renumber.
Action WC: put Jason's proposed 2.1 as 2.1 (about various forms of navigation). Move new 2.1 (about input errors) to end of section 2 and mark with something like: "this is a new item that is being explored. We are looking for input on wording, appropriateness, and possible pitfalls."
GV Remove success criteria if does not meet criteria: if do not do will not pass. if just things you can do, then they are examples.
JW Yes. Let's see whether adding to the list makes it exhaustive, it will take time to find cases that don't fit, does this make it exhaustive or not. Where large number of examples that can't be made to fit, they don't belong in success criteria.
GV Do we agree that a list of success criteria need to be necessary and sufficient? If you have an if statement, but don't do, then you've met.
JW If there are qualifiers, they should be taken account. Success criteria should be succifiently general to cover...if meet can satisfy the checkpoint.
GV Right, that would be sufficient.
JW We need to do an exhaustiveness check. Attempt to add to them where necessary.
Action GV: l do a pass of success criteria to determine if they are sufficient.
WC Combine 3.5 and 3.6 to highlight idea of annotation.
JW Like it.
GV elevates it to the "what" instead of "how." Why are you providing definitions? Because they are unfamiliar. "ASAP" and "c'est la vie" fall into the same category. My concern however, is that you end up taking 2 concrete things and make them a conceptual thing. But since success criteria fall beneath checkpoint, I like them together. We should try to make it work. It means I'll stare at success criteria for a while.
CS I'm fine with this in guidelines, if clear in techniques. Therefore makes sense for concrete in techniques.
GV Perhaps add the word abbreviations. Give it more scent.
TL I'll have to drop. As long as techniques reflect, it sounds like a good direction.
WC Agreement to put abbreviations in the checkpoint text?
CS Can see that it might not get a quick reaction from people.
JW Think if in the success criteria, will be ok.
GV Can seem like creating a 3rd category.
Action WC: 3.5: Annotate complex, abbreviated, or specialized information with summaries and definitions
Action WC:3.3 Write as simply as possible and appropriate for site's content.
WC I deleted.
GV I support this. It is recursive as it existed. The other problem, it did not get into making sure that you mark up with appropriate strucutre. If not other structure appropriate shouldn't make smaller.
JW Where the issue arises, there is structure there. The issue usually arises when structure is not recognized.
WC The following text was include, "Limiting each paragraph to one main idea will help people process the information" think it should be informative under write clearly and simply.
GV and JW agree.
Action WC: Move sentence "Limiting each paragraph to one main idea will help people process the information." to technique for "write simply" checkpoint.
WC Use XML GL eventually as success criteria.
JW But not normative, therefore can't use.
GV I don't like this one. If you're not going to follow the guidelines, then you're not going to. It's unnecessary.
CS It seems important to me, it's difficult to retrofit this stuff. When make your technology choice, not after you're stuck with something.
GV If you do nothing else, make sure you don't use a technology which you couldn't possibly use accessible.
CS People need to think about this. If you pick HTML, it's possible to use and not meet the guidelines. Also possible to use WordStar markup.
GV I buy that. What priority?
CS Haven't thought about.
GV Perhaps say "Choose technologies that support the use of priority 1 guidelines" you can't make a P1 that forces you to support all priority levels.
CS I think this is an element in a conformance scheme. I think support use doesn't mean every guideline, but those that you choose to support.
GV I see the reason to choose a technology, but we won't make it a P1 if it supports more than P1.
CS It's a dependency issue. It depends on all the other checkpoints.
Issue: dependency of checkpoints 4.1 and 4.2 on other checkpoints. Particularly priority issues.
WC What are the issues?
CS Perhaps problems with specialized user agents not doing complete implementation that other browser can compensate for?
WC Seems to be an issue with the server, not the content.
CS unless writing cgi.
GV Leave prorocols off success criteria list.
Action WC: add note about protocols for review.
WC Just a thought.
GV No. You can make it according to spec, and AT won't work.
Resolved: Don't combine 4.2 and 4.3.
WC Remove.
JW Use my proposal: when technologies that modify default presentation or behavior are turned off or not supported, the content should still be usable.
GV 4.4 seems to be an HTML-specific checkpoint for 4.3.
CS Be careful with term "default presentation" - I think this might be what happens when you don't play with the settings.
Action WC: Use JW's proposal, take care with the use of the word "default presentation."
WC There has been some great, creative discussion on this this week. Seems to be consensus on most of the checkpoint except the success criteria. As suggested, current success criteria are examples. Therefore, I'm working on new success criteria.
JW I have issue that qualifier "to facilitate comprehension" was left off.
WC Here's why I left it off: It falls under Guideline 3 which is "facilitate comprehension." Therefore I felt an echo and that if I did on one, would have to do on others. However, I understand this is a contentious case and qualifier could help clarify.
PB One quick comment on combining 1.1 and 3.4. I don't think appropriate for this draft, but will think about ways to explain it.
Action WC: Move current success criteria to examples, add qualifier to checkpoint text, place holder or new text for success criteria.
Action WC: Make sure issues from 26 July 2001 draft are addressed on the list this week.
$Date: 2001/08/08 23:56:12 $ Wendy Chisholm