1295
Scroll automático al campo enfocado
Cuando el usuario toca un campo de texto y el teclado sube, el campo debe quedar visible por encima del teclado con al menos 16pt de margen. En web mobile usa `scrollIntoView({ behavior: 'smooth', block: 'center' })`; en apps nativas ajusta el contentInset del scroll view en respuesta a `keyboardWillShow`. No dependas del comportamiento automático del OS, Android varia por fabricante.
investigación 2026
Al activar el campo de email, el scroll sube automáticamente para que el campo quede siempre visible sobre el teclado
KeyboardAvoidingView scrollea automáticamente para que el campo enfocado quede siempre visible. El usuario escribe con contexto visual completo.
Registro
Campo email oculto bajo el teclado
El campo de email activo queda oculto bajo el teclado: el usuario escribe a ciegas sin poder ver lo que escribe ni si hay errores en tiempo real.
1296
Padding vs scroll según layout
Si el formulario tiene pocos campos, anadir padding-bottom igual a la altura del teclado es suficiente. Si el formulario tiene muchos campos, usa scroll view con contentInset dinámico. Nunca uses position fixed para anclar el formulario sobre el teclado en web mobile, produce jank y saltos al animar el teclado.
investigación 2026
El botón Ingresar flota pegado al teclado. La tecla Return tiene la etiqueta "IR" para enviar sin levantar las manos
El CTA principal flota justo encima del teclado con KeyboardAccessoryView. La tecla Return del campo password tiene la etiqueta "Ir" para enviar sin cerrar el teclado.
Inicia sesión
Ingresar
El teclado tapa el botón Ingresar
El usuario no puede enviar el formulario
El teclado oculta el botón de submit: el usuario completa ambos campos pero no puede enviar el formulario sin cerrar el teclado primero.
1297
Input accessory view contextual
Usa el inputAccessoryView (barra sobre el teclado en iOS) para incluir botones Anterior/Siguiente entre campos, label del campo actual, y opción de descarte. Esta barra aprovecha espacio que de otro modo se desperdicia y reduce la necesidad de hacer tap fuera del teclado para cerrar.
investigación 2026
Accessory view con Anterior/Siguiente, label del campo activo y botón Listo para descartar
La barra sobre el teclado muestra el nombre del campo activo, flechas para saltar entre campos sin cerrar el teclado, y un botón Listo para descartarlo. Reduce pasos y aprovecha espacio muerto.
Sin accessory view: el usuario debe hacer scroll o tap fuera del teclado para navegar entre campos
El teclado aparece sin barra contextual. Para ir al campo siguiente el usuario debe cerrar el teclado, hacer tap en el otro campo, y volver a abrirlo. En formularios largos esto multiplica los pasos.
1298
Tres métodos de descarte obligatorios
El teclado debe descartarse con: (1) tap fuera del campo de texto activo, (2) scroll hacia arriba en el contenido principal, (3) botón explicito de cerrar teclado en el inputAccessoryView. Solo implementar tap-outside deja a usuarios sin touchscreen grande sin forma comoda de cerrar el teclado.
investigación 2026
3 métodos: tap fuera + scroll + botón cerrar en accessoryView. El usuario siempre tiene forma de descartar.
Solo tap-outside. Si el usuario no puede alcanzar fuera del campo, el teclado queda atrapado.
1299
Tipo de teclado según campo
Usa el atributo inputType / type correcto para cada campo: email para email (arroba visible), tel para telefonos (teclado numérico con guiones), number para cantidades, url para URLs (punto y slash visibles), search para busquedas (botón de busqueda en lugar de return). El teclado incorrecto fuerza al usuario a cambiar manualmente la disposición.
investigación 2026
Telefono type="tel"
55 8124
Teclado numérico con guiones y +: cada digito accesible con un solo tap, sin cambiar de capa
Telefono type="text"
55812
Teclado QWERTY completo para un campo de telefono: el usuario debe buscar los números en una segunda capa
