Headings inside legends not recognised by JAWS

[andymantell]

Bug Report

What is the issue?

When headings (e.g. <h1>) are nested inside a <legend> JAWS does not announce them when pressing the H key.

I note that a very similar issue has been closed in the past at #534. However this issue is current and is unrelated to any overflow: hidden css. It occurs in a plain html page outside of the nhsuk-frontend styles.

We have observed this in user research as well as my own testing. In user research it resulted in a fair amount of confusion for one particular user who regularly used the H key - often as the first thing they pressed after the page loaded.

The issue is currently being tracked in the following issues, but I wanted to open this one here so that it doesn't fly under the radar for us.

FreedomScientific/standards-support#549
FreedomScientific/standards-support#100
alphagov/govuk-frontend#1605
w3c/html-aria#350
hmrc/accessibility#34

What steps are required to reproduce the issue?

Create a page with the following markup, and listen to it with JAWS. Press the H key - observe that it says "No headings available"

<form>
  <fieldset>
    <legend><h1>This is a heading and a legend</h1></legend>    
    
    <label for="demo-input">Label</label>
    <input id="demo-input" type="text">
  </fieldset>
</form>

What was the environment where this issue occurred?

• Device: PC
• Operating System: Windows 10
• Browser: Chrome
• Browser version: 94
• NHS.UK frontend package version: N/A - this is a basic html issue
• JAWS version - 2021.2107.12

[andymantell]

Have a possible resolution, at least as a stop gap while JAWS fixes the underlying bug. Details here:

FreedomScientific/standards-support#549

Basically involves adding role="heading" aria-level="1" onto the <legend>. Am putting together some test cases using this technique and am going to test it thoroughly as it's slightly "exotic" so am concerned it could have adverse effects elsewhere.

[andymantell]

Working on a possible solution here:

https://nhs-duec.github.io/headings-inside-legends-test-cases/

[NickColley]

This is an interesting idea and loving the work to test it out, one test case to consider since you're proposing to change the semantics of the legend element is to check if that breaks context for things like radio or checkboxes. Does it get lost because now assistive technology considers it a heading e.g. going back to only announcing options and not the question as well.

Scenario: radios that say yes or no. Normally they'd get the question announced with the options making it easy to answer them when focusing the options themselves.

From a tree perspective my hunch is you're proposing this, just with aria roles. Which of course solves the heading navigation issue but breaks the arguably more useful association.

<fieldset>
  <h1>...</h1>
</fieldset>

[andymantell]

Thanks @NickColley that's a great point - I will add a test case to exercise this specifically

[NickColley]

Sweet, much love Andy, hope it turns out this pattern works well for both cases though.

[andymantell]

@NickColley I can't get JAWS to announce the legend when looking at radio buttons even before making my change. Is this definitely how it's intended to work? In NVDA when I press F to go to the radio button, it announces the legend first, even after my fix. But JAWS doesn't do this in either case.

[andymantell]

When I ask JAWS for all the form elements though, it still seems to recognise the association with the legend, even with the role="heading" added, so I'm fairly confident that this is at least as it was before:

[NickColley]

It may vary between different assistive technologies it's been a while since I've tested this so can't remember I'll be honest. Worth trying more than JAWs for this one I think if you're able to.

[andymantell]

oh absolutely, I'm testing as much as I can get my hands on, and, though he doesn't know it yet, I'm hoping @mcheung-nhs might be able to have a look through as well to test with a few other things

[andymantell]

Using the following markup pattern has tested well so far:

<legend class="nhsuk-fieldset__legend nhsuk-fieldset__legend--l" role="heading" aria-level="1">
  <span class="nhsuk-fieldset__heading">What is your address?</span>
</legend>

Tested in:

Windows 10 | Chrome 94 | JAWS 2021
Windows 10 | Chrome 94 | NVDA 2021.1
Windows 10 | Firefox | NVDA 2021.1
Windows 10 | IE11 | NVDA 2021.1
Windows 10 | Edge | NVDA 2021.1
Android 10 | Chrome 94 | TalkBack
iOS 14.7.1 | Safari | Voiceover

@mcheung-nhs Would you be able to take a look through the examples here https://nhs-duec.github.io/headings-inside-legends-test-cases/ at some point? Would be good to get another opinion. I'll DM you separately - it might be good to have a quick video call to explain.

[andymantell]

@adamliptrot-oc was able to test MacOS / Voiceover for me as I can't test that platform - but unfortunately it appears that the heading was not accessible when using the role="heading". Which is probably enough to make this pattern unviable :-/

[mcheung-nhs]

I also tested on (fairly old) MacOS/Safari/VoiceOver (Catalina 10.15.5, Safari 13.1.1) and the headings list was not there when using the rotor. However, I tried it on the latest version of Chrome and the headings list was there:

[andymantell]

To wrap this up for a moment - on 111 online we're going to un-nest the headings/legends, so for the time being we will have duplicated h1 and legend elements. Not ideal, but I think better than the current situation in JAWS. Not necessarily suggesting this gets rolled out to the design system, but this is the stopgap we're putting in on our service.

Beyond that - I think we just have to monitor the JAWS bug...

[andymantell]

Update from alphagov/govuk-frontend#1605 (comment)

"We've had an update from Freedom Scientific which suggests that this bug will be looked at as part of their 2022 cycle (i.e: released as an update at some point to version 2022)."

[andymantell]

As per the update on this thread, this is now fixed in JAWS 2022:

alphagov/govuk-frontend#1605 (comment)