Allow HTML textarea to have role combobox

[bdugan14]

Description of bug or feature request

I would like the ARIA spec to allow HTML textarea elements to have the role combobox .

The guidelines (Document conformance requirements for use of ARIA attributes in HTML) have this rule for textareas:

HTML element	Implicit ARIA semantics (explicitly assigning these in markup is NOT RECOMMENDED)	ARIA role, state and property allowances
[textarea)	role=textbox	No role other than textbox, which is NOT RECOMMENDED. Global aria-* attributes and any aria-* attributes applicable to the textbox role.

I’m specifically working with a feature that roughly matches the pattern of the APG’s Editable Combobox With List Autocomplete Example, but it uses a textarea instead of an input.

As a developer, I’d like to use a textarea as a combobox with these features:

• Support occasional long, multiline text entries
• Show an associated listbox, and alert assistive technologies about this listbox (plus all associated features like active descendent, etc)
• Override the Enter behavior for this textarea to behave like the Enter behavior of a typical listbox popup, depending on whether a descendant in the listbox is activated
• Preferably use Angular Material’s autocomplete component, which they aim to keep up to date with aria and accessibility standards so AT users are more likely to have a consistent experience as standards change

A very similar example to what I want: Google’s search bar, which is a textarea with role=combobox that currently does not conform to the ARIA spec.

Google’s textarea with role combobox and their failing lighthouse test

It looks like Aria 1.1 used to suggest adding role=combobox on a wrapping element instead of an input (link to 1.1 examples). I don’t have much context, but adding the role directly on the input instead of a wrapper does seem more intuitive.

But this change put Google out of compliance: this github issue on an accessibility compliance library includes a screenshot of Google using the wrapping pattern in October 2024. In both cases, Google.com used a textarea, but removing the wrapper pattern means there isn’t a clear way for them to get in spec and still support multiline inputs.

It seems that VoiceOver works with Google’s search bar. I’d like to implement a similar pattern to what they’re doing to show a combobox in an AT-friendly way while supporting multiline inputs, and I imagine other developers will take inspiration from their approach as well. Would it make sense to change the spec to allow textarea to have role combobox? Or, if not, can you provide any suggestions for how to make a widget like this AT-friendly in HTML?

Will this require a change to CORE-AAM?

If unknown, leave blank. If relevant, link bug. Unknown

Will this require a change to the ARIA authoring guide?

If unknown, leave blank. If relevant, link bug. Unknown

[scottaohara]

I’ve transferred this issue to the aria in html spec, as this is where allowed roles are defined, not the aria specification.

[scottaohara]

I’ve created a new issue against aria to consider multiline comboboxes.

It’d be good to have a test case to check against. As you mention VO seems to work with googles search bar - but a wrapping text input is not necessarily the same as all the functionality of a textarea. I can’t fully check this out right now being I’m responding on a phone, so I do not have access to a full keyboard or other screen readers beyond iOS VO. But the best way to demonstrate that a role should be allowed on a new element is to demonstrate that it can be used in a way to make an accessible widget that doesn’t have to fight against the inherit behavior of the html
Element it is used on.

[bdugan14]

Thanks for the help routing the issues, Scott.

It’d be good to have a test case to check against. As you mention VO seems to work with googles search bar - but a wrapping text input is not necessarily the same as all the functionality of a textarea. I can’t fully check this out right now being I’m responding on a phone, so I do not have access to a full keyboard or other screen readers beyond iOS VO. But the best way to demonstrate that a role should be allowed on a new element is to demonstrate that it can be used in a way to make an accessible widget that doesn’t have to fight against the inherit behavior of the html
Element it is used on.

And, thanks for your suggestion for how to advocate for this. Do you mean something like a textarea version of the codepen linked in this ARIA patterns article?

I should have time to put together a first-pass textarea combobox codepen early next week to help illustrate (and test) this proposal.