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