The keyboard occludes the input area and the submit control
Aliases: keyboard occlusion · covered field · hidden submit
What it is
A soft keyboard, once up, consumes the lower half of the screen. The field being edited and the button that submits often sit behind it. People can type and still not see the characters just produced, or they finish typing and cannot find Next / Log in / Send. What is covered is not chrome. It is two necessary pieces of the type–confirm loop.
Why it happens
The soft keyboard is a system layer one-third to one-half of the viewport high. If the app still lays out against the un-raised height, bottom fields, toolbars, and primary buttons fall behind it. Gaze has to jump among keyboard, caret, and button; when the field is covered, errors can only be judged from memory; when the button is covered, the loop breaks on the last step. Landscape, split view, and floating keyboards change the shape of the cover but not the fact of a large occupied area. The problem is a system layer covering the app layer, not whether the keys are drawn correctly.
Studying it
On target devices, raise the keyboard and record whether the current field, error text, and primary action remain in view, plus scrolls, taps on empty space to dismiss, and grip changes made in order to see them. Independent variables include device, orientation, keyboard height (candidate bar included), and field position on the page; dependent measures include count of covered controls, extra scrolls, and abandoned submits. Clicking an input in a desktop browser never shows this occupancy.
Where it stops holding
A hardware keyboard, or a keyboard collapsed to a toolbar, shrinks occupancy and eases this occlusion. On a large tablet the keyboard may not sit on the bottom, and the covered region moves. A covered password field may still be accepted because the user did not want bystanders to see it; a covered submit cannot be excused on the same grounds.
Applying it
- On focus, scroll the current field into the region above the keyboard, and keep the primary submit visible as well—not the field alone.
- Make Send / Next the keyboard’s Enter action or a bar attached above the keyboard, so it does not exist only in a footer that will be covered.
- Screenshot on a real device with the keyboard up: field, validation message, and primary button must all lie in view.