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



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