Hi,
Yes of course, just send it over when ready and Iâll be happy to take a look.
There are a couple of ways that you can do as you wish, and the one you are doing does work if it works as I think it is meant to, where you have a button that pops open a listbox and focus is set into the listbox to select a value, then pressing Enter should save the selected option and set focus back to the button when the listbox is dismissed. Ideally this button should also have aria-expanded on the button to convey that it opens something, and toggle this accordingly which helps on touch devices. In such cases it often helps to have other keystrokes enabled within the listbox, such as Home and End, and the ability to type and jump forward to options that match what is typed as seen within standard native listboxes. Technically aria-haspopup=âlistboxâ can be added too, but this doesnât work right and I donât recommend it at present on buttons for this reason.
The primary difference between this and the use of a combobox role, is where focus resides. For instance if you donât move focus into the listbox and leave it on the button, then it has to have the role of combobox to accept user input within the correct screen reader modality, and in such a case aria-activedescendant must be used to manage selection and all of the keystrokes that control the listbox must be attached to the button that has focus. This allows the user to perform typeahead functionality using a readonly combobox control regardless what it looks like visually. Here is an example of this second type of functionality:
http://whatsock.com/tsg/Coding%20Arena/ARIA%20Comboboxes/ARIA%20Comboboxes%20(Simulated,%20Readonly)/demo.htm
which includes all of the concepts mentioned within the how-to article.
Neither way is right or wrong, just different ways of doing something similar.
All the best,
Bryan
Bryan Garaventa
Accessibility Fellow
Level Access, Inc.
***@LevelAccess.com
415.624.2709 (o)
www.LevelAccess.com
From: Taliesin Smith <***@gmail.com>
Sent: Monday, September 10, 2018 5:23 AM
To: Bryan Garaventa <***@levelaccess.com>
Cc: w3c WAI List <w3c-wai-***@w3.org>
Subject: 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 <***@levelaccess.com<mailto:***@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/
Bryan Garaventa
Accessibility Fellow
Level Access, Inc.
***@LevelAccess.com<mailto:***@LevelAccess.com>
415.624.2709 (o)
www.LevelAccess.com<http://www.levelaccess.com/>
From: Taliesin Smith <***@gmail.com<mailto:***@gmail.com>>
Sent: Friday, September 07, 2018 1:14 PM
To: Bryan Garaventa <***@levelaccess.com<mailto:***@levelaccess.com>>
Cc: w3c WAI List <w3c-wai-***@w3.org<mailto:w3c-wai-***@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
~.~.~
***@colorado.edu<mailto:***@colorado.edu>
Inclusive Design Researcher
PhET Interactive Simulations
https://phet.colorado.edu/en/accessibility
Physics Department
University of Colorado, Boulder
On Sep 7, 2018, at 4:29 PM, Bryan Garaventa <***@levelaccess.com<mailto:***@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.
***@LevelAccess.com<mailto:***@LevelAccess.com>
415.624.2709 (o)
www.LevelAccess.com<http://www.levelaccess.com/>
From: Taliesin Smith <***@gmail.com<mailto:***@gmail.com>>
Sent: Wednesday, September 05, 2018 8:52 AM
To: w3c WAI List <w3c-wai-***@w3.org<mailto:w3c-wai-***@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), 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
