Minutes from 02 August 2001 telecon

available at:
http://www.w3.org/WAI/GL/2001/08/02-minutes.html

We discussed the 31 July 2001 draft.  We went through the issues identified 
in the change log.  We resolved all of them in some way.  Several 
resolutions will be included in a draft expected next Tuesday (7 August) 
however others we resolved to put off until after we go to TR, i.e. there 
are larger issues that we can not attempt to resolve before going to TR (in 
roughly one week).

Be well,
--wendy


02 August 2001 WCAG WG telecon

Present
·       Gregg
·       Loretta
·       Tim
·       Wendy
·       Jason
·       Paul
·       Cynthia

Regrets
·       Matt
·       Katie
·       Jo

Summary of action items, resolutions, issues, and insights
·       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.
·       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.
·       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."
·       Action GV: do a pass of success criteria to determine if they are 
sufficient.
·       Action WC:3.5: Annotate complex, abbreviated, or specialized 
information with summaries and definitions
·       Action WC:3.3Write as simply as possible and appropriate for site's 
content.
·       Action WC:Move sentence "Limiting each paragraph to one main idea 
will help people process the information." to technique for "write simply" 
checkpoint.
·       Issue: dependency of checkpoints 4.1 and 4.2 on other checkpoints. 
Particularly priority issues.
·       Action WC:add note about protocols for review.
·       Resolved:Don't combine 4.2 and 4.3.
·       Action WC:Use JW's proposal, take care with the use of the word 
"default presentation."
·       Action WC:Move current success criteria to examples, add qualifier 
to checkpoint text, place holder or new text for success criteria.

Latest draft
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.

Intro
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.

Paul's changes
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.

checkpoint 2.1
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.

Checkpoint 3.5
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.

Checkpoint 3.7
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.

Checkpoint 4.1
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.

Checkpoint 4.2
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.

Combine 4.2 and 4.3?
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.

Checkpoint 4.4
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."

Checkpoint 3.4
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/02 23:34:28 $ Wendy Chisholm

--
wendy a chisholm
world wide web consortium
web accessibility initiative
seattle, wa usa
/--

Received on Thursday, 2 August 2001 19:38:16 UTC