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

Andi,

>>  The focus is kept inside of autocomplete textbox when user operates with items of autocomplete menu

This is the catch and root cause for different FF and IE behavior.

I think IE presumes that physical focus is always on (menu) items in an open "dropdown".
Anyway, we believe that this is the right approach to go also for Matt's combo issue.

It is beside of my knowledge how IE treats activedescendant. Its documented:

http://msdn.microsoft.com/en-us/library/windows/apps/hh465692%28v=vs.85%29.aspx

but I doubt that IE9 does support the concept at all. Please prove me wrong.



-   Stefan


From: Andi Snow-Weaver [mailto:andisnow@us.ibm.com]
Sent: Donnerstag, 10. November 2011 15:56
To: david bolter; dbolter@mozilla.com
Cc: Matthew King; wai-xtech@w3.org; Schnabel, Stefan
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

[cid:image001.gif@01CC9FC3.0DDAE470]"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]
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