Principio 3/3.3 Assistencia en los input/3.3.1-B
De WCAG Wiki
3.3.1-B. Descripción de errores
- Nivel: A
- Versión: 2.0
- Principio: 3_Comprensible
- Pauta: 3.3_Assistencia_en_los_input
- Grupo: Formularios
- Subgrupo: Errores
Discapacidades afectadas
Este criterio puede afectar a distintas personas con discapacidad. A continuación se indican las más relevantes.
-
Cognitiva –
Barrera grave
-
Visual total –
Barrera grave
Enunciado del criterio (Observatorio de Accesibilidad Web)
- Se deben proporcionar descripciones textuales de los errores cuando los usuarios introducen datos en un formulario que no cumplen un formato o valor determinado, o no están entre los valores permitidos.
Comprensión del criterio
Descripción resumida
Cuando un dato introducido es incorrecto o inválido, se debe informar mediante un mensaje textual claro que explique el problema al usuario.
Objetivo
Asegurar que las personas entienden qué error se ha producido y cómo corregirlo, especialmente en formularios que requieren formatos específicos.
Importancia de cumplir el criterio
Sin mensajes claros, las personas con discapacidad visual, cognitiva o lector de pantalla pueden no entender por qué no pueden enviar el formulario.
Referencias WCAG
- G84: Providing a text description when the user provides information that is not in the list of allowed values
- G85: Providing a text description when user input falls outside the required format or values
- SCR18: Providing client-side validation and alert
- SCR32: Providing client-side validation and adding error text via the DOM
Recursos de apoyo
Evaluación del criterio
Tipo de evaluación
Evaluación Manual
Procedimiento de evaluación
- Paso 1. Localizar los formularios existentes.
- Paso 2. Intentar enviar el formulario sin haber completado los campos obligatorios.
- Paso 3. Verificar que se informa a los usuarios mediante texto de qué campos obligatorios faltan por completar.
Resultado esperado
Los errores se describen mediante texto claro vinculado al campo correspondiente.
Ejemplo
Se muestra el error claro y asociado al campo de texto donde se ha producido.
<label for="telefono">Teléfono (9 dígitos)</label> <input id="telefono" aria-describedby="tel-error" aria-invalid="true"> <p id="tel-error" role="alert">El número debe tener 9 dígitos.</p>
Otras herramientas de evaluación
- Prueba funcional: introducir datos incorrectos en campos del formulario (p. ej., email inválido, número fuera de rango, formato incorrecto) y comprobar que aparece un mensaje de error textual claro indicando el problema y cómo corregirlo.
- Inspección del código: verificar que los mensajes están asociados correctamente a cada campo (p. ej., mediante
aria-describedby), y que se usan las propiedades nativas (p. ej.type="email",min,max,pattern) junto con texto explicativo entendible. - Lectores de pantalla: (NVDA, JAWS, VoiceOver) confirmar que los errores se anuncian cuando aparecen y que el usuario entiende qué dato es inválido y cómo corregirlo.
- Revisión visual: comprobar que la notificación del error no depende únicamente del color y que el texto describe específicamente la causa y la solución (p. ej., “Introduce un correo válido con el formato nombre@dominio.com”).
Ejemplos accesibles y no accesibles creados por alumnos
Comentarios
A continuación se muestran comentarios sobre el criterio 3.3.1-B. Descripción de errores
Loading comments...
