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

Right. But this logic should be implemented by someone, either by
browser or by AT. It appears the amount of ATs is bigger than browsers
and each of them should invent the wheel. If browser would take care
to map this into focus concept then ATs should be a little bit
happier.

Alex.


On Wed, Nov 16, 2011 at 12:03 AM, Larry Weiss <lweiss@microsoft.com> wrote:
> Joseph, I agree the screen reader *should* behave the way you describe. But
> a screen reader isn't restricted to reading just the focused element, and a
> "smart" one will note and report the edit field update at the focus, *and*
> the non-focused list item update.
>
> Larry.
> [From my Windows Phone]
> ________________________________
> From: david bolter
> Sent: 11/15/2011 6:52 AM
> To: Alexander Surkov
> Cc: Larry Weiss; Joseph Scheuhammer; Cynthia Shelly; Andi Snow-Weaver; David
> Bolter; Matthew King; Stefan Schnabel; wai-xtech@w3.org
> Subject: 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) -
>> >
>> >
>
>

Received on Tuesday, 15 November 2011 15:30:52 UTC