<scribe> scribe: Andi

http://www.w3.org/WAI/PF/aria-implementation/#keyboard-focus_aria-activedescendant

aria-activedescendant issue

bullet 5 says UA must change aria-activedescendant in the DOM if AT changes focus

JC: aria-activedescendant is a work around for focus because the container actually has DOM focus

LW: there is a difference between DOM focus and application platform focus with aria-activedescendant

JC: not all AT works that way

LW: part of the problem - editorial note in this section that platform differences should be allowed

CS: in the case where AT modifies focus via the accessibility API, important to keep aria-activedescendant in sync
... where AT modifies the DOM, less of a concern

JC: AT should not be modifying the DOM without telling the application
... browser is modifying the DOM on behalf of the AT which it doesn't do in any other case
... app would have to poll for changes
... if user changes focus, browser just sends keyboard events and application modifies the DOM

LW: what about a simpler case where user is modifying moving from control to control?

JC: only the focus is changing, not any of the DOM element information

back to aria-activedescendant

LW: parent sets aria-activedescendant and sets platform focus
... voice reco application could be moving focus to a particular element

JC: no way to do that with current web standards
... user interface independence proposal will fix this eventually but that's not a reason to break current behavior

RS: HTML working group members don't want to have AT directly manipulating DOM
... Nuance could generate keyboard input to do the same thing - don't have to use accessibility API
... discussion of removing mutation events totally from the spec
... James has drafted a proposal
... does not modify aria-activedescendant - have device independent event

JC: browser will send event to web application which will then change aria-activedescendant
... doesn't exist yet but bullet #5 will break the way web applications work today

LW: a platform focus event is coming into the browser so what does the browser do about it?
... should the browser generate a click event to simulate it?

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

LW: proposing alternative: browser send a click event to fulfil the need of the AT being able to change focus

JC: but that's a click event, not a focus event
... not the same as a focus event

LW: so what can be done today without the future device independent event?
... if we take this section out of the UAIG, AT can take an action that the browser has no defined response for

RS: ATs can generate a click, down arrow, etc.

LW: there are some platforms where you cannot synthesize user actions like that
... Linux does not allow you to synthesize input

JC: using term "focus" in different ways

LW: two types of focus are diverging because of aria-activedescendant

JC: most of the time they are the same except for one of these managed focus widgets
... on Apple APIs, we have AT focus (Voiceover cursor)

desktop focus and DOM focus are always kept in sync

JC: Apple has keyboard focus on the element with aria-activedescendant

LW: on Windows, keyboard focus matches where the user thinks focus is

JC: depends on how the focus ring is drawn

LW: on Windows, keyboard focus, desktop focus, and user perception of focus are all on the descendant
... DOM focus is on the parent container

JC: keyboard focus means the element that will receive the keyboard events

LW: keyboard users are very sensitive to precisely what element the focus appears to be on

JC: difficult to define in spec ready language in a programmatically determinable way
... issue is that browser or AT should not modify any DOM properties without application's knowledge

LW: 4.3 is about WHEN focus events are received from AT - so what do we tell browsers to do?
... can't say don't do it because it's going to happen

JC: would recommend ATs don't do that

LW: but ATs will do what they will do

JC: implementation refers to both UA and AT - even if AT sends events, browser should ignore it
... because there is no way for the web application to know this has happened
... probably won't work anyway because web application is going to think something different has focus

LW: can't tell ATs not to do this because they are doing it
... in some cases, it is a platform constraint - they have no alternative

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

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

<richardschwerdtfe> [2:30pm] davidb: the web dev updates aria-activedescendant. perios. otherwise == can of worms.

<richardschwerdtfe> [2:30pm] davidb: clown knows this stuff well also.

<richardschwerdtfe> [2:31pm] davidb: that statement sounds like it belongs in best practices not UAIG

<richardschwerdtfe> [2:31pm] davidb: (the one you just pasted)

JC: simulating an event (DOMActivate or click?) is probably an acceptable stop gap solution in the meantime
... thought Larry said this wouldn't work on Linux because you can't simulate events

LW: browser on Linux can simulate an input event; AT just can't do it.

<jcraig> s/thought this wouldn't/thought Larry said this wouldn't/

RS: in 4.3, tell ATs to send a click, not a focus change

LW: but what is the recommendation if they do send a focus change?

RS: surprised if ATs are using the API. Think they are probably sending click or keypress events

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

RS: if browser gets focus change, browser should send default action to web app which is probably a click

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

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

JC: clicking a button and focusing a button do very different things
... if the element is a toolbar, and we have a SHOULD here, then the buttons will all get activated when they get focus

LW: but if it says MAY, user agents can choose not to do it

JC: in some cases they shouldn't do it
... 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

LW: there are some circumstances where it is not appropriate NOT to do it

JC: can we spec out some cases where it should be done and some where it should not be done
... will have to go through all of the roles to determine the exclusions and then we can make it a SHOULD requirement

<scribe> ACTION: james to make a proposal on what roles should be excluded [recorded in http://www.w3.org/2011/04/14-aapi-minutes.html#action01]

<jcraig> SHOULD not fire an activation event on button, link, menuitem, menuitemcheckbox, menuitemradio

<jcraig> SHOULD fire an activation event on listitem, radio, option

<jcraig> Not sure about gridcell, columnheader, rowheader, or row

<jcraig> SHOULD NOT fire an activation event on button, link, menuitem, menuitemcheckbox, menuitemradio

discussion about Larry's proposed changes to section 4.2

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

RS: you can assuming the application hasn't already moved the activedescendant
... app should take precedence over the AT

LW: aria-activedescendant element got deleted, parent may get deleted, so needs to be generic

JC: should be an error condition - if something has happened to the container, browser shouldn't fire a focus event on some other element

RS: think the UA should ignore it

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/thought this wouldn't/thought Larry said this wouldn't/
FAILED: s/thought this wouldn't/thought Larry said this wouldn't/
Succeeded: 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/
Found Scribe: Andi
Inferring ScribeNick: Andi
Default Present: Andi_Snow-Weaver, jcraig, Rich, Larry, Cynthia
Present: Andi_Snow-Weaver jcraig Rich Larry Cynthia
Got date from IRC log name: 14 Apr 2011
Guessing minutes URL: http://www.w3.org/2011/04/14-aapi-minutes.html
People with action items: james

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