0

Forms with yes/no questions that reveal new questions depending what you select... Is it "most correct" and most useful for those who are dependent on accessibility to have the new questions pop up after the fieldset surrounding the yes/no question, or inside the fieldset?

Example, with pseudo-html:

<fieldset>
  <legend>Do you like food?</legend>
  <label><input type="radio" name="like_food" value="yes"> Yes</label>
  <label><input type="radio" name="like_food" value="no"> No</label>

  <when like_food = yes>
    <fieldset>
      <legend>Do you have a favorite food?</legend>
      <label><input type="radio" name="have_favorite" value="yes"> Yes</label>
      <label><input type="radio" name="have_favorite" value="no"> No</label>

      <when have_favorite = yes>
        <label>What's your favorite food?</label>
        <input type="text" name="favorite_food">
      </when>
    </fieldset>
  </when>
</fieldset>

vs

<fieldset>
  <legend>Do you like food?</legend>
  <label><input type="radio" name="like_food" value="yes"> Yes</label>
  <label><input type="radio" name="like_food" value="no"> No</label>
</fieldset>

<when like_food = yes>
  <fieldset>
    <legend>Do you have a favorite food?</legend>
    <label><input type="radio" name="have_favorite" value="yes"> Yes</label>
    <label><input type="radio" name="have_favorite" value="no"> No</label>
  </fieldset>
</when>

<when have_favorite = yes>
  <label>What's your favorite food?</label>
  <input type="text" name="favorite_food">
</when>

The first one, means "Do you like food?" will contain more than just the radio-buttons to answer that question, but it also means it's possible to "drill down" into that "group of related questions", which I've found to be helpful when testing with e.g. findByRole('group', ...). But I don't know if it would be equally helpful for people using assistive technologies, or if it would actually make it more confusing.

With the second option, it's not possible to "drill down" into the groups, but each fieldset with a question in the legend only has the radio-buttons to ask that particular question.

Any advice? What is "most correct" and best ux here?


Added: Screenshot of such a question on a (norwegian) website. The first question is a yes/no question. The second question only appears if the user selects "yes" to the first one. Since the fieldset doesn't have any frame or padding, it looks the same whether the second fieldset is inside or after the first one.

screenshot

3
  • Don't you have any visual examples instead of code?
    – Danielillo
    Mar 18 at 12:28
  • To "normal users" they would look exactly the same, at least in the current design of this website, so I didn't add any. I can add a screenshot from one such question, but yeah.
    – Svish
    Mar 18 at 12:52
  • @Danielillo Screenshot added 🙃
    – Svish
    Mar 18 at 12:59

1 Answer 1

1

From an accessibility perspective, it would be better to not nest the fieldsets. Some screen readers announce the <legend> for all parent fieldsets. For example, with JAWS, if you tab backwards through the form in your nested example, meaning you tab to the "What's your favorite food?" <input> field first, you'd hear:

  • "Do you like food?, group"
  • "Do you have a favorite food?, group"
  • "What’s your favorite food?, Edit, Type in text"

So in this case I tabbed backwards to the input field and I heard the outermost fieldset/legend first, then the middle nested fieldset/legend, and then the label for the input field. It was read as one long paragraph and not as separate bullet points. The bullet points above were just to make it easier to read.

This doesn't happen when you tab forwards with JAWS (???). Not sure why. But it shows how it might sound confusing in some situations.

You don't gain anything by nesting them compared to having them separate.

(Note: I had changed the <label> on the <input> in your example to have the closing </label> after the <input> so that the label would be correctly associated with the field. That was probably just a typo in your original example because you had the labels of the radio buttons correct. But without that change, my third bullet point above would just say "Edit, Type in text".)

Note that having new form elements appear based on selecting other form elements could be an accessibility issue if the user doesn't know that new form elements are going to appear. See WCAG 3.2.2

Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component.

Where "change of text" includes

  1. content that changes the meaning of the Web page

So you'd want to be clear to the user that answering questions might cause other elements to appear.

The same is true even if all the form elements are visible but they are currently disabled until the user selects certain elements.

3
  • Do you mean that fieldsets should not be nested at all, or just that in this case with these radio-buttons, it's not good to do it for the screen reader?
    – Svish
    Mar 21 at 11:32
  • Oh, and yeah, in reality, all our labels and input-fields are actually linked with uniquely generated ids, I was just lazy when typing the example :P
    – Svish
    Mar 21 at 11:32
  • There might be situations where hearing multiple fieldsets might make sense. If you have a very large form contained in a fieldset, and then there are some sub-fieldsets inside it, it might help to hear both legends announced, but as I mentioned, not all screen readers do this. In your example, it's not needed. As a general rule, it's probably not needed either but there could be remote cases where it would be helpful. Mar 21 at 17:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.