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

[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 alphagov/notifications-admin#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?

[terrysimpson99]

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

[lfdebrux]

@terrysimpson99 an issue has been created: #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: alphagov/govuk-frontend#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").

[ghost]

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.

[mrkwrght]

Iv got a query around something relating to currently input. someone has raised that "every currency input page has to mention the the type of currency in the h1/question the £ symbol is hidden from screen readers, therefore without mentioning the currency this is an accessibility fail" within a design crit today

we currently have the currreny type as hint text "For example, £600 or £193.54." this was taken from the HMRC design patterns and the gov uk design system also calls out "If you need a specific type of information, say so in the input label or hint text as well. For example, put ‘Cost, in pounds’ in the input label and use the ‘£’ symbol in the prefix."

HMRC internal accessibility team have confirmed that hint text with 'For example, £600 or £193.54.' is fine from their point of view.

I wonder if this needs to be made clearer in the design system around currency input

[EPedley]

Is there any guidance on whether we should accept commas in number inputs? For example, a user inputs "1,000" instead of "1000"? Currently we don't handle that, so a user gets a "please enter a whole number" error.

[joelanman]

@EPedley yes, our guidance is to accept any unambiguous input, which 1,000 probably is. I say probably because some countries use comma as decimal points in numbers, so it might depend on your service and your users.

Use validation to ignore unwanted characters, unless it would make the information too unclear for you to use. For example, any spaces, invisible characters or punctuation, like hyphens, brackets, dashes and full stops.

https://design-system.service.gov.uk/patterns/validation/