Required file fields are not programmatically identified for assistive technology.

Created on 15 February 2017, over 8 years ago
Updated 6 May 2025, 3 months ago

Asterisks for certain fields are not announced by JAWS. As an example within the “Create Image” screen, the “Image Upload *” button is announced by JAWS as, “Image upload file upload edit browse…” instead of being correctly announced as e.g. “Image upload required file upload edit browse…”

The defect exists in IE 11 and Google Chrome v55.0.2883.87 m.

Expected result: All asterisks are expected to be announced by JAWS. For example required red asterisk is expected to be made available for JAWS to read with the associated form title e.g., “Image upload required file upload edit browse…”

Reference: Section 508, Part 1194.22, Paragraph (n).

Notes:
• This defect may exist elsewhere within the application.
• This defect exists on a screen that is not accessible via a keyboard. The tester was forced to use the mouse to access this screen, which is not acceptable for a JAWS user.

🐛 Bug report
Status

Active

Version

11.0 🔥

Component

file.module

Created by

🇺🇸United States kershme

Live updates comments and jobs are added and updated live.
  • Accessibility

    It affects the ability of people with disabilities or special needs (such as blindness or color-blindness) to use Drupal.

  • html5

    Implements and supports the use of HTML5.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • 🇺🇸United States dcam

    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.

  • 🇮🇳India mohit_aghera Rajkot

    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.

  • 🇨🇦Canada mgifford Ottawa, Ontario

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

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

  • 🇩🇪Germany rkoller Nürnberg, Germany

    @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.

Production build 0.71.5 2024