11 Dec 2003 - WCAG WG Teleconference Minutes

IRC log

Present

Loretta Guarino Reid, Ian Jacobs, Roberto Scano, Yvette Hoitink, Jason White, Roberto Ellero, Kerstin Goldsmith, John Slatin, Wendy Chisholm, Doyle Burnett, Avi Arditti, Ben Caldwell, Mark Friedman, Bengt Farre, Dave MacDonald, Andi Snow-Weaver, Roberto Castaldo, David D, Gregg Vanderheiden, Mat Mirabella, Mike Barta

Regrets

Patrizia Bertini, Silvia Dini, Cynthia Shelly

Action Items

WCAG 1.0 Errata

Ian Jacobs (editor of the W3C Process document) presented a summary of changes to the process document related to errata management (section 7.6 Modifying a W3C Recommendation).

Ian's summary

Working Groups are always encouraged to keep errata up-to-date and whether or not the errata are normative. Section 7.6.2 Classes of Changes to a Recommendation 4 types of errata. The 3rd seems most likely to apply to most of the WCAG 1.0 errata:

3. Corrections that MAY affect conformance, but add no new features

WCAG 1.0 errata are likely not to add, but to subtract features (i.e., until user agents clauses being met means that some of those checkpoints can be deprecated). To make normative changes based on errata, there are several possible paths. the easiest is to edit the document and publish a revision. get review of the revision (1 month review) and if agreement (from AC and public), then publish as WCAG 1.0 2nd edition. people can continue to refer to older version. It is called "proposed edited recommendation."

several WGs said, "we want to make our errata page contain normative changes w/out republishing our doc. pros: less effort and time. cons: if lots of corrections, people might not find them or might not integrate them into text in the same way (discussed in section 7.6.4 Call for Review of Proposed Corrections). AB created compromise process in section 7.6.4 - WG calls for review of proposed corrections. if no objections after 4 weeks, the proposed corrections become normative. useful for the case of labeling as normative, however, at some point have to integrate into spec. after 1 month review have 6 months to republish document. It is similar to proposed edited rec, but delay in publication. if nothing effects conformance, can republish and no review required. the review is required when there are dependencies and stakeholders who will be effected by changes.

Questions from the working group

Q: is it possible to add something (a link) to the old version that says, "new version available"?

A: It is a w3c policy to not modify published documents (archival state so important...) won't modify in place to say "new version available." In documents published more recently, we try to highlight fact that new ones might be available. Also, there is the "current version" link (for WCAG 1..0 it is http://www.w3.org/TR/WCAG10/). This is already at the top of WCAG 1.0.

Q: we can change WCAG 1.0, send it out for 1 month review, and it is normative?

A: yes. it would be called WCAG 1.0 second revision. would not replace the old version but become the new latest version and say "this doc supercedes the 1999 draft..."

Q: theoretically, we could publish WCAG 2.0 as WCAG 1.0 revision 2 with 1 month review?

A: doubtful that would be considered fixing WCAG 1.0. since WCAG 2.0 contains new features.

Q: Peruntil user agents would be deletions. is that acceptable? Perhaps considered deprecations rather than deletions?

they are not new features. process is largely geared towards protocol and format specs. seems to be a change that does effect conformance. could bring non-conforming documents conformant or conforming docs non-conformant.

Also, the list of possible errata to address that we have been collecting contains a variety of types of errata: technical problems in the PDF version, typos, 'until user agents' clauses that have been met, clarifications

In uaag had links to pdf and other version. at time of rec, got rid of them because took time to produce. suggest that in revision, don't link to them. create and link to them from someplace else. e.g., uaag faq, "is there a pdf version" "yes, here (uri)"

Q: What about WCAG 1.0 techniques documents?

A: worried that already sliding down slope of putting a lot of work in WCAG 1.0, would like WCAG 2.0 to finish.

A: techniques can help clarify some of the issues with WCAG 1.0.

Q: revised version help with harmonization?

A: Too late? Doesn't go far enough?

Proposal: take a conservative approach, fix significant typos and errors, until user agent clauses if necessary. (if we are to take this path, should be very limited in scope, type, and tightly managed so as not to jeopardize work on WCAG 2.0)

(A lot of support for working on a quick fix - typos and until user agents, and moving forward with WCAG 2.0 work)

Q: anything in html techniques for wcag 2.0 that would affect conformance to wcag 1.0?

A: write clearly and simply - perhasp? not in html techniques but in techniques gateway. techniques will change conformance. not so much does it effect, but could become conformant or not based on techniques. One exception might be placeholder text. html tech for wcag 2.0 that would effect conformance for 1.0. place-holders in forms.

Assigning guidelines to people

goal: to get more discussion on list, to get through comments, and to be more prepared for telecons. so that we can get a new public draft in february i.e., talk about proposals in january to prep for draft in february

Q: How do we search for issues related to a particular guideline? Is the search based on the guideline number, which has changed over time?

A: ben gives summary about issues inbugzilla. primarily issues from public comments. issues are assigned to a checkpoint/guideline by a unique id not by numbering (numbers have changed). ben is going to publish documentation about using bugzilla

Q: what do we want to know about?

A: Summarize the issues related to a particular guideline. template: outstanding issues, proposed solutions, proposed solution (feel free to propose more than one solution), dependencies between guidelines, assumptions (what assumption do you make when thinking about this guideline?), and rationale (why this guideline is important).

Q: Using bugzilla is enough? Not necessary to sift through mail archives?"

A: not all issues discussed on the list are in bugzilla. also, public comments were about june draft. many bugzilla comments point to a thread in the mail archives, should follow that thread for more comments. therefore, good to go through bugzilla first since reviewers picked up most of issues, but to be thorough, helpful to go through archives.

Q: in bugzilla: if a bug has been resolved, show up as resolved in bugzilla?

there are different states in bugzilla. Ben describes states - open, pending, closed, resolved.

anyone who did not accept one but has ideas, please submit them and the person who took it will incorporate it.

Adopting plain language proposals

This was primarily an attempt to encourage people to discuss the proposals. Instead, include plain language proposals as an issue to review for a guideline. plain language are issues in bugzilla, so when reviewing your guideline plain language will become part of the issues.

Upcoming meetings

no meetings on 25 december and 1 january

agenda for next week (18 December): Guidelines 1.6/1.7, 1.4, 1.5, wcag 1.0 errata


$Date: 2004/02/05 22:50:36 $ Wendy Chisholm