review allowed roles for legend elements

[scottaohara]

In reviewing the following test case with latest browser / screen reader combos, the implicit functionality of the legend to still name its parent fieldset remains intact, while also being exposed as a heading or the specified level.

https://codepen.io/scottohara/pen/zYzzXrw

Seems that allowing a role=tab might also be good her for parity with role=heading.

role=none/presentation could also be allowed... though I don't see a good practical reason for that, since legend presently does not announce a role anyway... so negating the role announcements wouldn't be all that useful.

[JAWS-test]

In reviewing the following test case with latest browser / screen reader combos, the implicit functionality of the legend to still name its parent fieldset remains intact, while also being exposed as a heading or the specified level.

Just because that's how it currently works (rather coincidentally, right?) we can't rely on it always being that way, because it's not correct in itself that a legend with a different role, still serves as a label for a fieldset. That's why I would be against allowing legend to have other roles - unless it is specified somewhere that the labeling function of legend must be preserved, even if it has another role.

But would that be necessary? Someone who wants to have a heading as a legend can nest the heading in the legend: <legend><h2>...</h2></legend>

[scottaohara]

changing an element's role does not necessarily change its underlying semantic functionality. Just like changing an img to a role=button doesn't stop alt from providing it an accessible name, nor does changing an <a href> to any allowed role remove the link's native context menu menuitems.

re: "rather coincidentally, right?"

not sure what you're implying? I have seen this done on and off over the years. Just happened to give it a full shake down today.

re: "But would that be necessary?"

oh come now @JAWS-test, you're slipping. Don't you remember this old gem? FreedomScientific/standards-support#549 while not the original issue, the varied support goes back to at least 2018.

[JAWS-test]

changing an element's role does not necessarily change its underlying semantic functionality. Just like changing an img to a role=button doesn't stop alt from providing it an accessible name

This also seems to me to be a coincidence that cannot be relied upon, as this is not regulated in Accname in this way

oh come now @JAWS-test, you're slipping. Don't you remember this old gem? FreedomScientific/standards-support#549 while not the original issue, the varied support goes back to at least 2018

I don't think JAWS bugs should lead to adapting the specification in a way that can be dangerous (on the one hand because it's not clear how browsers will behave in the future, on the other hand because developers expect that a legend with heading role is no longer a legend).

When it comes to what doesn't work in JAWS, legend should also be able to be a checkbox, a link, or a radio button, because all of those don't work either, even though checkboxes and radio buttons, for example, are recommended by the HTML specification

[scottaohara]

I think I need to stress again that changing a role does not undo the strong native semantics / functionality of the underlying element. ARIA does not change functionality, nor has it ever. So, while I respect where your concerns are coming from, please do keep in mind that this is not mere coincidence, as you keep putting it.

Concerning JAWS bugs adapting a specification - yes the bug is related to the writing of this issue, however it is not the only reason I opened it. More so that I've recently encountered situations where this allowance would be helpful to developers. Furthermore, issues are filed against this spec requesting additions to role allowances for individual elements. The spec needs to consider these requests and constantly review itself. If some elements are too strict with their role allowances, and there is no adverse impact on allowing additional roles to an element, then the spec should be updated to accommodate developers for situations where they might need to use ARIA. This issue is not a promise that the spec will be updated. But it is indicating that we need to review this element to determine if an update would be useful.

Now per your final comment on the elements that JAWS doesn't respect, when nested within a legend, sure? Those can be on the table for consideration, but I wouldn't have put them there. One generally wouldn't expect a checkbox or radio to serve as an individual item in a group, while also serving as its overarching label.

[JAWS-test]

If ARIA roles are allowed for legend, I'm in favor of allowing them for caption/figcaption as well, for consistency. role=heading on caption/figcaption would make similar sense as on legend.

The only problem with figcaption would be if it is not at the beginning of figure. For caption and legend this is automatically the case according to the HTML specification.

[JAWS-test]

@scottaohara

changing a role does not undo the strong native semantics / functionality of the underlying element.

I did not realize that this was the case in every respect. I also didn't find this so explicit in the W3C ARIA documents. I also think that this is not true in every case. For example, if I add a role to a th element, the element no longer serves as a column header for the table - and I actually destroy the entire table structure. This may be because th is not considered a label element in the HTML specification, but is only used by the screen reader for this purpose. For label elements such as legend, label, caption, and figcaption, what you write does indeed seem to apply. However, it might be helpful to point out this difference in the ARIA specification, Accname or in https://www.w3.org/TR/using-aria/, right?

[scottaohara]

per your first comment:
would need to test that, due to the strong role relationship / heuristics of tables and the expected elements/roles that are allowed as child elements of tables. Much different than a fieldset/legend which is not nearly as convoluted how they are processed as a table.

Which goes into your second comment, Tables are messy due to their long history of misuse for layout purposes. There are the standards for tables, and then there are additional heuristics that both browsers and screen readers have for tables. E.g., a table will only be exposed as a table if certain conditions are met with standard HTML. The CSS display values can contribute to whether it is exposed as a table or not And as mentioned above, all tied up in here are strong role-relationship heuristics to make sure a table is exposed logically to AT.

Note that ARIA's conflict with host language semantics alludes to this topic. And as such, it is in this spec where the allowances are defined. I'll let @stevefaulkner decide if he thinks an example/description is worth adding to Using ARIA.

[andymantell]

I've put some examples together here using <legend role="heading" aria-level="1">:

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

So far this has been testing well, with no issues using:

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

With the main benefit for me being that it works around the JAWS bug mentioned here: FreedomScientific/standards-support#549

[scottaohara]

appreciate you putting these together, @andymantell. thanks for sharing the results.

[andymantell]

I've just had feedback from someone that they were unable to access the heading with MacOS / Voiceover. Which is probably enough to render the pattern unviable :-(

[scottaohara]

looks like macOS is ignoring the explicit role and webkit continues to treat the element as static text (per inspecting the element with macOS's a11y Inspector). Webkit dev panel shows the proper explicit ARIA roles/properties set to the element - so this is definitely just Webkit under the hood ignoring what developers are doing here.

As you noted in your results, and I can verify with iOS 15.0.1, the legend role=heading is respected. I'd submit there's a webkit bug to be filed here for the desktop behavior.