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

legend seems to be recognised/used even when not *first* child #6645

Open
patrickhlauke opened this issue May 3, 2021 · 21 comments
Open

legend seems to be recognised/used even when not *first* child #6645

patrickhlauke opened this issue May 3, 2021 · 21 comments
Labels
clarification Standard could be clearer

Comments

@patrickhlauke
Copy link
Member

From some basic testing (https://codepen.io/patrickhlauke/pen/MWJNXXr) it seems that a <legend> is correctly recognised and used to provide the accessible name for a <fieldset> (in the accessibility tree) regardless of whether it's the first child of the <fieldset> or not - at least testing in Chrome, Firefox, Safari (macOS). could/should this be reflected in the spec?

It seems it still needs to be a child element (so sadly, it's not currently possible to have it at a deeper level / have some other wrapper/container in between) - while I'd love to see this relaxed as well (and allow something more along the lines of <fieldset><div><legend>...</legend> ... </div></fieldset>, I don't think there's currently any strong desire from implementations to change this.

@patrickhlauke patrickhlauke changed the title legend seems to be recognised/used even when not first child legend seems to be recognised/used even when not *first* child May 3, 2021
@annevk
Copy link
Member

annevk commented May 3, 2021

Are you talking about conformance or implementation requirements? As I think the latter is already covered by

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

@patrickhlauke
Copy link
Member Author

I'm basing this on https://html.spec.whatwg.org/multipage/form-elements.html#the-legend-element

Contexts in which this element can be used: As the first child of a fieldset element.

unless that means something other than "to be valid, it must be the first child..."

@annevk
Copy link
Member

annevk commented May 3, 2021

Hence my question.

@patrickhlauke
Copy link
Member Author

patrickhlauke commented May 3, 2021

well, implementation reality seems to be that engines don't care if it's the first child or the whatever child, as long as it's a child element. so should the spec not say that? (so i'm guessing that's conformance?)

i.e. can the wording in the spec match reality plz

@annevk
Copy link
Member

annevk commented May 3, 2021

It already does, per the sentence I quoted. It's just not conforming to put it anywhere. There are many cases like that, e.g., </br> is non-conforming even though it's parsed as <br> everywhere.

What's the use case for not having it as the first element child?

@patrickhlauke
Copy link
Member Author

patrickhlauke commented May 3, 2021

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

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

and then a screenful later https://html.spec.whatwg.org/multipage/form-elements.html#the-legend-element it says

As the first child of a fieldset element.

am i the only one thinking that these are two distinct statements that are contradictory?

What's the use case for not having it as the first element child?

I'm not interested in use cases per se. More about internal consistency in what the spec actually says (rather than having contradictory statements like the two above) - and either accepting that, as it says in the fieldset section, the legend can be any child (not necessarily the first), or not (and then changing the sentence in the definition for the fieldset element?), rather than the current vagueness/contradiction.

@annevk
Copy link
Member

annevk commented May 3, 2021

Some statements apply to web developers and some statements apply to implementers. So while they may seem contradictory, they are in fact complementary. Typically the latter is a superset. E.g., while the font element is non-conforming, the HTML standard still has to say something about it as you cannot create a competitive browser without it.

@patrickhlauke
Copy link
Member Author

clearly my understanding of en-US-x-hixie is not as sharp as it should be then... feel free to close this, but this is clearly confusing to commoners like myself...

@annevk
Copy link
Member

annevk commented May 3, 2021

This kind of thing has come up before and we should probably more clearly separate the implementation requirements for all the element definitions (and at the same time merge in the "obsolete" stuff that's now on the other side of the document). But that's a lot of work.

@annevk annevk added clarification Standard could be clearer and removed document conformance labels May 3, 2021
@annevk
Copy link
Member

annevk commented May 3, 2021

(I wonder what parts qualify as -x-hixie now we have https://whatwg.org/style-guide. I guess it's mostly an homage at this point.)

@patrickhlauke
Copy link
Member Author

I wonder what parts qualify as -x-hixie

to me, it's more the propellerhead engineering mentality vs clarity for a layperson ;)

@domenic
Copy link
Member

domenic commented May 3, 2021

That doesn't really seem fair or called for... The difference between conformance requirements and implementation requirements is important, even if sometimes confusing.

@patrickhlauke
Copy link
Member Author

then it's worth trying to make it more obvious/less confusing. having two statements that appear to directly contradict each other, and don't match with reality of what browser engines actually do, seems odd. anyway...

@shirsha
Copy link

shirsha commented May 6, 2021

In Edge browser, the legend is not calculated as the accessible name (in the accessibility tree) for a fieldset if the legend is not the first child.
Please see the discussion we had in Slack a11y -General channel on April 6th. As per the conversation in the slack, legend must be the first child of the fieldset.
In WHATWG spec, having two contradict statement is confusing.
"WHATWG spec page on form elements says the legend can be used as the first child of a fieldset element. However, the fieldset section says only that "the caption is given by the first legend element that is a child of the fieldset element" (emphasis added). They don't seem to agree."

Once WHATWG spec is clear, than we can ask aria group to change the fieldset Element Accessible Name Computation for #2
from
"If the accessible name is still empty, then: if the fieldset element has a child that is a legend element, then use the subtree of the first such element."
to
"If the accessible name is still empty, then: if the fieldset element has a first child that is a legend element …"

@annevk
Copy link
Member

annevk commented May 7, 2021

As per the discussion above that's a bug in Edge. The intent of the specification is that it's non-conforming for developers to have legend not be the first child, but that implementations must nevertheless use the first legend element child they come across.

@shirsha
Copy link

shirsha commented May 7, 2021

WHATWG itself says on form elements says the legend can be used as the first child of a fieldset element.. That's what browser is doing. I don't think it is browser issue. Spec should be clear.

@annevk
Copy link
Member

annevk commented May 7, 2021

This is what the specification says that is applicable to user agents:

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

It doesn't have to be the first child.

It's clear that some people find it confusing that web developer and user agent requirements differ and that we should do more to ameliorate that, but that doesn't make it not the case.

@shirsha
Copy link

shirsha commented May 7, 2021

From the slack conversation and other github bugs it seems many of them are confused with the fieldset and legend rule.
https://web-a11y.slack.com/archives/C042TSFGN/p1620333136251600

I think it would be beneficial to many user if this is made clear.

@annevk
Copy link
Member

annevk commented May 7, 2021

I cannot access that, but the reason this issue is open and not closed is to get that clarified. So I think we're on the same page now. 😊

@shirsha
Copy link

shirsha commented May 7, 2021

Pasted the chat conversation for your reference :)

AcessGub 20 hours ago
For the

element, should the must be the first child of the element? Currently in Edge browser, legend is not calculated as caption for in accessibility tree if it is not the first child.
9 replies

erik 20 hours ago
Contexts in which this element can be used:
As the first child of a fieldset element
https://html.spec.whatwg.org/multipage/form-elements.html#the-legend-element
✔️
1

AcessGub 20 hours ago
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.
If the accessible name is still empty, then: if the fieldset element has a child that is a legend element, then use the subtree of the first such element.
If the accessible name is still empty, then:, if the fieldset element has a title attribute, then use that attribute.
Otherwise, there is no accessible name.

AcessGub 20 hours ago
For me #2 doesn't reflect the same, so was wondering. Thanks for the input

mallory 19 hours ago
Hi the order absolutely matters, also things like wrapping divs and stuff around legends... but it differs between browsers.
https://stommepoes.nl/work/fieldsets.html
👍:skin-tone-6:👍
2

mallory 19 hours ago
but so, if the legend is not the first, direct child of a fieldset, all bets are off so... don't. :)

ccwilcox 19 hours ago
@AcessGub it looks like that's a quote from the HTML Accessibility API Mappings on fieldset. Based on the WHATWG link Erik provided, the text for #2 should be changed to something like "… has a first child that is a legend element …"

ccwilcox 19 hours ago
Hm, the WHATWG spec page on form elements says the legend can be used as the first child of a fieldset element. However, the fieldset section says only that "the caption is given by the first legend element that is a child of the fieldset element" (emphasis added). They don't seem to agree.
👀
1

AcessGub 19 hours ago
with whom should I raise issue 🙂

scott o’no 18 hours ago
add on here, rather than create a new issue: #6645
GitHubGitHub
legend seems to be recognised/used even when not first child · Issue #6645 · whatwg/html
From some basic testing (https://codepen.io/patrickhlauke/pen/MWJNXXr) it seems that a is correctly recognised and used to provide the accessible name for a

(in the ... (113 kB)
#6645

👍
1

For the

element, should the must be the first child of the element? Currently in Edge browser, legend is not calculated as caption for in accessibility tree if it is not the first child.
9 replies

erik 20 hours ago
Contexts in which this element can be used:
As the first child of a fieldset element
https://html.spec.whatwg.org/multipage/form-elements.html#the-legend-element
✔️
1

AcessGub 20 hours ago
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.
If the accessible name is still empty, then: if the fieldset element has a child that is a legend element, then use the subtree of the first such element.
If the accessible name is still empty, then:, if the fieldset element has a title attribute, then use that attribute.
Otherwise, there is no accessible name.

AcessGub 20 hours ago
For me #2 doesn't reflect the same, so was wondering. Thanks for the input

mallory 19 hours ago
Hi the order absolutely matters, also things like wrapping divs and stuff around legends... but it differs between browsers.
https://stommepoes.nl/work/fieldsets.html
👍:skin-tone-6:👍
2

mallory 19 hours ago
but so, if the legend is not the first, direct child of a fieldset, all bets are off so... don't. :)

ccwilcox 19 hours ago
@AcessGub it looks like that's a quote from the HTML Accessibility API Mappings on fieldset. Based on the WHATWG link Erik provided, the text for #2 should be changed to something like "… has a first child that is a legend element …"

ccwilcox 19 hours ago
Hm, the WHATWG spec page on form elements says the legend can be used as the first child of a fieldset element. However, the fieldset section says only that "the caption is given by the first legend element that is a child of the fieldset element" (emphasis added). They don't seem to agree.
👀
1

AcessGub 19 hours ago
with whom should I raise issue 🙂

scott o’no 18 hours ago
add on here, rather than create a new issue: #6645
GitHubGitHub
legend seems to be recognised/used even when not first child · Issue #6645 · whatwg/html
From some basic testing (https://codepen.io/patrickhlauke/pen/MWJNXXr) it seems that a is correctly recognised and used to provide the accessible name for a

(in the ... (113 kB)
#6645

👍
1

@hrvojegolcic
Copy link

What's the use case for not having it as the first element child?

Simply wrapping a LEGEND into a DIV does not seem to be unreasonable thing to do for any developer out there, whether it's for styling, or for structuring the code. It's as logical and straightforward as any other markup.

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

It doesn't have to be the first child.

But yet still the following code is not valid in https://validator.w3.org/nu/

<!DOCTYPE html>
<html lang="">
  <head>
    <title>Test</title>
  </head>
  <body>
    <fieldset>
      <div>
        <legend>OK</legend>
      </div>
      <div>
        <input type="text"/
      </div>
  </fieldset>
  </body>
</html>

HTML Validation Error: Element legend not allowed as child of element div in this context.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clarification Standard could be clearer
Development

No branches or pull requests

5 participants