Re: Bug 14320 as discussed in Re: [aapi] UAI TF Meeting Minutes, November 8, 2011

Thanks Larry.

Here's a fun tricky case:

In the case where there is an editable field, which has a some text "fo"
followed by a blinking text entry bar, and there is a drop down of
autocompletions such as "foo" "food" "fox"... etc, and in addition to this
it is possible to up and down arrow to move the selection highlight among
the completions, where is visual keyboard focus?

Cheers,
David

On Mon, Nov 14, 2011 at 3:43 PM, Larry Weiss <lweiss@microsoft.com> wrote:

>  A focus on "focus" is key to this discussion, so I want to clarify and
> expand David's definitions:****
>
> ** **
>
> I really like David's definition of "DOM focus": the element the browser
> tells the web developer has focus.  So much that I'd like to rename your
> "Desktop focus" to be "Accessibility API focus", and define it similarly:
> the element the accessibility API tells the application developer has
> focus.  (For this discussion, the application developer is always the web
> browser.)  And there is a third focus that has to be considered for a
> complete discussion is "Keyboard focus".  It can be defined as the element
> that the **user perceives** is receiving keyboard input.  (Note my
> emphasis on user perception, not implementation.)  The "Active child" is
> the element that the aria-activedescendant property points to.  And it
> should also be equivalent to the “Keyboard focus”.****
>
> ** **
>
> Internet Explorer only has to support Windows where the OS and the ATs
> rely on “Accessibility API focus” always equals “Keyboard focus” and there
> is no native support for “active descendant”.  So when
> aria-activedescendant is used, the web browser has to set “Accessibility
> API focus” == “Active child” to meet OS and AT expectations.****
>
> ** **
>
> Firefox **can** have it tougher since it runs on Windows and Linux ATK
> because the operating system rules can be different (and explains David’s
> ambivalence toward aria-activedescendant).  Linux ATK natively supports the
> “active descendant” semantics, but when used the OS and the AT relies on
> “Accessibility API focus” **not equal** to “Active child”.  Since this is
> exactly opposite of Windows, this complicates things for a multi-platform
> browser if it exposes the aria-activedescendant via the native “active
> descendant” support.****
>
> ** **
>
> Since Linux ATK does not **require** use of the native “active
> descendant” semantics, it would be easier to just duplicate the Windows
> semantics since those are “legal” too.  ****
>
> ** **
>
> I don’t have access to the current specs, but last time I saw something,
> there was no specification of the responsibility of the web developers to
> manage “Keyboard focus” when using aria-activedescendant.  Specifically
> that a keyboard handler be added to the element with “DOM focus”, and **
> specifically** what keyboard input must be supported for each type of
> control.  And that specification should be consistent with the native OS
> behavior.****
>
> ** **
>
> Have fun,****
>
> Larry.****
>
> ** **
>
> *From:* david bolter [mailto:david.bolter@gmail.com]
> *Sent:* Monday, November 14, 2011 12:02 PM
> *To:* Joseph Scheuhammer
> *Cc:* Cynthia Shelly; Andi Snow-Weaver; David Bolter; Larry Weiss;
> Matthew King; Stefan Schnabel; Surkov, Alexander; wai-xtech@w3.org
>
> *Subject:* Re: Bug 14320 as discussed in Re: [aapi] UAI TF Meeting
> Minutes, November 8, 2011****
>
> ** **
>
> Hi Joseph,
>
>
> I was talking about the browser firing a desktop accessibility event. E.g.
> EVENT_OBJECT_FOCUS on Windows.
>
> Cheers,
> David****
>
>  On Mon, Nov 14, 2011 at 9:54 AM, Joseph Scheuhammer <clown@alum.mit.edu>
> wrote:****
>
> Hi David,
>
> Regarding your explanation of why aria-activedescendant exitss, there is
> one thing that I need further explanation for.
>
> At a certain point, some ancestor element has DOM focus, (=
> document.activeElement), but one of its children appears visually focussed.
>  You wrote (my emphasis):****
>
> For screen readers the browser accessibility engine can use the semantics
> of aria-activedescedant to indicate what appears focused (*by firing a
> focus event for the active child*).****
>
>
> What kind of focus event is fired for the active child?  Is it a DOM focus
> event?  A desktop focus event?  An a11y API focus event?  Or some
> combination of the above?
>
> Also, what is firing this event?  Is it the browser?
>
> Thanks.****
>
>
>
> --
> ;;;;joseph
>
> 'I had some dreams, they were clowns in my coffee. Clowns in my coffee.'
>                     - C. Simon (misheard lyric) -****
>
> ** **
>