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

No semantics to distinguish labels, hint texts and error messages #574

Closed
selfthinker opened this issue Nov 8, 2017 · 6 comments

Comments

@selfthinker
Copy link
Member

commented Nov 8, 2017

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.

Example

Example "full name" within Elements

Screenshot

Code

<label for="example-full-name" id="error-full-name">
    <span class="form-label-bold">Full name</span>
    <span class="form-hint">As shown on your birth certificate or passport</span>
    <span class="error-message">Error message about full name goes here</span>
</label>

Screen reader output

"full name as shown on your birth certificate or passport error message about full name goes here"

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).

Potential solutions

Add punctuation

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.
So, this could only work with a complicated set of guidance, which, in my opinion, rules this solution out.

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.
So, another solution would be to move them out of the label and make the relation between them with aria-describedby instead. For example:

<label for="example-full-name" id="error-full-name" class="form-label-bold" aria-describedby="error-full-name-hint error-full-name-error">
    Full name
</label>
<p class="form-hint" id="error-full-name-hint">As shown on your birth certificate or passport</p>
<p class="error-message" id="error-full-name-error">Error message about full name goes here</p>

Other solutions

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.

@cjforms

This comment has been minimized.

Copy link

commented Nov 8, 2017

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.

@timpaul

This comment has been minimized.

Copy link
Contributor

commented Nov 13, 2017

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?

@edwardhorsford

This comment has been minimized.

Copy link
Contributor

commented Nov 13, 2017

@selfthinker I've forwarded you the thread from last year that I think I was talking about.

A possible downside of going with ariadescribedby is the increased code complexity and opportunity for errors. On the other hand, it would probably give us more control.

@paulwaitehomeoffice

This comment has been minimized.

Copy link

commented Nov 14, 2017

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.

nickcolley added a commit to alphagov/government-frontend that referenced this issue Dec 1, 2017

Split hint text from label and link them with aria-describedbhy
With long labels, by default this component visually makes the most important content
distinguishable, by using bold and color. We can't rely on this for users with disabilities.

If someone has difficulty seeing our pages, they might use assistive technologies such as screen readers.
In this case, if all our text is within our labels (even if visually they're distinct) that text will be announced
in it's entireity.

By splitting the hint text up and having it alongside our labels, we can then associate them with `aria-describedby`.

This results in the main label being announced, then an indication that this is a radio component and only after that is the additional text
read out. So it means users of screenreaders can scan and skip options just as easy as people making choices with sight.

The classes have to be reorganised to achieve this, since as explained before, these elements now have to be completely separated.

See alphagov/govuk_elements#574 for a prior discussion around this

nickcolley added a commit to alphagov/government-frontend that referenced this issue Dec 1, 2017

Split hint text from label and link them with `aria-describedby`
With long labels, by default this component visually makes the most important content
distinguishable, by using bold and color. We can't rely on this for users with disabilities.

If someone has difficulty seeing our pages, they might use assistive technologies such as screen readers.
In this case, if all our text is within our labels (even if visually they're distinct) that text will be announced
in it's entireity.

By splitting the hint text up and having it alongside our labels, we can then associate them with `aria-describedby`.

This results in the main label being announced, then an indication that this is a radio component and only after that is the additional text
read out. So it means users of screenreaders can scan and skip options just as easy as people making choices with sight.

The classes have to be reorganised to achieve this, since as explained before, these elements now have to be completely separated.

See alphagov/govuk_elements#574 for a prior discussion around this

nickcolley added a commit to alphagov/government-frontend that referenced this issue Dec 4, 2017

Split hint text from label and link them with `aria-describedby`
With long labels, by default this component visually makes the most important content
distinguishable, by using bold and color. We can't rely on this for users with disabilities.

If someone has difficulty seeing our pages, they might use assistive technologies such as screen readers.
In this case, if all our text is within our labels (even if visually they're distinct) that text will be announced
in it's entireity.

By splitting the hint text up and having it alongside our labels, we can then associate them with `aria-describedby`.

This results in the main label being announced, then an indication that this is a radio component and only after that is the additional text
read out. So it means users of screenreaders can scan and skip options just as easy as people making choices with sight.

The classes have to be reorganised to achieve this, since as explained before, these elements now have to be completely separated.

See alphagov/govuk_elements#574 for a prior discussion around this

nickcolley added a commit to alphagov/government-frontend that referenced this issue Dec 4, 2017

Split hint text from label and link them with `aria-describedby`
With long labels, by default this component visually makes the most important content
distinguishable, by using bold and color. We can't rely on this for users with disabilities.

If someone has difficulty seeing our pages, they might use assistive technologies such as screen readers.
In this case, if all our text is within our labels (even if visually they're distinct) that text will be announced
in it's entireity.

By splitting the hint text up and having it alongside our labels, we can then associate them with `aria-describedby`.

This results in the main label being announced, then an indication that this is a radio component and only after that is the additional text
read out. So it means users of screenreaders can scan and skip options just as easy as people making choices with sight.

The classes have to be reorganised to achieve this, since as explained before, these elements now have to be completely separated.

See alphagov/govuk_elements#574 for a prior discussion around this

nickcolley added a commit to alphagov/government-frontend that referenced this issue Dec 4, 2017

Split hint text from label and link them with `aria-describedby`
With long labels, by default this component visually makes the most important content
distinguishable, by using bold and color. We can't rely on this for users with disabilities.

If someone has difficulty seeing our pages, they might use assistive technologies such as screen readers.
In this case, if all our text is within our labels (even if visually they're distinct) that text will be announced
in it's entireity.

By splitting the hint text up and having it alongside our labels, we can then associate them with `aria-describedby`.

This results in the main label being announced, then an indication that this is a radio component and only after that is the additional text
read out. So it means users of screenreaders can scan and skip options just as easy as people making choices with sight.

The classes have to be reorganised to achieve this, since as explained before, these elements now have to be completely separated.

See alphagov/govuk_elements#574 for a prior discussion around this
@36degrees

This comment has been minimized.

Copy link
Contributor

commented May 3, 2018

This change is being implemented in GOV.UK Frontend.

@36degrees

This comment has been minimized.

Copy link
Contributor

commented Aug 22, 2018

Following the launch of the GOV.UK Design System, GOV.UK Elements will now only get major bug fixes and security patches, so I'm going to close this.

@36degrees 36degrees closed this Aug 22, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.