Button role should allow aria-required

[e111077]

Description

Button role should allow aria-required since the button role can be u sed as a popup button and it works in practice anyway.

Spec

Spec: https://www.w3.org/TR/wai-aria-1.1/#aria-required
Core-AAM language: https://www.w3.org/TR/core-aam-1.2/#details-id-164

Please note that the spec lists roles but the core-aam language does not.

Example / Use Case

An example is a widget to replace the native <select> element. Consider the following markup:

<form>
  <input type="text" aria-label="Street Address" required ...>

  <div class="custom-select">
    <div
        role="button"
        aria-haspopup="listbox"
        aria-labelledby="label"
        aria-required="true"
        tabindex="0">
      <div class="selected-text">CA</div>
    </div>
    <ul role="listbox" tabindex="0" class="popup-listbox">
      <li role="option" aria-selected="false" tabindex="-1"></li>
      <li role="option" aria-selected="true" tabindex="0">CA</li>
      <li role="option" aria-selected="true" tabindex="-1">TX</li>
    </ul>
    <label id="label">State</label>
  </div>
</form>

In that markup we have a form with two inputs: a native input and a collapsible dropdown listbox that is meant to act like a native <select> element.

A user tabbing through the form with a screen reader would hear "street address,text, required" and then "state, listbox popup collapsed, required". Unfortunately adding aria-required to role="button" is against the spec.

Alternatives tried

Spec does allow aria-required on role="listbox", but in windows NVDA screen reader will not read out "required" unless the popup is opened, and mac voiceover simply will not read "required" on listboxes. Thus a user simply tabbing through the form will not know that the <select> / role="button" is required until after attempting to submit the form.

[scottaohara]

generally allowing aria-required on a button is a bad idea. as i asked you previously, out of the context of this specific use case, how do you "require" a button?

Rather than taking this approach, could you not use the combobox pattern instead? seems it'd solve your use case as you described it here / over on slack?

[e111077]

Unfortunately, for our case, a combobox would allow typing inside of the component which would rather map to a material autocomplete component rather than a material select element.

[carmacleod]

Unfortunately, for our case, a combobox would allow typing inside of the component ...

Combobox does not have to allow typing inside the component. An example of a "select-only" combobox is being developed for the ARIA Practices Guide. It's not ready yet, but it will look something like the codepen linked in w3c/aria-practices#1026 (comment)

Edit: Or, more accurately, the one linked in w3c/aria-practices#1026 (comment)

[scottaohara]

A native select element allows a user to type characters to change the currently chosen option when it has keyboard focus, and in its collapsed state (let alone open state). So i'm not sure why a combobox, that could allow typing into it to autofill entire options / auto-select those options, would not be something to consider. As @carmacleod's comment alluded to, this component doesn't have to be based on a button. That would then allow you to achieve your goal of marking it required by using a role and element that would accept that state already.

Circling back, my point here is that a blanket allowance of aria-required on a button arguably helps your use case, but it doesn't make sense outside of it. How do you "require" a button? What does that mean outside of this particular context? It's not the button that's required, it's the selection of an option within the listbox.

[JAWS-test]

As long as the ARIA practice recommends buttons for listboxes, it should also be possible to mark them with aria-required, aria-invalid and aria-errormessage. However, it would be better to remove the example https://www.w3.org/TR/wai-aria-practices/examples/listbox/listbox-collapsible.html, see: w3c/aria-practices#1137

[scottaohara]

i disagree that there is no validity to demonstrating a pattern if that pattern doesn't completely replicate a native HTML control it is described as being "similar to". But, as the topic of that particular pattern's removal is not new, and seems to have support due to the revised combobox pattern providing more equivalent select feature parity, then sure. Remove the pattern, when appropriate, to reduce confusion that it should allow for all the features of a native select.

[e111077]

Heya, thanks for the select-only combobox example. There have been several other engineers that have pointed out that previous listbox button example on w3.org, so I can't wait until the combobox one gets published as well.

I think this solves our use case without the need for a spec change

[carmacleod]

I think this solves our use case without the need for a spec change

Great! Glad we could help. I'll close this issue, then.