Provide a compound form element with accessible labels

Updated:

Comment #278

Problem/Motivation

To help screen readers navigate complex forms, it is important to group related form elements in a manner that makes the form more semantic. The most established way of doing this is grouping it in a fieldset as per this WebAim Article. All WCAG 2.0 requires is a way to get the necessary information into the DOM in a way that the User Agent can pass it through to the accessibility API.

A challenge with adding fieldsets is that each fieldset added to a form adds a visual element, which changes the UI. The UI changes introduced by a fieldset may not improve the usability of complex forms for sighted users; additional CSS may be required to style out undesirable visual elements entailed by the addition of fieldsets.

Since #1168246: Freedom For Fieldsets! Long Live The DETAILS. → fieldsets are no longer used as collapsible or uncollapsible containers, which actually have little in common with the original purpose of HTML fieldsets. (The FIELDSET element allows authors to group thematically related controls and labels.)

Core's complex form elements:

• radios
• checkboxes
• dates

Most of the patches that have been written to address these problems have provided different ways to add fieldsets (or making it easier for users to do so), without altering the visual presentation of the form.

Unfortunately, there are problems with this approach that have not been easy to resolve:

• Present solutions require extensive CSS overrides to restyle automatic fieldset styling
• (This is no longer a problem with the addition of DETAILS, see patch #272)
• The automatic method presently just duplicates the #title rather than adding an explicit #property on the form elements

Proposed resolution

Provide a distinction between visual & logical ways to group form elements:
1) Logical FIELDSETS that group a set of composite form elements like checkboxes, radios, or other fields (such as a date's month, day and year);
2) Visual DETAILS that can collapse and expand and show a visual border.

Remaining tasks

There are no remaining tasks for this issue, however there is still a problem with inconsistency of styling. See #2002336: Introduce a CSS class to hide borders of fieldset elements → .

User interface changes

N/A

API changes

Patch #232 changes the form pre-render function call from form_pre_render_conditional_form_element to form_pre_render_composite_form_element.

Patch #272 includes a new theme_details function call, in addition to theme_fieldset function call, to indicate a visual display of grouped fields, as opposed to a logical organization of fields into a fieldset.

Original report by @BWPanda

---

Original Summary

To help screen readers navigate complex forms it is important to group related form elements in a manner that makes it more semantic. The most established way of doing this is grouping it in a fieldset as per this WebAim Article. All WCAG 2.0 requires is a way to get the necessary information into the DOM in a way that the User Agent can pass it through to the accessibility API.

A challenge with adding fieldsets is that it adds a visual element presently which changes the UI and which may not improve the usability of complex forms for sighted users. Since #1168246: Freedom For Fieldsets! Long Live The DETAILS. → fieldsets are no longer used as lame collapsible or uncollapsible containers, which actually have little in common with the original purpose of HTML fieldsets (The FIELDSET element allows authors to group thematically related controls and labels).

There is now a distinction between visual & logical ways to group form elements:
1) Visual DETAILS that can collapse and expand and show a visual border;
2) Logical FIELDSETS that group a set of composite form elements like checkboxes, radios, or other fields (such as a date's month, day and year).

Most of the patches have been looking at different ways to add fieldsets (or making it easier for users to do so) without altering the look of the site.

Core's complex form elements:

• radios
• checkboxes
• dates

Unfortunately, there are problems with this that aren't easy to resolve:

• Redundant fieldsets are very probable (This is no longer a problem with the switch to DETAILS)
• Present solutions require an awkward mess of lengthy CSS overrides
• Nobody wants to add extra HTML, CSS & Javascript if there is any way it can be avoided
• The automatic method presently just duplicates the #title rather than adding an explicit #property on the form elements

---

When trying to validate my site, I got a warning saying I had a "reference to non-existent ID". This was because the date fields didn't have an ID set on their container div, hence the preceding label didn't match anything.

This patch adds the ID to the date container.