- From: James Nurthen <james.nurthen@oracle.com>
- Date: Fri, 12 Feb 2016 16:56:24 -0800
- To: public-aria@w3.org
- Message-ID: <56BE7F38.60506@oracle.com>
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