2526UFV3.3.3-A-001
Edición de la página como formulario
1. Información básica
Enlace directo a la página del subcriterio en la wiki https://wikiwcag.udl.cat/Principio_3/3.3_Assistencia_en_los_input/3.3.3-A
2. Ejemplos prácticos
2.1. Ejemplo NO accesible
a) Imagen
No se ha subido ninguna imagen.
b) Enlace de donde se ha obtenido la imagen:
No se ha indicado ningún enlace.
2.1.2. Código HTML:
<form>
<div>
<label for="email">Correo electrónico</label>
<input id="email" name="email" type="text">
<span class="error">Error</span> <!-- No dice qué está mal -->
</div>
<div>
<label for="password">Contraseña</label>
<input id="password" name="password" type="password">
</div>
<button type="submit">Crear cuenta</button>
</form>
Explicación del problema detectado:
El problema surge cuando un formulario detecta un error, pero no proporciona ninguna indicación clara sobre qué ha fallado ni cómo corregirlo. En muchos casos se muestra simplemente una palabra como “Error”, un símbolo o un cambio de color sin contexto, lo que impide que el usuario comprenda qué acción debe realizar para continuar. Esta falta de orientación entra en conflicto con los criterios de accesibilidad descritos en WCAG 2.1, particularmente aquellos que exigen que los errores se identifiquen y que, cuando sea posible, se ofrezcan sugerencias que ayuden al usuario a resolverlos. Si el formulario solo marca un error sin explicar la causa, la persona usuaria puede quedar atrapada en un ciclo de prueba y error, sin pistas sobre el formato correcto, los requisitos específicos o los pasos necesarios para completar el envío del formulario. La ausencia de mensajes claros genera confusión, provoca fallos repetidos y convierte tareas simples en experiencias frustrantes.
Indica a que personas con discapacidad afecta y explicación de las barreras que causa
Las dificultades aparecen especialmente para personas con discapacidad cognitiva, que dependen de instrucciones claras y concretas para identificar problemas y tomar decisiones. También afectan a usuarios con baja visión, que necesitan que los errores se anuncien mediante texto explícito y no únicamente a través de colores, ya que los cambios cromáticos pueden pasar desapercibidos. Las personas que utilizan lectores de pantalla enfrentan barreras aún mayores cuando los errores no están asociados semánticamente a los campos, ya que la tecnología asistida no puede anunciar qué campo requiere corrección ni qué se espera del usuario. Además, quienes tienen menor alfabetización digital pueden sentirse desorientados si no reciben orientación clara sobre formatos válidos o requisitos de entrada. Todas estas situaciones conducen a una menor tasa de finalización del formulario, mayor frustración y abandono de la tarea.
2.2. Ejemplo Accesible
2.2.1. Evidencia de imagen:
a) Imagen
No se ha subido ninguna imagen.
b) Enlace de donde se ha obtenido la imagen:
No se ha indicado ningún enlace.
2.2.2 Código HTML:
<form novalidate>
<div>
<label for="email">Correo electrónico</label>
<input id="email" name="email" type="email" aria-describedby="email-error">
<span id="email-error" class="error" role="alert">
Introduce un correo electrónico válido, por ejemplo nombre@dominio.com
</span>
</div>
<div>
<label for="password">Contraseña</label>
<input id="password" name="password" type="password" aria-describedby="password-error">
<span id="password-error" class="error" role="alert">
La contraseña debe tener al menos 8 caracteres.
</span>
</div>
<button type="submit">Crear cuenta</button>
</form>
Explicación de la solución aplicada:
La solución consiste en proporcionar mensajes de error concretos, visibles, semánticos y asociados correctamente a los campos mediante mecanismos como aria-describedby, de manera que el lector de pantalla pueda anunciar el error en el momento adecuado. Además, los mensajes deben ofrecer información suficiente para que la persona usuaria sepa exactamente qué necesita corregir, siempre evitando exponer datos sensibles o comprometer la seguridad. Esta orientación puede incluir ejemplos, formatos esperados o condiciones mínimas, como en el caso de un correo electrónico inválido o una contraseña demasiado corta. También es fundamental que la presentación visual del error sea perceptible sin depender únicamente del color, combinando texto y, si corresponde, un cambio controlado en el borde del campo. Cuando estas prácticas se aplican, el formulario se vuelve comprensible y manejable para un público amplio, se reduce la carga cognitiva y se mejora significativamente la capacidad del usuario para completar el proceso con éxito, cumpliendo así con los criterios de accesibilidad establecidos por WCAG.
