joint WebAPI WAI_PF on topics of mutual interest with emphasis on DOM3
19 Apr 2006


Al Gilman, Gottfried Zimmermann, Tim Boland, Janina Sajka, Rich Schwerdtfeger, Anne van Kesteren, chaals, Dean


<Al> scribe: Gottfried

1-2 minutes around the table

<Al> Gottfried 2 mins: quiet weekend over holiday; working on URC standards in ISO process and with URC Consortium

Anne: Promoting double-click event.

Tim: Quality Assurance interest group and QA reviews. Authoring tools wg f2f meeting soon, working on ATAG 2. WCAG proof reading exercise, upcoming last-call wg. CSS 2.1 issues, media queries, css basic ui.

Chaals: We have a number of UI events that are device specific. We should at least develop guidelines for authors wrt these events.
... Roles and states. Do we want to revisit stuff (from 90s, early 2000) on device independence (with HTML wg and DI wg).

Al: Want to have on the agenda:Listener, discovery and trusted events.

Rich: How far does the WebAPI group want to go beyond DOM?
... There are DI issues, issues around states and properties. I'd like to get a feeling for that.
... UI specific stuff?

Chaals: Web-API deals with DOM in general. Web applications formats group, Anne is in this group.

Dean: To me an API isn't always a DOM. The biggest part is DOM, however. The charter describes that there are things beyond the DOM we will tackle. Charter is available from the public page.

Rich: Who are the people doing the implementations? Do we have browser manufacturers on board?

Dean: For Web-API we have quite some browser manufacturers, and Microsoft is considering attending our F2F.

Al: Reminds of discussion between PF, UAWG and DOM wg. I think we don't want to have events labeled "click". Authors need to provide what it does and what it has. DOM is a protocol in that it defines methods.
... DOM has to be a platform that allows for multiple authors, including discovering what the listeners are and what they do.
... A11y requirement is well-documented and well-supported API that AT can use.
... In the past there have been objections against naming events "click". DOM wg therefore created DOMActivate, but this has been widely ignored.
... Chaals' plan is to call it "click", but give it a more abstract and device-generic meaning.

Anne: Latest: DOMActivate event is dispatched if a link is clicked on.

Chaals: mouseWheel event is a one-dimensional event that can occur with a mouse or with other input devices.

Al: linear devices on cell phones, etc.

Chaals: People are familiar with "mouse wheel". If we called it "one-dimensional slider event", authors wouldn't understand.
... Gave up on strict naming schemes.

Al: I am not aware of a11y requirements that say naming has to be neutral.

Rich: Chaals, you want to abstract mouseWheel event?

Chaals: Yes, and you can trigger it with a track pad also. Apple does horizontal mouse wheel, interesting issues such as diagonally scrolling. Have to much to do to work on things that are not real.

Janina: My point is that we need to adopt terms that people understand and use.

Chaals: Names or not important.

Rich: The more device independence we get the better.
... How much do you have to maintain backward compatibility?

Chaals: We are not going to write up compatibility rules. We support existing content and implementations as much as possible. If all browser makers agree that we should change something we are doing that even if something breaks.

<anne> hmm, backpat with XForms and SVG that is...

<Zakim> chaals, you wanted to say naming is one thing...

Al: There are limits to our not caring about names: If name is not abstract we need a description from the author of what an event does.

Chaals: Example?

Al: Clicking on object causes a pop-up, or replace current content.
... The other thing is: people with cognitive disabilities need familiar presentations for content. We need metadata for standard action content. ETSI has a standard for commonly used verbs for phone dialogs.
... We would like to develop such action schemes with you.

Rich: Can we map device specific events to abstract events?

Chaals: Yes, to some degree with Activate. Not even started with mouseover.
... Focus might be related. Not clear what the best strategy is.

Rich: Have you thought of using profiles?

Chaals: Could be done.

Rich: Example: You direct the UA that double-click maps to activate events. You never see the double-click, it is internal to the UA.
... Now we have a bunch of handlers for every event. What can we do with this legacy code?

Anne: DOM3 events say what kind of events should be dispatched in what order.

Rich: Assume i have a blackberry. What would be the mapping?

Al: Moving the cursor may move the focus.
... XBL could be used to declaratively redirect events. Delivery context needs to be respected. AT could reprogram XBL.
... In the short run AT needs to know what a mouse click is.

Anne: Most of DI issues are because of lack of declarative widgets.

Al: Strategy must be how to subvert DD things into DI and device adaptable things.

Rich: Role taxonomy is not really integrated with whole application model. Do we want to have device mappings for roles?

Anne: Different keys used on different devices to control widgets. Select, input and submit are fairly device independent. But there is more widgets that don't have native controls; causes trouble.
... With XBL we could have more device independence.

Al: Using roles for widgets will help authors express things in terms what it does and how to operate.

Anne: Actively looking into XBL 2 proposal from Mozilla.
... Anne: XBL will be one of our deliverables.

Rich: XBL might help with some DI issues.

Al: XBL will build on DOM 3 events.

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2006/04/19 14:03:30 $