Required file fields are not programmatically identified for assistive technology.

If you need a workaround for this issue, then you can put this in your custom theme:

/**
 * Implements hook_element_info_alter().
 */
function MY_THEME_element_info_alter(array &$info) {
  $info['managed_file']['#process'][] = '_MY_THEME_process_managed_file_element';
}

/**
 * Processes managed file elements.
 *
 * A required attribute isn't set on the child upload element and it can't be
 * done in a preprocess function. It must be set before the element is
 * rendered.
 *
 * @param array element
 *   A managed file form element.
 *
 * @return array
 *   The processed managed file element.
 *
 * @see https://www.drupal.org/project/drupal/issues/2852874
 */
function _MY_THEME_process_managed_file_element(array $element) {
  if (isset($element['#required']) && $element['#required']) {
    $element['upload']['#required'] = TRUE;
  }
  return $element;
}

I'll see about fixing it properly in Drupal Core another time.

Tagging for initial review with the accessibility team.
I'll work on issues depending on the inputs from the team.

I'm in favour of using "aria-required: true" unless there aren't any other ways.

Currently when field is required, we have following markup in claro in standard profile.

I do want to make sure that we are building on well researched patterns. There are a few like:

• https://www.w3.org/WAI/WCAG21/Techniques/aria/ARIA2
• https://www.tpgi.com/doing-whats-required-indicating-mandatory-fields-in...
• https://www.digitala11y.com/anatomy-of-creating-accessible-forms-is-this...

This is a common problem and we should be able to leverage a pattern which is both well tested and well established.

@katannshaw, @mgifford, @the_g_bomb, and myself discussed the matter back and forth for the last couple of days to weeks about how to tackle and, in particular, scope the problem at hand.

In summary we agree with most of the problems raised in this issue, but from our point of view it would be a reasonable step to chop the issue up, create an overarching meta issue, and have this issue rescoped and create a few additional follow up child issues alongside.

In regard to scope, it also has to be noted, during our testing it turned out, it is not only the file field affected, but also the image field, the formatted long text field and the formatted long text with summary field that are missing a required attribute.

In the following we would suggest three general steps how to chop up the problem - at least one of the steps might be subdivided even further.

1. Add the required attribute
We would advise to stay consistent with the field api in Core. Instead of going with aria-required=“true” for the input elements for file and image fields, as suggested in #22 → , better go with required=“required” that is used on all the other input elements. Problem is for div elements (formatted long & formatted long with summary) that approach probably won’t work, there the aria-required=“true” might be required.

In regard to scope it might make sense to rescope this issue and make it solely about adding the required=“required” attribute to the image and file field and open another issue for adding aria-required=“true” to the formatted long & formatted long with summary fields.

Next, the following two issues should be postponed until step one is fixed and all field types in Core use a required attribute.

2. Improve the asterisks in the aural interface
In the aural interface for for example VoiceOver the announced text for a field with the label plain text currently is plain text *, required invalid data, edit text, main.

We are in line with #16 that the asterisk is potentially confusing for screen reader users. But instead of adding a visually-hidden “required” text snippet to the asterisk we would simply exclude and hide the asterisk from the aural interface. With the required attribute in place with step 1 completed the asterisk is now redundant information. →

The fix could be worked on in the already existing 🐛 Drupal should not use full CSS required marker in forms according to WCAG 2.0 Needs work . As the proposed resolution, wrap the asterisk in a span adding aria-hidden=“true” so it is hidden from screen reader users for all available field types while still visible for sighted users.

3. Improve how required fields are communicated in general
As previously stated, required fields have a few inherent problems - Adam Silver outlined those in: https://adamsilver.io/blog/how-to-highlight-required-and-optional-form-fields/

Our suggestion would be to open another follow up child issue, that will probably require a lot of discussions and testing with actual users, but as a discussion starter the following approach could be suggested.

In node edit forms, based on the number of required and optional fields, the group of fields that is smaller in number should get the (required) or (optional) suffix appended to the corresponding field labels. That way it would be clearly communicated what the requirements for that node edit form are - the automatic approach. Another option might be to add a vertical tab to the edit page for a content type and provide the user options to set the to be discussed behavior of the node edit form in regard to required and options fields.

The following video https://www.youtube.com/watch?v=mvIaUHr2i5U covers most aspects of that discussion. It includes the aspects of the article Adam Silver posted, and discusses https://www.nngroup.com/articles/required-fields/ as well as https://www.deque.com/blog/anatomy-of-accessible-forms-required-form-fields/. The arguments in the nngroup article argue for example against 🐛 Forms with required fields marked by asterisk do not have text explaining what the asterisk means Needs work a related issue that was raised during the discussions for this issue - providing some description for the asterisks is considered rather pointless according to the nngroup, since most users don’t read the instructions at the top of a form.

But looking at all those resources shows two things, that the current state of how required fields are handled in Drupal has room for improvement and that there might be no one-for-all solution. Either way the issue for step three will require a lot of discussion and user testing.