- From: Schnabel, Stefan <stefan.schnabel@sap.com>
- Date: Wed, 16 Nov 2011 09:06:43 +0100
- To: david bolter <david.bolter@gmail.com>, Joseph Scheuhammer <clown@alum.mit.edu>
- CC: Larry Weiss <lweiss@microsoft.com>, Matthew King <mattking@us.ibm.com>, Alexander Surkov <surkov.alexander@gmail.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>
- Message-ID: <8EA44C66E2911C4AB21558F4720695DC5F7633417A@DEWDFECCR01.wdf.sap.corp>
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<mailto: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 08:07:28 UTC