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

Clarification regarding using <h1> as field descriptors #320

Closed
joefitter opened this issue Sep 20, 2016 · 2 comments
Closed

Clarification regarding using <h1> as field descriptors #320

joefitter opened this issue Sep 20, 2016 · 2 comments

Comments

@joefitter
Copy link

Guidelines for labels states that all form fields should be given labels, the second point states that these can be hidden if the surrounding context makes them unnecessary.

Due to these points we have inconsistencies throughout our forms and the ways labels, legends and <h1>s represent fields.

On some (multi-step) forms/pages the field label is displayed as the page <h1> with the field directly below. In this case it seems like elements suggests adding a label/legend and hiding it, as per the example here.

My concerns regarding this approach are firstly visual users will only see the title, but screenreader users will have the title read out, and then the identical visuallyhidden label read out afterwards. Secondly we have some steps which contain more than one field/label, so by using this pattern of header-for-label, the first field will appear to have more weight over the others.

For my first point I wanted to check if having a label/legend and an identical h1 is necessary? Could we use aria-describedby or aria-labelledby (or something else) to link the field directly with the H1 without the need for a label? Another suggestion would be to lose the H1 and use CSS to display the label/legend with H1 styling? If semantically a page requires a H1 and a label for a field, how come we are hiding them for visual users but not screenreader users?

For my point regarding multiple fields on a page, we have gotten around this on certain forms by using the <h1> as a section heading usually spanning a few pages (contact details, enquiry details etc) and in addition always displaying a relevant label/legend alongside fields and fieldsets.

Any clarification/guidance would by greatly appreciated as we seem to be coming up against this issue each time a form is developed!

@edwardhorsford
Copy link
Contributor

Hi Joel,

This has come up several times on the accessibility mailing list (are you on it?). I don't think we have a solution to your first problem yet. My understanding is that pages require an h1, and fieldsets require a legend. By hiding the legend, we get visual simplicity for sighted users. Sadly this means it's repeated for AT users. We'll hopefully look at this shortly, but I don't know what the solution will be.

To your second question - where there is more than one question / field on the page, it makes sense for the h1 to be more of a section heading, with labels and legends as appropriate for the various questions.

selfthinker added a commit 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.
@gemmaleigh
Copy link
Contributor

Fixed by #507, where the recommended solution is to move the <h1> inside the <legend> element - to avoid this duplication, where there is one question per page the heading and legend text are identical.

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

3 participants