Accesibilidad de los formularios: la guía completa para los embudos de generación de clientes potenciales
Casi el 25 % de los formularios web analizados por AudioEye resultaban inaccesibles para las personas con discapacidad, y el fallo más habitual era la falta de etiquetas descriptivas que los lectores de pantalla pudieran usar para identificar los campos (estudio comparativo de AudioEye). Esa cifra debería hacer que los equipos de rendimiento se replanteen cómo abordan la accesibilidad de los formularios. No se trata de una simple cuestión de cumplimiento normativo, sino de un problema estructural en la forma en que se crean los formularios de captación de clientes potenciales, cómo se etiquetan y cómo se recuperan cuando algo falla.
Para los profesionales del marketing, la definición práctica es sencilla. Un formulario accesible es aquel que todos los usuarios pueden percibir, entender, manejar y del que pueden recuperarse, incluyendo a los usuarios de lectores de pantalla, a los que solo usan el teclado, a las personas con baja visión y a las que tienen discapacidades motoras. Las WCAG 2.1 vinculan esto directamente con la operatividad del teclado, el foco visible y las etiquetas programáticas, para que las tecnologías de apoyo puedan determinar el nombre, la función y el valor de cada control (WCAG 2.1).
Esto va mucho más allá de la ética. Los formularios defectuosos o confusos te exponen a riesgos legales en el marco de normativas como la ADA, la EAA y la Sección 508. Además, desperdician el tráfico pagado, ya que un formulario difícil de rellenar reduce el valor de cada clic que has comprado. Además, los envíos mal formados contaminan tu CRM con datos erróneos, clientes potenciales a medio completar y entradas que no reflejan lo que el usuario pretendía.
Un buen formulario de captación de clientes tiene que cumplir dos funciones a la vez. Tiene que generar conversiones y tiene que seguir siendo fácil de usar cuando el usuario navega con el teclado, utiliza un lector de pantalla o sigue un flujo condicional de varios pasos en el móvil. Ese es el criterio que se aplica en esta guía.
Table of Contents
Índice
- Qué significa realmente la accesibilidad de los formularios
- Argumentos comerciales y jurídicos a favor de los formularios de contacto accesibles
- Requisitos de las WCAG aplicados a las características reales de los formularios de contacto
- Patrones de implementación para etiquetas, selección de campos y gestión de errores
- Embudos de varios pasos, lógica condicional y realidad móvil
- Una lista práctica de comprobación de accesibilidad antes del lanzamiento
- Herramientas de pruebas y cómo usarlas juntas
- Ventajas de accesibilidad específicas de los embudos de estilo Growform
Qué significa realmente la accesibilidad de los formularios
La forma más clara de entender la accesibilidad de los formularios es esta: un formulario es accesible cuando el usuario puede rellenarlo sin tener que adivinar para qué sirve cada campo, dónde está el foco, qué ha fallado o cómo recuperarse tras un error. Si un usuario que usa el teclado no puede desplazarse por él con la tecla Tab en un orden lógico, o si un lector de pantalla solo dice «editar texto» sin contexto, el formulario no funciona bien en la práctica, aunque se vea bien en el navegador.
La magnitud del problema no es nada pequeña. El informe «WebAIM Million 2026» detectó 56 114 377 errores de accesibilidad distintos en un millón de páginas de inicio, lo que supone una media de 56,1 errores por página. En ese mismo estudio, los fallos de etiquetado seguían siendo habituales: el 34,2 % de los campos de los formularios no estaban etiquetados correctamente y el 51 % de las páginas de inicio más visitadas presentaban campos de formulario sin las etiquetas adecuadas (WebAIM Million 2026). Esto hace que la accesibilidad de los formularios no sea tanto un problema de acabado como un defecto de producción recurrente.
Regla práctica: si un usuario necesita la vista, un ratón o una memoria perfecta para navegar por el formulario, es que tu proceso no es accesible.
Para los equipos de generación de clientes potenciales, el argumento comercial es claro. Los fallos de accesibilidad provocan un aumento de las bajas, más solicitudes de asistencia, más trabajo de corrección tras las quejas por incumplimiento normativo y más ruido en el proceso de ventas. Además, obligan a los equipos de ventas y operaciones a gestionar los formularios que se han enviado a pesar de la confusión, lo cual es una mala señal para la calidad de los clientes potenciales. Un formulario que confunde a la gente no solo hace que se pierdan conversiones, sino que puede mermar la integridad de todo el sistema de captación.
La imagen de arriba es deliberadamente sencilla porque el tema principal también lo es. La accesibilidad no es una casilla que hay que marcar para cumplir con la normativa, sino un requisito para que la fase inicial de tu embudo funcione para todos los que lleguen hasta ella. Si lo construyes así desde el principio, el resto del sistema tendrá muchas más posibilidades de mantenerse limpio.
Argumentos comerciales y jurídicos a favor de los formularios de contacto accesibles
La accesibilidad se ha convertido en un tema que llega hasta la junta directiva, ya que los riesgos legales y operativos se están uniendo. Las entidades públicas ya están bajo presión por los plazos que impone la norma web del Título II de la ADA, y las empresas privadas se enfrentan a litigios en curso, a unas expectativas de accesibilidad cada vez mayores y a la realidad de que los formularios digitales son la puerta de entrada a los ingresos. Un formulario que excluye a los usuarios sigue siendo un problema empresarial incluso antes de convertirse en uno legal.
La lógica comercial es igual de sólida. Cada etiqueta rota, cada error oculto o cada paso que no se puede usar se convierte en un gasto publicitario desperdiciado, porque el clic se produjo, pero el cliente potencial no completó el proceso correctamente. Si un usuario no puede rellenar un formulario con confianza, el registro del CRM que se genera puede estar incompleto, mal transcrito o ser poco fiable desde el punto de vista estructural. Eso crea problemas a la hora de redirigir el cliente, atribuir el mérito, puntuar el cliente potencial y hacer el seguimiento de ventas posterior.
La accesibilidad es uno de los pocos proyectos que pueden mejorar el cumplimiento normativo, la calidad de los datos y la disciplina en la conversión, todo al mismo tiempo.
También hay que tener en cuenta el aspecto práctico del presupuesto. Adaptar un formulario a posteriori tras recibir quejas lleva más tiempo que incorporar desde el principio los patrones adecuados en el generador, la plantilla o la biblioteca de componentes. Los equipos que esperan suelen acabar retocando las etiquetas, el orden de tabulación, la gestión de errores y el contraste uno por uno, lo cual sale caro y es inestable. Los equipos que empiezan teniendo en cuenta la accesibilidad como una restricción se ahorran gran parte de ese trabajo.
Para los profesionales del marketing que subcontratan o revisan su conjunto de herramientas de embudo de conversión, resulta útil considerar la accesibilidad como parte de la infraestructura de conversión. Por eso, recursos como «cuándo contratar una agencia de CRO» son relevantes en este contexto, ya que la misma disciplina de rediseño que mejora la conversión suele solucionar también los fallos de accesibilidad. Un buen proceso de CRO no se limita a probar el texto de los botones, sino que comprueba si los usuarios reales pueden recorrer el flujo sin problemas.
El vínculo más claro entre el cumplimiento de las WCAG y los resultados empresariales pasa por la confianza. Si tu formulario de contacto tiene un aspecto impecable pero se comporta de forma impredecible, los usuarios se dan cuenta. Si un comprador descubre más tarde que los datos enviados son incoherentes o están incompletos, también se da cuenta. Los formularios accesibles no solo ayudan a la gente a completar el embudo de conversión, sino que también ayudan a que el embudo genere datos en los que otros equipos puedan confiar.
Requisitos de las WCAG aplicados a las características reales de los formularios de contacto
Las WCAG pueden parecer algo abstractas hasta que las relacionas con los controles del editor que usan los profesionales del marketing. Los campos de entrada nativos de HTML son importantes porque los navegadores y las tecnologías de apoyo ya saben cómo interpretarlos. Los elementos `div` con estilos personalizados que pretenden ser campos de entrada suelen alterar ese comportamiento integrado, por lo que «parece un campo» y «se comporta como un campo» no son lo mismo.
Los datos de WebAIM dejan una cosa muy clara: el etiquetado sigue siendo un punto débil recurrente (WebAIM Million 2026). Esto concuerda con el énfasis que ponen las WCAG en las etiquetas programáticas, porque la etiqueta no basta con estar cerca visualmente. Tiene que estar asociada correctamente para que la tecnología que lee la página pueda anunciar el nombre del campo, y el orden de tabulación tiene que seguir el orden visual para que los usuarios que usan el teclado no se vean obligados a seguir una ruta confusa (WCAG 2.1).
Las características que más importan
- Elementos de entrada nativos: utiliza elementos reales como
input,selectybuttonsiempre que puedas. Te ofrecen una semántica básica, un comportamiento adecuado con el teclado y una mejor interoperabilidad con los lectores de pantalla. - Etiquetas vinculadas: Vincula las etiquetas con
foryid. La proximidad visual no basta, porque las tecnologías de apoyo necesitan que esa relación quede reflejada en el código de marcado. - Foco visible: si los usuarios no pueden ver dónde se ha desplazado el foco, el formulario está, en realidad, decidiendo por ellos.
- Identificación clara de los errores: el texto del error tiene que explicar el problema con palabras sencillas, no solo poner el borde en rojo.
- Consejos, cuando sea posible: si un valor no está bien formado, dile al usuario qué tiene que hacer a continuación, en lugar de obligarle a ir probando hasta dar con la solución.
Un generador puede complicar todo esto cuando elimina el marcado pero no conserva la semántica. Lo mismo ocurre cuando los campos condicionales aparecen dinámicamente sin previo aviso o cuando los estados de error se ven, pero no se transmiten a las tecnologías de apoyo.
Si quieres ver un ejemplo práctico de un diseño para la captación de clientes potenciales en el que es fundamental que estos aspectos básicos estén bien gestionados, fíjate en la estructura de un formulario de captación de clientes potenciales. El diseño puede estar enfocado a la conversión y, aun así, fallar si las etiquetas, el foco y los mensajes de error no están configurados correctamente.
| Errores habituales de los desarrolladores y los criterios de las WCAG que incumplen | ||
|---|---|---|
| Error habitual | Criterio de las WCAG | Repercusión en los usuarios |
| Texto provisional que se usa como única etiqueta | Etiquetas y nombres de programas | El usuario pierde la función del campo en cuanto empieza a escribir |
| Div personalizado en el que se puede hacer clic y que se usa como botón | Funcionalidad y semántica del teclado | Los usuarios de teclado y de tecnologías de apoyo no pueden activarlo de forma fiable |
| El error solo se muestra en color | Identificación de errores y contraste | El fallo es invisible o ambiguo |
| El foco salta de forma impredecible después de dar un paso | Orden de enfoque y enfoque visible | El usuario se queda atascado en mitad del proceso |
Hay una regla práctica muy útil y sencilla. Si no puedes explicar cómo se introduce, se revisa y se corrige el campo, el formulario aún no está listo para su producción.
Patrones de implementación para etiquetas, selección de campos y gestión de errores
El mayor error que sigo viendo es que los equipos traten los formularios accesibles como una tarea de diseño visual. No lo es. Se trata de marcado, gestión de estados y lógica de recuperación. Puedes tener un diseño precioso y, aun así, estropear la experiencia en cuanto se activa la validación o aparece un campo condicional.
Establece la relación entre el campo de entrada y el texto de ayuda
Usa una etiqueta clara para cada campo y, a continuación, incluye instrucciones de ayuda y mensajes de error con la función « aria-describedby » cuando el texto ayude al usuario a rellenar el campo. Así, el usuario oye la instrucción al mismo tiempo que ve el control, no después. Cuando un valor no sea válido, el mensaje de error debería seguir apareciendo hasta que se resuelva el problema.
Consejo práctico: No escondas la solución en una ventana emergente o en un banner genérico si el usuario necesita esa explicación para corregir un campo concreto.
Informa de los problemas sin que el formulario se llene de mensajes
La validación en tiempo real debe usarse con moderación. Si avisas cada vez que pulsas una tecla, los usuarios se ven abrumados por las interrupciones. Una forma mejor de hacerlo es validar al salir del campo o al enviar el formulario en la mayoría de los casos, y luego mostrar el error en una zona destacada cuando el formulario necesite que prestes atención. La idea es ayudarte a corregir el error, no ir contando cada estado parcial.
Centra la atención donde el usuario la necesite
Cuando falle la validación, lleva el foco al primer campo que no sea válido o a un resumen que indique claramente cuál es el problema. No devuelvas al usuario al principio de la página sin darle ninguna explicación. Si un paso cambia por culpa de la lógica condicional, conserva los valores introducidos y mantén el orden de tabulación alineado con lo que el usuario ve ahora.
La guía de Bruce y Eddy te viene muy bien aquí porque refuerza los conceptos básicos que los equipos suelen pasar por alto cuando se pierden en las herramientas. Las buenas listas de comprobación solo son útiles si se centran en el comportamiento real que experimentan los usuarios, y no solo en la presencia de un atributo ARIA.
| Errores habituales de los desarrolladores y los criterios de las WCAG que incumplen | ||
|---|---|---|
| Error habitual | Criterio de las WCAG | Repercusión en los usuarios |
| Aparece un mensaje de error, pero el campo no hace referencia a él | Nombre, función, valor y relaciones | Los usuarios de lectores de pantalla no saben qué hay que arreglar |
| El foco se queda en el botón de enviar tras un error | Gestión del enfoque | Los usuarios tienen que buscar el campo dañado |
| El orden de tabulación no coincide con la disposición visible | Navegación con el teclado | El desarrollo parece aleatorio y propenso a los errores |
| Se ha quitado el anillo de enfoque por motivos estéticos | Enfoque visible | A los que usan el teclado se les va el hilo |
La norma es muy sencilla. Cada campo tiene que tener un nombre fácil de entender, cada error tiene que tener una ruta de recuperación y cada cambio de estado tiene que tener un resultado predecible en cuanto al foco. Esa es la diferencia entre un formulario que parece terminado y uno que ya se puede publicar.
Embudos de varios pasos, lógica condicional y realidad móvil
Los consejos generales sobre accesibilidad no sirven de nada aquí. Una cosa es un formulario sencillo con unos cuantos campos etiquetados, y otra muy distinta es un proceso de selección de cinco pasos con lógica de ramificación, vías de exclusión, verificación en tiempo real y diseño «mobile-first».
El riesgo oculto de los embudos de varios pasos es la pérdida de estado. Si un usuario responde al segundo paso, pasa al tercero y, a continuación, la interfaz cambia sin avisar de lo que ha pasado, los usuarios de lectores de pantalla pueden quedarse perdidos. Las WCAG 2.2 añaden requisitos como «Ayuda coherente», «Autenticación accesible» y «Entrada redundante», que son clave cuando un embudo te pide que repitas información o que pases por pasos de verificación (tutorial de formularios de la WAI). La cuestión no es solo si un campo tiene etiqueta, sino si el usuario puede seguir avanzando por una interfaz cambiante sin perder el contexto.
Lista de comprobación paso a paso
- Diseño: Decide qué campos son obligatorios y no hagas que el usuario tenga que volver a descubrirlos a través de mensajes de error. Mantén el orden visual y el orden lógico alineados desde el principio.
- Desarrollo: Cuando aparezca un campo condicional, asegúrate de que se incorpore al árbol de accesibilidad de forma que las tecnologías de apoyo puedan interpretarlo. Si un campo desaparece, no dejes el foco en un elemento inactivo.
- Puesta en marcha: Prueba todo el embudo en el móvil con el teclado en pantalla abierto, ya que ese teclado suele tapar las etiquetas, los botones o el texto de ayuda.
- Revisión: Comprueba que los indicadores de progreso transmitan algo significativo. Una barra decorativa no basta cuando el usuario necesita saber en qué punto del proceso se encuentra.
La versión móvil genera sus propios problemas. Los elementos en los que hay que pulsar pueden acabar siendo demasiado pequeños para usarlos con facilidad, el zoom con los dedos se desactiva por culpa de plantillas bienintencionadas, y los campos que se ven bien en el ordenador se convierten en un lío en una pantalla más pequeña. Si el embudo de conversión depende de pulsaciones precisas o de texto minúsculo, no está preparado para móviles, por mucho que lo diga el diseño.
También he visto casos en los que los procesos de descalificación se han gestionado mal. La interfaz muestra un error o un callejón sin salida, pero al usuario no se le da una explicación clara de lo que ha pasado. Eso es un problema de conversión y de accesibilidad a la vez, porque el usuario se merece saber claramente qué ha pasado, incluso cuando no cumple los requisitos.
Si buscas una guía práctica centrada en los dispositivos móviles, esta guía con seis consejos esenciales para el diseño de formularios móviles te resultará útil, ya que los fallos de accesibilidad en el móvil suelen ser simplemente fallos de usabilidad debidos a que la pantalla es más pequeña. Un formulario que funciona en un portátil pero que falla al usarlo con la pantalla táctil, al hacer zoom o ante cambios condicionales sigue sin funcionar bien.
Si un usuario no sabe qué ha cambiado entre un paso y otro, tu embudo se ha convertido en un juego de adivinanzas.
Una lista práctica de comprobación de accesibilidad antes del lanzamiento
Esta es la versión que me gustaría que figurara en una incidencia de gestión de proyectos antes del lanzamiento. Haz que sea concisa, sigue el orden y no la lances hasta que hayas comprobado todos los puntos.
Diseño
- Etiqueta cada campo con claridad: escribe el texto real de la etiqueta, no el texto provisional que luego desaparece.
- Deja espacio para los errores: no dejes que el diseño se desmorone cuando aparezcan los mensajes de validación.
- Planifica el orden de las pestañas: asegúrate de que la secuencia visual coincida con la secuencia del teclado.
Compilar
- Utiliza primero los controles nativos: recurre al HTML estándar antes de añadir widgets personalizados.
- Ayuda sobre el enlace y el texto de error: Adjunta la copia de apoyo en
aria-describedby, donde corresponde. - Mantén el enfoque visible: comprueba el anillo de enfoque en todos los puntos de ruptura, incluido el móvil.
Lanzamiento
- Haz la prueba solo con el teclado: rellena todo el formulario sin tocar el ratón.
- Prueba con un zoom del 200 %: comprueba si las etiquetas, los botones y los mensajes de error siguen cabiendo y se siguen viendo bien.
- Prueba una ruta completa con un lector de pantalla: usa NVDA, VoiceOver o JAWS durante todo el proceso.
Auditoría posterior al lanzamiento
- Lee con atención los comentarios de los usuarios: fíjate si hay quejas recurrentes sobre atascos, datos que se repiten o que no se entienden los errores.
- Vuelve a probarlo cada vez que cambies el embudo: la lógica condicional y los cambios en el texto pueden afectar a la accesibilidad sin que cambie el diseño de la página.
- Combina la automatización con las pruebas realizadas por personas: la automatización detecta problemas evidentes de estructura, pero no te dirá si el formulario es fácil de usar.
Las herramientas automatizadas son rápidas, las comprobaciones con el teclado son reveladoras y los lectores de pantalla sacan a la luz problemas de estado que los escáneres no detectan. Las pruebas con usuarios reales detectan los fallos que no se ven hasta que alguien intenta rellenar el formulario en condiciones normales. Usa las tres, porque cada una detecta una faceta diferente del problema.
Herramientas de pruebas y cómo usarlas juntas
Los escáneres automáticos son útiles, pero no son la solución definitiva. Herramientas como axe, Lighthouse, AudioEye y Level Access son muy útiles para detectar etiquetas que faltan, problemas de contraste y fallos estructurales, y por eso mismo no pueden faltar en ningún flujo de trabajo de desarrollo. Sin embargo, son mucho menos fiables a la hora de detectar las partes más complicadas de un embudo, como las transiciones entre pasos, los elementos que se muestran de forma condicional y la recuperación tras un envío fallido.
Por eso el conjunto de herramientas de pruebas necesita varias capas. Las extensiones para el navegador te ayudan a inspeccionar el contenido de la página en tiempo real. Los lectores de pantalla como NVDA, VoiceOver y JAWS te muestran lo que oye el usuario. Las pruebas solo con el teclado te indican si una persona puede desplazarse por el formulario sin quedarse atascada ni confundirse. La combinación es más importante que cualquier herramienta por sí sola.
Regla práctica: si una herramienta no puede cubrir todo el embudo de principio a fin, no puede ser tu único filtro.
Una cadencia razonable es sencilla. Revisa cada cambio, haz una prueba manual con el teclado y el lector de pantalla antes del lanzamiento y, después, programa revisiones externas periódicas para los formularios más importantes. Si utilizas una herramienta de análisis específica, un recurso como Growform Form Analytics te puede ayudar a detectar dónde abandonan los usuarios, pero los datos de análisis siguen necesitando la interpretación humana cuando la accesibilidad es la causa principal del abandono.
Los mejores equipos no se preguntan qué herramienta es «la mejor». Se preguntan qué detecta cada una, qué se les escapa y con qué rapidez pueden solucionar los fallos que realmente importan para garantizar la calidad. En un embudo, eso suele significar detectar los problemas antes de que el tráfico acabe pagando por ellos.
| Tipo de herramienta | Qué atrapa | Lo que le falta |
|---|---|---|
| Escáneres automáticos | Faltan etiquetas, hay problemas evidentes de contraste y errores estructurales básicos | Lógica de flujo, comportamiento de enfoque, confusión en el mundo real |
| Herramientas basadas en navegador | Estado del DOM, comportamiento en tiempo de ejecución, comprobaciones rápidas durante el desarrollo | La experiencia real del usuario y los resultados de la tecnología de apoyo |
| Pruebas manuales | Lagunas lógicas, trampas del teclado, problemas con los lectores de pantalla | Problemas de código puramente estáticos a gran escala |
La automatización es el primer paso. Las pruebas manuales son la comprobación. Los usuarios reales son la comprobación final.
Ventajas de accesibilidad específicas de los embudos tipo Growform
En los embudos de captación de clientes potenciales de varios pasos, condicionales y diseñados pensando primero en los dispositivos móviles, el trabajo de accesibilidad más valioso suele ser el que conserva el contexto. Los campos condicionales deberían eliminarse del árbol de accesibilidad cuando no sean relevantes, los cambios de paso deberían anunciarse a través de una zona interactiva y los datos introducidos deberían conservarse entre pasos para que los usuarios no tengan que volver a escribir lo que ya te han dado. Si el embudo descarta a alguien, el resultado debería anunciarse claramente, sin dejarlo a la interpretación.
¿Qué es lo que suele marcar la diferencia más rápido?
- Anuncia los cambios importantes: una breve actualización del estado permite a los usuarios de lectores de pantalla hacerse una idea clara del progreso.
- Conserva los datos introducidos en todas las ramas: no hagas que los usuarios tengan que empezar de cero solo porque hayan seguido una ruta diferente.
- Haz que el progreso sea informativo: el indicador de progreso debería indicarte dónde estás, no solo servir de adorno en la página.
La objeción más habitual es que la accesibilidad va a afectar negativamente a la conversión. En la práctica, una accesibilidad bien implementada suele ayudar, ya que elimina las dificultades para todo el mundo, no solo para los usuarios de tecnologías de apoyo. Lo que realmente frena la conversión es la ambigüedad, y los formularios accesibles la eliminan en gran medida.
Cuando los presupuestos andan justos, céntrate primero en lo básico. Las etiquetas, el orden de enfoque y la recuperación de errores siempre son mejores que los rediseños superficiales. El objetivo de cumplir con las WCAG 2.1 AA sigue siendo un mínimo razonable para 2026, pero los equipos que estén creando embudos más largos deberían prestar atención a los comportamientos de las WCAG 2.2 que afectan a los flujos de varios pasos, sobre todo los relacionados con la disponibilidad de ayuda, la introducción repetida de datos y la autenticación.
Los bots y la verificación son un tema aparte. Las comprobaciones por teléfono y correo electrónico deberían reducir el spam, no bloquear a los usuarios reales que necesitan un poco más de tiempo o que usan tecnologías de apoyo. Si un paso de verificación se convierte en un obstáculo, hay que rediseñarlo, no defenderlo.
Una opción en este ámbito es Growform, que está diseñado para la captación de clientes potenciales en varias etapas y la calificación condicional. Sin embargo, la elección del producto importa menos que las decisiones de implementación, porque incluso alguien con mucha experiencia en desarrollo puede acabar con un embudo que no funciona si no se gestionan con cuidado las etiquetas, el enfoque y los cambios de estado.
Si hoy vas a revisar un formulario en producción, empieza por tres cosas: etiquetas claras, un orden de selección predecible tras los errores y mensajes claros cuando el embudo cambie de estado. Esos tres cambios suelen poner de manifiesto el resto del trabajo que hay que hacer.
Si quieres un formulario de captación diseñado para flujos de calificación sin que los usuarios se encuentren con callejones sin salida, empieza por ver cómo gestiona Growform la captura en varios pasos, la lógica condicional y la cumplimentación pensada para móviles. Después, comprueba tu embudo actual con la lista de verificación de arriba y corrige los puntos en los que los usuarios tienen que adivinar qué hacer.