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: david bolter <david.bolter@gmail.com>
Date: Tue, 15 Nov 2011 09:44:42 -0500
Message-ID: <CAEO7jQDOK7B+DxBs7_pA+r9-bCu2qk1tbE5GbWEbZQ7YrT_wXA@mail.gmail.com>
To: Larry Weiss <lweiss@microsoft.com>
Cc: Joseph Scheuhammer <clown@alum.mit.edu>, Cynthia Shelly <cyns@microsoft.com>, Andi Snow-Weaver <andisnow@us.ibm.com>, David Bolter <dbolter@mozilla.com>, Matthew King <mattking@us.ibm.com>, Stefan Schnabel <stefan.schnabel@sap.com>, "Surkov, Alexander" <surkov.alexander@gmail.com>, "wai-xtech@w3.org" <wai-xtech@w3.org>
Haha!

It helps thanks. I guess the key here is to ensure the (non-parent-child)
sibling relationship, and that we don't allow aria-activedescendant on an
edit field.

D

On Tue, Nov 15, 2011 at 3:26 AM, 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 14:45:20 GMT

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