Formularios de contacto accesibles y la Ley Europea de Accesibilidad

Un formulario de contacto suele ser la única puerta entre un visitante y su empresa. Si esa puerta solo se puede abrir con un mouse, buena vista y paciencia para resolver un acertijo con imágenes borrosas, algunas personas simplemente se quedan afuera. Desde mediados de 2025, esto 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 ciertos productos y servicios ofrecidos a consumidores, entre ellos el comercio electrónico, los servicios bancarios para consumidores, los libros electrónicos, las comunicaciones electrónicas y determinadas áreas del transporte de pasajeros. Para un sitio web, esto significa la tienda en línea o el servicio bancario en su conjunto, incluidos los formularios que usan los clientes para comunicarse con usted, hacer preguntas o presentar quejas. Las microempresas que prestan servicios están exentas: empresas con menos de diez empleados y cuyo volumen de negocio anual o total del balance general no supera los 2 millones de EUR. Las ofertas dirigidas exclusivamente a otras empresas suelen quedar fuera de su ámbito.

Cada Estado miembro ha incorporado la directiva a su legislación nacional. En Alemania es la Barrierefreiheitsstärkungsgesetz (BFSG); en Polonia, una ley de 2024 sobre el cumplimiento de los requisitos de accesibilidad por determinados productos y servicios. Las autoridades de supervisión y las sanciones varían de un país a otro, pero el referente técnico es, en términos generales, el mismo: 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é vale la pena incluso sin una obligación jurídica

Quizá su empresa esté exenta o solo atienda a otras empresas. Los formularios accesibles siguen valiendo la pena por una razón sencilla: cada persona que se da por vencida a mitad del proceso es una consulta que usted nunca recibe. Las mejoras que ayudan a quien usa un lector de pantalla también ayudan a alguien que llena el formulario en un celular en el tren, bajo el sol intenso, con una muñeca fracturada o en un segundo idioma. Las etiquetas claras y los mensajes de error útiles reducen el abandono de formularios para todos, y ninguna de estas mejoras debilita la protección contra el spam.

Una lista práctica con referencias a WCAG 2.2

• Etiquetas visibles vinculadas a sus campos (1.3.1, 3.3.2): cada campo tiene una etiqueta visible conectada mediante for/id. Un texto de marcador de posición por sí solo no es una etiqueta: desaparece en cuanto alguien empieza a escribir.
• Mensajes de error que expliquen cómo corregirlos (3.3.1, 3.3.3): nombre el campo, indique qué está mal y cómo solucionarlo, con texto y no solo con un borde rojo. «Ingrese una dirección de correo electrónico como name@example.com» es mejor que «Entrada no válida».
• Uso completo con teclado (2.1.1, 2.1.2): se puede llegar a cada campo, casilla, CAPTCHA y al botón de envío, y utilizarlos con Tab, Espacio y Enter, sin trampas de teclado.
• Foco visible (2.4.7): siempre se puede ver qué campo está activo. Quitar el contorno de foco del navegador sin reemplazarlo 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 frente al fondo (3:1 para texto grande).
• Tamaño de los objetivos (2.5.8): los botones, las casillas y los 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): 1.1.1 exige una alternativa textual y el CAPTCHA en más de una modalidad sensorial; 3.3.8 se aplica estrictamente a los pasos de inicio de sesión, pero su idea también sirve aquí: un acertijo como volver a escribir letras distorsionadas o resolver una suma no debería ser la única forma de continuar. Ofrezca una alternativa o use un método que no requiera acertijos.
• Campos trampa ocultos a la tecnología de asistencia: el campo trampa lleva aria-hidden="true" en su contenedor y tabindex="-1", de modo que quienes usan lectores de pantalla y teclado nunca lleguen a él.

CAPTCHA y campos trampa: donde la protección contra el spam se encuentra con la accesibilidad

Estrictamente, 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 sustenta también resulta útil aquí: escribir letras distorsionadas, resolver una suma o seleccionar semáforos en una cuadrícula de imágenes excluye por completo a algunas personas. Las opciones que normalmente funcionan sin acertijos —como Cloudflare Turnstile, Friendly Captcha, un campo trampa combinado con una verificación de tiempo o un filtrado del lado del servidor como Akismet— mantienen fuera el spam sin pedir a los visitantes que demuestren nada. Un campo trampa solo es amable si es realmente invisible, también para quienes usan lectores de pantalla y 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 a un lado el mouse y llene todo el formulario usando solo el teclado. ¿Puede llegar a cada campo y al botón de envío, y siempre puede ver dónde se encuentra?
2. 2Envíe el formulario vacío y después con una dirección de correo incorrecta. ¿Los errores aparecen como texto junto al campo correspondiente y queda claro qué hacer?
3. 3Abra la página en un celular o aumente el zoom del navegador al 200%. ¿Todo se puede leer, es fácil tocar los botones y algún banner de cookies o widget de chat cubre el botón de envío?
4. 4Active un lector de pantalla (VoiceOver, NVDA o TalkBack) y escuche: ¿cada campo se anuncia con su etiqueta y el campo trampa permanece en silencio?
5. 5Ejecute una verificación automatizada como axe-core. Encuentra rápidamente etiquetas faltantes y problemas de contraste, pero no todo: siguen haciendo falta los pasos manuales anteriores.

Si prefiere comenzar con una visión general, formexposed revisa sus formularios públicos desde el exterior, sin enviar nada. Sus verificaciones de accesibilidad ejecutan axe-core en cada formulario, señalan CAPTCHA sin alternativa accesible y campos trampa que los lectores de pantalla anuncian, y revisan el formulario en un celular: objetivos táctiles, elementos superpuestos que cubren el botón de envío y desplazamiento horizontal. La verificación gratuita muestra el nivel general; estos detalles están en el informe completo. Es un buen punto de partida para la lista anterior, no un sustituto de las pruebas con personas reales.