<scribe> Scribe: Andi

davidb

Events table in events.doc that Cynthia sent out

DB: reviewed events.doc

CS: have not reviewed it with the IE team
... HTML element types that support certain events, ARIA semantics that map to similar HTML elements should support the same events

DB: modifying the DOM events?
... don't like the premise of modifying DOM events
... think ARIA's place is for desktop events

CS: don't necessarily have to change DOM events but ...
... DOM events create OS events
... look at onchange or onsubmit events, some get mapped up to OS level, not mapped to API events

DB: if <div> has role=combobox, selection via ARIA attribute, need to fire event....
... Firefox goes right to platform event

CS: when semantics of element have been modified by ARIA such that they are the same as HTML element...
... if the corresponding HTML element would throw platform events, then the ARIA element should fire the same events
... third table in events.doc is the one that is like what we need in the UAIG

DB: would be good to know if Safari is firing DOM events

CS: need to compare this to the tables we have and see if we have covered everything

DB: something that someone else could do - go through various attribute changes and see what the implementations do in terms of firing desktop events

CS: what do ARIA test suites test?

MC: still in planning stage, started wiki page for test planning

<cyns> I'm in

<MichaelC> ARIA test plan

MC: need some unit tests for what UAs do for a given role and properties - several hundred unit tests
... also need to do feature tests with combinations of roles, states, properties working together
... don't know if this is required for implementation or not but certainly required for interoperability
... might be room for adding suggestions to wiki page

DB: suggest adding events

MC: going to add a third category for dynamic tests
... plan is to be able to import these into a test tool

DB: FF runs on three platforms so have internal event model

MC: adding to the wiki page: "reaction to events (fairly UA specific, need to expand on this)"

DB: testing would be UA specific but want to aim for interoperability

CS: many will have to be operating system specific - something happening outside the browser that AT has to react to.
... ARIA is a bridge from Web application to platform implementation

MC: hoping to generate using XSLT, Jon G. has tests, want to automate what we can but there will be lots of human created tests

DB: created FF tests in Dojo

MC: hard to focus on test suite until test harness is done
... for human created tests, need a way to ensure they are valid

CS: writing a spec for each test, could be done without the test harness

MC: send note to Rich - UAI TF has thoughts about testing

<scribe> ACTION: Cynthia to send note to Rich about prioritizing testing on Monday's agenda [recorded in http://www.w3.org/2010/07/13-aapi-minutes.html#action01]

bug 7019

CS: section 4.7 rules
... element is focusable - doesn't necessarily mean there are actions
... why are menus treated differently? do any of the roles in the first table in 4.7 need this level of description?

DB: nice keeping the menu things in their own space

CS: we have a bunch of things that are separate one off things - the menu section is one of the last ones of those

DB: what does the actions column mean?

CS: aria states/properties that cause elements to have additional actions associated with them in the browser
... doDefaultAction on a button clicks
... <div> with aria-expanded, doDefaultAction comes in from OS, what should the UA do?

DB: in FF, doDefaultAction simulates a mouse click

CS: maybe the format we use for menu events is a better way to describe the actions tables

DB: Javascript is between user action and event
... browser has to fire event if state (aria-expanded) changes
... Javascript is handling actions

CS: if AT simulates arrow behavior...

DB: AT should let user keystrokes go through

CS: but what about things that simulate a keyboard - voice reco or onscreen keyboard

DB: they just synthesize the keystrokes

CS: for UA, keystrokes and mouse clicks need to get passed through

DB: for 2nd table in 4.7, specifying the default action might be useful, might depend on the role

CS: most are going to be click
... grabbed is interesting, exposes "grab" action
... back to bullet list at top of 4.7
... what actions get exposed when these are true
... just because something is focusable, doesn't mean there are actions associated with it
... click handler is obvious

DB: if it's in the tab order, FF exposes click as the default action

remove the xlink bullet

CS: maybe we need a table of user events
... but is that ARIA?

DB: more like HTML

CS: some discussion about moving authoring advice out of HTML spec and into a separate document
... been talking about doing a mapping document for HTML to accessibility APIs

prep for Monday's call - what can others help us with?

CS: actions and events topic could be given to someone else

9363 could be given to someone else

DB: could work with Joseph on events/actions bugs that are assigned to Cynthia

This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/davidb//
Succeeded: s/1 min//
Succeeded: s/primarily for the HTML/for desktop events/
Succeeded: s/exposed/exposes/
Found Scribe: Andi
Inferring ScribeNick: Andi
Default Present: Andi_Snow-Weaver, Cynthia_Shelly, David_Bolter, Michael_Cooper
Present: Andi_Snow-Weaver Cynthia_Shelly David_Bolter Michael_Cooper
Got date from IRC log name: 13 Jul 2010
Guessing minutes URL: http://www.w3.org/2010/07/13-aapi-minutes.html
People with action items: cynthia

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.