Minutes from 25 May telecon

available at: http://www.w3.org/WAI/GL/meetings/20000525.html

and included here:

25 May 2000 WCAG telecon
Summary of action items and resolutions
Action: GR XHTML checklist
Action: WC XML, SMIL, CSS checklists
Action: JW ask CMN to write an SVG checklist
Participants
Andi Snow-Weaver
Cynthia Shelley
Jason White
Dick Brown
Gregory Rosmaita
Gregg Vanderheiden
Jon Gunderson
Requirements document
JW it needs further review. It ought to be reviewed by other groups so it 
can be released as public working draft.
GV There were 3 things that I'm not sure are reflected in the document.
the question of whether 2.0 should be easier to use, did we go too far in 
saying that it has to look different from 1.0. with 508 stuff if we came 
out with 2.0 that was completely different it might mess up 1.0 taking 
root. we may not have the flexibility that some may think.
we want to make it simpler and more general, but perhaps we should do that 
in a context.
/* can't remember */
is our current wording is "making improvements" or will it cause us to 
believe that our mission is to remake it. if that's what's needed, then 
that's what's needed.
WC we could add a requirement that we don't weaken 1.0 in any way. that's 
the assumption i've been running on, but we may want to make it more explicit.
/* JW experiences phone problems */
JW the review of the guidelines that we conducted about a month ago, this 
was a reasonable process. It took stability as the starting point and 
looked only at inadequacies of 1.0.
CS our goal of making it less HTML-centric could change it significantly, 
but that is very important.
GV if you just change a couple words, many of them would be less-HTML 
specific. they appear in other types of technologies. Tables for example.
WC Are there tables in MathML? discussed generalized 3.1 and XML/style 
sheets. the generalized draft.
JW Yes, there are general ideas. Many of the current checkpoints can not be 
applied to SVG.
GV with the 508 stuff we see that as we collapse ... we could collapse to 2 
guidelines ... then everything else is an implementation. they are so 
general you can't figure out what to do. as we get specific, we get too 
HTML specific.
CS do you want this specific stuff to end up in a law?
GV no. if we had general principles, and then HTML-specific implementation 
information. if not using that technology you wouldn't need to look at that 
module. it's not techniques.
WC that's what we discussed at the f2f: general principles, then 
technology-specific checkpoints, then examples.
JW but need to be sure it does not need to be updated every 6 moths.
GV put checkpoints in non-normative section?
GR a direct mapping of how we migrated from 1.0 to 2.0. What has been 
generalized? what has been combined? what has been pushed to a 
technology-specific module?
GV only usable to a dozen or so analysts, i'm referring to .... i'm a 
manager at a corporation, we've created a web site, and someone walks in 
and says, "there's a new set of rules." fighting an emotional response.
GR we talked about dynamically generated version at f2f.
CS and the HTML version looks a lot like current guidelines.
GV that says that technology-specific checkpoints are normative if it is 
generated.
JW don't want that since technologies change. should be able to get a view 
that combines techniques with principles. we currently have that since 
techniques are modularized. we have one version for css, another for SVG, 
another for HTML, etc. to some extent we have the basis of that. techniques 
as informative...then update technology specific parts in an easy process.
GV three layer:
guidelines
compliance document (tech-specific) - if do these this is sufficient. kind 
of like our checkpoints now. the testing criteria.
techniques
JW there may be other ways to do this, but the group deems these satisfactory.
GV do this or do that. if satisfied that then you are ok. may allow us to 
write something that is more checkable.
CS and make it clear that style sheet prohibition only applies to XML.
JW should be covered in guidelines.
CS gregg has a good point that people need to be able to recognize 1.0 in 
2.0. adding support for new languages is not purely additive, sometimes it 
removes requirements.
GR what about recommending other languages for inaccessible languages? I'm 
worried about technology specific path. we could guide people from HTML to 
XHTML to XML.
CS we could say, "it's easier to do this in XML..."
GV "this is deemed sufficient, although this language has the following 
weaknesses."
JW with techniques there are certain aspects that apply to a whole range of 
technologies. e.g., if it can represent video or audio content then need to 
provide transcripts and captions. that guidance can be generic, the coding 
specific.
GV When i looked at the simplification it occurred to me that if the first 
layer is general principles, i'm thinking there wouldn't be any 
checkpoints. no one cites guidelines, they only cite checkpoints. they 
treat them independently. maybe the first guidelines would take on a 
different character. then do we return to, "usable without hearing, usable 
without sight, etc."? perhaps we say "ensure everything is modality 
independent" and if you follow the "master strategies" that would give the 
guidelines a new character. if had compliance checklists by technology and 
look like what we have today, then guidelines could change significantly.
JW yes, useful way to approach it. then what we call guidelines should 
become more specific.
JG I know the group is working hard on this issue, you seem to be moving 
towards a more general document. who is the intended audience? how will the 
document be useful to those people? how will it be organized? it's not 
currently intended for novice users. i'm ok with that because a document 
can't be all things to all people.
JW the overriding requirements expressed at the f2f is that the set of 
documents needs to be a stable reference that is as accurate as possible. 
Various groups point to these, such as ATAG, UAAG. etc. We're thinking 
about separating out the technology-specific checks. GV has been working on 
how to write checkpoints to facilitate comprehension. Problem with audience 
is that there are many that are interested in the material. we have to 
satisfy as many as we can. EO is trying to satisfy the needs of the 
less-technical.
JG are the envisioned modules intended to be stand alone or 
cross-referencing to more general document.
JW at the moment, a tech-specific akin to checkpoints, then a separate doc 
like current techniques.
JG a 3 layer model.
JW yes. not saying agreement, but seems to be where we're headed.
JG i like that model.
CS there are some in the audience who only want the general principles.
JW we have to put as much guidance into the general document so that 
technology-specific parts flow directly from that. it is the general doc 
that would be the w3c recommendation. only concerned that general doc 
shouldn't be too general since it be a rec.
GV in such a structure, the general layer go across technologies, the 2nd 
layer becomes your testing document. look like current checklist.
JW next stage is to draft a checklist that would have the layers in it. can 
we implement the idea and revisit the concepts as it evolves.
WC pick a technology and create specific checkpoints?
JW or create the general principles first. it would allow us to determine 
if there are principles that were not accounted for.
GV suggest we try bi-directional. have groups working on checklists, "what 
all should we be doing" another group "what are the principles." will find 
that there are principles without checks and checks without general 
principles. the groups could take these back for further processing.
WC I'll work on technology specific. who wants to work with me?
GR me.
GV we should keep the technology-specific checklists as short as possible, 
put variations in techniques doc. in checkpoint "use alt-text" in 
techniques "here's how to write alt-text." i wouldn't worry about the HTML 
checklist, but the PDF or XML checklist. those are the ones we need to 
learn from. we're already versed in HTML.
JW I suggest SVG. CMN has been working on that area.
GV I will look at general principles, but not until next Wednesday at the 
earliest.
JG what about non-w3c technologies?
JW partly an open issue.
GR given our small number, should the top layer be something written with EO?
JW I can answer that. It's been made clear that the writing of guidelines 
is our responsibility. techniques is exclusively this group. supporting 
materials and tutorials, non-normative and not part of our charter is EO.
GR that clarifies, but does not ease my un-ease. like GV's approach of 
working bottom-up and top-down.
GV who tackle which technologies?
@@GR XHTML checklist
@@WC XML, SMIL, CSS checklists
GV SVG?
@@JW ask CMN to write an SVG checklist
JW need to discuss DOM, since we don't have any techniques at the moment.

$Date: 2000/05/25 21:30:29 $ Wendy Chisholm
--
wendy a chisholm
world wide web consortium
web accessibility initiative
madison, wi usa
tel: +1 608 663 6346
/--

Received on Thursday, 25 May 2000 17:35:05 UTC