Minutes of 2 November 2000 WCAG WG Telecon

http://www.w3.org/WAI/GL/2000/11/2-minutes.html

Minutes of 2 November 2000 WCAG WG Telecon

Summary of action items and resolutions
·       Action WC: Incorporate Jason's proposal with Kynn's amendments into 
next draft.
·       Action KHS and CMN work on glossary. Be sure to look at Harvey's 
collection of defined terms from WCAG 1.0, ATAG 1.0 and UAAG 1.0.
·       Action GV&WC: pull rationale from WCAG 1.0 and pull into next draft 
of WCAG 2.0.
·       Resolved: Will include checkpoint on auditory descriptions in next 
draft.
·       Action LS: draft wording for Guideline 2.

Participants
·       Gregg Vanderheiden
·       Jason White
·       Claus Thøgersen
·       William Loughborough
·       Len Kasday
·       Cynthia Shelly
·       Wendy Chisholm
·       Katie Haritos-Shea
·       Lisa Seeman
·       Kynn Bartlett
·       Charles McCathieNevile
·       Donovan Hipke

Regrets
·       Dick Brown
·       Andi Snow-Weaver

Agenda
Agenda posted 31 October 2000

Checkpoint 1.1
Action WC: Incorporate Jason's proposal with Kynn's amendments into next draft.

Checkpoint 2.3
WL link to words "data model" to something in the glossary
JW More than likely there will be a subgroup between AU, UA, and WCAG to 
prepare a joint glossary between the three sets of guidelines. Who in our 
group is interested in participating in this?
Who wants to work on the glossary, based on WCAG 1.0?
Who would like to join special cross-group effort?
WL Well, since I don't know what a data model is, guess i can't do it.
CMN, KHS volunteer for both
Action KHS and CMN work on glossary. Be sure to look at Harvey's collection 
of defined terms from WCAG 1.0, ATAG 1.0 and UAAG 1.0.
CMN Proposes to run discussion on AUWG list.
JW CGWG is still discussing how best to coordinate the effort.
GV You talked about Kynn's suggestion, but not doing "imperative."
/* no further comments on "glossary" */
GV like KB's changes except "decorative or no further info." better to say, 
"if decorative, should be marked up." leave techniques to define decorative 
here. shouldn't define on the fly.
/* agreement */
CMN Would go well in the glossary.
GV How flexible do we want the definition to be? If in techniques, it is 
more flexible.
JW Perhaps defn. in glossary and how to apply in techniques. Further comments?
CT Do we have a way to mark decorative elements?
GV We ought to define standard class names for decorative and spacer so 
that we can blow those away. Here we say we should mark them. In techniques 
what will we tell them to mark them with?
JW Put in style sheet, then can't have text equivalent, they should be 
entirely decorative and turned off.
LS Isn't that a problem? Won't people won't want to use images as 
background images?
LK Theoretically, style sheets are not to carry info. No way to communicate 
what it means.
JW The answer I keep hearing, you aren't supposed to use SS for that 
purpose. If it's going to be included, it must be decorative and contain no 
informative value.
WL PFWG take up with CSSWG?
JW Not necessarily, there is an argument that this is not a problem if 
people use CSS correctly.
WL No way to preclude it, therefore it will happen.
LS It is all content to some degree. We encourage people to use SS. It 
seems a natural way to use it.
LK You could define class "new" and choose different ways to show which 
items on a page are "new." There's no way to tell what a class is w/out the 
style sheet. HTML4 says "class may be used for other things." Therefore, 
need a way to make class visible.
JW This should be in techniques.
CMN Attach it to the checkpoint that says "use metadata." I can't find it 
in WCAG 2.0.
WL "I'm using a class to say the following."
CMN Right, de facto schema. It would allow you to produce the transformation.
WL Would make people think about schemas.
JW 2.3
WC Agree would go with 2.3. In checkpoint map, point to old 2.5.
JW Any other comments or move on?
WL Anxious to see us flesh this out more.
JW Should every checkpoint have a rationale associated with it?
WL What is the argument against it?
GV Length. But a short rationale will increase readability.
LS Perhaps a blanket statement: rationale are main rationale but there may 
be further rationale elsewhere. We run the risk of leaving something out, 
then people will think "then I don't need to do it."
KB If we know the ultimate reasons, why wouldn't we state them?
WL Think she means the only reasons.
LS If you want to state all of the reasons that might detract. If you want 
it to be succinct to capture the reasons, you might leave out some particulars.
JW In WCAG 1.0 there are rationales.
WC Who wants to draft rationales for next draft?
/* silence */
WL How about a mapping? Only deal with rationale and not checkpoint.
WC So in next draft incorporate rationales from WCAG 1.0.?
/* agreement */
Action GV&WC: pull rationale from WCAG 1.0 and pull into next draft of WCAG 
2.0.

WCAG 1.0:3.1 and WCAG 2.0:2.2
GV Will we incorporate WCAG 1.0:3.1 into WCAG 2.0:2.2
JW New draft circulating based on CMN and my proposals.
GV Apply Guideline 3 to Guideline 2. Don't have any suggestions.
JW Think part of Guideline 3 helps to clarify Guideline 2.
CMN Clarify that it needs clearer wording but don't have it.
CT Do we understand what we mean? Maybe we don't agree?
GV Technically clear, but is there a higher, simpler principle? Others 
don't say "how to do it." In Guideline 1 we are no longer requiring that 
there be audio descriptions for people who are blind. Is that on purpose or 
accident? It requires a text description but no audio.
JW That was picked up over a month ago. We agreed it was a problem. It was 
an open issue as to what to do with it. It's a requirement that has an 
"until user agents" qualification. We're trying to remove those to the 
techniques.
CMN We could assume that that situation won't arise in the life of this 
document.
WL There was no intent not to require that.
GV Put in 1.3 as a placeholder.
JW Think we might meet the UUA on this one.
GV Can't look at the front-line of troops, have to look at the last of them.
/* GV explains auditory descriptions to CT */
JW With the emergence of processing happening in different places, the 
guidelines don't currently distinguish where processing happens. Processing 
can be distributed. Therefore, what the user sees is only the final form, 
the processing can occur on a gateway. e.g., a mobile device receiving 
final rendering from a gateway. Therefore, what is delivered to the user 
agent is what matters.
CS Good summary of the issue and changes we're looking at.
JW How do we frame the requirements? Where do they get applied? Does anyone 
object to including checkpoint on auditory descriptions in next draft?
/* no objections */
Resolved: Will include checkpoint on auditory descriptions in next draft.
/* GV reads proposal for change to Guideline 1. will send to list */
JW Sounds good. Addresses an open issue.
LS Why shouldn't we recommend to CSS that they incorporate accessibility 
features?
JW It is something for PFWG to consider.
LS I thought that PFWG doesn't think that that is their job.
WC PFWG will review.
CMN PFWG will try to review. You can send mail to PF.
LS I'm trying to think of Guideline 2 /* proposes wording */
CMN OK but need to define terms.
Action LS: draft wording for Guideline 2.

$Date: 2000/11/02 22:42:42 $ Wendy Chisholm

--
wendy a chisholm
world wide web consortium
web accessibility initiative
madison, wi usa
tel: +1 608 663 6346
/--