Un formulario accesible se crea con etiquetas visibles vinculadas a su campo en el código, los atributos autocomplete correctos, mensajes de error en texto junto al campo y un orden que funciona solo con teclado. En una tienda online esto se aplica con más rigor todavía al checkout. Ahí, un visitante que se atasca abandona en el acto, y es justo ahí donde pone el foco la European Accessibility Act.
Este artículo forma parte de nuestra guía completa sobre accesibilidad web. Repasamos los criterios de conformidad de WCAG 2.2 que más fallan en los formularios, con ejemplos de código que puedes copiar directamente. Cada número de criterio y cada nivel procede de la especificación oficial de WCAG 2.2.
Si antes quieres la visión de conjunto de WCAG 2.2 y los criterios nuevos, lee WCAG 2.2 explicado.
Por qué la European Accessibility Act afecta al comercio electrónico
La European Accessibility Act menciona expresamente los servicios de comercio electrónico como servicio que debe ser accesible. En la Directiva (UE) 2019/882, los "e-commerce services" figuran en el artículo 2, apartado 2, letra f. El artículo 3 los define como servicios prestados a distancia a través de sitios web y servicios móviles, a petición de un consumidor, con vistas a celebrar un contrato de consumo. Los Estados miembros aplican las normas desde el 28 de junio de 2025.
El anexo I, sección IV, letra g lo concreta para las tiendas online. Tienes que dar la información de accesibilidad disponible sobre los productos que vendes. Y las funciones de identificación, seguridad y pago deben ser perceptibles, operables, comprensibles y robustas. Eso son justamente tus formularios de inicio de sesión, de cuenta y de pago.
Según el artículo 4, apartado 5, una microempresa que presta servicios está exenta de estos requisitos. Si la EAA se aplica a tu empresa lo explicamos en European Accessibility Act. Este artículo es una explicación, no asesoramiento jurídico; si tienes dudas, consulta a un abogado.
Etiquetas: cada campo con un nombre visible y vinculado
Cada campo de entrada necesita una etiqueta visible que esté vinculada al campo en el código. El criterio 3.3.2 Labels or Instructions (nivel A) exige etiquetas o instrucciones cuando se pide una entrada. El criterio 1.3.1 Info and Relationships (nivel A) exige que la relación entre etiqueta y campo también se pueda determinar mediante programación, para que un lector de pantalla lea la etiqueta cuando el campo recibe el foco.
La forma más sencilla es un elemento label con un atributo for que apunte al id del campo. Así, un clic en la etiqueta también coloca el cursor en el campo, lo que ayuda en pantallas pequeñas.
<label for="email">Correo electrónico</label>
<input type="email" id="email" name="email" autocomplete="email" required>
<!-- No lo hagas: solo un marcador de posición -->
<input type="email" placeholder="Correo electrónico">
Un marcador de posición no es una etiqueta. Desaparece al escribir, suele tener poco contraste y, una vez rellenado el campo, ya no se puede comprobar. Usa el marcador de posición como mucho para un ejemplo, como "28001".
Autocomplete: deja que el navegador haga el trabajo
Con los atributos autocomplete le dices al navegador qué tipo de datos pide un campo, para que pueda rellenarlo automáticamente. El criterio 1.3.5 Identify Input Purpose (nivel AA) exige que la finalidad de los campos con datos sobre el propio usuario se pueda determinar mediante programación. WCAG enumera las finalidades válidas en una lista fija, que incluye nombre, correo electrónico, teléfono, dirección, código postal y datos de pago.
Para las personas con discapacidad motora o cognitiva, esto ahorra mucho tecleo y muchos errores. Para todo el mundo, hace que el checkout sea más rápido.
<label for="nombre">Nombre completo</label>
<input id="nombre" name="nombre" autocomplete="name">
<label for="calle">Calle y número</label>
<input id="calle" name="calle" autocomplete="street-address">
<label for="cp">Código postal</label>
<input id="cp" name="cp" autocomplete="postal-code">
<label for="localidad">Localidad</label>
<input id="localidad" name="localidad" autocomplete="address-level2">
<label for="tel">Teléfono (opcional)</label>
<input type="tel" id="tel" name="tel" autocomplete="tel">
Campos obligatorios y agrupación con fieldset
Los campos obligatorios se marcan tanto de forma visible como en el código, y los campos que van juntos se agrupan con fieldset y legend. El atributo required hace que el lector de pantalla diga "obligatorio". Si usas un asterisco, explica al principio qué significa. Si casi todos los campos son obligatorios, mejor marca los pocos campos opcionales.
Un fieldset con legend entra en el criterio 1.3.1. Es necesario sobre todo en botones de opción y casillas de verificación, donde la etiqueta de una opción no tiene sentido sin la pregunta. "Recogida" dice poco; "Método de entrega: recogida" sí.
<fieldset>
<legend>Método de entrega</legend>
<input type="radio" id="entrega-casa" name="entrega" value="casa" required>
<label for="entrega-casa">Entrega a domicilio</label>
<input type="radio" id="entrega-punto" name="entrega" value="punto-recogida">
<label for="entrega-punto">Punto de recogida</label>
</fieldset>
Usa también fieldset para separar la dirección de facturación de la de envío. Sin agrupación, un usuario de lector de pantalla oye dos veces "Código postal" sin saber a qué dirección corresponde.
Mensajes de error y sugerencias
Un mensaje de error debe decir en texto qué campo es incorrecto y qué falla. El criterio 3.3.1 Error Identification (nivel A) exige que un error de entrada detectado automáticamente se identifique y se describa en texto. Un borde rojo por sí solo, por tanto, no basta. El criterio 3.3.3 Error Suggestion (nivel AA) va más allá: si sabes cómo corregir el error, das esa sugerencia, salvo que eso ponga en riesgo la seguridad o la finalidad.
"Entrada no válida" no cumple el 3.3.3. "Introduce un código postal como 28001" sí. Vincula el mensaje al campo con aria-describedby y marca el campo con aria-invalid, para que el lector de pantalla lea el error cuando el campo recibe el foco.
<label for="cp">Código postal</label>
<input id="cp" name="cp" autocomplete="postal-code"
aria-invalid="true" aria-describedby="cp-error">
<p id="cp-error">Introduce un código postal español, por ejemplo 28001.</p>
En un formulario largo ayuda un resumen de todos los errores al principio, con enlaces a los campos. Tras el envío, pon el foco en ese resumen. Usa ARIA como aria-invalid solo donde aporte algo; WAI-ARIA complementa el HTML, pero no sustituye una buena base.
Para el último paso de un pedido se aplica además el criterio 3.3.4 Error Prevention (nivel AA). En envíos con consecuencias económicas o jurídicas, el usuario debe poder revisar y corregir los datos, poder deshacer el envío o confirmarlo de forma explícita. Una página de resumen antes de "Realizar pedido" suele cumplirlo.
Orden del foco, teclado y tamaño del objetivo
Un formulario debe poder manejarse por completo con teclado, en un orden lógico y con un foco visible. El criterio 2.1.1 Keyboard (nivel A) exige que todas las funciones se puedan usar con teclado. El criterio 2.4.3 Focus Order (nivel A) exige un orden que conserve el significado y el manejo. El criterio 2.4.7 Focus Visible (nivel AA) exige un indicador de foco visible.
Errores frecuentes en un checkout:
- Un desplegable o selector de fecha propio que solo responde a un clic de ratón.
- Un
tabindexcon valor positivo, que hace que el foco salte por el formulario. - Un contorno de foco eliminado con CSS (
outline: none) sin sustituto. - Una barra fija en la parte inferior que tapa el campo con el foco. WCAG 2.2 añadió para ello el criterio 2.4.11 Focus Not Obscured (Minimum, nivel AA).
En pantallas táctiles y para personas con temblor en las manos cuenta el tamaño de los botones y las casillas. El criterio 2.5.8 Target Size (Minimum, nivel AA) exige un área de objetivo de al menos 24 por 24 píxeles CSS. Hay excepciones, entre otras si hay suficiente espacio alrededor, si existe un elemento equivalente más grande o en enlaces dentro de un texto. Las casillas diminutas para aceptar las condiciones generales y los minúsculos botones de más y menos en el carrito son los casos problemáticos conocidos.
Entrada redundante y límites de tiempo
No pidas nunca dos veces los mismos datos en el mismo proceso. El criterio 3.3.7 Redundant Entry (nivel A), nuevo en WCAG 2.2, exige que la información introducida antes se rellene automáticamente o se pueda seleccionar. Las excepciones son cuando repetirla es esencial, cuando es necesario por seguridad o cuando los datos anteriores ya no son válidos.
El ejemplo más conocido en una tienda online es la dirección de facturación. Una casilla "La dirección de facturación es la misma que la de envío" cumple. Un segundo formulario de dirección vacío no. Pedir que se escriba dos veces la contraseña entra en la excepción de seguridad.
Los límites de tiempo entran en el criterio 2.2.1 Timing Adjustable (nivel A). Si tu checkout o tu carrito tiene un límite, el usuario debe poder desactivarlo, ajustarlo hasta al menos diez veces la duración predeterminada, o recibir un aviso previo y disponer de al menos 20 segundos para ampliarlo con una acción sencilla. Las excepciones son los eventos en tiempo real, como una subasta, los límites esenciales y los límites de más de 20 horas. Una sesión que caduca sin avisar a los diez minutos y vacía el carrito es, por tanto, un problema.
Iniciar sesión sin puzles
Iniciar sesión o confirmar tu identidad no puede exigir una prueba cognitiva, como recordar una contraseña o copiar un código, salvo que haya una alternativa o una ayuda. Así lo exige el criterio 3.3.8 Accessible Authentication (Minimum, nivel AA), nuevo en WCAG 2.2. Las excepciones en el nivel AA son reconocer objetos y reconocer contenido propio, como una foto que has subido tú.
La página Understanding del 3.3.8 concreta algunas cosas:
- Pegar tiene que funcionar. Si bloqueas el pegado en el campo de contraseña, o impides que un gestor de contraseñas rellene el campo, no cumples este criterio, salvo que haya otro método.
- Copiar códigos de verificación a mano no basta. Un servicio que solo permite copiar un código tecleándolo no cumple. El usuario tiene que poder al menos pegar el código.
- Los CAPTCHA necesitan una alternativa no cognitiva, salvo que se trate de reconocimiento de objetos. Un CAPTCHA de audio que tienes que transcribir no cuenta como alternativa.
Alternativas prácticas a un CAPTCHA son una comprobación invisible en segundo plano, un campo trampa oculto (honeypot), el inicio de sesión mediante un enlace por correo electrónico o una passkey. Pon en los campos de contraseña autocomplete="current-password" o autocomplete="new-password", para que los gestores de contraseñas los reconozcan. En el nivel AAA (criterio 3.3.9) desaparece también la excepción del reconocimiento de objetos.
El paso de pago y los iframes de los proveedores de pago
El paso de pago suele ser la parte más difícil de hacer accesible, porque una parte no está en tu propio código. Muchas tiendas online muestran los campos de la tarjeta en un iframe del proveedor de pagos o redirigen al cliente a una página de pago de ese proveedor. Lo que ocurre ahí, normalmente no lo puedes cambiar tú.
Aun así, sigue formando parte de tu proceso de compra, y la EAA menciona expresamente la función de pago de un servicio de comercio electrónico. Cómo se reparte exactamente la responsabilidad entre tú y tu proveedor varía según la situación y, en caso de duda, requiere asesoramiento jurídico. Lo que sí puedes hacer en cualquier caso:
- Pregunta a tu proveedor de pagos por su información o declaración de accesibilidad, y por la versión de WCAG y el nivel frente a los que se han probado los componentes de pago.
- Prueba tú mismo el paso de pago solo con teclado y con un lector de pantalla, incluida una entrada incorrecta y una verificación 3D Secure.
- Da a un iframe un título que diga qué contiene, por ejemplo
title="Datos de pago", si lo configuras tú. - Ofrece varios métodos de pago, para que un cliente que se atasca con uno pueda elegir otro.
- Menciona los problemas conocidos en tu declaración de accesibilidad, con una forma alternativa de hacer el pedido.
Cómo comprobarlo en tu propio sitio
- Recorre todo tu proceso de compra solo con teclado, desde la página de producto hasta la confirmación. Anota cada punto en el que el foco desaparece o se queda atascado.
- Comprueba que cada campo tenga una etiqueta visible y vinculada y el valor de autocomplete correcto. En el panel de accesibilidad de DevTools ves qué nombre recibe un campo.
- Envía el formulario con errores a propósito. ¿Recibes en cada campo un mensaje de error en texto con una sugerencia, y lo lee un lector de pantalla?
- Prueba el inicio de sesión con un gestor de contraseñas y comprueba si pegar funciona en los campos de contraseña y de código.
- Mide el tamaño del objetivo de las casillas, los botones de opción y los botones del carrito en un móvil.
- Lanza un análisis automático en cada paso del checkout. Detecta etiquetas que faltan y ARIA incorrecto; el resto de esta lista sigue siendo trabajo manual. Más sobre esa combinación en probar la accesibilidad web.
El control de accesibilidad de Flowproof está incluido en los planes de pago Pro y Business y evalúa tus páginas con axe-core frente a WCAG 2.2 A y AA. Puedes empezar gratis y comparar los planes en la página de precios.