W3C home > Mailing lists > Public > wai-xtech@w3.org > November 2011

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

From: Alexander Surkov <surkov.alexander@gmail.com>
Date: Wed, 16 Nov 2011 17:41:46 +0800
Message-ID: <CA+epNsci3R=YcLM55TDh=ETSzGtYCc8Lb=Gj28BnRDLVuxXynw@mail.gmail.com>
To: "Schnabel, Stefan" <stefan.schnabel@sap.com>
Cc: david bolter <david.bolter@gmail.com>, Joseph Scheuhammer <clown@alum.mit.edu>, Larry Weiss <lweiss@microsoft.com>, Matthew King <mattking@us.ibm.com>, Cynthia Shelly <cyns@microsoft.com>, Andi Snow-Weaver <andisnow@us.ibm.com>, David Bolter <dbolter@mozilla.com>, "wai-xtech@w3.org" <wai-xtech@w3.org>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 13:16:12 GMT