Thursday, 3 December 1998 4:00 - 5:30 PM EST
Announcement from Judy about call for X-disability review of WAI guidelines. Will circulate to WGs first, then within a day or two (to IG and other organizations).
Gregg: Please point people to latest Working Group draft (rather than reviewing stale documents).
Also, Judy welcomes Charles McCathie Neville to W3C Team for a period of about 6 months.
Charles: Timeline for next PAGL? Next Public Working Draft?
Wendy: As soon we get the scripts in place to make doc production easier.
Wendy: Nov 17 version of guidelines pretty stable. Techniques need updating.
Gregg: New WG draft likely Monday.
Ian: Proposes next public draft after Ian and Wendy meeting in Boston (next week).
Ian: Reminder that I leave town afternoon of 16 December.
Judy: Call for review on 15 December will not get much reaction due to holidays.
Gregg: Might get review between Xmas and New Year.
Judy: Need to get review started quickly for reasons of last call.
Gregg: Propose Monday 7 December for everything. Looking for review of major topics (or lack thereof). Not concerned with details. Get important review for UAGL before they go into their meeting.
Judy: Deadline for comments for PAGL?
/* Some discussion about deadline dates. consensus seems to be that we'll run the cross-disability review & the tech review for future evolvability at the same time; the formal last call is the only thing that will need to run separately. */
Gregg: 21 December.
Action Wendy and Ian: to install scripts/fix links by Monday. (Link fixed by Ian during call).
Jason: If discussion, in techniques document
Charles: Though not standard, can enhance accessibility.
Jason: Conflicts with Priority 1 guideline that says don't use non-W3C elements.
Charles: To ensure access to objects for legacy browser, there's no way to stick with a DTD. Does IMG allow, practice, a real-audio file?
Jason: Normally done with a link.
Charles: This is like tables for layout. Not abusing an element, using a non-standard element in the "proper" way.
Ian: UA GL refers to BLINK, but different world - talking about support by UA (thus, should recognize but not endorse non-standard elements), not authoring.
Jason: Difference between "referring to" and "endorsing".
Charles: Say: Don't use EMBED on its own, use OBJECT. Use EMBED within OBJECT as a legacy solution.
Jason: Not quite acceptable since still violates DTD guideline.
Charles: That guideline only says "When possible". In this case, there is no DTD for legacy browsers.
Jason: But OBJECT supported by browsers more and more. If any mention made of these elements, must be done with obvious warnings.
Why mention EMBED explicitly?
Charles:
Gregg: Should be in techniques or a Note?
Charles: Techniques document. In section on transforming gracefully with newer technologies.
Jason: EMBED is strongly discouraged. However, if the browsers for which this is designed don't support OBJECT, put it in OBJECT (and use OBJECT correctly).
Charles: The use of this technique requires the use of OBJECT and descriptive text as well.
(Jason and Ian remain opposed to mentioning EMBED, etc.)
Action Charles: to submit wording about EMBED to mailing list.
[They will be left on techniques]
[Note: Same issue in UA group]
Gregg: Strong positive feedback to remove priorities from guidelines themselves.
Judy: Please explain this feedback.
Gregg: Priority is not a function of the Guideline but is inherited from the techniques under it. Seemed artificial to find some priorities for some guidelines.
Jason: A lot of guidelines are right on the edge.
Ian: Also, I see guidelines as simply organizational. Finding priorities for them artificial.
Jason: Related issue - compliance requirements. Were there some guidelines that could have no techniques implemented and a site still claim compliance?
Gregg: People look at the techniques when they sit down to author, not the guidelines.
Ian: Same applies for UA Guidelines. Developers want a checklist, which is the techniques document.
/* Gregg examines all Priority 2 Guidelines */
Judy: I wanted to ask about PDF format issue. Where does that show up here (A9 and A14)? My concern about dropping priorities for Guidelines is that other people want to point to our stuff. How do people point to our stuff?
Ian: Claim compliance with sets of techniques. These are specific and measurable.
Charles: For PA, refer them to the 17 Guidelines. If you don't understand, go read the techniques document.
Gregg: We don't do that, we send them to the techniques column of the guidelines document. Do all the Pri 1 techniques and as many Pri 2 as you can. Guidelines try to explain why.
Jason: Also raises the question: Should the requirement be "All priority 1 techniques, plus one or more under every guideline."
Judy: To make guidelines as stable as possible over time.
Gregg: Presence/absence of priorities on Guidelines will not change the stability of the document. Guidelines designed to be generic and to survive revisions. Techniques also meant to be as stable as possible, though techniques might be added and occasionally deprecated.
/* Judy asks about how discussion has gone on list */
Jason: Feeling I have is that no one has found a reason not to do it. But no strong go-ahead sentiment yet.
Judy: I'm concerned about how external groups will refer to the guidelines.
Gregg: My experience is that guidelines are good for instruction.
Ian: Two-tiered numbering is confusing.
Wendy: Want to address concern about techniques being specification-specific. All HTML, CSS, etc. specifics are given as examples.
Ian: Good idea. Will result in fewer broken links as documents evolve.
Charles: When you are new to accessibility, you go to guidelines, get scared, and go to techniques. As you learn more, you use guidelines more and techniques less.
Gregg: Problem with that scenario is that when you design your fourth site, you want to make sure you do the important stuff. Looking at a guideline only doesn't give you enough information. The info about what's "really" important is at the techniques level.
Charles: You want to satisfy every guideline.
Jason: Are you arguing that every guideline is Priority 1?
Charles: Essentially yes, but I wouldn't use the current numbering formalism to rate them.
Jason: So priorities on Guidelines are at best redundant. Every applicable guideline has to be followed.
Charles: I'm saying we "don't" want priorities on guidelines.
Jason: Under scrutiny, we all seem to agree that ok to drop priorities for guidelines. Propose that we take to list and EO group and seek objections.
Judy: Would be helpful for me to see a clear definition of what priorities mean in document revision.
Jason: Conformance requirements.
Judy: Exactly. Discussion in the Team about this issue. Judy had been given action to draft a new paragraph about conformance for every new W3C document.
Jason: Conformance requirements something like "Implement applicable guidelines and all Pri 1 (or some Pri 2 techniques when no Pri1) under them."
Gregg: Don't suggest that approach. Just do it at the techniques level. Priorities at that level have clear meaning.
/* About conformance */
Charles: I would be horrified that conformance were based on techniques. In a court of justice, you would show the guidelines and ask experts to determine whether the guidelines were satisfied.
Gregg: "Rebuttable presumption". If you follow the techniques, you have a rebuttable presumption that you complied. If not, you have to prove in some other fashion. If you don't complete the checklist (techniques), you have to prove that the guidelines have been satisfied in other ways.
Judy: Do we need expiration date on techniques?
Wendy: In cases where techniques can expire, language is clear about when expires. Based on expected audience.
/* On general review */
Judy: Give to varied groups for fresh comments. Think about how new technologies, documents would affect guidelines. Ask people to focus on specific (critical) things, in addition to offering their own perspective.
Jason: Get input along with cross-disability review.
Judy: IMHO, Last call period shouldn't start until we have cross-disability review.
Gregg: Techniques list in Guidelines document are normative. But the techniques document is not normative.
/* Reply to Eric Hansen's email? */ http://lists.w3.org/Archives/Public/w3c-wai-gl/1998OctDec/0287.html
Action Editors: Draft a series of replies.
Gregg: In call for review, please ask people to examine in particular:
Action Everyone: Send ideas about issues to be emphasized to Gregg.
Action Judy: Draft memo about cross-disability review.
Action Editors/Chair: Need to draft a message to chairs asking for technical review of guidelines.