W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > October to December 2001

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

From: Ian B. Jacobs <ij@w3.org>
Date: Thu, 20 Dec 2001 17:29:04 -0500
Message-ID: <3C226630.49A0EAAE@w3.org>
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: 

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:

Next meeting: 10 January 2002

Reference document 12 September Candidate Recommendation:

Review of action items


  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


  1) JG: Review "How to Evaluate a user agent for conformance to UAAG

  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

  4) HB: Contact ION Systems for a review of their e-reader with UAAG


  1) Judy: Take the proposed charter to w3m (2 Jan 2002).
     JB: After charter is sent to AC, will send a call for

  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:

<Ian> RS: No comments.

<Ian> ...except that IJ will be working less.

<Ian> JB: We will be hiring someone new.

<Ian> RS: I'm concerned about getting to Recommendation in 2002;
that's an awful long time.

<Ian> JB: Options for getting there earlier are:

<Ian> - Stopping now and throwing out a bunch of requirements, going
to last call, anticipating argument over dropped requirements, unclear
path from there.

<Ian> +Eric

<Ian> JB: Not sure there's an easier, shorter path to get there

<Ian> RS: I'd like to have the 508 people looking at this.

<Ian> JB: My understanding of 508 timing is that they won't be opening
a new process between now and then.

<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.

<Ian> JB: Note that meanwhile, IBM needs to be implementing
requirements in CR.

<Ian> RS: Not sure that IBM would implement in CR.

<Ian> JB: That's a contradiction within IBM that needs to be

<Ian> JG: I think that waiting until end of January will help us. We
want to avoid taking out requirements in general.

<Ian> JB: If UAAG 1.0 were a Rec, would you be implementing more in

<Ian> RS: Yes.

<Ian> JG: If we get our implementation gathering done by late
February, then we could be done much sooner.

<Ian> ...I think that by the end of January we should know what we do
and don't have.

<Ian> JG: To move ahead we need to gather information; the more people
who contribute the faster we will go.

<Ian> JB: IJ, please ping me when in communication with Oratrix.

* Ian does a summary of upcoming meetings with developers.

<Ian> I have a list of 10 developers that I'm trying to organize
meetings with.

<Ian> JB: Mark Hakkinen is involved in work on projects that may
contribute to the list of implementations.

<Ian> Action RS: Follow up on IBM software that might contribute to
list of implementations.

<Ian> +Glen Gordon

<Ian> JB: One of the other things I wanted to do re: CR timeline is to
send a message to the wai interest group.

<Ian> ...saying that the CR period is being extended for another
several months.

<Ian> ...I think we need to provide ongoing education about what CR

[See action items at beginning of minutes.]

Agenda 2) Events / DOM / UA requirements

Refer to Summary of where we are as of teleconf:

Scribe's note: Thanks to everyone who attended this part 
of the meeting. I think it was very helpful.

<Ian> 1) What's the best way to ensure that assistive technologies

<Ian> can identify and trigger event handlers?

<Ian> RW: I'm satisfied that we converged on point one. I don't know
that it satisfies everyone.

<Ian> AG: I'm cool with one boolean API per type.

<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.

<Ian> GG, RS: No need to distinguish among handlers of a given type.

<Ian> Queue: PLH

<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.

<Ian> IJ: Bubbling down the tree affects all users equally.

<Ian> AG: AT developers agree- you don't target individual handlers,
only if an event is targeted you want to know the response.

<Ian> RW: You want to know who is handling events up the tree.

<Ian> ...if you make a boolean function resemble the event firing
itself, that's advantageous.

<Ian> GG: Can't one event handler determine that it will or won't

<Ian> RW: The boolean is "Is there anyone who is interested in a
keyboard event happening on this node?"

<Ian> ALH: You take the path between the current node and the document
element. You go down that path first (capturing phase) then up

<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

<Ian> ...this hasn't been checked out with the AT people at all.

<Ian> ...there is use to knowing whether a given node *and not some
other one in the path* has associated handlers .

<Ian> AG: I think ATs should be able to prioritize behavior.

<Ian> AG: What does it take to know the path? Can you ask for the path
of the focus?

<Ian> PLH: Yes, you have the list of parent nodes.

<Ian> AG: So you've already got services; not sure this is a big job.

<Ian> GG: Aren't there two questions?

<Ian> 1) What happens if I trigger an event on this node?

<Ian> 2) What happens if someone else triggers an event? Will I be

<Ian> RS: I'm interested in the first question.

<Ian> ...e.g., for alternative input devices.

<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.

<Ian> ...what answer do you want?

<Ian> RS: I need to know when we are on the actual child.

<Ian> IJ: Assumption of UAAG 1.0 today is that focus can go to
anything with an explicit event handler.

<Ian> RW: I'm concerned with the reverse case: I may have written my
event handler higher up; no explicit event handler.

<Ian> JG: We've talked about this before - we don't know what's going
on in the script.

<Ian> [JG leaning towards second point: describing behavior.]

<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?

<Ian> ...is it useful to get back a boolean reply of "no" and have to
look along the parent path.

<Ian> ?

<Ian> GG: I would like the information available at the most precise
point, not through it's parents.

<Ian> RW: Even if you can't invoke it properly at that level?

<Ian> RS: So the parent node is proxying for its child.

<Ian> RW: This is common for a big document.

<Ian> GG: In this case, the event would be attached to the parent.

<Ian> RW: But if you fire at the parent level, it makes no sense.

<Ian> JG: I don't think that the UAWG has a solution to this problem.

<Ian> IJ: What if we ask for both functionalities: is there an
explicit handler here? Is there a handler somewhere for the current

<Ian> IJ: I hear RW saying that we can solve the issue of non-explicit
event handlers.

<Ian> RW: "Is some listener out there going to address this node?"

<Ian> RW: All you can answer is "Yes, there is a listener that will be
called with this event."

<Ian> IJ: So you get more than zero.

<Ian> PLH: I agree.

<Ian> RW: I believe matching the granularity between dispatch and
triggering is the right thing to do.

<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

<Ian> RS: If the parent is proxying for a child, there's no way to
know which child the parent is proxying for.

<Ian> RW: No way to determine under what circumstances the child is
responding either.

<Ian> PLH: The event could be captured for a given node by a parent.

<Ian> PLH: One thing that IJ told me this morning - we don't want more
functionality than if you do have the mouse.

<Ian> ...a user that has a mouse doesn't know whether handled locally
or by a parent.

<Ian> GG: One reason - is it worth creating a list of things people
can click on.

<Ian> JG: If I can navigate to elements with explicit event handlers
and activate the events, I provided better accessibility.

<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.

<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.

<Ian> RW: Open issues: I'm not opposed to having both modes

--> halindrom (~ahby@demeter.mn.aptest.com) has joined #ua

<Ian> +Shane McCarron

<halindrom> afternoon folks

Point 2

<Ian> 2) What's the best place to describe the semantics of

<Ian> author-specified behaviors?

<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

<Ian> RS: What if you get a list of descriptions for a given type?

<Ian> RS: Biggest problem today - you can't tell today that on mouse
over, you will get a drop-down menu.

<Ian> Shane: In XHTML 2.0 (not yet available), there's a new element
we've introduced for that problem:

* Philippe raises his hand

<Ian> Jon, are you watching for hands up here?

<Ian> RS: I would like to have people be able to label functions.

<Ian> Q: PLH, Shane.

<halindrom> sorry - didn't recognize the protocol.

<Ian> There is no protocol. :)

<Ian> No sweat.

<Ian> PLH: Do you just want a simple text description?

<Ian> Q: Al.

<Ian> Shane: First question - if there's a selectable item on the
screen, why not be able to take advantage of existing attributes

<Ian> PLH: That's dangerous. Do you want each SCRIPT element to have a
title attribute?

<Ian> Shane: I didn't want the script element to do it; there's
another element before the script is executed.

<Ian> PLH: You wouldn't be able to have a description per type of
event handler.

<Ian> IJ: Given current supposed granularity of per-event-type, I
think that description per-event-type is minimum.

<Ian> GG: We try to look for quoted string in invocation in an event

<Ian> ...I would be more in favor of an approach that allowed us to
take advantage of existing pages as well as new pages.

<Ian> ...to assume that people will catch up and use techniques
exclusively takes a while.

<Ian> -GG

<Ian> Summarizing:

<Ian> - PLH and IJ to document why handler-here is useful; don't want
to include the latter functionality if not necessary.

<Ian> RW: Note that function names do not exist in the DOM.

<Ian> AG: Would you be able to participate in a later conversation on

<Ian> IJ: This is, I think, a format issue first, not a DOM issue.

<Ian> RS: You could, when you register an event handler, you could
have a description method on registering the handler.

<Ian> RW: If we're headed towards semantics, why not go there.

<-- jongund has quit ()

<Ian> IJ: Who would like to be on subcommittee: RS, RW, PLH, IJ, SM

<Ian> AG: Me too.

<Ian> JG: Charles will probably want to as well.

<Ian> JG: May want to invite GG or Aaron Smith or other AT folks.

<halindrom> presumably some of you have read the XML Events draft

<halindrom> if not, please look at http://www.w3.org/TR/xml-events/

* Philippe needs to go


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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:31 UTC