Re: Guide for Combobox

Hi Bryan,
I changed the subject line to "Guide for Combobox" to reflect the change in topic.

We followed a combination of approaches including your the Level Access article about changes to combobox role.

Our combobox is not fully implemented yet. I can share it when it is working, but not sure when that will be.

I think the main difference from your guidance is that we used a button with a dynamic label, so the selected item is read out on focus. We have a list of “Solutes” and we want both the name of the list “Solutes” and the selected solute to be read out on focus. The read out on focus might be something like, “Solutes, pop-up button, Drink Mix, selected.”

I don’t have an interactive example handy, but I think our html code will be something like what I have below. I removed the role combobox and am just using a button, but maybe we should re-look at this approach when we are ready to for full implementation.

There are two aria-labelledby id in order to get both the name of the list and the selected item read out on focus.
<div tabindex="-1 <>" id="container-4-59-414-303-307 <>">
 <span id="listbox5-static-label <>">Solute</span>
 <button id="listbox5-dynamic-label <>" tabindex="0 <>" aria-haspopup="listbox <>" aria-labelledby="listbox5-static-label listbox5-dynamic-label <>">Drink Mix</button>
</div>
  <ul role="listbox <>" tabindex="-1 <>" id="listbox5 <>" aria-activedescendant="listbox5-1 <>" aria-labelledby="listbox5-static-label <>" style="list-style:none; <>">
   <li role="option <>" id="listbox5-1 <>" class="selected <>" aria-selected="true <>">Drink mix</li>
   <li role="option <>" id="listbox5-2 <>">Cobalt (II) nitrate</li>
   <li role="option <>" id="listbox5-3 <>">Cobalt Chloride</li>
   <li role="option <>" id="listbox5-4 <>">Potassium dichromate</li>
   <li role="option <>" id="listbox5-5 <>">Gold (III) chloride</li>
   <li role="option <>" id="listbox5-6 <>">Potassium chromate</li>
   <li role="option <>" id="listbox5-7 <>">Nickel (II) chloride</li>
   <li role="option <>" id="listbox5-8 <>">Copper sulfate</li>
   <li role="option <>" id="listbox5-9 <>">Potassium permanganate</li>
   <li role="option <>" id="listbox5-10 <>">Potassium dichromate</li>
  </ul>
Taliesin


> On Sep 8, 2018, at 9:12 PM, Bryan Garaventa <bryan.garaventa@levelaccess.com> wrote:
> 
> No problem, if I may ask, which guidance were you using where you were not able to get the combobox role to work?
>  
> If you follow this guidance, it does result in an accessible combobox.
> https://www.levelaccess.com/differences-aria-1-0-1-1-changes-rolecombobox/ <https://www.levelaccess.com/differences-aria-1-0-1-1-changes-rolecombobox/>
>  
>  
>  
> Bryan Garaventa
> Accessibility Fellow
> Level Access, Inc.
> Bryan.Garaventa@LevelAccess.com <mailto:Bryan.Garaventa@LevelAccess.com>
> 415.624.2709 (o)
> www.LevelAccess.com <http://www.levelaccess.com/>
>  
> From: Taliesin Smith <talilief@gmail.com> 
> Sent: Friday, September 07, 2018 1:14 PM
> To: Bryan Garaventa <bryan.garaventa@levelaccess.com>
> Cc: w3c WAI List <w3c-wai-ig@w3.org>
> Subject: Re: Role Application - is a parent containing element required?
>  
> Thanks Bryan,
> Thanks for this recommendation about not combining two custom widgets under one parent application. I had not thought to do that until I read the Using ARIA guidance more carefully.
>  
> To clarify our approach we only use application role to create interactions that don’t map to native HTML or ARIA roles, and we implement these custom interactions with a non-semantic elements such as a div.
>  
> Regarding, “aria-activedescendant”, it is not relevant for the draggable "Chemistry book”, but it would be relevant to any combobox interaction we may create. You got me thinking there because we couldn’t make the combobox role to work, so we used a pop-up button and a listbox role.
>  
> Regardless, you think a single div without a parent is not a problem for focus, and our code does indeed work, though needs more vigorous testing.
>  
> Thanks folks,
> Taliesin
>  
> ~.~.~
> Taliesin.Smith@colorado.edu <mailto:Taliesin.Smith@colorado.edu>
> Inclusive Design Researcher
> PhET Interactive Simulations
> https://phet.colorado.edu/en/accessibility <https://phet.colorado.edu/en/accessibility>
> Physics Department
> University of Colorado, Boulder
> 
> 
> On Sep 7, 2018, at 4:29 PM, Bryan Garaventa <bryan.garaventa@levelaccess.com <mailto:bryan.garaventa@levelaccess.com>> wrote:
>  
> Hi,
> This particular markup should be fine, since the application role does support focusability in addition to aria-activedescendant to simulate internal focus when needed.
>  
> I don’t recommend combining multiple interactive widgets within each other however, because the more you complicate the user interactions the more likely it is that end users will not be able to correctly understand what is required to use them.
>  
> Going back to your general question about role=application on interactive widgets, this is only allowed when the focusable element does not have its own native role, such as on a div or span that has no native semantics.
>  
> If, however, role=application is applied to native interactive elements like buttons, links, and editable or selectable form fields, then this will cause critical accessibility issues and will likely break the widget for end users because the explicit role will destroy the native mapping for that control in the accessibility tree.
>  
>  
>  
> Bryan Garaventa
> Accessibility Fellow
> Level Access, Inc.
> Bryan.Garaventa@LevelAccess.com <mailto:Bryan.Garaventa@LevelAccess.com>
> 415.624.2709 (o)
> www.LevelAccess.com <http://www.levelaccess.com/>
>  
> From: Taliesin Smith <talilief@gmail.com <mailto:talilief@gmail.com>> 
> Sent: Wednesday, September 05, 2018 8:52 AM
> To: w3c WAI List <w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org>>
> Subject: Role Application - is a parent containing element required?
>  
> Hi Folks,
> In the Using ARIA documentation (https://www.w3.org/TR/using-aria/#using-application <https://www.w3.org/TR/using-aria/#using-application>), it says that the role="application" should be placed on the "closest containing element" of your widget or widgets. 
>  
> I am specifically refering to the paragraph that says, 
> "Put it on the closest containing element of your widget, for example, the parent div of your element that is your outer most widget element. If that outer div wraps only widgets that need the application interaction model, this will make sure focus mode is switched off once the user tabs out of this widget."
>  
> My question is it ok to place it on the interactive element itself? Or will not having a parent div affect how screen reader software manages focus mode when the user tabs off of the widget?
>  
> Here’s a code snippet that is working nicely:
> <div tabindex="0" id="283-347-553-367" aria-label="‪Chemistry book" role="application" aria-roledescription="move in four directions">‪Chemistry book</div>
> <!-- On-demand help text -->
> <p description-283-347-553-367>Use arrow keys, or letter keys W, A, S, or D to move book or zoomed-in book up, left, down, or right.</p>
>  
> Note that we added an explicit aria-label to get all screen readers to read out the name of the widget.
>  
> Or is mark-up with an actual explicit application parent better? And  if so, how do we get an accessible name description read out. Would it be something like this:
>  
> <div id="283-347-553-367" role="application">‪
>                 <div tabindex=“0" aria-roledescription="move in four directions">Chemistry book</div>
> </div>
>  
> And I have a second question regarding multiple interactive widgets:
> We actually have two interactive elements, a Chemistry book and a Zoomed-in Chemistry book, perhaps it would be better to have both interactive elements within the same div that has the role="application"? Currently, we are implementing them seperately, each with their own application role?
>  
> We are role=“application” for these interactive items because they can be dragged in 4 directions, and no native HTML elements or ARIA roles do that.
>  
> Any thoughts are much appreciated.
> Taliesin Smith