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

Hi Alexander,

well just for now just a quick answer. For a in-depth discussion I need to prepare elaborated examples based on the OAA ones.

With "roving" tabindex technique I mean applying it in a concept how to do an ARIA combo:

1) The focus "roves" WITH the item selection using arrow up/down between the list items in the dropdown and will NOT stay in the combo box text field all the time
2) In this sense, the dropdown list content "controls" the updates of the text field and would need therefore an aria-controls reference TO the text field
3) Nevertheless the text field controls may "control" the dropdown visibility, too (you can associate a key handler to open/close with the text field DOM node) and needs therefore also an aria-controls reference (?). The visual arrow down indicator is only an add on for mouse users)

With "roving", you will get better results for this type of ARIA combo with IE8/9. Simply an observation I made in tests. 

In addition, suppose you want to execute additional keyboard operations on a list item (e.g. open an ARIA tooltip associated with it). Key Handlers could be written easier if you address this directly to the event handler for the list item actually focused. You even may include entire objects with their own focus handling as part of the list, and I believe the Job for AT will be easier when these items really have the physical focus instead of tricky JS routing code does mimic this.

But I see also use cases for combos where focus remains in the edit field (e.g. combos with static content). Seems that we have to define in APG a more granular design pattern for different types of combos.

Regards
Stefan



-----Original Message-----
From: Alexander Surkov [mailto:surkov.alexander@gmail.com] 
Sent: Mittwoch, 16. November 2011 10:42
To: Schnabel, Stefan
Cc: david bolter; Joseph Scheuhammer; Larry Weiss; Matthew King; Cynthia Shelly; Andi Snow-Weaver; David Bolter; wai-xtech@w3.org
Subject: Re: Bug 14320 as discussed in Re: [aapi] UAI TF Meeting Minutes, November 8, 2011

Hi, Stefan.
What do you mean by "roving" tabindex technique (together with
aria-controls) should be better supported in FF also."

Thanks.
Alex.


On Wed, Nov 16, 2011 at 5:06 PM, Schnabel, Stefan
<stefan.schnabel@sap.com> wrote:
> David,
>
>
>
> The real issue regarding combo but also grid is that developers are not
> willing to implement workarounds.
>
>
>
> When they try to implement the ARIA spec, they choose ONE of the techniques
> (aria-activedescendant OR "roving" tabindex)
>
> and expect then that ALL USER AGENTS fully support BOTH techniques
> (aria-activedescendant AND "roving" tabindex technique).
>
>
>
> IMHO this is actually not the case (IE favors "roving" tabindex technique).
>
>
>
> I don't think this is a good situation and vote for that "roving" tabindex
> technique (together with aria-controls) should be better supported in FF
> also.
>
>
>
> As Alexander Surkov said:
>
>
>
>>>. The focus is a concept very well
>
>>> supported by ATs and it looks AT are happy with this approach
>
>
>
> The strange thing is that the oaa combo examples (e.g,
> http://oaa-accessibility.org/example/9/) behave differently with IE9/Jaws 12
> and FF6/Jaws 12.
>
> This must not be the case. Really. I'm looking for an answer why this
> happens.
>
>
>
> Best Regards
>
> Stefan
>
>
>
> From: david bolter [mailto:david.bolter@gmail.com]
> Sent: Dienstag, 15. November 2011 20:39
> To: Joseph Scheuhammer
> Cc: Larry Weiss; Matthew King; Alexander Surkov; Cynthia Shelly; Andi
> Snow-Weaver; David Bolter; Schnabel, Stefan; wai-xtech@w3.org
>
> Subject: Re: Bug 14320 as discussed in Re: [aapi] UAI TF Meeting Minutes,
> November 8, 2011
>
>
>
> I reply on one bit inline, down near the "practical error" part:
>
> On Tue, Nov 15, 2011 at 12:23 PM, Joseph Scheuhammer <clown@alum.mit.edu>
> wrote:
>
> All:
>
> This thread began as a comment by Matt King that he hasn't found a useable
> ARIA combobox.  The general feeling is, I think, that this is related to the
> use of aria-activedescendant, and how it affects focus.
>
> IMHO, the current example of the autocomplete combobox suggests that there
> is a subtle difference in the meaning of aria-activedescendant compared to
> its original purpose.  Using Larry's concept of "perceived focus", let me
> try to flesh that out.
>
> Consider another common example where one might use aria-activedescendant:
>  a grid.  As the user arrows around the grid, a cell is visually marked with
> a focus ring to show the user which one has focus.  And, the user perceives
> that cell as focussed.  Under the hood, however, DOM focus is on the grid
> container element and remains there.  The code tracks the cell that the user
> has navigated to, and styles it to appear as if it has focus.
>
> This case is what aria-activedescendant was designed for.  Instead of using
> the roving tabindex technique, where DOM focus *is*moved among the cells,
> DOM focus stays on a parent container, and it keeps track of the perceived
> focus using aria-activedescendant.
>
> Compare that with the autocomplete combobox example.  For me (and maybe it
> is just me) perceived focus stays on the text input always.  I don't
> perceive focus ever moving to the list even when using up and down arrows.
>  The input caret is clearly blinking in that text field, and I know that if
> I type any characters, they will end up there.  The highlighting of list
> items with up/down arrows is undoubtedly useful feedback, but I don't
> perceive focus moving to the highlighted item.
>
> Perhaps it is a practical error to use aria-activedescendant in this case.
>  Since highlighting list items is extra information, perhaps it is better
> handled by an aria-controls relationship.
>
> I think this might be right. Perhaps we should advocate that aria-AD not be
> used in these cases and  in addition to your suggestion of an aria
> relationship perhaps a polite live region could help.
>
> D
>
>
>
>  By way of comparison, consider a tabbed pane.  Here, the DOM focus and the
> perceived focus remains on the tabs as the user navigates among them, but
> the visible tab-panel keeps switching according to which tab has focus.
>  Users do not perceive the tab-panel as the focussed object (if
> aria-activedescendant were used), rather, they see it as the relevant panel
> associated with the tab that currently has focus (the object identified by
> aria-controls).
>
> Is a combobox more like a tabbed pane, or more like the grid example?
>
>

Received on Wednesday, 16 November 2011 10:51:56 UTC