- From: david bolter <david.bolter@gmail.com>
- Date: Tue, 15 Nov 2011 09:44:42 -0500
- 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>
- Message-ID: <CAEO7jQDOK7B+DxBs7_pA+r9-bCu2qk1tbE5GbWEbZQ7YrT_wXA@mail.gmail.com>
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 UTC