Preparar una prueba de teclado para el contacto de una web

Aprende a probar el contacto de tu web con teclado: recorrido del foco, campos, errores y confirmación, con criterios concretos para revisar una entrega web.

Equipo Latech·15 de octubre de 2026· 22 min

1. Empieza por una tarea que pueda terminarse

Para preparar una prueba de teclado para el contacto de una web, define primero qué debe conseguir la persona: llegar desde una página de servicio, explicar su necesidad y completar una solicitud sin utilizar el ratón. El recorrido termina cuando entiende qué ha ocurrido con su mensaje. Alcanzar el botón de envío es solamente una parte de esa tarea.

La referencia técnica de partida es sencilla: la funcionalidad debe poder manejarse mediante una interfaz de teclado, con las excepciones que contempla el criterio correspondiente. El W3C explica este principio en su documentación sobre operabilidad mediante teclado. Para una revisión comercial, tradúcelo en acciones reconocibles: abrir contacto, escoger una opción, escribir, corregir y continuar hasta el desenlace previsto.

Formula un objetivo concreto antes de empezar. Por ejemplo: una persona interesada en renovar su tienda debe poder indicar que ya tiene una web, escribir su dirección y solicitar una conversación. Si el recorrido conduce a una aplicación externa, define ese traspaso como parte del objetivo. Abrir una conversación preparada y enviar una solicitud desde un formulario propio son resultados diferentes; conviene evaluarlos con palabras distintas.

Delimita también qué decisión tomarás con la prueba. Puede servir para aceptar el recorrido principal, localizar un bloqueo o escoger entre dos propuestas de contacto. Esta revisión acotada no equivale a una evaluación completa de accesibilidad ni determina por sí sola obligaciones legales. Su utilidad está en mostrar dónde una acción concreta resulta posible, confusa o imposible. Así podrás conversar sobre cambios observables sin convertir cada incidencia en una discusión abstracta sobre si toda la web está bien o mal.

2. Escoge el tipo de contacto por su recorrido

Un formulario integrado permite reunir información dentro de la propia web. Un enlace de correo entrega la redacción al programa que utilice cada visitante. Una salida hacia mensajería conduce a otro entorno, donde quizá deba identificarse o escoger cómo continuar. Para decidir entre estas alternativas, representa la tarea completa: qué escribe la persona, dónde lo escribe y en qué momento cree haber contactado.

Propón una comparación basada en necesidades. Si basta con iniciar una conversación breve, una salida claramente anunciada puede encajar. Si necesitas distinguir entre soporte, contratación y una consulta comercial, un formulario con opciones comprensibles puede ayudar a ordenar la petición. Evita añadir preguntas únicamente porque resulta fácil incorporarlas: cada campo debería cambiar una decisión posterior o aportar contexto útil a quien recibe el mensaje.

El texto del botón merece una prueba propia. Pide a otra persona que explique qué espera después de leer «Enviar consulta», «Preparar mensaje» o «Continuar por WhatsApp». Si sus expectativas no coinciden con el funcionamiento previsto, cambia la redacción antes de añadir explicaciones extensas. El mejor resultado de esta comparación es que acción, destino y expectativa encajen sin exigir que el visitante adivine el proceso.

En la web oficial de Latech, el contacto principal presenta un recorrido que continúa por WhatsApp y señala que el mensaje puede revisarse antes de enviarlo. Ese detalle permite plantear una prueba específica: completar la información, activar la continuación y reconocer el cambio de entorno. No permite afirmar que abrir WhatsApp ya constituya el envío. Al evaluar tu propio proyecto, utiliza esta misma distinción para elegir el canal por su funcionamiento real y por las preferencias de tus clientes.

3. Prepara el escenario sin contaminar el resultado

Elige una página de entrada realista. Empezar directamente dentro del primer campo oculta lo que ocurre antes: menús, avisos, enlaces repetidos o botones flotantes. Una buena primera sesión comienza en una página de servicio y busca el contacto desde allí. La segunda puede entrar directamente en contacto para separar las dificultades de navegación de las que pertenecen al formulario.

Utiliza un equipo y un navegador identificables, con una ventana de tamaño conocido. Antes de atribuir una anomalía a la web, comprueba la configuración de navegación por teclado del entorno. La finalidad práctica es que otra persona pueda repetir la misma experiencia. Si cambias de navegador, tamaño de ventana y configuración simultáneamente, perderás la oportunidad de saber qué variación explica una diferencia.

Prepara datos de ensayo breves: un nombre ficticio, una dirección de correo reservada para la prueba y una consulta que se reconozca como ensayo. Acuerda con quien gestiona la recepción cómo realizar el envío final. Para practicar errores, basta con textos incompletos y opciones vacías; no necesitas introducir información personal de clientes. Si existe un entorno de pruebas equivalente al publicado, úsalo para los intentos que puedan generar solicitudes repetidas.

Aparta el ratón durante cada recorrido. Si necesitas utilizarlo para recuperar el control, detén ese intento y anota el punto exacto; después podrás investigar la causa con otras herramientas. No conviertas el rescate en parte del resultado satisfactorio. Trabaja primero con una ruta corta y luego añade variaciones. Esta preparación permite distinguir una dificultad que aparece siempre de un despiste ocasional del observador, y evita que una sesión improvisada produzca conclusiones demasiado amplias sobre todo el proyecto.

4. Sigue el foco desde la entrada hasta el contacto

El foco identifica el elemento que recibe la interacción del teclado. Durante la prueba, observa qué control queda activo después de cada avance. Como recorrido inicial, utiliza Tab para avanzar y Mayús más Tab para retroceder, atendiendo a las convenciones del entorno. El criterio de orden del foco del W3C pide preservar el significado y la operabilidad cuando la secuencia influye en ellos.

Dibuja una ruta esperada con nombres visibles: enlace de contacto, nombre, correo, motivo, mensaje y continuación. No la conviertas en una secuencia obligatoria para cualquier diseño. Una distribución puede admitir varios órdenes comprensibles; lo que buscas es detectar saltos que desorienten o separen acciones relacionadas. Por ejemplo, resulta sospechoso abandonar un campo, recorrer enlaces del pie y regresar después a la siguiente pregunta del mismo formulario.

Haz también el trayecto inverso. Sitúate en el botón final y vuelve hacia los campos para corregir la consulta. Esta vuelta representa una acción normal: alguien recuerda un detalle antes de enviar. Observa si puede regresar al mensaje de forma comprensible o si termina en controles alejados. Aprovecha para comprobar que los enlaces visualmente duplicados tienen una función clara dentro del recorrido, en lugar de sumar pasos sin aportar una alternativa útil.

No persigas un número universal de pulsaciones. Un formulario con más opciones puede requerir más navegación y seguir siendo comprensible. Utiliza el recuento para comparar dos versiones del mismo recorrido: si una añade numerosos pasos antes del primer campo, examina qué los provoca. La decisión útil será conservar accesos relevantes, simplificar repeticiones innecesarias y corregir saltos que impidan entender dónde continúa la tarea.

5. Comprueba que el indicador se ve de verdad

Una persona puede estar avanzando por controles sin reconocer cuál está activo. Por eso, dedica una pasada exclusivamente a la percepción del foco. El W3C recoge la necesidad de un indicador visible del foco de teclado. En tu revisión, observa cada campo, enlace y botón con sus fondos reales, incluidas fotografías, tarjetas de color y zonas oscuras.

Detente antes de activar cada acción y responde una pregunta: ¿puedo señalar el elemento activo sin deducirlo de la pulsación anterior? Si necesitas recordar mentalmente toda la secuencia, el diseño merece revisión. Diferencia el borde permanente de un campo del indicador que aparece al enfocarlo. Un elemento puede estar bien delimitado y, aun así, no comunicar con claridad que recibirá la siguiente interacción.

Ensaya especialmente los controles pequeños que acompañan al formulario: iconos de ayuda, casillas, enlaces de privacidad y cierres. Para comparar propuestas visuales, pide ver el mismo control en reposo y con foco. Un indicador que resulta claro sobre blanco puede perderse al pasar a una tarjeta de otro color. La decisión de diseño debería considerar ambos estados desde el principio, igual que se consideran el texto normal y el texto de un botón.

Añade una observación distinta para los elementos superpuestos. Una cabecera fija o una banda inferior puede cubrir el control activo. El criterio sobre foco no oculto del W3C aborda la ocultación completa por contenido creado por el autor. Como objetivo práctico del proyecto, busca que se reconozcan cómodamente tanto el control como su contexto. Avanza hasta el final y retrocede: las superposiciones pueden molestar en lugares distintos según la dirección del recorrido.

6. Revisa los campos mientras escribes y corriges

Prueba el formulario con una consulta breve y otra algo más detallada. Al entrar en cada campo, identifica qué información pide y qué parte es opcional. El tutorial del W3C sobre etiquetas de controles explica la relación entre etiquetas y campos. La comprobación visual inicial consiste en reconocer el propósito del campo incluso después de empezar a escribir; la asociación técnica requiere una revisión adicional.

Utiliza «Empresa» como ejemplo de decisión. Si atiendes también a particulares, marcarla como opcional puede evitar que alguien invente una respuesta para continuar. Si necesitas saber cómo devolver la consulta, decide si solicitas correo, teléfono o una elección entre ambos. No conviertas una preferencia interna en una pregunta obligatoria sin considerar qué hará la persona que no pueda o no quiera responder por ese canal.

Dentro del mensaje, escribe dos párrafos, vuelve al primero y modifica una palabra. Comprueba que la edición resulta previsible y que puedes continuar al siguiente control cuando terminas. Añade una dirección web dentro del texto y una consulta con tildes. El objetivo del ensayo no es agotar todas las combinaciones posibles, sino representar una explicación normal de tu cliente, con sus correcciones y detalles habituales.

Examina también las instrucciones. Si pides un formato concreto, ofrece un ejemplo antes del intento fallido. «Dirección de tu web» orienta mejor que «URL» cuando tu público no usa ese término. Si existe un límite de extensión, prepara una consulta que se acerque a él y observa cómo se comunica. El criterio comercial es conservar la intención de la persona: debería poder explicar lo suficiente para iniciar una conversación sin enfrentarse a un pequeño examen de terminología técnica.

7. Ensaya opciones, desplegables y campos condicionales

No todos los controles se manejan como una caja de texto. En un grupo de opciones excluyentes, las flechas pueden intervenir en la elección; el patrón de grupos de botones de opción del W3C describe esta interacción. Antes de considerar que un grupo se ha saltado elementos, distingue entre entrar en el grupo y recorrer sus opciones. La prueba debe atender al tipo de control utilizado.

Para escoger el motivo de contacto, compara dos alternativas concretas. Tres motivos breves pueden presentarse como opciones visibles; una relación más extensa puede necesitar otro tratamiento. Evalúa cuánto contexto necesita el visitante para elegir. «Quiero una web», «Quiero una tienda» y «Tengo otra consulta» ayudan a describir una necesidad. Categorías internas como departamentos o códigos comerciales pueden exigir conocimientos que el cliente no tiene.

Si una elección muestra nuevas preguntas, cambia de opción después de rellenarlas. Por ejemplo, selecciona que ya tienes web, introduce una dirección y luego indica que empiezas desde cero. Observa qué campos permanecen visibles, qué se solicita ahora y cómo sigue el recorrido. El objetivo es detectar contradicciones: una pregunta escondida que continúa bloqueando el envío o una elección que obliga a regresar al principio sin explicación.

Prueba también una respuesta que no encaje en las categorías principales. Una persona puede necesitar soporte sobre algo existente o querer combinar servicios. Decide si una opción abierta resuelve ese caso sin sobrecargar a todos los visitantes. La mejor organización será la que permita elegir con seguridad razonable y después ampliar la explicación. Si necesitas un componente visual complejo para una decisión sencilla, incluye en la comparación una versión más simple y examina ambas con el mismo caso.

8. Abre, cierra y recupera el recorrido

Una ventana superpuesta puede mostrar ayuda, privacidad o el propio contacto. Su prueba necesita un pequeño recorrido independiente: abrirla, entender dónde estás, utilizar sus controles y cerrarla. El patrón de diálogo modal del W3C describe la entrada del foco, su recorrido dentro del diálogo, el cierre con Escape y el regreso al elemento que lo abrió, con excepciones según el flujo.

Aplica esa referencia con una situación concreta. Estás escribiendo una consulta, abres una explicación sobre los datos solicitados y después quieres continuar. Comprueba si reconoces la ventana activa y si encuentras una salida visible. Al cerrarla, observa dónde queda el foco y si puedes retomar la pregunta anterior. La alternativa de abrir otra página también debe ensayarse: regresar al contacto debería formar parte de la experiencia prevista.

Distingue una contención deliberada de una trampa. Mientras un diálogo modal está abierto, limitar el recorrido a su interior puede ser correcto. El problema aparece si no hay una salida operable y quedas atrapado. El criterio de ausencia de trampas de teclado del W3C fundamenta esta comprobación. Anota qué elemento permite entrar y cuál debería permitir salir para localizar el fallo con precisión.

Presta atención a las ventanas encadenadas. Si desde una ayuda puedes abrir otra explicación, prueba el regreso por ambos niveles. Como decisión de producto, valora si esa profundidad compensa el esfuerzo para una simple consulta comercial. A veces una frase junto al campo evita una ventana completa. Otras veces una explicación extensa necesita espacio propio. Escoge la solución después de comprobar cuánto interrumpe la tarea y qué información aporta realmente a quien está rellenando el contacto.

9. Provoca errores que enseñen algo útil

Un recorrido correcto con todos los datos preparados deja sin examinar la recuperación. Organiza tres intentos: uno con un obligatorio vacío, otro con un formato incorrecto y otro con varios problemas simultáneos. El tutorial del W3C sobre validación de entradas ofrece referencias sobre obligatoriedad y formatos. Utiliza esos fundamentos para decidir qué casos representan errores plausibles de tus visitantes.

Empieza dejando vacío el correo cuando sea necesario para responder. Después escribe una dirección incompleta. Compara la orientación que recibe la persona en ambos casos: «Falta tu correo» y «Revisa el formato del correo» describen problemas diferentes. Para el proyecto, propón textos que indiquen una acción posible. Evita convertir un error sencillo en un mensaje técnico que mencione procesos internos o responsabilice al visitante sin ayudarle.

En el intento con varios errores, observa cómo encuentras cada uno desde el teclado. Decide si el recorrido necesita un resumen inicial, avisos junto a los campos o una combinación de ambos. No impongas una solución idéntica para todos los formularios: cuatro campos y varias etapas plantean necesidades diferentes. El tutorial sobre notificaciones de formularios del W3C trata la identificación y explicación de errores y la comunicación del resultado.

Después corrige un único problema y vuelve a intentarlo. Esta variación permite examinar si los avisos corresponden al estado actual o siguen mostrando información antigua. Conserva para el ensayo un mensaje suficientemente largo como para que resulte molesto reescribirlo. La recuperación será más convincente si permite mantener lo que ya estaba bien y concentrarse en lo pendiente. Esa es una decisión concreta de experiencia: ayudar a terminar la consulta con el menor trabajo repetido razonable.

10. Separa privacidad, lectura y elección

El enlace de privacidad también forma parte del recorrido de contacto. Comprueba que puedes alcanzarlo, abrirlo y volver a la tarea. La AEPD recomienda presentar la información sobre el tratamiento por capas, con información básica en el momento y medio de recogida y acceso al resto. Puedes consultar su explicación del derecho de información. La revisión del teclado observa cómo se accede; la revisión jurídica determina el contenido aplicable.

No confundas leer información con elegir recibir comunicaciones comerciales. Si tu diseño presenta ambas cuestiones, revisa cada control por separado. La AEPD distingue la cláusula informativa del consentimiento. No añadas una casilla obligatoria de manera automática pensando que con ella queda resuelto todo el tratamiento de datos.

Plantea dos ensayos de interfaz: enviar una consulta sin seleccionar una opción comercial voluntaria y enviar otra seleccionándola. El resultado esperado debe corresponder al funcionamiento definido para cada elección. Lee el texto como lo leería alguien que solo quiere una respuesta a su pregunta. Si necesita interpretar una frase larga para averiguar si se suscribe a algo, considera separar las decisiones y simplificar la redacción con asesoramiento adecuado.

Incluye aquí los avisos que puedan aparecer antes del contacto, sin convertir esta prueba en una guía general sobre cookies. Observa si ocupan la pantalla, si sus acciones son alcanzables y si después puedes continuar. Para el formulario, decide qué información necesita estar próxima al punto de recogida y qué explicación puede ampliarse en otro lugar. El objetivo operativo es que informarse y elegir no destruyan el recorrido que la persona estaba realizando.

11. Examina la espera y la confirmación

Después de activar el envío, permanece en la página y observa. ¿El botón cambia? ¿Se indica que la acción está en curso? ¿Aparece un resultado comprensible? Diseña esta parte como una secuencia con principio y final, no como un destello decorativo. El criterio del W3C sobre mensajes de estado aborda cómo pueden presentarse determinados cambios a las tecnologías de apoyo sin recibir el foco.

Para la revisión inicial con teclado, describe lo que ves y lo que puedes hacer después. Una notificación visual no demuestra por sí sola que el mensaje se anuncie adecuadamente con un lector de pantalla; eso requiere otra comprobación. Mantén diferenciadas ambas observaciones. Así evitarás aceptar una confirmación únicamente porque apareció un recuadro verde o rechazar una solución porque el foco no se desplazó de una manera concreta.

Ajusta la redacción al resultado que la aplicación conoce. «Solicitud recibida» necesita una base distinta de «Mensaje preparado». Si el paso abre una conversación externa, el texto debería explicar que todavía puedes revisar y enviar allí. Si el contacto propio termina en una pantalla de agradecimiento, decide qué información necesita el cliente: qué solicitud acaba de realizar y cuál es el siguiente paso previsto, sin inventar tiempos de respuesta.

En un entorno de ensayo, comprueba también una respuesta fallida del servicio receptor con ayuda técnica. La alternativa útil al éxito no es siempre volver a empezar. Puede consistir en conservar el texto y ofrecer un reintento comprensible. Diferencia además la confirmación mostrada en pantalla de la recepción efectiva por el negocio. Una solicitud de prueba identificada permite contrastar ambas cosas y detectar un recorrido aparentemente terminado que no llega al destino previsto.

12. Prueba los límites que afectan a tus clientes

Selecciona casos límite por su relación con el negocio. Si tus clientes suelen explicar proyectos con varias partes, utiliza un mensaje con párrafos y una dirección web. Si pueden contactarte desde otros países, ensaya nombres y teléfonos que representen esa situación. El propósito es evitar reglas innecesariamente estrechas, sin convertir una sesión comercial en una batería interminable de datos extravagantes o improbables.

Si existe un adjunto, prueba elegirlo y después cancelar la selección. A continuación cambia un archivo por otro y examina qué nombre se muestra. Pregúntate si el adjunto aporta suficiente valor para incluirlo en el primer contacto. Para una consulta inicial puede bastar una descripción; para revisar una referencia visual quizá tenga sentido ofrecerlo. La elección debería responder a cómo trabajas, con límites explicados antes de que la persona invierta esfuerzo.

Incluye cualquier mecanismo antispam que aparezca en el recorrido real. Intenta resolverlo desde el teclado y localiza su alternativa cuando exista. No aceptes una comprobación parcial que termine justo antes de ese paso. Si el mecanismo resulta inabordable, estudia con quien desarrolla la web otras opciones adecuadas al riesgo del proyecto. La funcionalidad completa de contacto, y no solo sus campos visibles, es la que interesa evaluar.

Por último, repite la ruta en una ventana estrecha con teclado físico. Observa si cambian el menú, la posición de los controles o las superposiciones. No extrapoles ese resultado a toda la experiencia móvil: representa una variante concreta. Si aparecen numerosos componentes adicionales, elige los que realmente intervienen en contactar. Un calendario opcional, una ayuda desplegable o una selección de servicio merecen atención cuando condicionan la tarea; los elementos ajenos pueden revisarse en otra sesión.

13. Un ejemplo completo para escoger qué corregir

Este ejemplo es hipotético. Marta dirige un estudio de interiorismo y quiere revisar el contacto antes de aprobar una renovación. Óscar representa a una persona interesada en reformar un local: llega desde la página de proyectos, necesita explicar el espacio y prefiere recibir una respuesta por correo. Ensayan dos propuestas, un formulario breve y un botón que prepara una conversación de mensajería.

En la primera versión del formulario aparecen nombre, correo, teléfono obligatorio, tipo de espacio y mensaje. Óscar completa la explicación, pero no quiere facilitar teléfono. Marta considera dos alternativas: mantenerlo obligatorio por comodidad del estudio o permitir elegir el canal de respuesta. Escoge la segunda porque conserva una vía suficiente para iniciar esta consulta y evita pedir un dato que no necesita para valorar el primer contacto.

Durante el recorrido, el foco pasa del tipo de espacio a varios enlaces del pie y después regresa al mensaje. Además, al dejar vacío el correo, la pantalla señala un error que queda lejos del botón. Marta prioriza corregir el salto y facilitar la localización del campo pendiente. Deja para otra iteración un cambio decorativo de las tarjetas: ambos problemas detectados afectan directamente a terminar la tarea que están probando.

En la alternativa de mensajería, Óscar entiende «Enviar proyecto» como un envío inmediato. Al abrirse otra aplicación descubre que debe continuar allí. Marta propone «Preparar consulta por WhatsApp» y una explicación breve del siguiente paso. Finalmente conserva el formulario con elección de canal y deja la mensajería como alternativa. La decisión no se basa en que un sistema sea universalmente superior, sino en la combinación concreta de datos necesarios, expectativas y obstáculos observados durante la misma tarea.

14. Convierte los hallazgos en una revisión breve

Reúne las incidencias en un único lugar con cuatro datos: punto de partida, acción, resultado observado y resultado esperado. «El formulario no funciona» obliga a investigar desde cero. «Desde correo, al avanzar, el foco entra en el pie y después vuelve al mensaje» identifica un comportamiento reproducible. Añade navegador y tamaño de ventana cuando ayuden a repetirlo; una captura complementa la descripción, pero no sustituye la secuencia.

Prioriza por consecuencias. Un bloqueo impide completar la consulta. Una dificultad recuperable permite continuar después de buscar o repetir trabajo. Una mejora de claridad reduce dudas aunque el recorrido ya sea practicable. Esta clasificación es una herramienta de proyecto, no una escala oficial. Ayuda a decidir qué resolver primero y evita que una preferencia estética reciba la misma urgencia que un control imposible de activar.

Utiliza esta checklist como cierre de la sesión:

Se llega al contacto desde la página de entrada elegida.
Se reconoce el control activo y se puede retroceder.
Se completan las opciones y los campos necesarios.
Se encuentran y corrigen los errores provocados.
Se sale de ayudas y ventanas sin abandonar la tarea.
Se entiende la espera, el resultado y cualquier cambio de aplicación.
La solicitud de ensayo llega al destino previsto.

Para valorar una propuesta comercial, pide que las correcciones incluyan repetir los casos afectados y un recorrido completo al terminar. Distingue ajustar un componente existente de sustituir una integración externa o replantear el formulario. Concentra aquí el acuerdo de alcance y responsabilidades; el resto de la conversación puede volver a las decisiones concretas del contacto. Una aceptación útil explica qué se probó y qué resultado produjo, sin extender esa conclusión a funciones que nadie examinó.

15. Preguntas específicas antes de aceptar el contacto

¿Basta con pulsar Tab hasta el botón final?

No. Ese recorrido solo muestra una parte de la navegación. Necesitas activar opciones, escribir, corregir, abrir ayudas y terminar una solicitud. Incluye al menos un error y una vuelta hacia atrás. Una prueba breve con acciones reales aporta más información que recorrer muchos elementos sin utilizarlos. Decide el final antes de empezar para no detenerte en el primer resultado visualmente satisfactorio.

¿Una herramienta automática puede sustituir esta prueba?

Para esta decisión, trata sus resultados como información complementaria. Aunque una herramienta señale problemas concretos, todavía necesitas experimentar si el orden tiene sentido, si entiendes una elección y si reconoces el desenlace. Tampoco una pasada manual con teclado cubre todas las necesidades de accesibilidad. Si contratas una evaluación más amplia, define por separado tecnologías de apoyo, páginas, estados y combinaciones que se revisarán.

¿Debo eliminar todos los desplegables y ventanas?

No tomes esa decisión por el nombre del componente. Compara la tarea con una alternativa más sencilla y observa qué aporta cada una. Un desplegable puede organizar una lista extensa; una ventana puede contener una explicación necesaria. El problema práctico aparece cuando añaden esfuerzo sin resolver una necesidad, ocultan la continuación o no permiten regresar al punto desde el que se abrieron.

¿Mejorará el posicionamiento por superar el ensayo?

No conviertas el resultado en una promesa de ranking. La guía de SEO de Google explica que no hay garantías de alcanzar la primera posición. El resultado que puedes exigir aquí es mucho más concreto: una persona completa el contacto previsto en las condiciones probadas. Evalúa ese beneficio directamente y mantén las decisiones sobre búsqueda dentro de su análisis correspondiente.

16. Elige el siguiente paso según el problema encontrado

Si el recorrido principal se completa y los hallazgos afectan a etiquetas o expectativas, plantea una mejora acotada: ajustar las palabras, repetir los intentos afectados y comprobar de nuevo la solicitud. Si hay un salto de foco, una ventana sin salida o una integración que bloquea el contacto, empieza por ese obstáculo. Un rediseño visual completo no es automáticamente la respuesta más proporcionada a un fallo localizado.

Cuando hay varios canales, decide cuál será el principal y qué alternativa ofrecerás. La persona debería entender si está enviando una consulta, preparando un mensaje o pasando a otro servicio. Revisa además la coherencia entre la página de entrada y el contacto: una invitación a pedir información no debería desembocar inesperadamente en preguntas propias de una contratación avanzada. Ajustar esa transición puede formar parte del trabajo tanto como corregir un componente.

Latech presenta en su web servicios de diseño web, tiendas online y agentes de IA, y señala atención en toda España mediante videollamada. Puedes partir de ese contexto para explicar qué necesita tu proyecto, sin dar por incluida una evaluación especializada ni un alcance de accesibilidad determinado. Lo útil es describir la tarea de contacto que deseas ofrecer y los obstáculos que ya has localizado, aunque todavía no conozcas su causa técnica.

Antes de cerrar la revisión, vuelve a realizar el recorrido como visitante: entra, encuentra el contacto, elige, escribe, equivócate, corrige y termina. Comprueba que el resultado corresponde a lo que anuncian las palabras de la interfaz. Si quieres valorar una nueva web o mejorar cómo se inicia una consulta en la que ya tienes, puedes contar tu proyecto a Latech por WhatsApp y explicar este caso concreto para pedir información sobre el siguiente paso.