Re: ACTION-1490 proposal says good bye to the "inline" notion for combobox

Cynthia,
Here is an example.
http://jdevadf.oracle.com/adf-richclient-demo/faces/components/inputComboboxListOfValues.jspx

The Component has a list where you can select data from a grid (note: we 
should change this to table in the future now we have an aria role of 
table) as well as a search link which takes you to a dialog where you 
can do a more complex search.

Regards,
James

On 2/12/2016 4:45 PM, Cynthia Shelly wrote:
>
> Sorry I’m late to the thread. I’ve been digging through this, HTML 5 
> datalist, and some implementation discussions with my team.
>
> Bryan raises some good points.
>
> Opening a dialog from a combobox seems bizarre to me. Do you have an 
> example of a UI that does that? To me, that’s not a combobox. That’s 
> (maybe) a button that opens a dialog. A combobox is a <em>combo</em> 
> of a text <em>box</em> and a list.  Sometimes, they’re read-only, like 
> the HTML Select element.  I can sort of see the grid and tree as 
> extensions of that model, but not dialog.
>
> Search autocompletes sometime use aria-controls with 
> aria-activedescendant (often aria-owns too). I don’t see why this is a 
> problem.
>
> A modal combobox also seems bizarre to me. A combobox is a fairly 
> simple control. When you tab out of one, it closes, and you go to the 
> next control on the page. This has been true since the earliest 
> versions of Windows (I assume other platforms too). Why does it 
> suddenly need to be modal?
>
> On the auto-complete question, I think the most confusing thing is 
> that we’re using the term auto-complete for two very different things. 
> Autocomplete=inline is an automatic completion of the text being 
> typed. Autocomplete=list is something that we call an “auto-suggest.” 
> They often coexist, but they don’t have to, and they’re quite 
> different. What if we took a page from the html5 book, and had 
> something similar the this @list attribute pointing to the datalist.  
> This is similar to aria-controls (we actually map it to the same thing 
> in UIA) but is more clear from an authoring perspective. So, you could 
> have something like this
>
> <div role=textbox content-editable=true aria-autosuggest=foo></div>
>
> <div id=foo role=listbox>
>
> <div role=listitem>
>
> …
>
> </div>
>
> That’s pretty much the same as
>
> <input type=text list=foo>
>
> <datalist id=foo>
>
> <option>
>
> …
>
> </datalist>
>
> We could call it aria-autosuggest or aria-list. Thoughts?
>
> *From:*Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com]
> *Sent:* Thursday, February 11, 2016 1:37 PM
> *To:* Rich Schwerdtfeger <richschwer@gmail.com>; Joseph Scheuhammer 
> <clown@alum.mit.edu>
> *Cc:* Matt King <mck@fb.com>; ARIA Working Group <public-aria@w3.org>
> *Subject:* RE: ACTION-1490 proposal says good bye to the "inline" 
> notion for combobox
>
> “Here "descendants" means either a DOM descendant of the container, or 
> one referenced by aria-owns.  This procedure won't succeed for 
> combobox containers if aria-controls is used instead of aria-owns.”
>
> This is the part that is confusing me, because it already works, I’ve 
> tested this in IE11, Firefox, Chrome using JAWS and NVDA and it works 
> accessibly, and the same implementation is accessible in iOS using 
> VoiceOver in Safari.
>
> I get that in the browser you are referring to the mappings, but the 
> web is a weird place, and there are many instances that involve 
> relationships like this that are not necessarily good to represent as 
> trapped modals or as requisite children.
>
> E.G a search field that dynamically updates a region of the page as 
> you type into it, that can announce the first result that is matched 
> while also allowing you to use Up/Down to scroll through the results 
> while leaving focus on the search field. The user will not want to be 
> trapped and to be unable to read the rest of the page if they desire to.
>
> This currently works accessibly using the method I’ve described here, 
> but will be practically useless if trapped in the manner you are 
> describing.
>
> So if the implementation I’ve got here is incorrect, regardless that 
> it is already provably accessible, what will changing it accomplish, 
> and what specifically needs to be changed?
>
> I also am having a hard time understanding the relationship of 
> triggering a dialog from a combobox.
>
> E.G If you are typing into a combobox, at what point would you be 
> navigating a dialog? How could you read back what you have typed if 
> focus is then trapped in a dialog?
>
> *From:*Rich Schwerdtfeger [mailto:richschwer@gmail.com]
> *Sent:* Thursday, February 11, 2016 1:03 PM
> *To:* Joseph Scheuhammer <clown@alum.mit.edu <mailto:clown@alum.mit.edu>>
> *Cc:* Bryan Garaventa <bryan.garaventa@ssbbartgroup.com 
> <mailto:bryan.garaventa@ssbbartgroup.com>>; Matt King <mck@fb.com 
> <mailto:mck@fb.com>>; ARIA Working Group <public-aria@w3.org 
> <mailto:public-aria@w3.org>>
> *Subject:* Re: ACTION-1490 proposal says good bye to the "inline" 
> notion for combobox
>
> using aria-activedescendant for aria-controls would be hugely bad. 
> Think live regions where a checkbox controls the content of the live 
> region.
>
> Rich Schwerdtfeger
>
>     On Feb 11, 2016, at 2:10 PM, Joseph Scheuhammer
>     <clown@alum.mit.edu <mailto:clown@alum.mit.edu>> wrote:
>
>     Hi Bryan,
>
>     On 2016-02-11 1:03 PM, Bryan Garaventa wrote:
>
>         The use of aria-controls in this case solves the issue by
>         setting an explicit association, and aria-activedescendant
>         works in identifying the referenced node that is active.
>
>
>     There may still be a problem -- I am investigating.  The Core-AAM
>     describes an algorithm associated with aria-activedescendant that
>     user agents MUST execute in order to mark the potential active
>     descendants as focusable.  In summary, when the user agent
>     encounters a container with an aria-activedescendant attribute,
>     the user agent must visit all descendants of the container and
>     determine if they could be the target of the container's
>     aria-activedescendant.  The user agent must expose a focusable
>     state for each such target, and only for those descendants that
>     are targets.
>
>     Here "descendants" means either a DOM descendant of the container,
>     or one referenced by aria-owns.  This procedure won't succeed for
>     combobox containers if aria-controls is used instead of aria-owns.
>
>     A way to patch this is to run the exact same algorithm but base it
>     on aria-controls if aria-owns is not used.  However, that requires
>     buy-in from all user agents, and tests cases for the ARIA test
>     harness.
>
>         I'm getting confused by the reference to modal dialogs. This
>         isn't a modal dialog, it's a Listbox, and focus is never meant
>         to leave the element that includes role=combobox. So what does
>         the modal dialog have to do with it?
>
>
>     Matt's new definition of combobox includes drop-downs that contain
>     a grid, a treegrid, or a dialog instead of a listbox.  When Rich
>     discussed this with Freedom Scientific, they were willing to
>     handle such cases, but only if the drop-down was modal.  The
>     thread starts here:
>     https://lists.w3.org/Archives/Public/public-aria/2016Feb/0151.html
>
>     -- 
>     ;;;;joseph.
>
>     'Die Wahrheit ist Irgendwo da Draußen. Wieder.'
>                     - C. Carter -
>

-- 
Regards, James

Oracle <http://www.oracle.com>
James Nurthen | Principal Engineer, Accessibility
Phone: +1 650 506 6781 <tel:+1%20650%20506%206781> | Mobile: +1 415 987 
1918 <tel:+1%20415%20987%201918> | Video: james.nurthen@oracle.com 
<sip:james.nurthen@oracle.com>
Oracle Corporate Architecture
500 Oracle Parkway | Redwood Cty, CA 94065
Green Oracle <http://www.oracle.com/commitment> Oracle is committed to 
developing practices and products that help protect the environment

Received on Saturday, 13 February 2016 00:57:06 UTC