We first benchmarked touch keyboard implementations across 48 leading mobile e-commerce sites back in 2013 and now again in 2015, and sadly, touch keyboard implementations have only improved by a measly 9%.
This latest 2015 benchmark reveals that 54% of mobile sites fail to invoke optimized touch keyboards for either phone, ZIP code, or credit card form fields. And even among the sites that do invoke these special touch keyboards, 25% fail to do so consistently throughout their checkout flow.
Good touch keyboard usability of course goes beyond simply invoking the most appropriate touch keyboards available (e.g. a numeric keyboard for credit card field). During our large-scale mobile e-commerce usability study, we found that configuring auto-correction and auto-capitalization settings appropriately were important to mobile form field usability as well. The settings and combinations for these differ on a field-by-field basis, with auto-correction and -capitalization being neglected by 79% and 27% of mobile sites respectively.
In this article we’ll therefore dive into the 5 guidelines on user-friendly touch keyboard implementations from our mobile usability study which lay the foundation for a good mobile form filling experience. We’ll also look at stats from our 2013 and 2015 benchmark of touch keyboard implementations across 48 major mobile e-commerce sites to see how things have developed in the past two years. Finally, the article wraps everything up with our updated Touch Keyboard Cheat Sheet (free) which includes demos and ready-to-use code for some of the most common fields types used in a typical mobile checkout flow or mobile sign-up form.
Ok, enough intro. Let’s look at those 5 touch keyboard guidelines for user-friendly mobile form fields.
Poor auto-correction is frustrating when users actually notice it, and can be downright harmful when they don’t. Auto-correct often works very poorly for things like abbreviations, street names, e-mail addresses, person names, and similar words that are not in the dictionary.
During the usability tests, auto-correction on this type of information led to numerous interruptions in the subjects’ flow. (In fact, it proved so pervasive during testing that we have considered referring to the feature as ‘auto-incorrect’.) Even worse, these auto-corrections also resulted in a great deal of erroneous data being submitted as many subjects completed their purchase without noticing a “correction” had taken place.
During testing, the subjects were generally focused on what they were typing instead of what they had typed. In multiple instances, this led to valid addresses being auto-corrected into invalid ones, and thereafter submitted because the subject failed to notice an auto-correction had taken place. Issues like this can be downright harmful to the user experience since incorrect order information naturally leads to delivery issues, not to mention confused customers and angry calls to customer support.
Auto-correct can be disabled by adding an
autocorrect attribute to the
input tag and setting it to
off, like this:
<input type="text" autocorrect="off" />
When benchmarking 48 leading US e-commerce sites back in 2013, just 8% disabled auto-correction for fields like Name, Address Line, and Email. Our most recent benchmark reveals that this has improved significantly, with 21% disabling auto-correct for these fields in 2015. However, that still leaves the vast majority of mobile sites risking invalid order data and certainly frustrating their customers with automatic “incorrections”.
See the Touch Keyboard Cheat Sheet for demos and code examples of the inputs that require disabling of auto-correction.
Unlike physical keyboards, touch keyboards can be optimized for each form field the user has to fill out. Our usability test sessions showed vastly better performance on sites that utilized these purpose-built touch keyboards, especially for numeric inputs. Yet an astonishing 54% of mobile sites fail to utilize all of the (relevant) mobile-optimized keyboards available to them!
On an iPhone 6S, the size and hitarea of the keys on the purpose-built numeric keyboard are 521% larger than on the traditional touch keyboard (257x109 vs 63x85 pts). Not only did the test subjects negatively comment on it when the purpose-built keyboards weren’t used at a site, we also recorded significantly more typos.
The decrease in typos on sites with numeric keyboards naturally led to fewer form validation errors, which in turn resulted in a better and more seamless shopping experience for the test subjects on those sites. Particularly long number sequences such as phone and credit card numbers benefitted from this keyboard optimization.
In general, there are three HTML attributes that will invoke the purpose-built keyboard layouts, namely the
pattern, attributes. The exact attributes and values depend on the field. For instance, E-mail and Phone have special purpose-built keyboards, while other inputs such as Credit card number don’t and must instead make do with a more generic (but still optimized) implementation.
Because different fields require different attribute combinations (type, pattern, novalidate, auto-capitalize, etc.) we’ve created a Touch Keyboard Cheat Sheet with the recommended code combination for inputs such as credit card, phone, ZIP code, and quantity, to make your life a little easier. (The cheat sheet also notes things like which countries require an alphanumeric postal code deviation.)
When benchmarking the 48 major mobile sites across three fields (e-mail, phone, and credit card number), we found that support for purpose-built keyboards has only increased from 40% in 2013 to 46% in 2015. This meager improvement is fairly alarming given how easy it is to fix and just how big of an impact it can have on the user’s form filling experience for numeric inputs in particular.
During testing, the subjects struggled with sites that failed to properly honor the “Next” and “Previous” button behavior. The expected behavior is very straightforward: when the user clicks the “Next” button they expect to be taken to the next logical field in the form without any other changes or form submissions.
Most sites will get this right by default, and it’s mainly on form pages with dynamically injected fields, non-native fields, or altered tab-sequences where we’ve observed this to go wrong in practice. And we’re happy to say that support for correct ‘Next’ and ‘Previous’ button behavior has increased from 96% in 2013 (where Nike and Disney Store were observed to violate it), to 100% in 2015.
The default behavior on smartphones is to auto-capitalize the first letter in standard text fields, which is generally desirable. However, in some cases you will want to disable auto-capitalization since most users will actually want to enter lowercase values, or configure the field to auto-capitalize the first letter of every word because the input is going to be a name or place.
During testing, multiple instances occurred where test subjects noticed a capitalized letter and made an active effort to delete the capital letter and replace it with its lowercase equivalent. The subjects explained that they were unsure if uppercase characters were allowed, or if email addresses in general were case sensitive. On sites that had disabled auto-capitalization in the email field, no subjects ever actively capitalized the first character. It is therefore recommended that auto-capitalization be disabled for email fields and other fields where appropriate (for example a website URL).
You can disable auto-capitalization behavior by adding an
autocapitalize attribute to the
input tag and setting its value to
off, like this:
<input type="text" autocapitalize="off" />
Certain input types such as
<input type="email"> will on recent versions of iOS and Android automatically disable auto-capitalization too. However, even for these fields we’d still recommend expliciting setting the ‘autocapitalize’ attribute since it doesn’t interfere with the behavior on those platforms and may be needed on other platforms that do not support these input types.
Another option for the
autocapitalize attribute is to set its value to
words. This will instruct the touch keyboard to automatically uppercase the first letter of each word the user types, which can be helpful for inputs such as names and places.
Turning off auto-capitalization for appropriate fields has improved somewhat with 60% of sites in 2013 to 73% 2015.
While invoking an appropriate keyboard layout for different input fields is great (see section 2) Show optimized keyboard layouts above), be sure to do it consistently throughout your site as it can otherwise greatly confuse users.
While this advice may seem obvious, 25% of sites here in 2015 still fail to consistently invoke optimized keyboard layouts throughout their site. In 2013 it was an astonishing 52% of sites that only invoked numeric keyboards on some of their numeric fields.
What is perhaps even more surprising is just how confused some of the test subjects were by sites that had such inconsistent implementations. In some cases, the test subjects stopped in their tracks and began questioning their initial interpretation of the field altogether, thinking that maybe something else was required. When thinking about it, this is actually quite a reasonable logic.
Take the above Urban Outfitters example. By showing a numeric keyboard for the credit card number, the site lets the user know that this is a purely numeric input. When the site then two fields later in the form displays an alphanumeric keyboard for the (already difficult-to-understand) ‘Security Code’ input, it logically suggests that this will not be a purely numeric input, and the user naturally begins questioning their initial interpretation of the field.
If we dive a little deeper into the benchmark numbers and look at the overall quality of the touch keyboard implementations across the 48 major mobile e-commerce sites, we see that:
If we define getting only two of these guidelines wrong as “decent support” we get a modest 9% improvement in touch keyboard implementations over the past two years. If showing the correct keyboard type for Phone, Email, and Credit Card fields, is instead taken as the sign of basic support, the improvement is just 6%.
On a more positive note, the number of perfect touch keyboard implementations has increased greatly from 2% to 15%. In 2015, Office Depot, Target, Overstock, Kohl’s, 1-800-Flowers, Hayneedle, and Nike, adhered to all 5 touch keyboard usability guidelines.
To help improve these numbers, we’ve created a Touch Keyboard Cheat Sheet. The cheat sheet includes demos and code for common fields like Email, Phone, Addresses, Credit Card, Quantity, and Date, that outline the correct combination of keyboard
autocomplete attributes. You can also see a detailed breakdown of the 2013 and 2015 benchmark compliance of the 48 sites on this page.
Whenever we begin to think “oh wow, mobile design is really maturing nowadays, we’re leaving the early days behind us”, it’s healthy to remind ourselves that 54% of the leading US e-commerce sites – all beyond the $50 million dollar mark in online sales – still don’t get something as basic as invoking the correct touch keyboard type right.
This article presents the research findings from just 1 of the 850+ UX guidelines in Baymard Premium – get full access to learn how to create a “State of the Art” mobile e-commerce user experience.
Join 22,000+ readers and get Baymard’s research articles by RSS feed or
Topics include user experience, web design, and e-commerce
Articles are always delivered ad-free and in their full length
1-click unsubscribe at any time
1. There is a bug with autocapitalize=“words” on iOS, where the second letter of each word is capitalized.
2. On Android the pattern-based inputs don’t trigger a numeric keyboard (see credit card fields in your demo). I think, type=“number” should be used.
On #1, I am seeing this behavior as well. Has anyone confirmed the bug or come up with a workaround besides removing the attribute?
I think the cheat sheet should be updated to account for this issue. Appears to be a problem on both iOS 8 and iOS 9. That’s a pretty large percentage of mobile devices being affected by the bug.
Hi Šime and Eric, in regards to autocapitalize words on iOS it’s oddly officially “supported” by Safari on iOS; https://developer.apple.com/library/safari/documentation/AppleApplications/Reference/SafariHTMLRef/Articles/Attributes.html
A bug report have been submitted to Apple.
We’ll remove it temporarily from the cheat sheet until Apple have fixed this.
Note from above link that autocapitalize=“off” was deprecated in favour of “none” in iOS5, but remains in place for Chrome.
Quite unhelpful since Safari’s autocapitalize=“none” can cause sentence capitalisation in Chrome.
Also issue for masked fields that are numeric, you can’t consistently trigger the correct keyboard
Loved this article. Thanks a lot man. :)
@Sime On CC do not use number field unless you’re ready for Firefox’s rounding behaviour.
Unfortunately Chrome on Android appears to ignore autocorrect=off.
Fortunately I think touch keyboards will start to get phased out anyway as speech recognition continues to improve. And I, for one, can’t wait for that.
Hi, what are the sources for all those claims and facts? I’d like to read an original research.
Very nice article. I too would like to know your sources. ;-)
© 2021 Baymard Institute US: +1 (415) 315-9567 EU: +45 3696 9567 email@example.com