Un formulario de contacto puede parecer sencillo y resultar difícil de completar: un campo sin nombre, un error que solo cambia de color o un botón al que no se llega con el teclado bastan para interrumpir la consulta. Crear formularios accesibles en WordPress exige revisar lo que sucede antes, durante y después del envío.
Esta guía propone una revisión práctica para una web corporativa. Complementa el diagnóstico de formularios que no envían correos: aquí nos centramos en la interacción de la persona que rellena los campos.
Empieza por decidir qué necesitas preguntar
Como criterio de diseño, recomiendo justificar cada dato solicitado. Para una primera consulta puede bastar con un medio de respuesta y una explicación del proyecto. Si el teléfono no es necesario para atenderla, valora dejarlo como opcional en lugar de convertirlo en una barrera.
Haz una lista con tres columnas: campo, motivo y obligatoriedad. Esta revisión ayuda a explicar cada pregunta y a detectar peticiones que pertenecen a una fase posterior. No existe un número de campos que garantice más contactos: la elección debe responder al proceso real.
Una etiqueta visible para cada campo
W3C recomienda identificar los controles mediante etiquetas asociadas. En HTML, la relación habitual se establece entre el atributo for de label y el id del campo. La proximidad visual por sí sola no crea esa relación.
El placeholder puede ofrecer un ejemplo, pero no debe ser el único nombre del campo: desaparece al escribir. La guía de etiquetas de W3C explica las distintas formas de identificar controles.
En el constructor de formularios, escribe nombres concretos como «Correo electrónico» o «Descripción del proyecto». Después revisa la página publicada: ocultar la etiqueta desde el diseño puede alterar el resultado que habías preparado en el editor.
Instrucciones donde hacen falta
Explica al principio cómo se identifican los campos obligatorios. Si hay un formato específico o una limitación para adjuntos, indícalo antes de que la persona intente enviar. W3C documenta cómo asociar instrucciones adicionales mediante aria-describedby.
Ejemplo de redacción propuesto para un campo de mensaje: «Describe qué necesitas cambiar y pega la URL de la página si ya existe». Es más orientativo que «Introduce un mensaje válido». Adapta las instrucciones a lo que realmente permita tu formulario.
Para una selección de opciones relacionadas, la guía de formularios de W3C contempla agrupaciones con fieldset y legend. Comprueba la salida del plugin antes de añadir atributos manualmente.
Errores que expliquen cómo continuar
La validación accesible debe ayudar a identificar los datos incorrectos y corregirlos. Un borde rojo aislado no explica qué ocurre. Es preferible un mensaje textual junto al campo, con una indicación concreta del problema.
- Campo vacío: «Escribe un correo electrónico para que pueda responderte».
- Formato incorrecto: «Revisa el correo: falta una parte de la dirección».
- Adjunto no admitido: indica el formato o el tamaño permitido según la configuración real.
Son ejemplos editoriales, no mensajes instalados en una web. Evita afirmar que una dirección existe solo porque supera la validación de formato. Revisa también si una corrección conserva los datos ya introducidos: obligar a escribir todo de nuevo añade trabajo innecesario.
El envío necesita una confirmación comprensible
W3C distingue entre notificar errores y comunicar que la operación se ha completado. Cuando la respuesta se inserta sin recargar la página, debe poder percibirse también con tecnologías de asistencia. Su guía de notificaciones explica mensajes y mecanismos de anuncio.
Recomiendo describir únicamente el estado comprobado. «Solicitud registrada» puede ser adecuado si el sistema confirma ese registro. «Te responderé en una hora» solo debe aparecer si existe ese compromiso. Una respuesta visual de éxito tampoco demuestra por sí sola que la notificación por correo haya llegado.
Prueba el recorrido completo
- Abre la página sin iniciar sesión. Comprueba que las etiquetas y ayudas aparecen en el formulario real.
- Recórrelo con Tab y Mayús + Tab. Observa el orden y la visibilidad del foco. Activa las opciones y el botón con teclado.
- Provoca un error controlado. Deja un obligatorio vacío y revisa si puedes localizarlo y corregirlo.
- Comprueba una pantalla estrecha y el zoom. Busca campos cortados, instrucciones ocultas o botones superpuestos.
- Realiza una prueba con lector de pantalla. Verifica nombres, instrucciones, obligatoriedad y anuncios de error o éxito.
- Confirma el resultado de extremo a extremo. Usa datos de prueba identificables y comprueba el registro y la notificación según el sistema utilizado.
Organiza estas pruebas en un entorno controlado para no generar contactos comerciales ficticios. Si necesitas cambiar el plugin, estilos globales o lógica de envío, prepara primero un entorno de staging.
Cómo registrar los problemas sin perder el foco
Propongo guardar cada incidencia con el campo afectado, el dispositivo, los pasos para reproducirla y el resultado esperado. «El foco no se distingue sobre el botón» es una tarea comprobable; «mejorar la accesibilidad» necesita concretarse.
Esta revisión es un punto de partida y no acredita por sí sola conformidad completa con WCAG. Las comprobaciones automatizadas y las pruebas manuales aportan evidencias diferentes. Conserva el recorrido de prueba para repetirlo después de actualizar el formulario o el tema.
¿Tu formulario facilita el contacto?
Puedo revisar su estructura e integración dentro del servicio de desarrollo WordPress.
Fuentes oficiales
Fuentes consultadas el 2 de octubre de 2026. Los ejemplos y el procedimiento de revisión son propuestas de aplicación.
