Links embedded in a fieldset > legend not reading correctly with JAWS + IE11

[eppixdev]

Describe the bug
When passing in a link to hint as a prop in ChoiceList, TextField, or FormLabel (maybe some others?) JAWS + IE11 won't read the link text because it's nested in the legend element.

Related:
https://www.powermapper.com/tests/screen-readers/labelling/fieldset-links/

To Reproduce
Steps to reproduce the behavior:

1. Pass link as a prop to one of the above Components

Expected behavior
Screen readers to read the link text

Screenshots
Current (ChoiceList):

<fieldset>
  <legend>
    <span>
      Some hint text here
    </span>
    <a href="link">Click here to learn more</a>
  </legend>
  ... choices
</fieldset>

Possible Fix:
Moving the link out of the legends fixes the issue AFAIK.

<fieldset>
  <legend>
    <span>
      Some hint text here
    </span>
  </legend>
  <a href="link">Click here to learn more</a>
  ... choices
</fieldset>

Desktop (please complete the following information):

• OS: [e.g. iOS]
• Browser [e.g. chrome, safari]
• Version [e.g. 22]

Smartphone (please complete the following information):

• Device: [e.g. iPhone6]
• OS: [e.g. iOS8.1]
• Browser [e.g. stock browser, safari]
• Version [e.g. 22]

Additional context
Originally reported by @1Copenut here: https://jira.cms.gov/browse/MEA-215

[1Copenut]

@eppixdev Yes, moving the <a> out of the <legend> and into its own space, possibly in a div that sits between the legend and the div containing your checkboxes / radio buttons should work well. You may have to add aria-labelledby attributes to the inputs themselves, and IDs to each label and the legend to get all screen reader pairings to respond correctly.

Recommend testing this solution with several pairings:

• IE11 + JAWS (Win10)
• Chrome + JAWS (Win10)
• Firefox + NVDA (Win10)
• Safari + VoiceOver (MacOS)
• Mobile Safari + VoiceOver (iOS, ideally)

<form>
  <legend id="unique-legend-id">Your legend text</legend>
  <div>
    <a href="#">Trigger to open the help drawer</a>
  </div>
  <div>
    <input
      aria-labelledby="unique-legend-id unique-label-id-1"
      id="checkbox-1"
      name="option-1"
      type="checkbox" 
    />
    <label for="checkbox-1" id="unique-label-id-1">Checkbox one label</label>
    ...
  </div>
</form>

[bernardwang]

Tracked here: https://jira.cms.gov/browse/WNMGDS-281

[bernardwang]

One possible issue with moving the link outside of the legend is that the "hint" text is supposed to come before the error message, which is inside the legend. I assume it's not possible to move the error message outside of the legend right? @1Copenut @davidakennedy @melwoodard

[line47]

I'm wondering what it would look like to separate out the legend from the formlabel component and would recommend we update formlabel to only render labels and not legends as well.

I see the value and reason to have a fieldset and legend on components like checkboxes or radios but think the hint text should render outside of the legend in those instances as @1Copenut and @eppixdev pointed out.

Maybe we should create legend and legend hint props to allow for this customization and make it more clear how the prop will be applied. Right now it's a bit confusing and unclear about where and how the props will be rendered.

[1Copenut]

I'm wondering what it would look like to separate out the legend from the formlabel component and would recommend we update formlabel to only render labels and not legends as well.

I'd be all for that. We should approach this deliberately and ensure good test coverage. Our whole form system uses formlabel to generate <label> and <legend> tags ATM.

[line47]

I'd be nice to get a cross-section of formlabel <legend> usage in the wild

[davidakennedy]

I agree with what @line47 mentions here. And would be happy to test things out.

I wonder if it's smarter to make a fieldset component, and pair that with the legend?

[bernardwang]

@davidakennedy are you ok with removing hint text and error messages from the legend? This would prevent the need to add new props or any other technical solutions. So it would look like this:

<fieldset>
   <legend> Select an option </legend>
   <span class="ds-c-field__hint">Optional</span>
   <span class="ds-c-field__hint ds-u-color--error">blah blah error</span>
    ....

<div>
   <label> 
       Select an option 
       <span class="ds-c-field__hint">Optional</span>
       <span class="ds-c-field__hint ds-u-color--error">blah blah error</span>
  </label>
    ....

[bernardwang]

And as far as the splitting FormLabel convo, my take is that the most important thing is that all the form input components are using the correct markup. Currently that means ChoiceList & DateField are using legend+fieldset and Dropdown & TextField are using label. Aside from those components, FormLabel will only be used for custom form use cases, in which the developer has to choose the correct component type anyway.

In that case, I dont think there's a whole lot of benefit for separating out FormLabel besides being better naming.

    <FormLabel component="legend"> ... <FormLabel>
    vs 
    <FormLegend> ... <FormLabel>

So I wonder instead of separating the component, which would be a larger breaking change, we could instead remove the default value for the component props for FormLabel, which is currently set to label. This way every time someone wants to use FormLabel for a custom use case, they need to be explicit with whether they need legend or label.

[line47]

I think for fixing this issue moving the hint and error outside of the legend would fix the issue.
I still don't feel great about having the formlabel component generate legend and think it would make more sense to think about creating a fieldset component that can render a legend and including that where applicable.

[davidakennedy]

are you ok with removing hint text and error messages from the legend? This would prevent the need to add new props or any other technical solutions. So it would look like this

@bernardwang Yeah, I think it's fine.

Long term, as @line47 says, I'd like to see us create a fielset component. Also, related to this, an error summary component. Like this. Maybe by taking some of the pressure off other components to handle error messages, they become more versatile and usable.