Formularios de contacto accesibles y la Ley Europea de Accesibilidad

Un formulario de contacto es a menudo la única puerta entre un visitante y su empresa. Si esa puerta solo puede abrirse con un ratón, buena vista y la paciencia necesaria para resolver un acertijo con una imagen borrosa, algunas personas simplemente se quedan fuera. Desde mediados de 2025 ya no es solo una cuestión de usabilidad: para muchas empresas que venden a consumidores en la UE, se ha convertido en una cuestión jurídica.

Qué abarca la Ley Europea de Accesibilidad

La Ley Europea de Accesibilidad (Directiva (UE) 2019/882) se aplica desde el 28 de junio de 2025. Establece requisitos de accesibilidad para determinados productos y servicios ofrecidos a los consumidores, entre ellos el comercio electrónico, los servicios bancarios para consumidores, los libros electrónicos, las comunicaciones electrónicas y partes del transporte de viajeros. Para un sitio web, eso significa la tienda en línea o el servicio bancario en su conjunto, incluidos los formularios que los clientes utilizan para contactarle, hacer preguntas o reclamar. Las microempresas que prestan servicios están exentas: empresas con menos de diez empleados y un volumen de negocios anual o un balance general anual que no supere los 2 millones de euros. Las ofertas dirigidas exclusivamente a otras empresas quedan, en general, fuera de su ámbito de aplicación.

Cada Estado miembro ha transpuesto la directiva a su Derecho nacional. En Alemania es la Barrierefreiheitsstärkungsgesetz (BFSG); en Polonia, una ley de 2024 sobre la garantía del cumplimiento de los requisitos de accesibilidad por parte de determinados productos y servicios. Las autoridades de supervisión y las sanciones varían de un país a otro, pero la referencia técnica es en gran medida la misma: en la práctica, la norma europea EN 301 549, que a su vez se basa en las Pautas de Accesibilidad para el Contenido Web (WCAG).

Por qué compensa incluso sin obligación legal

Quizá su empresa esté exenta, o solo atienda a otras empresas. Aun así, los formularios accesibles merecen la pena, por una razón sencilla: cada persona que abandona a mitad de camino es una consulta que usted nunca recibe. Las mejoras que ayudan a un usuario de lector de pantalla también ayudan a quien rellena el formulario en el móvil en un tren, a pleno sol, con una muñeca rota o en un segundo idioma. Etiquetas claras y mensajes de error útiles significan menos formularios abandonados para todos, y ninguna de estas mejoras debilita su protección antispam.

Una lista de comprobación práctica con referencias a las WCAG 2.2

• Etiquetas visibles vinculadas a sus campos (1.3.1, 3.3.2): cada campo tiene una etiqueta visible conectada a él mediante for/id. Un texto de ejemplo (placeholder) por sí solo no es una etiqueta: desaparece en cuanto alguien empieza a escribir.
• Mensajes de error que explican la solución (3.3.1, 3.3.3): nombre el campo, diga qué está mal y cómo corregirlo, con texto y no solo con un borde rojo. «Introduzca una dirección de correo electrónico como nombre@example.com» es mejor que «Entrada no válida».
• Manejo completo con teclado (2.1.1, 2.1.2): cada campo, casilla, CAPTCHA y el botón de envío pueden alcanzarse y utilizarse con Tab, Espacio e Intro, sin trampas para el teclado.
• Foco visible (2.4.7): siempre se ve qué campo está activo. Eliminar el contorno de foco del navegador sin sustituirlo incumple este criterio.
• Contraste suficiente (1.4.3): el texto, las etiquetas y los mensajes de error tienen una relación de contraste de al menos 4,5:1 con el fondo (3:1 para texto grande).
• Tamaño del objetivo (2.5.8): los botones, casillas y enlaces miden al menos 24 × 24 píxeles CSS o tienen suficiente espacio a su alrededor.
• Alternativas al CAPTCHA (1.1.1) y autenticación accesible (3.3.8): el 1.1.1 exige una alternativa textual y el CAPTCHA en más de una forma sensorial; el 3.3.8 se refiere estrictamente a los pasos de inicio de sesión, pero su idea es trasladable: un acertijo como volver a escribir letras distorsionadas o resolver una suma no debería ser la única forma de pasar. Ofrezca una alternativa o utilice un método que no necesite ningún acertijo.
• Honeypots ocultos a las tecnologías de apoyo: el campo trampa lleva aria-hidden="true" en su contenedor y tabindex="-1", para que los usuarios de lectores de pantalla y de teclado nunca lleguen a él.

CAPTCHAs y honeypots: donde la protección antispam se encuentra con la accesibilidad

En sentido estricto, el criterio 3.3.8 se refiere a los pasos de inicio de sesión y autenticación, no a los formularios de contacto. Sin embargo, la idea que lo inspira se traslada bien: escribir letras distorsionadas, resolver una suma o elegir semáforos en una cuadrícula de imágenes deja completamente fuera a algunas personas. Las opciones que normalmente funcionan sin ningún acertijo (como Cloudflare Turnstile, Friendly Captcha, un honeypot combinado con una comprobación de tiempo o un filtrado en el servidor como Akismet) mantienen alejado el spam sin pedir a los visitantes que demuestren nada. Un honeypot solo es amable si es realmente invisible, también para los usuarios de lectores de pantalla y de teclado:

<div class="hp" aria-hidden="true">
  <label for="hp-website">Deje este campo vacío</label>
  <input type="text" id="hp-website" name="website"
         tabindex="-1" autocomplete="off">
</div>
<!-- CSS: .hp { position: absolute; left: -10000px; } -->

Pruebe su propio formulario en quince minutos

1. 1Deje el ratón a un lado y rellene todo el formulario usando solo el teclado. ¿Puede llegar a todos los campos y al botón de envío, y ve siempre dónde se encuentra?
2. 2Envíe el formulario vacío y después con una dirección de correo electrónico incorrecta. ¿Aparecen los errores como texto junto al campo correcto y está claro qué hay que hacer?
3. 3Abra la página en un móvil o amplíe el navegador al 200 %. ¿Se puede leer todo, son fáciles de pulsar los botones y tapa un banner de cookies o un widget de chat el botón de envío?
4. 4Active un lector de pantalla (VoiceOver, NVDA o TalkBack) y escuche: ¿se anuncia cada campo con su etiqueta y permanece en silencio el honeypot?
5. 5Ejecute una comprobación automatizada como axe-core. Encuentra rápidamente etiquetas que faltan y problemas de contraste, pero no todo: los pasos manuales anteriores siguen siendo necesarios.

Si prefiere empezar con una visión general, formexposed examina sus formularios públicos desde fuera, sin enviar nada. Sus comprobaciones de accesibilidad ejecutan axe-core en cada formulario, señalan los CAPTCHAs sin alternativa accesible y los honeypots que anuncian los lectores de pantalla, y examinan el formulario en un móvil: objetivos táctiles, superposiciones que tapan el botón de envío, desplazamiento horizontal. La comprobación gratuita muestra el nivel global; estos detalles figuran en el informe completo. Es un buen punto de partida para la lista anterior, no un sustituto de las pruebas con personas reales.