Skip to content
This repository has been archived by the owner on Jul 30, 2019. It is now read-only.

Consider adding headings to allowed content in <legend> element #724

Closed
DavidMacDonald opened this issue Nov 14, 2016 · 5 comments
Closed
Assignees
Milestone

Comments

@DavidMacDonald
Copy link

DavidMacDonald commented Nov 14, 2016

Screen reader users often navigate using headings. Many web developers wrap up groups of form fields in the <fieldset> <legend> construct and they feel this is most accessible. There are some accessibility wins with this construct but the big loss is the that headings cannot be used according to current HTML spec which only allows "phrasing" content https://www.w3.org/TR/html5/dom.html#phrasing-content-1

I've done some testing of headings inside <legend> elements and it doesn't appear to break anything in browsers, and it is navigable by assistive technology which easily find these headings.
http://davidmacd.com/test/fieldset-legend-heading.html

Therefore, it appears simply allowing heading content in the <legend> element would be a reasonable amendment to the spec.

https://www.w3.org/TR/html5/forms.html#the-legend-element

Proposed amendment
In section 4.10.17 under content model change
Content model:
Phrasing content.

to

Content model:
Phrasing content or Heading content

With a link on Heading Content to
https://www.w3.org/TR/html5/dom.html#heading-content

@stevefaulkner stevefaulkner changed the title Consider adding headings to allowed content in <legend> tag Consider adding headings to allowed content in <legend> element Nov 14, 2016
@StommePoes
Copy link

Also, legends are screwed up by some AT, despite legends/fieldsets existing since like forever https://twitter.com/powermapper/status/797913194404728832 and this could be a useful solution.

@stevefaulkner
Copy link
Contributor

any input @sideshowbarker?

@chaals chaals added the a11y label Nov 14, 2016
@chaals
Copy link
Collaborator

chaals commented Nov 14, 2016

At a glance this seems reasonable.

It would be nice if form navigation were better - especially for the nearly all of us who don't use screen readers - and it is in principle feasible to use ARIA with legends in this way already to achieve the same effect for screen readers.

But this doesn't seem to break anything, to enable an improvement, and to match what at least some people do as they design forms. All of which should count as arguments in its favour.

@sideshowbarker
Copy link
Contributor

any input @sideshowbarker?

Seems like a good change to me, for the same reasons @chaals and @StommePoes and @DavidMacDonald give and because I can’t think of any authoring mistake it would prevent an HTML checker from helping authors catch.

This history FWIW is that HTML4 restricted legend to inline/phrasing and we just propagated that because as far as I remember at least nobody til now ever proposed loosening it.

@chaals
Copy link
Collaborator

chaals commented Nov 23, 2016

@stevefaulkner if you can explain this, get agreement and do it in a hurry, that would be grand. If someone - @DavidMacDonald ?? provides a Pull Request that would be even grander :)

Otherwise please re-assign the milestone to give a bit more time for consideration…

arronei pushed a commit to arronei/html that referenced this issue Apr 17, 2017
selfthinker added a commit to alphagov/govuk_elements that referenced this issue Jun 28, 2017
When we have one thing per page, our current pattern is
to let the h1 be the question and then repeat but visually hide it
in the legend (or label).
That means screen readers will read the question twice,
which is not a proper barrier but annoying and gets raised as an issue
again and again, e.g. in #320 or on the cross-government accessibility mailinglist
and from accessibility auditors.

This changes that by moving the h1 into the legend.
That is currently invalid but will be valid in HTML 5.2
[https://www.w3.org/TR/html52/sec-forms.html#the-legend-element]
and the W3C validator passes it fine.
Also see the reason for the change: w3c/html#724.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants