- From: Ian B. Jacobs <ij@w3.org>
- Date: Thu, 20 Dec 2001 17:29:04 -0500
- To: w3c-wai-ua@w3.org, plh@w3.org, rayw@netscape.com, lehors@us.ibm.com, gleng@freedomscientific.com, shane@aptest.com
20 December 2001 UAWG Teleconference Agenda announcement: http://lists.w3.org/Archives/Public/w3c-wai-ua/2001OctDec/0120 Participants: Jon Gunderson (Chair), Ian Jacobs (Scribe), Jim Allan, Katie Haritos-Shea, Eric Hansen, Rich Schwerdtfeger For the charter discussion: Judy Brewer For the DOM discussion: Ray Whitmer (Netscape), Philippe Le Hegaret, Al Gilman, Arnaud Le Hors (IBM), Glen Gordon (Freedom Scientific), Shane McCarron (Invited expert from HTML WG) Absent: Harvey Bingham, Denis Anson, David Poehlman Regrets: Charles McCathieNevile, Jill Thomas Previous meeting 13 December: http://lists.w3.org/Archives/Public/w3c-wai-ua/2001OctDec/0105 Next meeting: 10 January 2002 Reference document 12 September Candidate Recommendation: http://www.w3.org/TR/2001/CR-UAAG10-20010912/ -------------------------- Review of action items -------------------------- Completed: 1) PLH and IJ: Convene a subgroup to address DOM requirements issue Source: http://lists.w3.org/Archives/Public/w3c-wai-ua/2001OctDec/0105 2) KHS and JA: Continue to work on the comparison document with Jim Allan Source: http://lists.w3.org/Archives/Public/w3c-wai-ua/2001OctDec/0054.html Open: 1) JG: Review "How to Evaluate a user agent for conformance to UAAG 1.0" Source: http://lists.w3.org/Archives/Public/w3c-wai-ua/2001OctDec/0054 2) JG: Improve Implementation Report Views To do: a) "What's left to implement" view b) Single product views 3) TL: Review initial implementation report for IE and comment Source: http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JulSep/0191 4) HB: Contact ION Systems for a review of their e-reader with UAAG guidelines Source: http://lists.w3.org/Archives/Public/w3c-wai-ua/2001OctDec/0082 New: 1) Judy: Take the proposed charter to w3m (2 Jan 2002). http://www.w3.org/WAI/UA/charter-20011218 JB: After charter is sent to AC, will send a call for participation. 2) Judy: Send email about CR extension to wai ig 3) Action IJ/JB: Exchange more information about potential developer contacts. 4) IJ and PLH: Organize a subcommittee to work on a proposal for DOM 3 requirements. ------------------------------- Agenda 1) Revised UAWG Charter ------------------------------- Revised charter: http://www.w3.org/WAI/UA/charter-20011218 [14:06:46] <Ian> RS: No comments. [14:06:58] <Ian> ...except that IJ will be working less. [14:07:09] <Ian> JB: We will be hiring someone new. [14:11:56] <Ian> RS: I'm concerned about getting to Recommendation in 2002; that's an awful long time. [14:12:04] <Ian> JB: Options for getting there earlier are: [14:12:33] <Ian> - Stopping now and throwing out a bunch of requirements, going to last call, anticipating argument over dropped requirements, unclear path from there. [14:13:33] <Ian> +Eric [14:14:55] <Ian> JB: Not sure there's an easier, shorter path to get there sooner. [14:15:27] <Ian> RS: I'd like to have the 508 people looking at this. [14:15:43] <Ian> JB: My understanding of 508 timing is that they won't be opening a new process between now and then. [14:16:21] <Ian> ...with regard to equivalent facilitation, I don't know whether CR is different from Rec. It's not as formal a process; maybe it does matter, but I'm not clear on this. [14:17:10] <Ian> JB: Note that meanwhile, IBM needs to be implementing requirements in CR. [14:17:17] <Ian> RS: Not sure that IBM would implement in CR. [14:17:28] <Ian> JB: That's a contradiction within IBM that needs to be addressed. [14:18:13] <Ian> JG: I think that waiting until end of January will help us. We want to avoid taking out requirements in general. [14:19:00] <Ian> JB: If UAAG 1.0 were a Rec, would you be implementing more in house? [14:19:02] <Ian> RS: Yes. [14:20:14] <Ian> JG: If we get our implementation gathering done by late February, then we could be done much sooner. [14:20:43] <Ian> ...I think that by the end of January we should know what we do and don't have. [14:22:19] <Ian> JG: To move ahead we need to gather information; the more people who contribute the faster we will go. [14:23:28] <Ian> JB: IJ, please ping me when in communication with Oratrix. [14:25:17] * Ian does a summary of upcoming meetings with developers. [14:25:33] <Ian> I have a list of 10 developers that I'm trying to organize meetings with. [14:27:47] <Ian> JB: Mark Hakkinen is involved in work on projects that may contribute to the list of implementations. [14:28:10] <Ian> Action RS: Follow up on IBM software that might contribute to list of implementations. [14:28:52] <Ian> +Glen Gordon [14:29:20] <Ian> JB: One of the other things I wanted to do re: CR timeline is to send a message to the wai interest group. [14:29:37] <Ian> ...saying that the CR period is being extended for another several months. [14:30:05] <Ian> ...I think we need to provide ongoing education about what CR is. [See action items at beginning of minutes.] ---------------------------------------- Agenda 2) Events / DOM / UA requirements ---------------------------------------- Refer to Summary of where we are as of teleconf: http://lists.w3.org/Archives/Public/w3c-wai-ua/2001OctDec/0132 Scribe's note: Thanks to everyone who attended this part of the meeting. I think it was very helpful. [14:36:36] <Ian> 1) What's the best way to ensure that assistive technologies [14:36:36] <Ian> can identify and trigger event handlers? [14:40:25] <Ian> RW: I'm satisfied that we converged on point one. I don't know that it satisfies everyone. [14:41:21] <Ian> AG: I'm cool with one boolean API per type. [14:41:56] <Ian> GG: From a screen reader side of the world, it's far less interesting to fire events than to know when events have been fired or that they've been fired. [14:42:23] <Ian> GG, RS: No need to distinguish among handlers of a given type. [14:42:41] <Ian> Queue: PLH [14:43:31] <Ian> PLH Clarification: There is a slight difference - when you ask if there's an event listener on a particular node, it's only on the node. You don't snoop into the subtree. When you do the dispatch, it goes into the subtree. [14:45:18] <Ian> IJ: Bubbling down the tree affects all users equally. [14:45:46] <Ian> AG: AT developers agree- you don't target individual handlers, only if an event is targeted you want to know the response. [14:46:02] <Ian> RW: You want to know who is handling events up the tree. [14:46:33] <Ian> ...if you make a boolean function resemble the event firing itself, that's advantageous. [14:46:59] <Ian> GG: Can't one event handler determine that it will or won't bubble? [14:47:31] <Ian> RW: The boolean is "Is there anyone who is interested in a keyboard event happening on this node?" [14:48:03] <Ian> ALH: You take the path between the current node and the document element. You go down that path first (capturing phase) then up (bubbling). [14:49:24] <Ian> AG: I wanted to know this path-wise so that you could present, if you were to create a menu, you could filter it by immediate/next/next/...and the AT could build this path if it wanted it. [14:49:34] <Ian> ...this hasn't been checked out with the AT people at all. [14:50:16] <Ian> ...there is use to knowing whether a given node *and not some other one in the path* has associated handlers . [14:50:49] <Ian> AG: I think ATs should be able to prioritize behavior. [14:51:11] <Ian> AG: What does it take to know the path? Can you ask for the path of the focus? [14:51:17] <Ian> PLH: Yes, you have the list of parent nodes. [14:51:26] <Ian> AG: So you've already got services; not sure this is a big job. [14:51:54] <Ian> GG: Aren't there two questions? [14:52:03] <Ian> 1) What happens if I trigger an event on this node? [14:52:17] <Ian> 2) What happens if someone else triggers an event? Will I be informed? [14:52:27] <Ian> RS: I'm interested in the first question. [14:52:53] <Ian> ...e.g., for alternative input devices. [14:53:29] <Ian> PLH: Imagine you have a link in a paragraph. You ask whether you have a domActivate event on the paragraph. The paragraph doesn't have one, but a child of the paragraph (the link) does. [14:53:33] <Ian> ...what answer do you want? [14:54:24] <Ian> RS: I need to know when we are on the actual child. [14:55:23] <Ian> IJ: Assumption of UAAG 1.0 today is that focus can go to anything with an explicit event handler. [14:55:55] <Ian> RW: I'm concerned with the reverse case: I may have written my event handler higher up; no explicit event handler. [14:56:18] <Ian> JG: We've talked about this before - we don't know what's going on in the script. [14:56:29] <Ian> [JG leaning towards second point: describing behavior.] [14:57:04] <Ian> RW: The real question that I'm trying to get to: should there be finer granularity on being able to know where things are than being able to fire them? [14:57:31] <Ian> ...is it useful to get back a boolean reply of "no" and have to look along the parent path. [14:57:32] <Ian> ? [14:57:45] <Ian> GG: I would like the information available at the most precise point, not through it's parents. [14:57:57] <Ian> RW: Even if you can't invoke it properly at that level? [14:58:16] <Ian> RS: So the parent node is proxying for its child. [14:58:22] <Ian> RW: This is common for a big document. [14:58:30] <Ian> GG: In this case, the event would be attached to the parent. [14:58:37] <Ian> RW: But if you fire at the parent level, it makes no sense. [14:58:51] <Ian> JG: I don't think that the UAWG has a solution to this problem. [15:00:24] <Ian> IJ: What if we ask for both functionalities: is there an explicit handler here? Is there a handler somewhere for the current node? [15:01:14] <Ian> IJ: I hear RW saying that we can solve the issue of non-explicit event handlers. [15:01:42] <Ian> RW: "Is some listener out there going to address this node?" [15:02:06] <Ian> RW: All you can answer is "Yes, there is a listener that will be called with this event." [15:02:17] <Ian> IJ: So you get more than zero. [15:02:19] <Ian> PLH: I agree. [15:02:31] <Ian> RW: I believe matching the granularity between dispatch and triggering is the right thing to do. [15:04:12] <Ian> RW: I need to hear the use case for when it's useful to know that the event handler was declared on the current node and not an ancestor. [15:05:15] <Ian> RS: If the parent is proxying for a child, there's no way to know which child the parent is proxying for. [15:05:28] <Ian> RW: No way to determine under what circumstances the child is responding either. [15:05:41] <Ian> PLH: The event could be captured for a given node by a parent. [15:06:42] <Ian> PLH: One thing that IJ told me this morning - we don't want more functionality than if you do have the mouse. [15:07:13] <Ian> ...a user that has a mouse doesn't know whether handled locally or by a parent. [15:07:26] <Ian> GG: One reason - is it worth creating a list of things people can click on. [15:08:15] <Ian> JG: If I can navigate to elements with explicit event handlers and activate the events, I provided better accessibility. [15:09:36] <Ian> AG: I agree with IJ; I've learned things on this call and my personal opinion is that the DOM could give you either. I don't think there's a P1 class problem here: GG gets more votes in figuring out what's more valuable. [15:10:59] <Ian> JG: When you get away from explicit handlers, any element in a document could respond to a mouse click. We ask for explicit handlers to provide better granularity. [15:14:07] <Ian> RW: Open issues: I'm not opposed to having both modes (locally/globally). [15:14:08] --> halindrom (~ahby@demeter.mn.aptest.com) has joined #ua [15:14:54] <Ian> +Shane McCarron [15:15:04] <halindrom> afternoon folks =================== Point 2 ================ [15:17:23] <Ian> 2) What's the best place to describe the semantics of [15:17:23] <Ian> author-specified behaviors? [15:17:50] <Ian> RW: I don't think that providing descriptions at the level of the listener is the right granularity if you can't activate them independently. [15:17:58] <Ian> RS: What if you get a list of descriptions for a given type? [15:18:33] <Ian> RS: Biggest problem today - you can't tell today that on mouse over, you will get a drop-down menu. [15:18:51] <Ian> Shane: In XHTML 2.0 (not yet available), there's a new element we've introduced for that problem: [15:19:40] * Philippe raises his hand [15:19:50] <Ian> Jon, are you watching for hands up here? [15:20:07] <Ian> RS: I would like to have people be able to label functions. [15:20:23] <Ian> Q: PLH, Shane. [15:20:35] <halindrom> sorry - didn't recognize the protocol. [15:20:42] <Ian> There is no protocol. :) [15:20:44] <Ian> No sweat. [15:20:52] <Ian> PLH: Do you just want a simple text description? [15:21:03] <Ian> Q: Al. [15:21:32] <Ian> Shane: First question - if there's a selectable item on the screen, why not be able to take advantage of existing attributes ("title")? [15:21:46] <Ian> PLH: That's dangerous. Do you want each SCRIPT element to have a title attribute? [15:22:02] <Ian> Shane: I didn't want the script element to do it; there's another element before the script is executed. [15:22:14] <Ian> PLH: You wouldn't be able to have a description per type of event handler. [15:23:22] <Ian> IJ: Given current supposed granularity of per-event-type, I think that description per-event-type is minimum. [15:23:40] <Ian> GG: We try to look for quoted string in invocation in an event handler. [15:24:03] <Ian> ...I would be more in favor of an approach that allowed us to take advantage of existing pages as well as new pages. [15:24:18] <Ian> ...to assume that people will catch up and use techniques exclusively takes a while. [15:24:21] <Ian> -GG [15:25:34] <Ian> Summarizing: [15:26:00] <Ian> - PLH and IJ to document why handler-here is useful; don't want to include the latter functionality if not necessary. [15:27:05] <Ian> RW: Note that function names do not exist in the DOM. [15:27:18] <Ian> AG: Would you be able to participate in a later conversation on labels. [15:27:41] <Ian> IJ: This is, I think, a format issue first, not a DOM issue. [15:28:02] <Ian> RS: You could, when you register an event handler, you could have a description method on registering the handler. [15:28:15] <Ian> RW: If we're headed towards semantics, why not go there. [15:30:10] <-- jongund has quit () [15:30:44] <Ian> IJ: Who would like to be on subcommittee: RS, RW, PLH, IJ, SM [15:30:59] <Ian> AG: Me too. [15:31:04] <Ian> JG: Charles will probably want to as well. [15:31:37] <Ian> JG: May want to invite GG or Aaron Smith or other AT folks. [15:32:07] <halindrom> presumably some of you have read the XML Events draft [15:32:19] <halindrom> if not, please look at http://www.w3.org/TR/xml-events/ [15:33:14] * Philippe needs to go [15:33:45] <Ian> ADJOURNED -- Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs Tel: +1 718 260-9447
Received on Thursday, 20 December 2001 17:29:20 UTC