Chair: Jon Gunderson
Date: Wednesday, August 4th
Time: 12:00 noon to 1:30 pm Eastern Standard Time
Call-in: W3C Tobin Bridge (+1) 617-252-7000
Chair: Jon Gunderson
Scribe: Ian Jacobs
Present:Gregory J. Rosmaita
DP: Send reference to the mousetrap to the list.
ACTION JB:Follow up with W3C meeting planner and Microsoft for 11-12 October. Backup plan for Florida after ATIA (Sun 10-11).
ACTION IJ: Send proposed text for resolved checkpoints (see below) to list.
CMN: Copy request sent to blinux users for info about orientation to UAGL
HB: Ask Alan Cantor for links to pages where OS system keyboard conventions are documented. Also, send reference to infamous 600 combinations.
HB: Contacted him, but he hasn't sent reference.
DP: AC pointed us to info on the list.
ACTION DP: Send reference to the mousetrap to the list.
RS: Review conformance statement, and classes of browsers (HPR) see where it
fits into classes, present proposal to list if needed.
Status: No proposal sent.
IJ: Review member participation for next week.
Status: Still waiting for comments from Judy Brewer.
JG/IJ: Will finalize dates for next F2F by next teleconf 4 August and
announce on 5 August.
Status: Still waiting for info from Judy Brewer.
GR/DP: Review all checkpoints and document how particular issues apply in a
Status DP: Pending. Mostly info about providing context information outside the document.
IJ: Write a proposal for dealing with natural language changes and primary
identification to replace Checkpoint 9.9. Also, look into bidi support.
Status: Not done.
IJ: Write a proposal to combine 9.16-9.18 into one Pri 3 checkpoint worded
something like: "Make available information about a focused link to to
enable the user to decide whether to follow the link. In particular, make
available whether the link has been visited and whether it involves a
Status: Not done.
GR: Write a proposal for a configuration checkpoint for guideline 9 (any
information made available to the user).
/* Ian reviews Process of going to Recommendation and anticipated timeline */
Anticipated last call: mid/late August
Anticipated Proposed Rec (AC review): mid October
Anticipated Recommendation: early December
JB: Please note that the AC review is not vote-counting. Review comments are processed by Chair, editors, WAI, W3C Team, and Director. AC comments usually result in minor changes. If major changes required, doc usually recycled as a WD.
HB: My concern is that some companies will say "If we have to do this, you will put us out of business."
JB: These are Recommendations. Yes, distinguishing "guideline" from "technical standard" is important. We have chosen wording carefully.
IJ: We need to start to focus on techniques as a strong support for the guidelines.
JB: I second and think that the doc shouldn't go to last call until this is done.
/* On Face-to-face meeting schedule */
JB: Optimal if face-to-face after last call and before proposed recommendation. Initially we wanted to have the meeting held at a developer site. We talked to Microsoft about hosting a meeting. No definite response yet. Dates we asked them to consider were 30 Sep/1 Oct at Microsoft. (Not interesting in hosting an offsite meeting). I know there is also discussion of a meeting around ATIA. In terms of timing, if the WG slips schedule on last call, the 30 sep/1 oct meeting might be too early anyway.
HB: Earlier meeting at MS ok with me.
MN: I have a conflict with 1 Oct. Would like to attend, yes.
KB: Don't know whether I would attend.
DP: Dates are ok with me.
IJ: Dates are ok with me.
GR: 30/1 no problem. I'd like to piggyback ATIA.
JB: Note that it's important that a core group my have to make hard decisions during last call/PR. Thus, a face-to-face would probably be more of a core (active) group meeting not a general call for participants. Need to set expectations about who would attend.
JB: Ensure that assitive technology developers review during last call (send messages getting review commitment in advance!). When you go to last call, send reminder message, then follow-up during last call to ensure they have responded.
/* Rich joins */
Also discussion of piggy-backing with Closing the Gap (21-23 Oct).
IJ: Problem of communications during the last week of the year - Comm Team will not take a document to Recommendation during the holidays. Thus, if we slip, we slip until January.
JB: There's a lot of tight internal scheduling that needs to be done and that would be difficult during the holidays.
JB: Do you need more time?
IJ: I think the guidelines are almost stable. I think the techniques document needs work before going to last call.
JB: While the Techniques don't go to last call, without them too many questions.
RS: A lot needs to be done in the Techniques Document. The Guidelines look good.
JB: Lots of key members on vacation this month as well.
JG: I'd like to get a developer to host a meeting.
GR: Yes, for AUGL that gave the WG a boost when we met at Lotus.
JG: Who's going to ATIA (in Orlando)?
RS: I would go if UAGL had a meeting.
JB: Is 11-12 October in Redmond a possibility?
RS: Ok, although I'd prefer in Florida
MN: Either ATIA or Redmond
DP: Redmond better
KB: Dates fine, but not sure if I can go.
ACTION JB: Follow up with W3C meeting planner and Microsoft for 11-12 October. Backup plan for Florida after ATIA (Sun 10-11).
JB: If people want to talk to me about WAI resources for attending meetings, please contact Judy
/* Judy drops off */
Last week'ss discussion:
a) Proposed Checkpoint: Provide statistical information on document content [Priority 2]
IJ: Still seems too general to me. But I like the idea (although language would be separate for me.)
GR: Propose overarching checkpoint about configurability.
KB: What about "quantity of elements" instead of "statistical"?
IJ: Is it important to know the number of tables?
RS: I think that's useless info, especially if tables are used for formatting.
DP: Provide information about the number of active elements in a document?
RS: I think that the number of headers is important. Yes, it's important to know what context you're in.
IJ: I think that providing a structural view is more important than knowing the number of headers.
GR: Structured view very important.
MN: Knowing the number of data tables is important. I agree with Ian number of headers not helpful, but knowing heading levels is.
JG: Is knowing the size of the document useful? Characters, bytes, etc.?
DP: Characters less interesting than percentage of document viewed.
IJ: Like proportional scrollbars, but available also non-visually.
RS: Good thing to know where you are in the DOM (how much has been viewed). Don't know that that's available today.
ACTION IJ: Send proposed text for resolved checkpoints to list.
For visited links, GR proposes that this be technique for a more general checkpoint on configuration. This will be part of his action item on configuration checkpoint. Also: info about fee, visited, external, etc.
For other proposed checkpoints:
Checkpoint: Provide access to header information for a table cell selected by the user [Priority 1, DUA]
Checkpoint: Ensure that when the selection changes, it is in the viewport after the change. [Priority 2]
Checkpoint: Ensure that when the focus changes, it is in the viewport after the change. [Priority 2]
Group: Combine these two.
Checkpoint: Maintain consistent user agent behavior and default configurations between software releases. Consistency is less important than accessibility and adoption of system conventions. [Priority 3]
RS: Mention keyboard defaults explicitly.
MN: This checkpoint seems like a comment on existing checkpoints. I would rather tell developers what to do through other checkpoints. This is an inherent principle that should follow from others.
DP: I don't think this should be a checkpoint. Focus on accessibility issues directly, not higher issue. I understand the issue and sympathize, but documentation is available.
JG: The goal is to stop developers from indiscriminately changing configs.
RS: In previous meeting, Glen Gordon and I felt strongly about this one.
MN: I don't object to it but would like to see it reflected elsewhere in the document.