aria-required attribute is redundant when required attribute is present

Created on 26 November 2019, about 5 years ago
Updated 6 August 2024, 5 months ago

Problem/Motivation

Required fields in Form API have both the required="required" attribute as well as the aria-required="true" attribute.

  • This is flagged in Siteimprove as a WCAG Level A warning, with the following generic text:

    A WAI-ARIA attribute that has the exact same features as the HTML element it has been applied to has been used. The WAI-ARIA attribute is redundant since is doesn't provide the user with any additional information.

    For landmarks it has previously been a recommendation to use HTML5 and WAI-ARIA landmark roles together (e.g. WAI-ARIA role="navigation" on HTML5 'nav' elements) to maximize support, but with the widespread adoption of HTML5 this is no longer needed.

    Where to find it in WCAG 2:
    4 Robust > 4.1 Compatible > A > 4.1.2 Name, Role, Value > Warning > Redundant WAI-ARIA attribute

  • According to On HTML belts and ARIA braces (The Default Implicit ARIA semantics they didn’t want you to know about) by Steve Faulkner — one of the editors of the ARIA spec — adding the 'aria-required' in addition to the native HTML 'required' attribute is a, quote, “waste of time” since it is already set by the browser, as can be seen in https://stevefaulkner.github.io/html-mapping-tests .

Steps to reproduce

Inspect a node edit screen and look at any required field, such as node title.

Proposed resolution

Siteimprove suggests the following fix:

The WAI-ARIA attribute can be removed without any impact for end users. The result will be cleaner, easier to maintain code.

The suggested changes would affect Drupal Core in these places:

  1. setAttributes method of core/lib/Drupal/Core/Render/Element/RenderElement.php:
        // This function is invoked from form element theme functions, but the
        // rendered form element may not necessarily have been processed by
        // \Drupal::formBuilder()->doBuildForm().
        if (!empty($element['#required'])) {
          $element['#attributes']['class'][] = 'required';
          $element['#attributes']['required'] = 'required';
          $element['#attributes']['aria-required'] = 'true';  #<-- HERE
        }
    
  2. $document.on('state:required' of core/misc/states.es6.js.
          if (e.value) {
            const label = `label${e.target.id ? `[for=${e.target.id}]` : ''}`;
            const $label = $(e.target)
              .attr({ required: 'required', 'aria-required': 'true' }) /*<-- HERE */
              .closest('.js-form-item, .js-form-wrapper')
              .find(label);
            // Avoids duplicate required markers on initialization.
            if (!$label.hasClass('js-form-required').length) {
              $label.addClass('js-form-required form-required');
            }
          } else {
            $(e.target)
              .removeAttr('required aria-required') /*<-- HERE */
              .closest('.js-form-item, .js-form-wrapper')
              .find('label.js-form-required')
              .removeClass('js-form-required form-required');
          }
    

The addition of aria-required in addition to the required attribute was done over 10 years ago in #1174938: Natively support the HTML5 required and aria-required FAPI properties .

Remaining tasks

  1. Validate that this is an actual bug or a red herring from Siteimprove.
  2. If bug, write a patch with tests.
  3. If red herring, write to Siteimprove to fix their tests.

User interface changes

API changes

Data model changes

Release notes snippet

📌 Task
Status

Needs work

Version

11.0 🔥

Component
Form 

Last updated 2 days ago

Created by

🇫🇮Finland thatguy

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

Merge Requests

Comments & Activities

Not all content is available!

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

  • Status changed to RTBC almost 2 years ago
  • Status changed to Needs work almost 2 years ago
  • 🇨🇦Canada mgifford Ottawa, Ontario

    @xjm I don't think we need to backport issues that fall under WCAG SC 4.1.1. There's a big debate about removing it from WCAG 2.2, so it may not be in WCAG's future.

    The thing is that most parsing errors aren't a problem for accessibility. When 4.1.1 was written, there was some assistive technology that worked with HTML source code. Now they all use the DOM or Accessibility Tree, both of which have been cleaned up by the browser.

    So we're an organization that supports open standards, so it is good to fix parsing errors, but it may not make sense to see them as accessibility issues.

    I tagged this with WCAG SC 4.1.2 Name, Role, Value.

    Redundancy isn't good, but not sure if it needs backporting. It's a pretty low impact issue.

    I have to say I also had trouble finding this reference "Where to find it in WCAG 2: 4 Robust > 4.1 Compatible > A > 4.1.2 Name, Role, Value > Warning > Redundant WAI-ARIA attribute" from the project descrption. Not sure why a link wasn't given.

  • 🇩🇪Germany mrshowerman Munich

    Re-roll against current 10.1.x. Leaving in NW as per #34.

  • 🇺🇸United States bnjmnm Ann Arbor, MI

    Tagging for accessibility maintainer review of whether it is okay to backport this to 10.0.x and 9.5.x. I considered FEFM signoff, but in this case I think the accessibility aspect is the main thing that's important.

    It is OK to backport this change to 10.0.x and 9.5.x, but as mentioned in in #44 it is also not imperative that this happens.

  • Pipeline finished with Failed
    6 months ago
    Total: 124s
    #206647
  • Pipeline finished with Failed
    6 months ago
    #206651
  • Pipeline finished with Failed
    6 months ago
    Total: 510s
    #206750
  • 🇸🇪Sweden mohammed motar

    I have created a patch file from the latest commit in the merge request.

  • 🇪🇸Spain patricia_zoocha

    Patch #49 applied successfully on Drupal version 10.3.6 and working fine.

Production build 0.71.5 2024