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.
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:
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/11/08 08:30:15 $ Wendy Chisholm