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

Right. You've described the devious case well here. I see this is a problem
even with a sibling relationship between the list and the edit field.

D
On Tue, Nov 15, 2011 at 4:42 AM, Alexander Surkov <
surkov.alexander@gmail.com> wrote:

> 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) -
> >
> >
>