Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
No semantics to distinguish labels, hint texts and error messages #574
When we have a hint text and/or an error message under a label, we currently put everything into the label element and only separate them with spans. That is not very semantic and means it gets read out all at once by screen readers.
Screen reader output
Screenshot without CSS
Is this actually a problem?
This is probably just a relatively mild issue for screen reader users as they will be used to missing or small pauses between various texts. But it would be good to get confirmation from real screen reader users how big or small this issue is. @edwardhorsford told me there was a discussion about this before. Can you add a reference to that here?
But another issue is that this generally doesn't make a lot of semantic sense. You can best see the lack of semantics when you disable the CSS (see screenshot above).
Adding punctuation could work in general but will be really difficult to apply as form labels, hints and error message can be so very different per form. They are sometimes several sentences, sometimes a single sentence, sometimes just a word or several words with or without already existing punctuation.
Move out of label into paragraphs
Ideally labels, hints and error messages should be in their own paragraphs. But that is not possible if they're in the label as it would be invalid HTML. There are some people who also argue that if everything is within the label, it is too verbose for screen reader users.
I'm pretty sure there must be a couple of more solutions. But that is probably for a team which includes designers and content designers to figure out.
Is there a possible benefit for maintenance of forms in future?
With semantic markup, it ought to be much easier to extract the different text elements according to their use, and therefore to compare / check / decide whether they need to be updated.
For example, I can see a circumstance in which all the 'first name' boxes across GOV.UK need to be updated with a different hint text, such as 'as shown on your passport or driving license'. A much easier job if you have markup saying that there's hint text.
Assuming 'ariadescribedby' has good support there are definite advantages to splitting out the hint text from the label. Better semantic structure, more control over positioning etc.
If we did this, we could roll it out in Elements, or save it for GOV.UK Frontend. Thoughts?
@selfthinker I've forwarded you the thread from last year that I think I was talking about.
A possible downside of going with
We had a legend that contained both a label (“Does the person need any support getting around the airport or to and from the plane?”) and hint text (“For example, they are physically impaired or have communication difficulties”).
We tested with a screen reader user (not an actual user of our app; it’s an internal tool, and none of the current users use a screen reader), who found it repetitive to have so much text read out every time a radio button in the fieldset was focused.
Based on this feedback, we removed hint text from fieldset legends. We’ve yet to re-test to see if this causes any other problems.