June 10, 1999
4:00 - 5:00 PM EDT
Longfellow Bridge: (617-252-1038)
Ian Jacobs
Charles McCathie-Nevile
Wendy Chisholm
Chuck White
Jason White
Daniel Dardailler
Consensus: Chuck to try and switch 4th Thursday morning meeting back to Thurdsday afternoon (4:00 PM EDT). Too many of the key players would be unable to attend the morning sessions.
WC: would like to get a very general sense of when we should look at it.
JW: rather look at 2.0 than 1.1 - when new XML based technologies take hold then we should reappraise the document.
CL: Agrees with Jason as far as 2.0 goes, but if a 1.1 is necessary, should it be before the end of the charter or left for the next charter?
DD: thinks we should look at the seriousness of the issues.
CMN: pointed to the serious discussion underway in IG on learning disability as to something we missed.
Consensus: lets look at the seriousness of the changes and decide whether they go in FAQ or Errata, or 1.1 with process.
WC: Al Gilman proposed a test to determine which document: an FAQ is a recurring question, Errata if it misleads someone, Techniques to clarify. Or some combination of all three.
Consensus: Al's test is good.
WC: Errata document can be changed frequently. Techniques Doc is a W3C Note and can't be changed too frequently. Working Drafts can be published as often as necessary. FAQ is a page. Will be doing a big update on the Techniques document soon. Anything to go in FAQ or Errata should also go into Techniques.
WC: Hakon Lee has offered to help keep Opera updated
IJ: should rely on UA group to also help keep up. But the UA group is not doing it yet.
WC: do you mean UA will be responsible?
IJ: really, I mean me. Ian will do it with the help of UA.
JW: thinks tools working group could also help.
DD: has anyone looked at the alternative browser page from the EO WG [http://www.w3.org/WAI/References/Browsing.html]
WC: wondering how we solicit input from actual developers for the Techniques document. We should use the GL list for these kinds of things.
DD: but if people just use the list to say "this browser does such and such" it isn't very efficient
CMN: better to see it on the public list than on the Editor's list.
WC: in Trace testing, they are actively going out to get information, e.g. House of Style - does good updates on supported features in the mainstream browsers. Maybe we just need to point people to those, but for accessibility features, we should be maintaining the updates and doing the research.
JW: at least as we can test them ourselves, we can report on them
WC: is EO working on test pages?
DD: not as such.
WC: most of the techniques have been tested and most are likely ok.
CL: the WCAG Curriculum has live examples of many of the techniques, where possible at least.
CMN: should not duplicate any wheels.
WC: this discussion came up from a June 1 Co-ordination Group meeting which tasked GL to flesh out the page and then W3C WAI Staff would be allocated to maintain it.
JW: will try to squeeze in a bit more testing of techniques.
Action WC: will try to collect more information.
WC: at first didn't think this was a big issue. also the use of deprecated elements (e.g. Use of BORDER doesn't work in CSS properly)
DD: People are concerned about the killing of AA ratings by trivial (non access related) coding.
JW: would not support any lowering of priority on strict compliance to the strongest DTD.
DD: thinks it is not an accessibility issue.
JW: but by the time a version 1.1 comes out, maybe the problems with deprecated elements may have gone away.
CMN: agrees that allowing tables rather than CSS is a blockage for improved access, but something like BORDER is too trivial to bother with.
JW: The PDF issue: a very substantial amount of effort in Adobe to support a new structure tree. More closely related to a markup language in its capabilities. When both the input and output environments support this new structure, it will probably produce very accessible reformats. At present, nothing such like exists. Should generate PDF and HTML from the same input file. Rather than create HTML from PDF.
WC: may need to fix the guideline with respect to granularity (i.e. deprecated features).
JW: anything that is a proprietary format is a double A killer and should remain so. Also the serious access deprecated elements.
CMN: some are serious. BORDER is not. These have to be fixed in the Guidelines. This might show a need for a 1.1 version (that would not likely have much trouble going through the process).
WC: is thinking about some usability testing for the guidelines to ensure that we have hit all the major issues? What sort of timeline for a version 1.1?
CMN: it depends how many guideline issues we have.
JW: thinks there will not be many new major issues.
IJ: disagrees. All other W3C documents have been hit with major issues after publication. He doesn't rule out serious problems. Not being negative, just realistic.
Consensus: user testing is a good idea and should be implemented.
Consensus: more interpretation of Guideline 11 should go into the Errata and FAQ.
CMN: at least lay out the plan and make it public as to where we hope to go with the document.
DD: issue of BORDER.
CMN: we want to remove some restrictions without opening the floodgates. There will be some difficult writing. Would like to move it to P3 and call out the ones that actually cause access problems.
JW: like ones that deal with colors, etc.
WC: wonders if what we are trying to do is not otherwise covered in the guide? Needs close scrutiny.
IJ: Proposed: change priority to P3 and deal with checkpoints and techniques.
JW: 11.2 would need strong wording to keep people from using deprecated elements.
Will try for Thursday, June 24 at 4:00 PM EDT
Copyright © 1999 W3C (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.