Accessibility labels for form fields and fieldsets

[arnelap]

What I changed and tested > see comment below.

I propose to wrap every input in its label, that way we don't need to deal with ID's
this way we prevent any issues with duplicated IDs and are still w3c accessible compliant by Associating labels implicitly
https://www.w3.org/WAI/tutorials/forms/labels/#using-aria-label

to this end I

• Removed the ID from the default form content

• Wrapped inputs in their label

• Added "fieldset" around checkbox and radios with the agree to terms excluded as that has only 1 choice it can still be wrapped in label

• removed the wrap in P option for "fieldset" as a fieldset will close the p / can't be wrapped in p

  this would close Small tweak for accessibility (currently fails two WCAG guidelines) #640

[arnelap]

Changes:
Updated default form code to NOT include id=...
Changed field generator to wrap inputs in their label
Changed field generator to wrap checkboxes and radio groups in fieldset with a legend
Removed option to wrap checkboxes and radio groups in P as a fieldset shouldn't be in a P

Tested:

• Creating a new form, the new code from config/default-form-content.php is correctly loaded
• Adding text fields with and without wrapping in P, with and without selecting "required"
• Adding text fields without a label - no label tags are added, p wrapping still works
• Adding address fields
• Adding address type country as dropdown with and without P wrapping
• Adding address type country as radio (results in fieldset, can't wrap in p)
• Adding submit button, no label is added
• Adding procapcha hidden field, no label is added
• Adding Audience choice with radio and with checkbox, fieldset with legend is added, p wrapping is not avialable
• Adding Audience with drop-down, the select is wrapped in label and p wrapping is available
• Adding audience choice with checkboxes without setting a label, results in fieldset without legend
• Repeated the same tests as audience field for the form action
• Tested Agree to terms checkbox,it's wrapped in label because it always has only 1 checkbox so no fieldset required, the label now has a "span" inside of it (this was the way i got it to put on a new line...

[dannyvankooten]

Why do we wrap the label in <span> here now?

[arnelap]

if i don't, it puts on the same line as the already very long agree to terms text.
I tried to add ' ' and '\n' and that did nothing...

[dannyvankooten]

Should we include a <span> or something here to make it a tiny bit easier to style the label text or have it be on a separate line from the field by default?

I think a lot of themes used to have display: block on the <label> element, resulting in a neat line-break between the label text and the input field. After this change, a lot of themes will have the input field on the same line as the label unless their input is display: block.

We should also check the CSS themes we ship to see what we're doing.

[arnelap]

Good idea

[arnelap]

and styles builder possibly as well, will click around

[arnelap]

added the span around text inside the label

made some changes to the default themes but warrants more testing.
also need to update the styles builder

[dannyvankooten]

Yes

…

On 15 December 2025 15:16:19 CET, Arne Lap ***@***.***> wrote: @arnelap commented on this pull request. > + const content = config.type === 'terms-checkbox' + ? field + : isNested + ? (hasLabel + ? m('label', [config.label, field]) I believe this is resolved with your push?

[arnelap]

I've put it back in draft mode now that I realize we have to update the styles builder too

[arnelap]

reminder for myself that the CSS changes also need to keep the old css in place for existing forms.
and that I need to make sure the styling stays consistent even if someone has a mix of old and new style in case someone adds a new field to an existing form.