19 July 2001 - WCAG WG Telecon

available at: http://www.w3.org/WAI/GL/2001/07/19-minutes.html

19 July 2001 - WCAG WG Telecon

Present
·       Jason White
·       Wendy Chisholm
·       Gregory J. Rosmaita
·       Andi Snow-Weaver
·       Paul Bohman
·       Jo Miller
·       Jenae Andershonis
·       Gregg Vanderheiden
·       Tim Lacy

Regrets
·       Charles McCathieNevile
·       Loretta Guarino Reid
·       Katie Haritos-Shea
·       Matt May
·       Cynthia Shelly

Summary
We discussed the proposed sufficiency criteria reactions from GV to JW's 
proposals for 3.1, 3.2, 3.3, and 3.4. We decided that it was difficult to 
determine the criteria for these before documenting and agreeing on the 
intent of each checkpoint.
It was felt that a good way to help determine evaluation criteria for 
checkpoints is to look at existing examples, then determine if the WG can 
agree on whether something conforms to a checkpoint or not. This is 
basically what Len was trying to do with the discussion re: WCAG 1.0 3.1 
(text in images). Chris Ridpath and Josh Krieger are working on test files 
to run ER tools through. We thought that we could use these test files as 
basis for some of these discussions, and also that we might want to create 
more as well as look at existing sites. Gregory, Paul, and Wendy are 
interested in working on this. Gregory will begin a thread with Chris, 
Paul, Josh, Wendy, and himself.
Resolved for 3.1 to create intent, no agreed criteria right now.
Resolved for 3.2 to put in as examples, along with examples of positioning 
and labels. no agreed criteria right now.
Resolved for 3.3: checkpoint text being reworked to mention audience and 
context (as discussed w/in the last few months). The requirements under 
checkpoint: identify audience, use appropriate language, take into account 
complexity, then make sure that met requirement.
No resolution for 3.4, will return to next week with new draft.

Action Items:
·       Action GR and WC (and anyone else who is interested) - create tests 
and bring discussion to group to determine which conform or not. Also, see 
if can coordinate with Josh and Chris on creation of test files for ER.
·       Action WC: publish new draft before next week.


Sufficiency Criteria
Pertinent Document Links:
JASON: Notes on WCAG 2.0 Sufficiency/Checkpoint Criteria
GREGG: Comments on WCAG 2.0 Sufficiency/Checkpoint Criteria

3.1
GV When houses on the block all look the same, children get lost. If don't 
have differences, people will confuse. Therefore can't look exactly the 
same everywhere.
JW The idea in writing this, every element type will have a uniform style 
applied to it. Usually via style sheet. Sometimes not the case. Consistency 
understood in terms of hierarchical divisions. Every element should have 
its own style properties.
WC In CSS draft, identify function of terms or function of pieces, each 
piece have similar presentation throughout site.
GV Agreed.
JW Reading too much into it GV.
GV So all bathrooms should be laid out the same.
GR Different aspect: braille should always be to the right of the objects.
GV We're all agreeing, but we're writing sufficiency or requirement 
language. Doesn't matter intent, but the actual words. Instead say, "when 
setting up type structure, use controls consistently so that users can 
predict or know or behave way.."
WC We separated behavior from presentation.
JW Think this would work if redrafted.
ASW problem with the word must.
GV We struck on this before, if this were to be a P3, can't use must 
language in a lower priority checkpoint.
JW Perhaps rewrite that not every element has to have consistent style.
WC More to do with function. e.g. W3C copyright.
GV What if nav always on top, on some on bottom, would that site be not be 
AAA b/c nav bar moved?
JW Yes, would be a problem.
WC Although, in future, depend on semantics. Won't have to worry so much 
about positioning.
GV Instead of having a requirement...
JW Examples.
GV Statement of intent, pages should be generally consistent layout so that 
easy to locate info.
JW Propose "Intent" for each checkpoint.
WC Similar to rationale that I already took as an action to put into the 
draft. We need to create tests and then reach consensus on which we think 
conform and which don't.
GV Absolutely great idea.
JW Need next draft first.
GV Before the next draft, put in things that we are comfortable with.

3.2
GV Are these techniques or requirements?
JW Add these as examples under the checkpoint, others for positioning and 
labels be added.
WC Therefore some don' thave requirements?
GV Might find that we can't set them for all. e.g. clear and simple language.
WC Need to give guidance as to how to determine if met. If a judgement, 
what quesitons ask?
ASW removing checkpoints if can't determine?
GR Minimum for 3.2 is ensure distinctions captured in markup.
JW Yes, but redundant w/1.5
Resolved: put in as examples, along with examples of positioning and labels.

3.3
GV Same issues.
WC Change in text of checkpoint, basically what we had in 1.0 - include 
audience. Therefore: a. identify audience, b. identify reading level, c. 
test that these match up.
JW Nothing in there that it relates to complexity of content.
WC Also want to capture - make use of the web. Use meta data to associate 
simpler versions, i.e. for WCAG - quicktips or work from IBM or other 
simplified versions or other EO work...also translations.
GR Link at top to checklist.
GV Not an equivalent for people with CD/RD/LD. How relate to other checkpoints?
JW WC Proposal was this being reworked to mention audience and context. The 
requirements under checkpoint: identify audience, use appropriate language, 
take into account complexity, then make sure that met requirement.
WC What about link to simpler content - examples?
GR links are "if all else fails" metadata something different.
GV We're getting into "if you want to make things simpler" instead of "if 
you want to make it accessible."
JW Agree make it more usable, but that it doesn't make the document more 
accessible.
WC This will go on the open issues list. A portal's content is their 
organization of content, not their own written content. Many sites combine 
content. Content is more than a static page, it is blurring. It is 
applications. Metadata and annotations are important pieces of content. 
Linking to other sites - part of content. Some of this is usability, but 
the usability/accessibility issue is something we still have to figure out.
GV Because there is no bright line, it is difficult.
Resolved: WC Proposal was this being reworked to mention audience and 
context. The requirements under checkpoint: identify audience, use 
appropriate language, take into account complexity, then make sure that met 
requirement.

IRC discussion about test files
WC: GR, PB, and I discussing coordinating with Chris and Josh about test 
files.
Action GR and WC (and anyone else who is interested) - create tests and 
bring discussion to group to determine which conform or not. Also, see if 
can coordinate with Josh and Chris on creation of test files for ER.

3.4
GV These are techniques.
JW Are the set of items sufficient to satisfy the checkpoint and are they 
required. 2 different things. Any obvious omissions? counterexamples?
WC "illustrations" is
GV multimedia means graphic and sound. it says you must illustrate every 
concept with a movie. this is unreasonable.
WC We don't state that. that's the point of this exercise. what does it 
take to satisfy it?
JW The use of multimedia is inconsistent with all of the other documents, 
it has to include graphical, multimedia, and etc.
JM People who are working in 508 has a clear idea of multimedia since 
defined in the law.
JW That's one country's view. We're concerned about consistency within our 
documents.
GV "non-text presentations for concepts presented only in text" - then can 
use multimedia or other...auditory does not count, it has to be graphic. if 
that's what is intended then we should say graphic. Not sure of the intent. 
Want to leave 3 questions: is a page accessible if only some of the ideas 
on it are accessible or does the whole page have to be accessible? 
previously, not ok for some parts of a page to be accessible. if the answer 
is no, then this requirement would have to say that every concept would 
have to be represented in graphical form or page not be accessible unless 
we're talking about usable.
JW If we're going to include this checkpoint, it will lie more along the 
lines of non-text presentations can help clarify meaning, and they are 
useful. We don't have consensus beyond that.
WC But, for some people, this is necessary to access the content. /* 
reminds people of the discussion that I sent re: this checkpoint to the 
list last week. lots of axes and possibilities. how do we define "most"? */ 
Charles had propose if you describe relationships or data, clearly can 
illustrate.
GV But does that really help people with CD/LD/RD?
GR Yes. the data is put into graph to help people process.
JW Someone with a CD/LD would not understand a scie
WC From Anne and my discussion last week, the intent of our people pages 
was to give people a better idea of who we are. They don't have to 
understand every concept on the page. However, they have some idea of 
concepts: who we look like and some things we are involved in (through the 
logos).
GV Yes, perhaps there is a misunderstanding about how much is needed to 
illustrate to make it work. We need to create a gallery of example and if 
people think they go one side or the other. To determine if we're all on 
the same page or where we differ. Figure out the difference between our 
words and our intent. You can't say thing precisely, in the normative part 
I would like to err on the side of flexibility, then in the techniques we 
should err on the side of lots of examples for how to do it.
WC I would like to continue discussion with Anne to determine if I am 
understanding what she is saying.
GV We ought to greek the page and see what info people take from it. 
Comparison tests to determine if guidelines making a difference or not.
WC Have the minutes from the F2F, can pull out questions to move forward on 
the discussion. This was one thing we discussed: usability of them versus 
the effectiveness. Wrestled with CSS draft to come up with criteria. Think 
intent and ways to test are important. I can write "these are the ways that 
I know how to conform, but here's what I'm looking for..."
JW For guidelines 1 and 2 we were able to come up with criteria, it's 3 and 
4 that we're having trouble with. Therefore, we'll have to reserve judgement.
Resolved: next week with new draft, come back to next week.

New CSS Techniques Draft

Pertinent Document Links:
CSS Techniques for Web Content Accessibility Guidelines 2.0
W3C Working Draft 16 July 2001
Issue Tracking for CSS Techniques for WCAG 2.0
Open Issues
Did not discuss this today, but please review and comment.

WCAG Timeline: July through November

Pertinent Document Links:
Timeline: July through November
Did not discuss today, but please review and comment.

Next Meeting:
Thursday, July 26th, 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).


--
wendy a chisholm
world wide web consortium
web accessibility initiative
seattle, wa usa
tel: +1 206.706.5263
/--

Received on Thursday, 19 July 2001 19:11:00 UTC