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

Hi All,

Let's consider this question: why does aria-activedescendant exist?

Full disclaimer: I'm not a huge advocate of aria-activedescendant but I've
heard it can be handy for large web app performance. I know there is a lot
of confusion in this area though.

Let me quickly try another stab at explaining things and I hope I don't
make mistakes. Currently, even with ARIA, web developers can put a
container element in the tab navigation order (via tabindex="0" for
example). They can then capture keyboard events and change the styling of
child elements so that they appear to have focus. My understanding is that
we want to allow this practice and for it to be accessible, so we ask these
same web developers to indicate which child elements appear visually to
have focus. They can do this by adding one attribute to the container
element, namely aria-activedescendant. Then it is a matter of updating this
attribute to point to the id of the child element which appears visually
focused. 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).

DOM focus: the element the browser tells web developers has focus.
Desktop focus: I'm not 100% sure this is well defined, but I'll call it the
object that most recently had a related desktop focus event.
Active child/element: the element that aria-activedescendant points to.

Does this help or am I addressing the wrong concerns?

Note: it sounds like we'll be discussing aria-activdescendant
interoperability on the next AAPI call. Yay. :)

Cheers,
David

On Thu, Nov 10, 2011 at 2:05 PM, Cynthia Shelly <cyns@microsoft.com> wrote:

>  Please also include Larry Weiss (copied) in this discussion.****
>
> ** **
>
> *From:* Andi Snow-Weaver [mailto:andisnow@us.ibm.com]
> *Sent:* Thursday, November 10, 2011 7:34 AM
> *To:* David Bolter
> *Cc:* david bolter; 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****
>
>  ** **
>
> David,
>
> Matt reacted to our discussion about bug 14320 as recorded in the minutes
> from Tuesday's UAI TF meeting and Stephan added his thoughts. Since you own
> the bug to follow up with Alexander, I thought you should also consider
> Matt's & Stephan's comments in the resolution.
>
> The minutes may have given Matt the wrong impression about what the spec
> says. On a widget with aria-activedescendant, even though DOM focus stays
> with the parent (the edit field in the case of a combo box), the spec says
> the desktop focus should be on the activedescendant.
>
> It sounds like we have a problem somewhere though if FF and IE
> implementations are causing developers to have to code combo boxes
> differently. That's really not a good thing. The design pattern we document
> in the Authoring Practices Guide should work.
>
> Andi
>
> [image: Inactive hide details for David Bolter ---11/10/2011 09:10:58
> AM---Hi Andi, this thread is new to me and I'm not sure what spec]David
> Bolter ---11/10/2011 09:10:58 AM---Hi Andi, this thread is new to me and
> I'm not sure what specific actions you want us to take here. ?
>
> From: David Bolter <dbolter@mozilla.com>
> To: Andi Snow-Weaver/Austin/IBM@IBMUS
> Cc: Matthew King/Fishkill/IBM@IBMUS, wai-xtech@w3.org, Stefan Schnabel <
> stefan.schnabel@sap.com>, david bolter <david.bolter@gmail.com>, "Surkov,
> Alexander" <surkov.alexander@gmail.com>
> Date: 11/10/2011 09:10 AM
> Subject: Re: Bug 14320 as discussed in Re: [aapi] UAI TF Meeting Minutes,
>  November 8, 2011****
>  ------------------------------
>
>
>
>
> Hi Andi, this thread is new to me and I'm not sure what specific actions
> you want us to take here. ?
>
> Cc'ing Alexander since I don't want to bottleneck.
>
> Aside: Stefan, "aria-activedescendant handling is different in IE and FF"
> concerns me. Perhaps you can send me a direct email about this so we don't
> conflate this thread?
>
> Cheers,
> David
>
> ----- Original Message -----
> > From: "Andi Snow-Weaver" <andisnow@us.ibm.com>
> > To: "david bolter" <david.bolter@gmail.com>, dbolter@mozilla.com
> > Cc: "Matthew King" <mattking@us.ibm.com>, wai-xtech@w3.org, "Stefan
> Schnabel" <stefan.schnabel@sap.com>
> > Sent: Thursday, November 10, 2011 9:56:15 AM
> > Subject: RE: Bug 14320 as discussed in Re: [aapi] UAI TF Meeting
> Minutes, November 8, 2011
> > David,
> >
> > Can you please keep Matt and Stephan in the loop with your
> > investigation into 14320 with Alexander.
> >
> > Matt,
> >
> > Here is the link to bug 14320:
> > http://www.w3.org/Bugs/Public/show_bug.cgi?id=14320
> >
> > If you don't have access to the W3C Bugzilla system, here is the text
> > from the bug as reported by Alexander Surkov:
> >
> > <bug text>
> >
> > Menus as UI control doesn't acquire DOM focus, that makes me think
> > that ARIA
> > menus shouldn't be different. So that if ARIA menu manages the
> > accessible focus
> > by aria-activedescendant then it shouldn't be required to have DOM
> > focus.
> >
> > It seems that part doesn't contradict with
> >
> http://www.w3.org/TR/wai-aria-implementation/#keyboard-focus_aria-activedescendant
> > .
> >
> > However it has inconsistency with setFocus section
> > http://www.w3.org/TR/wai-aria-implementation/#keyboard-focus_at where
> > we are
> > required to set DOM focus on menu that is not focusable, otherwise
> > setFocus is
> > considered as failing.
> >
> > The usecase of this is autocomplete widgets. The focus is kept inside
> > of
> > autocomplete textbox when user operates with items of autocomplete
> > menu, the
> > active item is managed by aria-activedescendant. In order to expose
> > widgets
> > consistently to AT (both native widgets and ARIA widgets) the
> > accessible focus
> > event should be fired on active menuitem.
> >
> > </bug text>
> >
> > Andi
> >
> > Inactive hide details for "Schnabel, Stefan" ---11/10/2011 02:33:39
> > AM---Matt, Many thanks pointing out that, also my major pai"Schnabel,
> > Stefan" ---11/10/2011 02:33:39 AM---Matt, Many thanks pointing out
> > that, also my major pain point currently.
> >
> > From: "Schnabel, Stefan" <stefan.schnabel@sap.com>
> > To: Matthew King/Fishkill/IBM@IBMUS, "wai-xtech@w3.org"
> > <wai-xtech@w3.org>
> > Date: 11/10/2011 02:33 AM
> > Subject: RE: Bug 14320 as discussed in Re: [aapi] UAI TF Meeting
> > Minutes, November 8, 2011
> >
> >
> >
> >
> > Matt,
> >
> > Many thanks pointing out that, also my major pain point currently.
> >
> > IMHO, this is the result of the situation that the focus concept is
> > lugubrious and not clearly communicated and defined
> > for all parties involved (authors, browsers, screen readers).
> >
> > Even worse, aria-activedescendant handling is different in IE and FF.
> > Browser "track switchers" inside JS code are currently the only way to
> > deal with the situation
> > (This is an unreasonable demand for developers for ARIA should be is a
> > COMMON standard).
> >
> > Bad luck. Cries desperately for "normalization" activities.
> >
> > Regards,
> > Stefan
> >
> >
> >
> > -----Original Message-----
> > From: Matthew King [ mailto:mattking@us.ibm.com <mattking@us.ibm.com> ]
> > Sent: Mittwoch, 9. November 2011 23:49
> > To: wai-xtech@w3.org
> > Subject: Bug 14320 as discussed in Re: [aapi] UAI TF Meeting Minutes,
> > November 8, 2011
> >
> > Could someone provide a link to bug 14320?
> >
> > I am intensely interested in the combo box topic.
> >
> > I have not found a single usable ARIA implementation. Occasionally, I
> > find
> > it "possible" to use one, but that is because I have fore knowledge
> > ...
> > too much of it. If the typical user were to attempt, success would be
> > a
> > matter of luck.
> >
> > I have been trying our example implementations with both JAWS and
> > NVDA.
> >
> > Among the worse are those that have a drop down but the focus stays in
> > the
> > edit ... It's really confusing. If the user is scrolling through a
> > list,
> > the focus needs to be in the list. So, I disagree with the statements
> > in
> > the minutes regarding keeping DOM focus in the edit if the user is
> > scrolling through a list.
> >
> > It would be useful to have a set of clear functional descriptions of
> > each
> > type of combo we are trying to make accessible with ARIA markup. Many
> > different behavioral options exist. There may be some that can not be
> > effectively addressed at this time. We need to make sure the most
> > common
> > and necessary cases are well-defined and that usable implentations
> > actually exist. I think this is an extremely important role.
> >
> > Matt King
> > IBM I/T Chief Accessibility Strategist
> > IBM BT/CIO - Global Workforce and Web Process Enablement
> > Phone: (503) 578-2329, Tie line: 731-7398
> > mattking@us.ibm.com
> >
> >
> >
> > Andi Snow-Weaver/Austin/IBM@IBMUS
> > 11/08/2011 12:57 PM
> >
> > To
> > wai-xtech@w3.org
> > cc
> >
> > Subject
> > [aapi] UAI TF Meeting Minutes, November 8, 2011
> >
> >
> >
> >
> >
> >
> > Minutes from today are posted here:
> > http://www.w3.org/2011/11/08-aapi-minutes.html
> >
> > Andi
>
> ****
>