WCAG 1.3.1 A: Label not programmatically associated with input (Issue 6)

[CJE001]

Summary

Via Vision Australia assessment: August 2024

Impact: medium

Note: DTA have a 90 day remediation period to address the identified issues within the audit, all issues must be resolved to obtain WCAG 2.2 certification for digital.gov.au.

Steps to reproduce

Contact digital.gov.au beta | digital.gov.au (https://www.digital.gov.au/contact)

Observed outcome

The contact form contains visible <label> elements above inputs; however, these labels have not been programmatically associated with their corresponding inputs.

This is because the id attribute that the labels reference is not unique, as it has also been given to the parent <div> elements for the inputs.

Code used

<div class="ct-form-element ct-theme-light ct-form-element--textfield ct-form-element--name ct-form-element--label--before ct-form-element--label--after js-form-item js-form-type-textfield js-form-item-name">
<label class="ct-label ct-theme-light ct-label--regular ct-form-element__label">
<label class="ct-label ct-theme-light ct-label--regular " #civictheme_theme="light" for="edit-name">
Your Name
</label>
</label>
<div class="ct-input ct-theme-light ct-input--default ct-input--text form-text" #component_theme="light" data-drupal-selector="edit-name" id="edit-name" name="name" size="60" maxlength="255">
<input type="text" value="" class="ct-textfield ct-input__element ct-theme-light form-text" #component_theme="light" data-drupal-selector="edit-name" id="edit-name" name="name" size="60" maxlength="255">
</div>
</div>

Why this matters

When screen readers encounter a form, they will generally enter forms/focus mode. In this mode, only text that has been programmatically associated with a form element will be announced.

Without this relationship, screen reader users may not know the input purpose or what data is expected. They may struggle to complete and understand the form.

When id attributes are not unique, form elements are often left without an accessible name, due to how accessible names are computed.

Expected outcome

Ensure that there is a programmatic association between all labels and their corresponding inputs.

In this instance, remove the id attribute from the parent <div> element for all inputs.

Ensure that id attributes are unique on each page.

Code example

<label class="ct-label ct-theme-light ct-label--regular ct-form-element__label">
<label class="ct-label ct-theme-light ct-label--regular " #civictheme_theme="light" for="edit-name">
Your Name
</label>
</label>
<div class="ct-input ct-theme-light ct-input--default ct-input--text form-text" #component_theme="light" data-drupal-selector="edit-name" name="name" size="60" maxlength="255">
<input type="text" value="" class="ct-textfield ct-input__element ct-theme-light form-text" #component_theme="light" data-drupal-selector="edit-name" id="edit-name" name="name" size="60" maxlength="255">
</div>

Note

In general, ensure that all form controls have an accessible name. The table below contains accessible naming options for form elements.

Accessible name options - form elements

Related issues

For other issues related to this component, please refer to:

• Issue 7 – Error messages not programmatically associated with input
• Issue 12 – Inputs missing autocomplete attribute
• Issue 20 – Form input borders have insufficient contrast
• Issue 32 – Required fields not indicated
• Issue 37 – Success message not announced by screen readers

Additional example

Tell us what you think about digital.gov.au Beta | digital.gov.au (https://www.digital.gov.au/tell-us-what-you-think-about-digitalgovau-beta-0)

Description

The feedback form contains visible <label> elements above inputs; however, these labels have not been programmatically associated with their corresponding inputs.

This is because the id attribute that the labels references is not unique, and has been used on the parent <div> elements for the inputs.

Recommendation

Please refer to the recommendation in the primary example.

[AlexSkrypnyk]

The labels are working correctly. In this specific case, there is a strange <label> without a closing tag - has this been edited manually? How did this markup being produced?

Please move this to Drupal as this is not related to the UIKit in any way.

[alan-cole]

Looking at this page it seems likely that the way form fields are being applied to the contact form is incorrect.

E.g.

<div class="ct-form-element ct-theme-light ct-form-element--email ct-form-element--email ct-form-element--label--before ct-form-element--label--after   js-form-item js-form-type-email js-form-item-email" >
  <label class="ct-label ct-theme-light ct-label--regular ct-form-element__label">
    <label class="ct-label ct-theme-light ct-label--regular " #civictheme_theme="light" for="edit-email">
      Your Email
    </label>
  </label>
  <div class="ct-input ct-theme-light ct-input--default   ct-input--email form-email" #component_theme="light" data-drupal-selector="edit-email" id="edit-email" name="email" size="60" maxlength="254">
    <input type="email" value="" class="ct-textfield ct-input__element ct-theme-light   form-email" #component_theme="light" data-drupal-selector="edit-email" id="edit-email" name="email" size="60" maxlength="254">
  </div>
</div>

In this snippet of code, you can see a label inside a label - The inner label is correctly using the for attribute, while the outer is not. Only 1 label should exist, so this itself is a bug.
Secondly, the input element correctly applies the id attribute, but so does it's wrapping div which means there's a double-up in matching ids.
Also, label having #civictheme_theme is incorrect - this is not a valid attribute.

I'd guess this might be an issue in preprocess with how fields are being mapped. Further investigation needed to see if it's a core issue.

I don't think the issue will be solved in this repo though, it'd likely be in https://github.com/civictheme/monorepo-drupal

[febdao]

Thanks @alan-cole for the suggestion.
I've checked the https://github.com/civictheme/monorepo-drupal repo and don't see this issue with the webform.
I have a same opinion with @AlexSkrypnyk that the issue might come from a custom template/code.

cc @fionamorrison23

[fionamorrison23]

Closing this issue as this is related to the sub-theme for the site mentioned in the ticket. This is not an issue with CivicTheme core. Thanks all for the input.