Form input prefixes and suffixes

[timpaul]

Update: This proposal was approved by the Design System working group in June 2020. See #5920 (comment) for more details.

Earlier review:
Update: This proposal was rejected by the Design System working group on 13 April 2018. See the comments for more details.

---

What

Prefixes and suffixes on form inputs.

Why

Prefixes and suffixes are useful for any service that needs to ask for things like measurement units, currencies, percentages, area codes etc.

Anything else

Here's a prototype showing some proposed guidance and examples

The code is on GitHub here

[edwardhorsford]

Some thoughts:

The gap between input text and right aligned suffixes can get quite large. I wonder if there's any solutions to this. Off the top of my head:

• Right align all input on this
• Size the fields dynamically to the content
• Leave as is

Will js be included to swallow characters matching the prefix?

The telephone one makes me slightly uncomfortable as it's something that users may want to change - I presume they can't. I guess the label could be 'UK telephone number' - but then is the prefix necessary? It may be easier to treat international phone numbers as a separate pattern to be researched.

[timpaul]

Thanks Ed. I think the suffix issue is one to keep an eye on. My hunch is that suffixes are typically used for things that have a relatively short or known length, like numbers - but of course there will be exceptions.

Good call about swallowing the prefix/suffix characters. Feels like a future enhancement rther than something that should block publication?

Yes, telephone numbers would need an additional control that lets you change the country - which would then automatically update the country code prefix.

[NickColley]

Do we need to associate this information in anyway for users with access needs?

If the +44 input indicates that we are looking for a UK telephone number, should that be repeated in a hint?

[edwardhorsford]

I think it would be good to treat international numbers as a separate pattern.

My hunch for something to try:
Phone number prefix
[custom autocomplete]

Telephone number
[ ]

I wouldn't have the prefix in the number - I'd just treat it as a separate field.

[abbott567]

We had this conversation on our service for when agents were entering Child Benefit numbers. They always start CHB, so should we just prefix the input? But then what happens if I type CHB into the field. Is it now CHBCHB? Is that a validation error? Because, technically you've added a valid number, but the prefix made it invalid.

In the end, we just accepted it was probably better to let the agents put it in how they wanted, with or without the prefix, and do some work to sanitize and format it in the backend.

[joelanman]

are there any examples of services that use suffixes and prefixes?

[ghost]

@timpaul I am in the middle but slightly more down so I voted 👎

In the examples, all of the prefixes and suffixes are hidden from screen readers, making them just a visual enhancement. This is fine but how do we give this extra information to those users without loads of visuallyhidden text or aria-hidden=true? That seems over the top to me when the user need can be achieved with better content and labels.

Similar to what @abbott567 said, we would still need to be deal with people who repeat the suffix or prefix.

@joelanman I have seen a lot of pound signs used outside of inputs like on Pay your Self Assessment and occasionally seen things after inputs too but cannot think of the service.

Both are usually in <span>s and can seem random when you use a screen reader, especially the suffix because it is read out after you leave the field.

[edwardhorsford]

@stevenaproctor

I'm pretty sure there's a hidden label too that's attached to the field. When we tested them as part of the patterns work last year, each had hidden text. Something along the lines of "Ticket price in £".

I suspect most suffixes should still get read out beforehand. Something like "Total weight in kg, INPUT". Not all of them need to be announced - I think "Percent complete" is correct as it is. Keeping the visual treatment and the labels separate works well for this - services will need to decide on the most appropriate label.

In terms of repeating suffix or prefix - depending on use case, I think we could swallow those characters - but regardless services will need to deal with them on the backend - just like they strip whitespace on postcodes. Services should be able to deal with "£2.56" and "2" etc.

[edwardhorsford]

@joelanman

We had a prefix on passports for the tracking number:

We didn't swallow the "PEX" characters if users typed them, but would have stripped them on the backend.

If I were doing it again I'd have the prefix inside the box as per the designs above (which I subsequently worked on).

[ghost]

@edwardhorsford There is visuallyhidden text in the label but it seems over-engineered to me. You could say 'Ticket price in pounds' and that would work for everyone. They do look like mini-buttons too.

[timpaul]

Thanks everyone, this is really useful. So, what I think @stevenaproctor and @abbott567 are suggesting is something more like this?:

[tspear]

I voted down too, I agree with the 'mini-buttons' comment and I wonder whether the user need is better served with hints or examples?. So not sure about useful/unique here.

[cathydutton]

I’m also leaning towards a thumbs down,

•	Is there a clear user need for this or do we have evidence of users failing to recognise units in labels?
•	Would this pattern replace units being placed in labels/hint text or be used alongside? 

Could this be useful in situations where multiple units are accepted?

[jonhurrell]

I built the prefix this was based on for the budgeting loans service to denote loan amount as pounds. I was hesitant to see any utility over a label, until I went to a job centre and saw people struggle trying to find and execute the keyboard shortcut for the pound glyph. For those that entered it within the input, we allowed it and stripped it out on post.

I saw no evidence of people trying to click them as buttons, especially given the context of using a service, where a button or action convention is pre-established.

Is there a reason people with dyslexia may prefer unit glyphs over label, or vice-versa?

[ghost]

@jonhurrell The British Dyslexia Style Guide says "Pictograms and graphics help to locate information." which could explain people struggling to find the £ on a keyboard. This is the principle behind Easy Read documents too.

The examples could use both words and symbols. Something like 'Ticket price in pounds (£)'.

[MalcolmVonMoJ]

@hannalaakso

The only thing I can offer now (and I have mentioned it before, so this might seem familiar) is some user research from the MoJ regarding currency fields. Some users were reported as thinking that the grey box around the prefix (as found on the MoJ Design System) was a button to change the currency (£, $, € etc). For this reason, many services opted to drop the grey background for a clear one (you can see the pattern we all use in the video I posted). However I don't know any more than that - the user research and design decision preceded my joining the team - I was just told the results. I would assume that a similar behaviour might be witnessed for suffixes (kg, lb, st etc).

However, now that the Design System working group has decided on this pattern, I was just trying to suggest that the prefix and suffix should be considered part of the input. If users were expecting the currency to change, the input box receiving focus might inform them that typing in is all they can do. If nothing happens, that might lead to a moment's confusion.

I think we have a new round of user research and testing on the horizon, I'll suggest that we make the changes as seen here and see what the results are. However, most of our currency fields have a selectable suffix as can be seen in the video (select: per week, per month etc), so might not be ideal for testing this pattern.

Hope that all makes sense (and is useful).

[edwardhorsford]

I like @MalcolmVonMoJ's suggestion. It loosely follows the existing pattern that clicking on an input label will focus an input.

[hannalaakso]

I think we have a new round of user research and testing on the horizon, I'll suggest that we make the changes as seen here and see what the results are.

@MalcolmVonMoJ It would be great if you could post findings from relevant user research here. We hope to publish the new prefix/suffix variant within the next month so it'll be available for testing then. If you need to combine it with a pattern for choosing the unit it would still be useful to document the findings here.

[timpaul]

I think click area should include the prefix/suffix box as well as the main input box, so that if a user clicks on the prefix box, the input receives the focus.

I made a quick mock-up of this behaviour by altering the CSS of one of our current currency fields:

Hi @MalcolmVonMoJ - did you have any results with your suggestion of making clicking on prefixes and suffixes focus their input?

[MalcolmVonMoJ]

Hi @timpaul

In regards to user research, I'm afraid not. All our currency inputs are using this approach, but the round of user research that I was hoping would look at this didn't look at this part of the service. I am still hoping to have this included in the next round of research in this part of the service. The previous pattern (without the grey border) worked well, and that had an identical click area with this one.

In regards to technical implementation, it is quite easy (we had to make an unexpected adjustment in the CSS for Firefox as this behaves slightly differently, but this was also easy).

However, we just did it for currency input where the size of the prefix is constant - this means that the padding can be fixed in the CSS.

I was thinking about this last week and if you cannot be sure what the width of the prefix is, then the padding either has to be changed by the developer for each input or be a set by JavaScript.

Given that the pattern is published, it might be best to just write a bit of JavaScript to get the width of the prefix and then change the padding for the input element accordingly.

With our setup, we only use JavaScript for a slight adjustment to the error state. As the whole area is selectable, we initially highlight the whole box in red.

We then use JS to change the black prefix border to red too - as it is a little odd to leave this black.

[frankieroberto]

I like the "honesty", as I think @timpaul put it, of having only the input area highlight on error or focus. This also avoids any overlaps where browsers add icons within the form fields (eg for autofill).

Possibly having the input field focus if the prefix or suffix boxes are clicked could be considered as a javascript enhancement though?

[timpaul]

Thanks for the suggestions @MalcolmVonMoJ and @frankieroberto - I've raised an issue for this idea here: alphagov/govuk-frontend#1973

[timpaul]

Following up on @edwardhorsford s comment here: #5920 (comment)

Here's how Paypal do it...

So less of an input mask, more of a placeholder hint?

[edwardhorsford]

@timpaul that's different than what I was describing.

[timpaul]

Hah, yeah I see that now - that Paypal use case is pretty limited

[lalexander12]

When asking about pounds (currency) can I ask if we always need to spell out the pounds?

eg, Tell us how much you have in your bank account, in pounds?

There's lots of examples on this thread where people aren't saying the 'in pounds' bit.

[RobSinclair]

Findings from a DAC Accessibility Audit on a service using various inputs with both prefix and suffix types:

We are actioning their feedback by adding hint text to be read out.

Might be worth adding some extra detail into the component guidance to make sure there's enough information on the page for screen readers to be able to determine the information that's in the prefix/suffix - or updating the component to not hide the prefix and suffix from screen readers.

[jfranciswebdesign]

Hello - currently in Beta on a service and were seeing users try to click the suffix 'box' thinking that's how they change the value. It's not a blocker, they immediately realise that's not how to make the change. Just noting the behaviour here.

[NickColley]

Moving this historical artifact into this discussion so it's easier to find.

Original url: https://github.com/alphagov/govuk-design-system/wiki/Character-count-testing-and-user-research
Originally published on Dec 7, 2017

---

Currency input testing and research - December 2017

The currency input component helps users enter an amount of money in a specified currency.

• Try a demo of the currency input component
• Get the code for this component on GitHub
• Read the guidance for this component on Dropbox Paper

User research

We carried out research lab sessions in autumn 2017 with various different types of users. All users knew to enter the data in numbers and without the addition of a currency symbol.

Currency symbols that were tested

The component has been lab tested with the currency symbol for pound sterling. In addition, it has been developer tested with the euro currency symbol where the unit precedes the input.

Devices tested on:

• Chrome, Firefox, Safari (desktop) - latest version at the time of writing
• Internet Explorer 11
• Microsoft Edge 14, 15
• Android Galaxy S8, Pixel 8, Nexus 7: Chrome and Firefox
• iPhone 6, iPhone 5s: Safari, Chrome

Accessibility

The currency input component announces to screen reader users that they should enter the value in pound sterling. The currency symbol itself is not announced.

Assistive technology that the component has been tested with:

• Jaws 14/15 + IE11 + Windows 7
• Jaws 17/18 + IE11 + Windows 10
• NVDA + Firefox (latest version at time of writing) + Windows 10
• VoiceOver + Safari + iOS 10.3.2 + iPhone 5s
• VoiceOver + Safari + Mac OS 10.11.6
• Dragon NaturallySpeaking 13