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

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

[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<mailto:dbolter@mozilla.com>>
To: Andi Snow-Weaver/Austin/IBM@IBMUS
Cc: Matthew King/Fishkill/IBM@IBMUS, wai-xtech@w3.org<mailto:wai-xtech@w3.org>, Stefan Schnabel <stefan.schnabel@sap.com<mailto:stefan.schnabel@sap.com>>, david bolter <david.bolter@gmail.com<mailto:david.bolter@gmail.com>>, "Surkov, Alexander" <surkov.alexander@gmail.com<mailto: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<mailto:andisnow@us.ibm.com>>
> To: "david bolter" <david.bolter@gmail.com<mailto:david.bolter@gmail.com>>, dbolter@mozilla.com<mailto:dbolter@mozilla.com>
> Cc: "Matthew King" <mattking@us.ibm.com<mailto:mattking@us.ibm.com>>, wai-xtech@w3.org<mailto:wai-xtech@w3.org>, "Stefan Schnabel" <stefan.schnabel@sap.com<mailto: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<mailto:stefan.schnabel@sap.com>>
> To: Matthew King/Fishkill/IBM@IBMUS, "wai-xtech@w3.org<mailto:wai-xtech@w3.org>"
> <wai-xtech@w3.org<mailto: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 ]
> Sent: Mittwoch, 9. November 2011 23:49
> To: wai-xtech@w3.org<mailto: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<mailto:mattking@us.ibm.com>
>
>
>
> Andi Snow-Weaver/Austin/IBM@IBMUS
> 11/08/2011 12:57 PM
>
> To
> wai-xtech@w3.org<mailto: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