-
Notifications
You must be signed in to change notification settings - Fork 328
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
Add heading level option to label component called headingLevel
#5240
base: main
Are you sure you want to change the base?
Add heading level option to label component called headingLevel
#5240
Conversation
This optional setting only works if the label is a page heading i.e `isPageHeading` is set to true. A HMPPS service had an external accessibility audit raised the following point on a few of it pages: > The form labels are styled to look like headings and stand out visually. While sighted users can identify headings based on larger font size and bold formatting, screen reader users rely on proper HTML markup to understand the structure of a page. > Screen reader users sometimes jump between the headings of the page to gain a better understanding of the structure and content on the page. The [WebAIM screen reader survey](https://webaim.org/projects/) has found that [headings are the number one means by which screen reader users get a sense of a complex page](https://webaim.org/projects/screenreadersurvey9/#finding). When headings are not available programmatically to users, it affects the time and effort needed to understand how the content is presented on the page. Furthermore, this creates a discrepancy between information available to a sighted individual and users relying on assistive technology. They suggested something like ``` <h2> <label class="govuk-label govuk-label--m" for="myInputField"> This is a h2 label </label> </h2> ``` The problem is that the existing label component: 1. It does support custom html, but that would place the headings inside the label means Inline elements would contain block level elements which is not valid 2. Using isPageHeading, uses a hard coded h1 so cannot use that options These changes are backwards compatible by setting the heading level to 1.
Hi Alistair! Thanks for the suggestion, this feels useful, but before moving further with it, we'll likely want some more input from our accessibility specialist and research to better understand when and when not form labels need wrapping in headings so we could issue the appropriate guidance with the option. Releasing the option would also have an effect on our Fieldset component which has a similar In terms of API, it may be preferable to have it replace the As an aside for when we look further into this, I've tracked the introduction of the |
Thanks for your replying. A very good point about fieldset component would need to behave in exactly the same way. Do you want me to make those changes as part of this PR? I agree, replacing isPageHeading might be a better option but I was trying to suggest a smaller change that wouldn't break existing functionality and mean that the change would have to wait to be part of a major version bump. It terms of this change, I'm not 100% clear on what is required of me to move this forward. Happy to help out and contribute as much as I can. |
@aliuk2012 I think the next step before going any further is to figure when/when not to make field labels headings from an accessibility standpoint. Would you or your organisation have any research around when/when not to make field labels headings? @selfthinker are you aware if it's something that's ever been looked into at GDS (seems the original PR only added |
This optional setting only works if the label is a page heading i.e
isPageHeading
is set to true.A HMPPS service had an external accessibility audit raised the following point on a few of it pages:
They suggested something like
The problem is that the existing label component:
These changes are backwards compatible by setting the heading level to 1.