19:03:02 RRSAgent has joined #aapi 19:03:02 logging to http://www.w3.org/2011/04/14-aapi-irc 19:03:21 zakim, this will be aapi 19:03:21 ok, Andi, I see Team_(aapi)19:00Z already started 19:03:29 rrsagent, make logs public 19:03:37 rrsagent, make log world 19:03:46 scribe: Andi 19:04:05 Meeting: AAPI 19:04:18 chair: Cynthia 19:04:44 richardschwerdtfe has joined #aapi 19:05:08 +Rich 19:05:21 Zakim, who is on the phone? 19:05:21 On the phone I see Andi_Snow-Weaver, [Apple], [Microsoft], ??P5, Rich 19:05:22 [Apple] has jcraig 19:05:54 Zakim, ??P5 is Larry 19:05:54 +Larry; got it 19:06:02 Zakim, Microsoft has Cynthia 19:06:02 +Cynthia; got it 19:06:19 Zakim, who is on the phone? 19:06:19 On the phone I see Andi_Snow-Weaver, [Apple], [Microsoft], Larry, Rich 19:06:21 [Microsoft] has Cynthia 19:06:21 [Apple] has jcraig 19:06:28 http://www.w3.org/WAI/PF/aria-implementation/#keyboard-focus_aria-activedescendant 19:08:10 topic: aria-activedescendant issue 19:08:38 bullet 5 says UA must change aria-activedescendant in the DOM if AT changes focus 19:09:16 JC: aria-activedescendant is a work around for focus because the container actually has DOM focus 19:09:49 LW: there is a difference between DOM focus and application platform focus with aria-activedescendant 19:09:56 JC: not all AT works that way 19:10:29 LW: part of the problem - editorial note in this section that platform differences should be allowed 19:10:56 CS: in the case where AT modifies focus via the accessibility API, important to keep aria-activedescendant in sync 19:11:08 CS: where AT modifies the DOM, less of a concern 19:11:24 JC: AT should not be modifying the DOM without telling the application 19:11:45 JC: browser is modifying the DOM on behalf of the AT which it doesn't do in any other case 19:11:53 JC: app would have to poll for changes 19:12:11 JC: if user changes focus, browser just sends keyboard events and application modifies the DOM 19:12:39 LW: what about a simpler case where user is modifying moving from control to control? 19:12:51 JC: only the focus is changing, not any of the DOM element information 19:13:43 back to aria-activedescendant 19:14:01 LW: parent sets aria-activedescendant and sets platform focus 19:14:25 LW: voice reco application could be moving focus to a particular element 19:14:34 JC: no way to do that with current web standards 19:15:01 JC: user interface independence proposal will fix this eventually but that's not a reason to break current behavior 19:15:17 RS: HTML working group members don't want to have AT directly manipulating DOM 19:15:39 RS: Nuance could generate keyboard input to do the same thing - don't have to use accessibility API 19:15:58 RS: discussion of removing mutation events totally from the spec 19:16:08 RS: James has drafted a proposal 19:16:35 RS: does not modify aria-activedescendant - have device independent event 19:16:56 JC: browser will send event to web application which will then change aria-activedescendant 19:17:18 JC: doesn't exist yet but bullet #5 will break the way web applications work today 19:18:18 LW: a platform focus event is coming into the browser so what does the browser do about it? 19:18:41 LW: should the browser generate a click event to simulate it? 19:19:32 JC: when AT fires focus event, browser will get it, UAIG says browser modifies the DOM directly which is not done in any other case 19:20:19 LW: proposing alternative: browser send a click event to fulfil the need of the AT being able to change focus 19:20:29 JC: but that's a click event, not a focus event 19:20:41 JC: not the same as a focus event 19:21:06 LW: so what can be done today without the future device independent event? 19:21:38 LW: if we take this section out of the UAIG, AT can take an action that the browser has no defined response for 19:21:54 RS: ATs can generate a click, down arrow, etc. 19:22:11 LW: there are some platforms where you cannot synthesize user actions like that 19:22:33 LW: Linux does not allow you to synthesize input 19:22:44 JC: using term "focus" in different ways 19:23:08 LW: two types of focus are diverging because of aria-activedescendant 19:23:25 JC: most of the time they are the same except for one of these managed focus widgets 19:24:13 JC: on Apple APIs, we have AT focus (Voiceover cursor) 19:24:24 desktop focus and DOM focus are always kept in sync 19:24:59 JC: Apple has keyboard focus on the element with aria-activedescendant 19:25:20 LW: on Windows, keyboard focus matches where the user thinks focus is 19:25:48 JC: depends on how the focus ring is drawn 19:26:20 LW: on Windows, keyboard focus, desktop focus, and user perception of focus are all on the descendant 19:26:29 LW: DOM focus is on the parent container 19:27:22 JC: keyboard focus means the element that will receive the keyboard events 19:28:37 LW: keyboard users are very sensitive to precisely what element the focus appears to be on 19:29:00 JC: difficult to define in spec ready language in a programmatically determinable way 19:29:18 JC: issue is that browser or AT should not modify any DOM properties without application's knowledge 19:30:30 LW: 4.3 is about WHEN focus events are received from AT - so what do we tell browsers to do? 19:30:38 LW: can't say don't do it because it's going to happen 19:30:51 JC: would recommend ATs don't do that 19:31:02 LW: but ATs will do what they will do 19:31:29 JC: implementation refers to both UA and AT - even if AT sends events, browser should ignore it 19:31:57 JC: because there is no way for the web application to know this has happened 19:32:32 JC: probably won't work anyway because web application is going to think something different has focus 19:32:47 LW: can't tell ATs not to do this because they are doing it 19:32:59 LW: in some cases, it is a platform constraint - they have no alternative 19:33:09 f they dodefaultaction on a child of an aria-activedescendant container, we will update the attribute indirectly because we turn around and simulate a mouse click which the web dev listens to and updates via. 19:33:09 [2:30pm] richardschwerdtfeger: If the assistive technology sets focus to a descendant of a container with aria-activedescendant, change the value of aria-activedescendant to point to that item. 19:33:10 [2:30pm] davidb: the web dev updates aria-activedescendant. perios. otherwise == can of worms. 19:33:10 [2:30pm] davidb: clown knows this stuff well also. 19:33:10 [2:31pm] davidb: that statement sounds like it belongs in best practices not UAIG 19:33:13 [2:31pm] davidb: (the one you just pasted) 19:34:13 JC: click event is an acceptable stop gap solution in the meantime 19:35:32 JC: thought this wouldn't work on Linux because you can't simulate events 19:35:53 s/thought this wouldn't/thought Larry said this wouldn't 19:35:59 LW: browser on Linux can simulate an input event; AT just can't do it. 19:36:03 s/thought this wouldn't/thought Larry said this wouldn't/ 19:36:52 RS: in 4.3, tell ATs to send a click, not a focus change 19:36:52 s/click event is an acceptable stop gap solution in the meantime/simulating an event (DOMActivate or click?) is probably an acceptable stop gap solution in the meantime/ 19:37:15 LW: but what is the recommendation if they do send a focus change? 19:37:42 RS: surprised if ATs are using the API. Think they are probably sending click or keypress events 19:38:17 PROPOSAL: Change the following from: "If the assistive technology sets focus to a descendant of a container with http://www.w3.org/WAI/PF/aria/states_and_properties#aria-activedescendant, change the value of http://www.w3.org/WAI/PF/aria/states_and_properties#aria-activedescendant to point to that item." 19:38:28 RS: if browser gets focus change, browser should send default action to web app which is probably a click 19:39:58 PROPOSAL: Change to: "If the assistive technology fires a desktop API focus event to a descendant of a container with aria-activedescedant, the browser MAY simulate a DOMActivate event on the descendant element. 19:40:57 PROPOSAL: Change to: "If the assistive technology fires a desktop API focus event to a descendant of a container with aria-activedescedant, the browser MAY simulate a activation event on the descendant element. 19:44:31 JC: clicking a button and focusing a button do very different things 19:45:04 JC: if the element is a toolbar, and we have a SHOULD here, then the buttons will all get activated when they get focus 19:45:25 LW: but if it says MAY, user agents can choose not to do it 19:45:35 JC: in some cases they shouldn't do it 19:46:12 JC: until we have the device independent events, we can do the best we can but we can't hack it so it will break implementations 19:47:02 LW: there are some circumstances where it is not appropriate NOT to do it 19:47:23 JC: can we spec out some cases where it should be done and some where it should not be done 19:47:58 JC: will have to go through all of the roles to determine the exclusions and then we can make it a SHOULD requirement 19:49:07 action: james to make a proposal on what roles should be excluded 19:50:57 SHOULD not fire an activation event on button, link, menuitem, menuitemcheckbox, menuitemradio 19:52:43 SHOULD fire an activation event on listitem, radio, option 19:53:05 Not sure about gridcell, columnheader, rowheader, or row 19:53:19 SHOULD NOT fire an activation event on button, link, menuitem, menuitemcheckbox, menuitemradio 19:54:44 discussion about Larry's proposed changes to section 4.2 19:55:35 LW: bullet 3 - Wouldn’t it be better to fire a desktop focus event for the element with DOM focus (or it’s active descendant)? 19:56:02 RS: you can assuming the application hasn't already moved the activedescendant 19:56:10 RS: app should take precedence over the AT 19:58:55 LW: aria-activedescendant element got deleted, parent may get deleted, so needs to be generic 19:59:09 -Larry 20:00:22 JC: should be an error condition - if something has happened to the container, browser shouldn't fire a focus event on some other element 20:00:49 RS: think the UA should ignore it 20:01:33 -Andi_Snow-Weaver 20:01:34 -[Microsoft] 20:01:34 -[Apple] 20:01:36 -Rich 20:01:36 Team_(aapi)19:00Z has ended 20:01:38 rrsagent, make minutes 20:01:38 I have made the request to generate http://www.w3.org/2011/04/14-aapi-minutes.html Andi 20:01:38 Attendees were Andi_Snow-Weaver, jcraig, Rich, Larry, Cynthia 21:26:40 jcraig has left #aapi 21:34:53 Zakim has left #aapi