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

Hi, Larry.

It doesn't look like the command prompt history navigation example
describes well what happens when the user navigates autocomplete
(editable combobox) list. For autocompletes the caret and DOM focus
stays on text edit when the user navigates through items of the
autocomplete list (for example, if user starts to type characters then
they appear in text edit). That's how it looks visually. From AT user
perspective that shouldn't be different because when the user arrows
up or down through the list (while text edit has DOM focus) then the
user should get information where he is, for example, group
information should be announced.

For that browser should report the accessible focus differently from
DOM focus. So that when user types into text edit then text edit has
the focus, if user navigates through the list then selected list items
receive the focus. That's how screen readers work. Some APIs has
active item concept but I don't think all screen readers rely on it.
Anyway I don't see benefits to treat autocompletes differently from
comboboxes in terms of focus management.

Thanks.
Alex.


On Tue, Nov 15, 2011 at 5:26 PM, Larry Weiss <lweiss@microsoft.com> wrote:
> I think editable combo boxes were invented to test implementation rules!
> <grin>
>
>
>
> The selected item should be a child of the list which is a child of the
> combo box, and the edit field is a sibling to the list.  When the caret is
> present, that should be the (DOM and Accessibility) “focused” sub-element.
> Even though the “Active child” is set to the selected item, since the list
> doesn’t have “DOM focus”, it doesn’t meet the criteria for (Accessibility or
> Keyboard) “focus”.
>
>
>
> And even though “moving” the cursor up or down “feels like” you are moving
> the selection up and down, the result in the edit field isn’t really any
> different than the using the up or down to move through the history in a
> command prompt.
>
>
>
> Since the obvious next “devious example” is the non-editable version…  There
> is no caret in the text field and the “action” is in the list, so “DOM
> focus” should be on the list, and the (Accessibility and Keyboard) focus
> should be on the selected item.
>
>
>
> Does that help?
>
>
>
> From: david bolter [mailto:david.bolter@gmail.com]
> Sent: Monday, November 14, 2011 1:28 PM
> To: Joseph Scheuhammer
> Cc: Larry Weiss; Cynthia Shelly; Andi Snow-Weaver; David Bolter; Matthew
> King; Stefan Schnabel; Surkov, Alexander; wai-xtech@w3.org
>
> Subject: Re: Bug 14320 as discussed in Re: [aapi] UAI TF Meeting Minutes,
> November 8, 2011
>
>
>
> (resending from list approved account)
>
> Here's the bit I was trying to probe on:
>
> LW: The "Active child" is the element that the aria-activedescendant
> property points to.  And it should also be equivalent to the “Keyboard
> focus”.
>
> I just wanted to make sure Larry was on the same page with my example.
>
> Cheers,
> David
>
> On Mon, Nov 14, 2011 at 4:14 PM, Joseph Scheuhammer <clown@alum.mit.edu>
> wrote:
>
> On 11-11-14 4:08 PM, david bolter wrote:
>
> Thanks Larry.
>
> Here's a fun tricky case:
>
> In the case where there is an editable field, which has a some text "fo"
> followed by a blinking text entry bar, and there is a drop down of
> autocompletions such as "foo" "food" "fox"... etc, and in addition to this
> it is possible to up and down arrow to move the selection highlight among
> the completions, where is visual keyboard focus?
>
>
>
> Not tricky enough, or, it's just implicit:  add the fact that any characters
> that the user types are shown in the text field.  Using your example,
> starting with "fo":  if the user types an 'o', the text field becomes "foo"
> followed by a blinking cursor.  Also, left and right arrows move among the
> characters in the text field.  Yet another also, shift+left/right arrows
> select characters in the text field.
>
> Yours in explicitness,
>
> --
> ;;;;joseph
>
> 'I had some dreams, they were clowns in my coffee. Clowns in my coffee.'
>                     - C. Simon (misheard lyric) -
>
>

Received on Tuesday, 15 November 2011 09:42:55 UTC