Listitem in a list as a possible aria-activedescendant ID reference target for combo box role

[stes-acc]

Suppose want to create an ARIA combo box according to the ARIA spec but aria-activedescendant on element with the combo box role points not to an ID of an option in the associated listbox with available option values but to a listitem in a list with available values.

Also, aria-haspopup="dialog" is set instead the typical (implicit) value aria-haspopup="listbox" and the list is put inside the dialog and listitems inside are referenced using aria-activedescendant. This can be easily coded and works interestingly very well e.g. with Jaws/Chrome.

ARIA spec is quiet on this possibility. I want to discuss if listitem in a list as a possible ID reference target of aria-activedescendant in an associated dialog of a combo is allowed or could even be added in future versions of the spec as allowed example.

[scottaohara]

what's the use case for this variant rather than using the expected listbox > option pattern?

Putting aside whether this works or not (which would need further testing), wouldn't including this variant muddle the differences between what a list and listbox and their descendants are meant to represent? I question if this would not introduce confusion in what authors are supposed to do, just so that something that is not expected but 'works' can be called out as well?

[stes-acc]

There is a reason a list is used instead of a listbox. List items in aforementioned example DO contain non-presentational subcontent which excludes listbox role with options.

just so that something that is not expected but 'works' can be called out as well?

Besides, for reasons given, I'd like exactly for this reason clarification on the topic.

[scottaohara]

Thanks @stes-acc. That's a pretty big distinction that was missing from your initial comment - the fact that these list items contain other non-presentational content.

[JAWS-test]

If I understand the ARIA specification correctly, no aria-activedescendant may be used within role=dialog and therefore also not in a combobox with aria-haspopup=dialog.

The dialog may of course contain listitem with interactive elements. But these listitem would not be reachable with arrow keys, but only with tab the interactive elements within the listitem. I don't see any difference between a normal page, a dialog or a dialog that is opened via a combobox. If it is different, the ARIA specification should name that.

If I use a combobox with aria-haspopup=listbox, only one listbox with option should be allowed and no listitems.

[stes-acc]

If I understand the ARIA specification correctly, no aria-activedescendant may be used within role=dialog

Hm. is this explicitely forbidden or just not mentioned as a possibility in the spec?

But these listitem would not be reachable with arrow keys,

They are. You can code that. And it works gracefully.

If I use a combobox with aria-haspopup=listbox, only one listbox with option should be allowed and no listitems.

Right but this is not the point here.

[JAWS-test]

Hm. is this explicitely forbidden or just not mentioned as a possibility in the spec?

I think it is explicitly forbidden: " If the popup element supports aria-activedescendant, in lieu of moving focus, such keyboard mechanisms can control the value of aria-activedescendant on the combobox element." (https://w3c.github.io/aria/#combobox)

They are. You can code that. And it works gracefully.

Of course it works with aria-activedescendant, but if this is forbidden in dialog, it doesn't work because in listitem the screen reader is not in form mode. It would only work if the dialog also has role=application, but that would still be a wrong use of listitem. Also, the operation of interactive elements within listitem would be unclear because there is no equivalent for it in HTML and ARIA. Better would be a solution for #1440 or #1385

[smhigley]

@stes-acc when you mention the reason for not using listbox/option being "non-presentational content", would that be something that would fall under this issue? #1440

That is to say, if there were the ability to have secondary action buttons for listbox options, would that remove your use case for using a list with a combobox instead of a listbox?

[stes-acc]

@stes-acc when you mention the reason for not using listbox/option being "non-presentational content", would that be something that would fall under this issue? #1440

That is to say, if there were the ability to have secondary action buttons for listbox options, would that remove your use case for using a list with a combobox instead of a listbox?

The investigations on #1440 are really nice and well observed but here we have the issue that it is presumed that secondary actions come always in a separate part of the item. This is not the design reality, it must be done as a prerequisite. Reality UI design could show really "embedded layout" use cases, like multiple different links inside an option text.

If you mean a row of single action buttons in a toolbar as top overlay associated to an option item is the solution: can this association be mapped to platform API in ONE AND ONLY standardized way that AT has a chance to know on focus that there IS such a thing present?

I feel that all OS app solutions in that direction are more ore less currently "tweaked fakes", like the clickable delete icons in MS Outlook list items (function is keyboard acessible in context menu only) and the context menu item with the same function is then generally the fallback for everything.

Regarding #1385: This is to short, there can be actions NOT in that property definition realm.

As a matter of fact, devs start putting etire input fields in options (or menu items), not because it its allowed but because they CAN. Of course an authoring error, but ARIA is also about pushing boundaries (it already has), so why not actively thinking about concepts that remove limitations already on platform API level?

I think the non-possibility to map interactive content being present in roles like option is the major hurdle. Why can't this be fundamentally changed on ACC API level as a new MS development idea? It seems holy cow thinking to me not to touch these things.

[jnurthen]

I wonder if some of the proposals coming out of web components for cross-root aria will overcome this kind of issue
https://github.com/behowell/aom/blob/element-handles-explainer/element-handles-explainer.md