Un error exclusiu del mòbil pot procedir del disseny responsive, validació, teclat, capes tàctils, JavaScript, CAPTCHA o xarxa. Una prova d’escriptori no reprodueix aquestes condicions.
Identifica si el botó no es pot prémer, la petició falla o el missatge es lliura sense feedback.
Reprodueix en un mòbil real
Utilitza un perfil net i el tipus de xarxa informat quan sigui possible. Registra dispositiu, sistema, navegador, orientació, URL, hora i consentiment.
Introdueix una referència única. No premis repetidament un botó congelat; revisa les entrades abans. L’emulació ajuda amb el disseny, però no reprodueix el teclat, les polítiques de Safari o la xarxa cel·lular.
Inspecciona obstacles tàctils
Comprova si un peu fix, xat, bàner de galetes o capa transparent cobreix Submit. Prova zoom, horitzontal i teclat obert.
Utilitza inspecció remota per saber quin element rep el toc. Corregeix stacking i espai a la font. No elevïs simplement el z-index del formulari per damunt del consentiment o navegació.
Revisa els valors introduïts al mòbil
Els teclats de correu, telèfon o data poden afegir espais, puntuació intel·ligent o formats locals. La validació client els pot rebutjar sense mostrar cap error visible.
Mantén labels i errors per damunt del teclat i mou el focus al primer camp invàlid. Utilitza tipus semàntics, però valida i saneja també al servidor. Prova noms accentuats i telèfons internacionals previstos.
Captura JavaScript i xarxa
Utilitza depuració remota o eines amb el mateix navegador. Localitza el primer error i l’estat de la petició.
Una xarxa lenta revela curses: caduca el token CAPTCHA, arriba tard una dependència o venç el request. No augmentis timeouts sense confirmar si el servidor ha rebut i desat l’entrada.
Prova també el mode d’estalvi de dades i navegadors integrats de xarxes socials si formen part del trànsit real. Poden retardar scripts, bloquejar finestres o modificar galetes d’una manera que Chrome d’escriptori no reprodueix.
Prova CAPTCHA, consentiment i privadesa
Els bloquejadors mòbils, protecció estricta o estat del consentiment poden impedir carregar scripts externs. El formulari ha de continuar sent comprensible i mostrar un error específic si no carrega la verificació.
Revisa domini i clau del proveïdor i CSP. No desactivis CAPTCHA per a tot mòbil; corregeix la integració o utilitza un altre control compatible. Prova acceptació i rebuig del consentiment opcional.
Compara variants responsive i memòria cau
Un constructor pot generar formularis separats per a escriptori i mòbil o ocultar una còpia amb CSS. Es poden duplicar IDs o nonces i inicialitzar scripts dues vegades.
Inspecciona DOM i Xarxa. Prefereix un formulari responsive únic. Revisa variants mòbils de CDN per scripts o tokens antics i purga només després de corregir la font.
Verifica servidor, notificació i interfície
Després de reparar, prova iOS/Safari i Android/Chrome quan siguin rellevants. Confirma èxit HTTP, una entrada, un correu i una confirmació accessible.
Prova validació, rotació, navegació enrere i adjunts. La conversió d’Analytics ha d’activar-se només després de confirmar el servidor.
Prova les limitacions reals
Utilitza almenys un dispositiu real amb dades mòbils i un altre amb Wi-Fi. Registra la versió, hora i si ha arribat la petició.
Comprova que els camps acceptin dades realistes sense autocorreccions perjudicials. Mantén l’error al costat del camp i desplaça el focus perquè el visitant no quedi bloquejat fora de pantalla.
Per a pujades, prova una foto autoritzada de la càmera amb format i mida habituals. El límit, HEIC o una regla de seguretat pot fallar només amb fitxers mòbils.
Quan cal demanar reparació mòbil
Demana ajuda si intervenen overlays, Safari, CAPTCHA o memòria cau mòbil. Facilita dispositiu, navegador, URL, hora i error redactat, sense dades personals.
La reparació ha de fer fiable el recorregut mòbil real, no només superar l’emulació d’escriptori.