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 09:42:14 UTC