Re: Combobox value property follow-up

We talked about 2 issues relating to comboboxes in the call yesterday but my recollection of the discussion was not that there was any intention to remove the ability to have a child element representing the value. Was this a part of https://www.w3.org/2022/04/07-aria-minutes.html#t05 or https://www.w3.org/2022/04/07-aria-minutes.html#t08 from the agenda?
________________________________
From: Bryan Garaventa <bryan.garaventa@levelaccess.com>
Sent: Friday, April 8, 2022 11:32 AM
To: ARIA <public-aria@w3.org>
Subject: Combobox value property follow-up


Hi,

I wanted to follow up on our discussion from yesterday about the combobox design pattern and how this maps to a value property assignment. This is specific to simulated comboboxes that do not consist of a native input element.



Of concern to me was the assertion that anything that did not represent a proper value within the combobox container was an “author error” and that a statement to this effect would be included in the spec. By the nature of a simulated combobox, there are so many possible variations of this type of functionality that saying something like this is not just short-sighted, but also extremely limiting.



Here are two examples of this that, according to what I heard yesterday, are not valid implementations.



Simulated readonly: https://whatsock.com/Templates/Comboboxes/Simulated,%20Readonly/index.htm



Simulated readonly with multiselect: https://whatsock.com/Templates/Comboboxes/Simulated,%20Readonly%20Multiselect/index.htm



Rather than saying that these should be standard buttons and just move focus into a listbox, the value of a combobox design pattern is that it handles situations where the focus is meant to stay on the triggering element and not move away from that element. This cannot be achieved by a standard button because there is no way to preserve the correct browse modality during interaction without resorting to inadvisable hacks.



The basic example given during the call does work as expected, such as the following:



<div id="lbl">Choose your language:</div>

<div role="combobox" aria-labelledby="lbl" aria-readonly="true" tabindex="0" id="test">English</div>



The name is properly assigned, and the value property is set to the content in the accessibility tree.



In the case of the second live example above though, for the multiselect combobox, the value is not meant to be the content of the combobox, which acts instead as a filter for an external list of selected options.



I’m not saying that the value property should be changed or not included as a result of this type of implementation, but rather, that it is folly to say in the spec that anything that does not conform to a limited view of what the syntax of a combobox should be is “author error”.



All the best,

Bryan





Bryan Garaventa

Principal Accessibility Architect

Level Access, Inc.

Bryan.Garaventa@LevelAccess.com<mailto:Bryan.Garaventa@LevelAccess.com>

415.624.2709 (o)

www.LevelAccess.com<http://www.levelaccess.com/>