Consider allowing aria-required on fieldset element

[offsetChris]

There is not a clear way to denote a required group of input elements, particularly checkboxes. If only one checkbox input is required within a group how can that be communicated to assistive technology that is consistent with non-grouped elements?

Previously explored solutions

• Adding the html required attribute to each checkbox element. This will not work because each would need to be selected to validate correctly.
• Adding aria-required to each checkbox element. This might be confusing and suggest that each checkbox would need to be selected to validate correctly.

Code example with no programatic required denotation

This works to communicate that one check is required, but is not consistent with the implementation for non-grouped elements that would include aria-required or the html required attribute.

<fieldset>
  <legend>This is a group of checkboxes (one selection required)</legend>
  <label><input type="checkbox" name="check1"> Checkbox 1</label>
  <label><input type="checkbox" name="check1"> Checkbox 2</label>
  <label><input type="checkbox" name="check1"> Checkbox 3</label>
</fieldset>

Proposed solution

Ideally aria-required could be added to the grouping element to denote the group is required, not the individual input fields.

<fieldset aria-required="true">
  <legend>This is a group of checkboxes (one selection required)</legend>
  <label><input type="checkbox" name="check1"> Checkbox 1</label>
  <label><input type="checkbox" name="check1"> Checkbox 2</label>
  <label><input type="checkbox" name="check1"> Checkbox 3</label>
</fieldset>

Please let me know if more information is needed or if there are existing resources I may have missed in the existing documentation.

[jnurthen]

I think the use of aria-required on a group would be ambiguous. An equally valid reading of a required fieldset is that all of the child fields are required (indeed this is how aria-disabled on a fieldset is specified)
To be honest I don't think there is a better way to communicate this in an unambiguous way to all users than specifying it in text as you are doing in the code above.

[stes-acc]

If aria-disabled on a fieldset is specified, then also aria-readonly should be, see this issue. I agree that this should be also reflected by attribute in host language for all three cases. Therefore flagged this with openui.

[cookiecrook]

Almost identical response to #542 (comment)

IMO, if you want this, it should be an HTML issue, not an ARIA issue...

A required state inherited from a container role will never override the host language's "equivalent semantic" attribute in the host language. For example, the absence of required on <input> means it's explicitly not required. So I don't see a lot of value in adding a required state for containers.

[jnurthen]

Based on the previous comment closing

[offsetChris]

Thanks for the discussion. I still find this problematic since checkboxes are not tied together in the same way radio buttons are when sharing a name property. There should be a programmatic way to indicate and validate that input to an option in the group is required. I'm not comfortable just leaving that to the text in the legend and it seems disjointed from the way aria is intended to communicate state of elements in a form.

[scottaohara]

for what you want, @offsetChris, it would require custom scripting presently and one's own internal rules to determine what was the required amount of checkboxes to check. for instance, i've seen checkbox groupings where one to three of many checkboxes were necessary to check to properly fulfill the requirements of the grouping .

simply allowing aria-required on a fieldset doesn't fully support those use cases. It also doesn't do anything to differentiate what in a fieldset may be required or not (e.g., technically various "name" fields could be within a single fieldset, where first and last are required, but the middle name is not.)

in contrast, allowing aria-required on a role=radiogroup makes sense because it indicates the grouping must be interacted with, and there is only the possibility for a single radio to be chosen.

[offsetChris]

Thanks @scottaohara. I understand your points. To me however the specificity of how many fields are answered would always be custom scripting much in the same way that validating an email address format would be in a text field. That doesn't prevent the field from showing that user input is required. I've always considered aria-required="true" to mean some user input is required, not the specific format, number, length etc which would be handled by further custom script validation. That concept was really the basis of this question/issue request but thank you for the discussion, it is appreciated.

[mbgower]

in contrast, allowing aria-required on a role=radiogroup makes sense because it indicates the grouping must be interacted with, and there is only the possibility for a single radio to be chosen

@scottaohara if there was a checkboxgroup role, it could have almost identical functionality. 'It indicates the grouping must be interacted with, and at least one checkbox must be chosen'. That would address the basic use case: you have a survey or input and you wish to allow someone to indicate one or more responses. As it stands right now, there is no simple way to ensure the user has not missed the question.

Yes, if a use case required some more explicit business rule, the author would need to address that. I suspect in a number of such cases, the requirements could be broken down into logical subsets of checkbox groupings, rather than gathering them all into a single group and requiring multiple selections. Regardless, outlier cases for complex logic needn't detract from a clear gap in a common input case.

[scottaohara]

@mbgower suggesting a new role is a separate issue though, and out of scope for this thread.

As it stands right now, there is no simple way to ensure the user has not missed the question.

I am not sure if just adding a role would solve this. I don't disagree that there's a gap here, but agree with James Craig. Likely something best to try and take up with HTML first.