Fieldset

[govuk-design-system]

Use this issue to discuss this component in the GOV.UK Design System.

[edwardhorsford]

Adding this to fieldset as it applies to both checkboxes and radios.

I've occasionally wanted to put paragraph text and other content between a legend and the checkboxes / radios it represents. At the moment I don't think this is possible. I tried passing html to the hint - but this doesn't work - and I don't want hint styling anyway.

My immediate need was wanting to put a details element after the legend:

[dominic-cyb]

Is there a method to apply an errorMessage to an entire fieldset? I can see that no errorMessage attribute exists for the nunjucks implementation. Below is what we want to achieve v what is currently implemented, followed by the the code used.

Implementation:

{% call govukFieldset({
    attributes: {
        id: "locations-set",
        name: "locations"
    },
    legend: {
        text: "Add locations for 'Nearest towns or cities' question",
        classes: "govuk-fieldset__legend--l",
        isPageHeading: true
    }
}) %}
    {% if inputError %}
        {{ govukErrorMessage({
            text: inputError,
            classes: 'govuk-error-message'
        }) }}
    {% endif %}
{% endcall %}

[joelanman]

you're right that there doesnt appear to be a nunjucks option, but its odd because Radios and Checkboxes use fieldsets and do support error messages, so I'd start looking there for the right approach

https://design-system.service.gov.uk/components/radios/#error-messages

[dominic-cyb]

Good shout @joelanman. Looking at the HTML I can see the class govuk-form-group--error on the div around the fieldset. It seems that adding this into the classes attribute for govukFieldset doesn't do anything, so I have a kinda hacky workaround.

{% if inputError %}<div class="govuk-form-group--error">{% endif %}

  {% call govukFieldset({...}) %}
    {% if inputError %}
      {{ govukErrorMessage({
        text: inputError,
        classes: 'govuk-error-message'
      }) }}
    {% endif %}

    ...all inputs & other content
  {% endcall %}

{% if inputError %}</div>{% endif %}

<hr class="govuk-section-break govuk-section-break--m"/>

By wrapping the fieldset in a conditional div with the govuk-form-group--error class, we can achieve the look that I've described below. Below are some screenshots by using the above implementation:

Sidenote on the line break <hr class="govuk-section-break govuk-section-break--m"/>, if it's not added the error line appears up until the start of the next div. Without the break, it ends up looking like:

[jrbarnes9]

Should this example on the question page pattern not be using the fieldset, to utilise the page heading ('Passport details') for its legend?

[querkmachine]

@jrbarnes9 Not particularly.

The use case for a fieldset is to group multiple inputs together that relate to the same 'question'. For example, asking for a user's address may have multiple address line fields, a list of checkboxes asking for preferred contact methods, or the 'expiry date' example in that screenshot. One question, multiple inputs.

You could argue that there is one overarching question here ('What are your passport details?') but for our purposes it's two questions—you could split this across two separate pages and it would still make sense in a way that splitting up lines of an address wouldn't.

Nesting fieldsets is also generally not good for accessibility, as screen readers may not announce the correct legend, or will be overly verbose and re-announce every legend.

[Nikolaos-Gkionis]

I think we need to label every input field. Both (required) and (optional).

According to my reading of this: https://www.w3.org/WAI/WCAG21/Techniques/general/G131.html

And this: https://www.w3.org/WAI/WCAG21/Understanding/labels-or-instructions

We currently only label (optional) fields, is this right?

[joelanman]

@Nikolaos-Gkionis WCAG is presented in quite a confusing way, I find. WCAG's actual requirements are here:

https://www.w3.org/TR/WCAG22

The relevant points for labels are these two

• 2.4.6 Headings and labels describe topic or purpose
• 3.3.2 Labels or instructions are provided when content requires user input

So the requirements are: you must have labels (associated with the fields), and they must be descriptive.

The other docs you linked are guidance to help meet WCAG, and not part of the standard themselves. One of them said 'or the optional fields', so our approach of only marking optional fields is covered. However this line has been removed in the latest version, I've raised an issue here:

• https://github.com/w3c/wcag/issues/3795

Fundamentally, the most important thing is whether the approach works for all users. We've used this approach for many years and I'm not aware of it causing issues. In fact I think its more clear to label optional fields than imply they are optional by the lack of an asterisk or 'required'.

One suggestion if it ever was an issue might be to have a notice at the start along the lines of 'You must answer all questions unless they are marked as optional'