Text input

[govuk-design-system]

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.

[timpaul]

If this component is also intended to be used for things like decimals, emails and telephone numbers, should we rename it to 'Input'? @nickcolley ?

[joelanman]

Problem is, if we're trying to follow the html naming where possible, input is a lot of things including radios and checkboxes. This is input type=text, so 'text input'? I think decimals, emails, phone numbers are all people entering text

[soniaturcotte]

The example for the govuk-input--width-3 says CVV.

On GOV.UK Pay, we found from research that CVV isn't very meaningful to people. "Card security code" performed much better in user research. In addition, card security codes can be 4 digits for AMEX cards, so maybe the entire example isn't so good in this case.

I'm not sure if this matters at all since it's just an example of how to change the size of the inputs.

[NickColley]

We try to make sure the examples always make sense, since people may copy and paste them, so that sounds sensible to update that.

I guess we'd just need an example for 3 characters to replace that one.

[stevenaproctor]

@nickcolley Tax office number is 3 characters.

[charge-valtech]

The example for this should probably have the correct type="email" in both the HTML and Nunjucks snippets. Or maybe don't use email as an example. Lots of people will be copy and pasting this example without the correct type.

[36degrees]

The example for this should probably have the correct type="email" in both the HTML and Nunjucks snippets. Or maybe don't use email as an example. Lots of people will be copy and pasting this example without the correct type.

Good spot, thanks Henry! I've raised a PR to change the default example for the text input component to ask for full name instead.

[36degrees]

The example for the govuk-input--width-3 says CVV.

On GOV.UK Pay, we found from research that CVV isn't very meaningful to people. "Card security code" performed much better in user research. In addition, card security codes can be 4 digits for AMEX cards, so maybe the entire example isn't so good in this case.

I'm not sure if this matters at all since it's just an example of how to change the size of the inputs.

@soniaturcotte We've replaced the labels on the example inputs with 'non-realistic' labels that just denote the width of the input, so 'CVV' became 3 character width. Thanks for raising! 👍

[36degrees]

As raised by @edwardhorsford in Elements, our text inputs don't currently have a disabled style (this is still the case in GOV.UK Frontend):

Similar to https://github.com/alphagov/govuk_elements/issues/367, should we provide styles for disabled inputs? With our current styles there will be no visual difference if an input is disabled, which is not good.

Services will either have inputs that are identical but don't actually work (confusing) or come up with their own designs (inconsistent.

We do not recommend the use of disabled elements, but that doesn't mean they won't be used. There may also be situations where they can't be avoided - a 3rd party payment interface, for instance.

How would you expect it to work?

Disabled textboxes should have some visual difference when disabled.

How does it work currently?

Disabled inputs look identical to non-disabled inputs

Feel free to suggest a fix...

An example with the colours knocked back and a grey background applied.

There is more discussion about this in the original issue.

[edwardhorsford]

A couple thoughts on inputs from me.

1. Pattern naming

I consistently look to input to find the pattern, not text input - I wonder if any others struggle to find the pattern?

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 w or m. At the moment this may lead to our users choosing a wider input than needed if they're accepting numeric input only.

Example: my service has users type in a 6 digit 2fa code. Going by the available classes, 10 character width is the closest. But in reality 5 character width is good for us.

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 styles section, which I'd missed - I don't think I expected them under 'spacing' - I see they're in search so I should probably rely on that more. I'm curious why they don't include the fixed width styles - which to me are the more useful ones.

[36degrees]

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:

<input  type="text" name="reference-number" class="govuk-input govuk-input--extra-tracking">

Without modifier

With modifier

You can also play with a preview here: https://govuk-frontend-review-pr-1222.herokuapp.com/components/input/extra-tracking-reference/preview

This is based on work by @quis in https://github.com/alphagov/notifications-admin/pull/1545.

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?

Potential risks:

• Users misinterpreting the extra tracking as additional spaces that they then try to delete.
• Users confused because of the different way we present numbers (especially noticeable with 1s)

[edwardhorsford]

I really like the idea! I could see it being used for 2FA code fields too.

I share a concern about people thinking there's a space in there - perhaps the tracking could be reduced until we think that's much less likely?

[lauriejones]

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 ex units?

Before inspecting the inputs in devtools I had expected to potentially see ch units, but was wrong!

Is the height of a lowercase x more similar to the average width of a character than the width of a 0?

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

[dashouse]

@lauriejones It's somewhat dependant on the font itself, we also expected ch to be more accurate but had a closer result with ex in our situation. We did this considering the worst case scenario using all cap W's and an extra 10px or so for Safari's autocomplete icon, so we generally overestimate the size.

[lauriejones]

@dashouse thanks for the reply! I am at the point where I am looking to implement character-based widths for our inputs and I am having some issues for (extremely) zoomed in users. Is the only solution for that to just add a bit of "give" in the widths?

[titlescreen]

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.

Intro

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

Participant T16 identified themselves as having dyslexia and slight issues on colour, they may need to zoom in the screen, enlarge the text of change the colour to help them read content online. No other modifications were required.

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 hint is too light for me, I didn't even notice that. I probably wouldn't take any notice of the grey words I'd just read the top.

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.

The grey things (hint text) are doing my eyes in, the lighter colour. I've got the enter bank details and the sort code but the light grey is just not working with me on the white bg, it looks light Its quite small and lighter so I just zone into the black text

Our solution

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.

[edwardhorsford]

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.

[edwardhorsford]

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

[titlescreen]

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.

[timpaul]

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.

[titlescreen]

Hey @timpaul,

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.

By providing this content they became confident in their answer on this page

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.

[edwardhorsford]

@titlescreen for those examples, could you use body copy instead?

The pattern some of my services have used is:

# Page heading

body copy with more description

## label
[ input ]

[timpaul]

Thanks @titlescreen - I agree - in your examples, using the standard body copy colour for the hint text would be preferable. We're going to be investigating labels and hint text in a future sprint - thanks for the input.

[titlescreen]

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?

[tomsykes]

inputmode="numeric" prevents users from enter a decimal point on iOS devices

According to the docs, we should be using inputtype="numeric", with a pattern="[0-9]*" attribute.

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 <input type="numeric"> to <input type="text" inputmode="numeric">.

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.

[titlescreen]

@tomsykes were there any negative consequences of changing it to inputmode="decimal"? I ask because I think if it does not make the experience worse for users that do not need to enter decimal numbers then I wonder if we should consider changing this for all numeric inputs.

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.

[36degrees]

We have an issue in our backlog to add guidance and an example for asking users for numbers with decimals:

https://github.com/alphagov/govuk-design-system/issues/1212

[tomsykes]

@titlescreen From where we've tested, I don't think there would be any negative impact from always using inputmode="decimal"... Android 9 (and from limited testing, 8) shows the same input for both numeric and decimal input modes. iOS simply adds/removes the decimal point from the same input method depending upon decimal/numeric.

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.

[joelanman]

Just to be clear, our guidance is to turn off HTML5 validation completely, using novalidate. The pattern attribute is just for old ios to display a number keyboard. Written up here:

https://technology.blog.gov.uk/2020/02/24/why-the-gov-uk-design-system-team-changed-the-input-type-for-numbers/

[tomsykes]

@joelanman Ah - that makes more sense then. We are using novalidate on our forms, but I wasn't sure why the pattern attribute was there. Either way, I'm unsure of its affect regarding the input of decimals as opposed to integers on old iOS, so more testing would be needed I think.

[terrysimpson99]

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?

[lfdebrux]

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

Thanks again!

[terrysimpson99]

Thanks very much. I would really appreciate it if you could do it for me.

[lfdebrux]

@terrysimpson99 an issue has been created: https://github.com/alphagov/govuk-design-system/issues/1734

Please feel free to add more information and/or follow the issue for updates.

[jeanesims]

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.

[fred-jackson]

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: clarifying specifics, like United Kingdom (what does that include) and Great Britain (what does that include) giving further explanation of something users may not understand, like ‘throughput’

Hint text

Used to explain what users need to do to prevent getting an error message, such as:

• explaining the interface, like 'select all that apply' for checkboxes
• input formats, examples, or where to find things

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.

[neves-io]

Are there any services out there that include an option for a user-changeable measurement next to an input? There's an example on the component page of a suffix which helps users if the measurement is pre-defined. In this case I'm looking for an example where the user can change the suffix "Feet" and "Metres" or maybe "mph" and kph". Maybe a niche need... at the moment we're putting the question below the text input and trying to avoid using a select. Screenshot below:

Any other ideas welcome!

[edwardhorsford]

@neves-io I don't think there's a standard pattern for this interaction yet, though a few services have similar needs - I'd probably try reaching out to HMRC for starters.

Commonly:

• changing weight
• changing time period (day / week / month) (eg How much are you paid?)
• changing units

They're less common in gov services, but if there were a common unit I might try testing an inline select with a default unit. This is also how non-gov services tend to approach this - treating the the input and units as one thing with one legend.

Accessibility

A tricky thing though is communicating to non visual users that they'll be able to change the unit. Sighted users can see that they're going to be given an option - but how does a screen reader user know? The same challenge would apply with a select as with your example. I've wondered before if it would work to have hidden text as part of the first input that notified the user they'd be given a choice of units.

An alternate approach would be to ask the units first. I think this has its own problems as the question would need to be long and cumbersome as it needs to talk about the thing you're measuring as well as the measurements. And for many people they probably think of this question in 'one' - so asking the units first might be confusing.

[neves-io]

Thanks very much @edwardhorsford - yeah will try the inline select and see how it tests. My worry is also with users of screen magnifiers with the action to the right. I wonder if there's been any issues with the suffix in general being to the right of the input in that scenario?

[edwardhorsford]

@neves-io definitely something to test with - though I think you can alleviate that by constraining your input width. If you're accepting numeric input, then the field can be quite short in most cases. In your example above, a text input alongside a select would likely be shorter than your question text.

[connorthompsoncode]

Has any work been carried out on the standard for labelling a text input area as "optional". I haven't been able to find anything or other design examples.

The use case is that as part of our tools users can add additional comments based on the previous question (questions are separated onto pages like a microservice/gform etc.). These comments are optional, but currently, in our tool users have to enter something in a text input to be able to continue to the next page/question. Our current solution is to ask the user to enter "n/a" into the text box to be able to move on but we were looking at possibly updating the functionality to allow text inputs to not need something entered to move on (this would only be on inputs we specify).

What we're mainly needing to figure out is:

• What's the best way to signal to the user that entering an input is "optional"
• Which is the preferable interaction: entering n/a OR not having to enter anything.

I haven't been able to find another discussion or example of this so any help would be greatly appreciated.

[rachelmalic]

Does anyone know if using a font with a slashed zero has ever been considered for the design system?

We have recently designed several pages like this, where the user has been given a payment reference containing a string of number 0s. A lot of people think it is a letter o, and if they pay at their bank and enter this it could cause their payment to get lost.

Dyscalculia research has found that using a font with a slashed zero (zero with a line through it) helps people distinguish between the letter o and the number 0.

Does anyone know if this is something being considered? Not sure where the best place to raise this is?

[querkmachine]

Hi @rachelmalic, it's something on our list to investigate: https://github.com/alphagov/govuk-frontend/issues/3916

This isn't something we can do in-house, however, and implementing it would involve commissioning a type foundry to modify Transport, so this isn't a change likely to happen in the near future.

In the interim, would it be useful to clarify that they are numbers in the hint text? (e.g. "This starts with an X followed by 3 letters and 11 numbers")

Breaking the example up into parts may also aid in readability (e.g. "XALF 0000 0123 456").

[Katqgds]

Insights

Experienced a user struggling to read the hint text within the input component.

• user with visual impairment who did not know how to use screen zoom
• shielding eyes, leaning in and saying "it gets smaller and smaller and lighter and lighter what word can I use fade - ier"
• We recognise that this component passes WCAG AAA - but think this observed behaviour likely to be common in older users with later onset visual impairments and wonder if its worth exploring alternatives to help them

Methods

This was within the context of testing web journey for proving identity, although it was only the one user with the extreme struggles and commentary, we had two others leaning in to see the screen more clearly.