-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Comments
Are you talking about conformance or implementation requirements? As I think the latter is already covered by
|
I'm basing this on https://html.spec.whatwg.org/multipage/form-elements.html#the-legend-element
unless that means something other than "to be valid, it must be the first child..." |
Hence my question. |
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 |
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., What's the use case for not having it as the first element child? |
so in https://html.spec.whatwg.org/multipage/form-elements.html#the-fieldset-element it says
and then a screenful later https://html.spec.whatwg.org/multipage/form-elements.html#the-legend-element it says
am i the only one thinking that these are two distinct statements that are contradictory?
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. |
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 |
clearly my understanding of |
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. |
(I wonder what parts qualify as |
to me, it's more the propellerhead engineering mentality vs clarity for a layperson ;) |
That doesn't really seem fair or called for... The difference between conformance requirements and implementation requirements is important, even if sometimes confusing. |
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... |
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. Once WHATWG spec is clear, than we can ask aria group to change the fieldset Element Accessible Name Computation for #2 |
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. |
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. |
This is what the specification says that is applicable to user agents:
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. |
From the slack conversation and other github bugs it seems many of them are confused with the fieldset and legend rule. I think it would be beneficial to many user if this is made clear. |
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. 😊 |
Pasted the chat conversation for your reference :) AcessGub 20 hours ago 9 replies erik 20 hours ago AcessGub 20 hours ago AcessGub 20 hours ago mallory 19 hours ago mallory 19 hours ago ccwilcox 19 hours ago ccwilcox 19 hours ago AcessGub 19 hours ago scott o’no 18 hours ago #6645 👍 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 AcessGub 20 hours ago AcessGub 20 hours ago mallory 19 hours ago mallory 19 hours ago ccwilcox 19 hours ago ccwilcox 19 hours ago AcessGub 19 hours ago scott o’no 18 hours ago #6645 👍 |
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.
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> |
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.The text was updated successfully, but these errors were encountered: