Should fieldsets be nested for yes/no questions?



  • 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:

    
      Do you like food?
       Yes
       No
      
        
          Do you have a favorite food?
           Yes
           No
    
      <when have_favorite = yes>
        <label>What's your favorite food?</label>
        <input type="text" name="favorite_food">
      </when>
    </fieldset>
    

    vs

    
      Do you like food?
       Yes
       No
    
    
      
        Do you have a favorite food?
         Yes
         No
      
    
    
      What's your favorite food?
      
    
    

    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. https://testing-library.com/docs/queries/byrole . 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



  • From an accessibility perspective, it would be better to not nest the fieldsets. Some screen readers announce the for all parent fieldsets. For example, with https://www.freedomscientific.com/products/software/jaws/ , if you tab backwards through the form in your nested example, meaning you tab to the "What's your favorite food?" 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 on the in your example to have the closing after the 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 https://www.w3.org/TR/WCAG21/#on-input

    Changing the setting of any user interface component does not automatically cause a https://www.w3.org/TR/WCAG21/#dfn-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.




Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2