Raw minutes from 20 December 2001 UAWG teleconference [charter, dom events]

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