Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unclear which legend element to be used as accessible name for fieldset #145

Closed
zcorpan opened this issue Aug 27, 2018 · 4 comments
Closed

Comments

@zcorpan
Copy link
Member

zcorpan commented Aug 27, 2018

5.5.1 fieldset Element Accessible Name Computation
If the fieldset element has an aria-label or an aria-labelledby attribute the accessible name is to be calculated using the algorithm defined in Accessible Name and Description: Computation and API Mappings 1.1.
Otherwise use legend subtree
Otherwise use title attribute
If none of the above yield a usable text string there is no accessible name

What is the legend subtree?

Similarly for figure/figcaption, table/caption.

Cases to consider:

  • there might be no such child element
  • there might be more than one such child element
  • the flat tree might differ from the DOM tree (e.g. if there's a display: contents element in between, or if it crosses a shadow DOM boundary).
  • the element might exist in the DOM but not in the flat tree (e.g. display: none).
@LJWatson
Copy link
Contributor

What is the legend subtree?>

Good question! In this context I think it would be the child of the element in question (a heading inside a legend element for example), where it is the content of the child element that becomes the accessible name for the grandparent.

<fieldset>
<legend><h2>Contact information</h2></legend>
...
</fieldset>

there might be no such child element>

Continuing with legend as an example...

If the legend element has no children, the text content of the legend becomes the accessible name for the fieldset. If there is no legend element inside the fieldset, the fieldset does not have an acessible name (unless it's been provided using ARIA).

there might be more than one such child element>

If the legend element has multiple conforming children, the combined text content inside those children would become the accessible name for the fieldset. I haven't tested this extensively though (because it isn't a pattern seen in the wild beyond span elements AFAIK).

If there are multiple legend elements inside the fieldset, only the first is used as the accessible name for the fieldset.

the flat tree might differ from the DOM tree (e.g. if there's a display: contents element in between, or if it crosses a shadow DOM boundary).>

I'm not sure about the shadow DOM boundary, but a brief experiment suggests that inserting an element with display:contents; between the opening fieldset tag and the legend, has no noticeable effect on the behaviours described above.

Another quick experiment suggests that putting display:contents; on the legend itself has no impact on the accessible name calculation. Probably because the legend element itself does not convey any specific semantic information, the removal of semantics caused by display:contents; in some browsers is irrelevant in this instance. Similarly, the removal of semantics on any child elements inside the legend has no apparent effect on the accessible name calculation.

the element might exist in the DOM but not in the flat tree (e.g. display: none)>

If display:none; is set on the legend or it's children, that element is removed from the accessible name calculation.

@zcorpan
Copy link
Member Author

zcorpan commented Aug 28, 2018

I'm not sure about the shadow DOM boundary, but a brief experiment suggests that inserting an element with display:contents; between the opening fieldset tag and the legend, has no noticeable effect on the behaviours described above.

How did you experiment?

I tested in Firefox and Chrome on macOS, using their accessibility tree view in developer tools, with this test case.

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/6165

In both browsers, the fieldset is represented as a "group" node with accessible name "The legend" for the first fieldset, and a "group" node with accessible name "" for the second fieldset, which suggests that there is a difference.

If display:none; is set on the legend or it's children, that element is removed from the accessible name calculation.

The spec doesn't say so AFAICT, and at least in Firefox, for this test case

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/6166

the "group" node still has the accessible name "The legend". (In Chrome it is "".)

@zcorpan
Copy link
Member Author

zcorpan commented Aug 29, 2018

shadow DOM

For this test

https://github.com/web-platform-tests/wpt/blob/89d1f02395ce625bc98745ba8c53729c00dc5b1a/html/semantics/forms/the-fieldset-element/accessibility/shadow-dom-manual.html

Both Firefox and Chrome have empty accessible name for the "group" node in the accessibility tree.

@zcorpan
Copy link
Member Author

zcorpan commented Aug 29, 2018

Based on the above, I propose that the accessible name algorithm use the same logic as how it's defined semantically in the HTML standard:

The caption is given by the first legend element that is a child of the fieldset element, if any.

https://html.spec.whatwg.org/multipage/form-elements.html#the-fieldset-element

Separately, on the difference for display: none, it seems like Firefox is using innerText to get the text to use as the accessible name -- it uses the textContent if the element is itself display: none but otherwise will ignore display: none children, just like innerText.

Edge seems to not give the fieldset an accessible name at all, unless you use aria-label or aria-labelledby or title attributes.

zcorpan added a commit to zcorpan/html-aam that referenced this issue Aug 30, 2018
stevefaulkner pushed a commit that referenced this issue Sep 7, 2018
* Clarify which legend/figcaption/caption element to use

Fixes #145.

* Keep trying to find an accessible name/description if earlier steps didn't yield anything

thanks @zcorpan
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants