This is what we get, when we don’t fully get HTML: Ep 1

Slowed down, encouraged to make mistakes by wrong mobile keyboards

This article is part of a mini series on the effects of writing — versus not — semantic HTML, and how that can affect our experience using the web.
Feel free to also checkout the other episodes:

• Ep 0: Introduction
• Ep 2: Left wondering, figuring out form fields

Scenario A: you’re on your mobile device, about to type in a phone number on a web page.

Writing phone numbers on non-semantic HTML

When that web form is not using semantic HTML, the result of tapping that input element is usually the generic keyboard showing up, with the actually needed numeric keys lurking behind a second tap, on the ‘123’ key:

All illustrated examples below have been done on iOS 13’s Safari browser.

input type=”text”, without any other bells/whistles/pattern attr for telephone numbers

Sure, it’s just one extra step to get to those numeric keys.
But it’s also one extra step towards other potential extra steps, in case you mistype any of those small numeric digits that, while displayed after that second tap, will still share the entire keyboard layout with many other characters that are not needed for this kind of input.

Now compare that experience — after you multiply the potential frustrations by the number of cases when you’re on-the-go while using your phone — with the following.

Writing phone numbers on semantic HTML

The first tap on the phone input directly gets you a custom, phone-specific (T9) keyboard displayed.

Only numeric keys get displayed, significantly enlarged and spanning the entirety of the keyboard, while a second tap on the “+*#” key will only bring up phone-specific special characters (also enlarged).

input type=”tel”, for telephone numbers

Scenario B: again on your mobile device, you’re at the check-out step of an online shopping app.

Writing credit card numbers on non-semantic HTML

Despite its high relevance as part of a web form, often times there seems to be low HTML consideration for credit card number fields, relying exclusively on javascript to proactively/reactively resolve any kinds of wrong content being filled in.

This results in bringing up the same kind of keyboard as in the previous example, with that first tap on the input element bringing up that same generic keyboard. Constraining users to hit tiny keys that are in a single-row-not-helpful-here layout, right above a bunch of not-currently-needed-and-can-only-cause-issues-here keys.

input type=”text”, without any other bells/whistles/pattern attr for credit card numbers

Writing credit card numbers on semantic HTML

Contrast that, to a single tap on the input element directly bringing up only large numeric keys, as bellow:

input type=”text” plus pattern=”[0–9]*” attribute, for credit card numbers

Similarly, yet likely to a lesser extent, the same slow-downs can occur for a user when generic inputs are used instead of their semantically corresponding siblings, when typing in emails or URLs.

Writing email addresses & URLs on semantic HTML

Instead of letting the user tap the ‘123’ key, and then look for specific email or URL related symbols, once again we can pay attention to the semantics of those fields to set their corresponding type attribute in HTML, and enable optimised versions of the on-screen keyboard.

For URLs we also see some validation-related precautions done to actually remove the ‘space’ key altogether, and replace that with the most commonly used special characters when typing links: dot, slash and a shortcut key for ‘.com’ .

input type=”text” vs input type=”url”

Interestingly, for email inputs the spacebar is not fully removed but just shrunk down, to make room for the most commonly used characters here.

input type=”text” vs input type=”email”

All seemingly tiny details, but with realistically tiny effort to achieve, that can add up to a more seamless experience using a web product.

Closing this part, remember that while setting the correct type and pattern attributes on inputs will yield benefits, client and server side validation are still needed to ensure forms don’t allow invalid data to go through.

Takeaway
Paying a closer attention to the type of information that is held by each input field, and then writing those input fields in a semantically correct manner, will significantly improve the experience of people using that web form on a mobile device.

Until next time! where we’ll take a look, at why we may take too long of a look at web forms, even before we get to the mobile keyboard.

Sources for logo image assets used in article cover:
- HTML: https://www.w3.org/html/logo/#downloads
- CSS: https://commons.wikimedia.org/wiki/File:CSS3_logo_and_wordmark.svg#file
- JS: https://github.com/voodootikigod/logo.js