Text input #51
Use this issue to discuss the text input component in the GOV.UK Design System.
There is a separate issue to discuss form input prefixes and suffixes.
The text was updated successfully, but these errors were encountered:
Change the default example for the text input component from an input asking for an email address to an example asking for someone’s full name. As raised in the backlog , we are not currently using the correct `type=“email”`. We could fix this, but as users are likely to take this ‘default’ example and modify it to ask different questions, it makes sense to make it as generic as possible, avoiding using a type specific to a particular type of input. Therefore changing to a more ‘generic’ question, such as full name, which does not require specific input types, makes more sense. : alphagov/govuk-design-system-backlog#51 (comment)
A couple thoughts on inputs from me.
1. Pattern naming
I consistently look to
2. Input width classes
I keep looking for width classes in style / layout, not in this one pattern. Presumably the width classes apply to more than just text inputs - textareas, autocompletes, selects. Should / could helper classes live in the styles section?
3. Text width classes
Do we have use cases for the fluid width classes? If inputs are meant to be sized appropriately to their content, when do we expect fluid to be used?
Long ago we had discussions about recommending fixed widths (or min widths) on inputs - I wonder if we could consider this again? If we do, ideally we'd include widths wider than 20 characters. At the moment, on desktops the fluid classes provide a greater range of choices.
4. Fixed width classes
I wonder if naming them by characters is correct? Talking with @dashouse he told me this is measuring the width of the widest possible character - presumably
Example: my service has users type in a 6 digit 2fa code. Going by the available classes,
Dave also mentioned that they're sized to allow a bit extra width because some browsers add icons in the inputs - I wonder if this should be mentioned in case some users pick a smaller one that visually works, without realising what needs to be allowed for.
IMHO if it was clearer how many numeric characters and how many latin characters each supported, users could pick the right one.
Update @dashouse mentioned on Slack that fixed width classes were also in the
I'd like to propose a new modifier that increases the tracking on an input, useful for situations where we expect a user to be 'proof-reading' a character at a time, such as when entering a reference number from a document.
Example usage might look like:
You can also play with a preview here: https://govuk-frontend-review-pr-1222.herokuapp.com/components/input/extra-tracking-reference/preview
I've raised a PR to introduce this but it could do with testing in a few services before we roll it out.
Is anyone else already using something similar in their service?
Is anyone interested in trying this out on their service? Ideally where there is an opportunity to observe how users react to it in user research and/or there's analytics in place where we might be able to see a drop in error rates?
Hi! I am a big fan of the govuk design system and reference it often when working on my own system.
I have a question about the fixed width inputs:
Why are the widths defined in
Before inspecting the inputs in devtools I had expected to potentially see
Is the height of a lowercase
Playing around with this myself I quickly noticed that box-sizing, border and padding makes what would be a delightful solution of the number of characters being used directly in the width impossible.
@lauriejones It's somewhat dependant on the font itself, we also expected
Hey all so I wanted to chime in with a text related issue we had on the claim beta and suggest a slight tweak.
TL;DR - the hint text is too light and some people with dyslexia cannot see the hint text. We darkened it slightly to improve the situation.
We have currently got to services in beta that allow teachers to claim money if they are in the first 5 years of their careers. Our users have good digital skills.
The hint text is too light
Although the hint text is AA for small text, I feel that it is too light and can be hard to see or totally missed by users. We had 8 participants for user research who identified as having dyslexia, they all had issues to varying degrees. Below is a summary of the participant that struggled the most.
Participant T16 identified themselves as having dyslexia and
When they were viewing a particular question that asked if they were in a leadership position at their school they hesitated and re-read the question and the options (yes/no) a couple of times. When prompted they said they needed clarification on what was a leadership position. After a while we asked if they had read the hint text to which they replied:
The same thing happened again on the bank details page that was made using the recommended bank details pattern. The problem was compounded on this page as we had 3 different hint text sections that they could not read.
We tried to approach this problem with a light touch. It was clear that the hint text should be clearly distinguishable from the main copy and we wanted to keep that distinction clear. We opted to darken the hint text from #626A6E to #52575B.
This hits AAA accessibility for normal text and made it a bit clearer for our users whilst keeping it distinguishable from the normal copy.
The hint text being found to be too low contrast in user research has come up multiple times. Ultimately it's about finding a balance between making it high enough contrast for % users and different enough from body text to work as a pattern.
I wonder if GDS should set an expected % of users they're targeting to be able to distinguish it. Are we meeting that level now?
One drawback is that in making the hint darker, it gets harder to distinguish from body text. With the current hint the contrast between body and hint is 3.6:1. With #52575B it's 2.7:1 (on my monitor and with good eyesight I can distinguish it still, but it's much closer). I suspect it being 3.6:1 is not an accident - it's allowing the hint to be as dark as technically allowed if you're aiming for sufficient contrast with body text.
To add to my above - perhaps we should just treat distinguishing hints from body text as an enhancement that isn't required for all users - so allow the hint to be a bit darker and make sure hints work regardless of whether they can be distinguished (which they may well do already).
Yeah, I think that it is more important that people can see the hint text than they can easily distinguish it from regular body text. For us, it was not a problem as we mainly used headers, hints then inputs on the pages.
I'm not suggesting we want to but we could make the font-weight a bit heavier on body text to make it more easily distinguishable.
I do think the problems of amending the hint text colour and keeping the hint text distinguishable from body text can be decoupled and look at independently.
Thanks for the feedback @titlescreen
We darkened the secondary text colour in the 3.4.0 release of GOV.UK, to try to reduce the issues you describe. But clearly for some users it wasn't enough.
Would you be able to share a screenshot here of a representative page? If we can understand the different contexts that hints are being used in it might help us consider other approaches.
Here are some screenshots of the questions with the slightly darker hint text. I've tried to pull out examples of high-cost questions where the hint text was really useful and saved us a few Zendesk tickets.
With the TRN question the hint text meant that they now had a way to find out their TRN in a short amount of time, rather than just emailing the head's PA and asking them.
The leadership question below was one where teachers repeatedly showed the need for the hint text to validate their opinion that they were or were not in a leadership position. When we didn't have this hint text they agonised on the page, re-reading the question again and again.
The student loan repayment question was one that users could easily answer but with a rather large variation in accuracy. Originally some teachers were getting their last payslip and multiplying it by 12, others were putting a finger in the air and estimating.
By providing this guidance it saved a lot of emails/calls to teachers to work through their calculations.
Hey @edwardhorsford, yeah using body copy is a possibility but to me, the purpose of that text is that its additional info to help a user answer the question, either by providing more context or guidance. In my head this is a hint, so I'm using the hint text as intended.
If we can't use the thing for what we think its intended for then maybe it needs changing?
inputmode="numeric" prevents users from enter a decimal point on iOS devices
According to the docs, we should be using
The pattern attribute is only used to inform client side validation, and does not assist devices/browsers in choosing which input method to show the user.
This article has good information on why it was decided to move from
Through our own user testing, we have discovered the inputmode="numeric" does not allow users to enter a decimal point on iOS devices, and that inputmode="decimal" should be used where a decimal place is expected/allowed.
The documentation should be updated to include this information.
@tomsykes were there any negative consequences of changing it to
I think this may be a situation where being consistent with a 'catch all' numeric input could help prevent this kind of problem in the future, rather than adding a variation specifically targeting decimal inputs.
@titlescreen From where we've tested, I don't think there would be any negative impact from always using
The biggest concern comes from the pattern attribute, which is used in browser input validation. I believe more testing would be needed here to find a best fit.
@36degrees Thanks for highlighting that... I did have a search before posting here, but obviously not extensive enough! I didn't mean to duplicate the issue.
Just to be clear, our guidance is to turn off HTML5 validation completely, using
@joelanman Ah - that makes more sense then. We are using
An issue was recently raised on slack that has cropped up before. The guidance says "If the input uses characters that are not allowed and you do not know what the characters are. Say ‘[whatever it is] must only include [list of allowed characters]’."
Challenging example 1: A designer pointed out that following guidance would result in "Business name must only include letters, numbers, hyphens, spaces, apostrophes, exclamation marks, commas, quotation marks, ampersand, underscore, full stop, round brackets and forward slash". The consensus appeared to be that it was not desirable.
Challenging example 2: A service I worked on allowed ~180 char (it was the entire ISO-8859-15 char set). We also believed that listing the characters as per guidance wasn't desirable.
In both examples, the conclusion was to use the example from guidance ‘[whatever it is] must only include letters a to z, hyphens, spaces and apostrophes’.
This scenario is likely to happen again. Can the guidance be updated to indicate that this is acceptable, or suggest a different approach?
@terrysimpson99 that's an interesting situation, I agree we should look at updating the guidance to make these scenarios simpler.
Would you mind creating an issue on govuk-design-system with the information in your comment? Alternatively I can create one for you, if you'd prefer.
Once the issue has been created we can look at the problem in more detail and decide how the guidance should be changed.
We're working on services for HMRC our FE dev an accessibility expert has said that hint text needs a full stop for accessibility reasons. If not, a screenreader runs the hint text into the error message text. We are adding full stops to all our hint text including 'fragments'. Also having full stops on some hint text and not others can be distracting to some users in UR as they call it out thinking you have missed a full stop. Also if the hint text is 2 sentences some CDs don't put a full stop at the end of the second sentence because of the fragment rule, which impacts accessibility and makes it look like it's missing a full stop.
As part of our content design community we came up with some guidelines...
Both paragraph and hint text should be concise. Only add it if there is a user need or for accessibility.
Paragraph text (body text)
Used to add extra context and further explain the H1, such as:
Used to explain what users need to do to prevent getting an error message, such as:
Hint text includes examples of dates, Unique Taxpayer References, and National Insurance and VAT registration numbers.
Hint text should include a full stop to prevent it running straight into an error message for screen readers:
‘For example, 12 11 2007.’
Do not use hint text for general help. Do not rely on hint text. Users will pay less attention to help text than the question or field label, so these need to be descriptive and clear.