Diferencia entre revisiones de «Principio 3/3.3 Assistencia en los input/3.3.1-B»

De WCAG Wiki
Sin resumen de edición
Sin resumen de edición
Línea 43: Línea 43:
|wcag_referencias=
|wcag_referencias=
<ul>
<ul>
<li><span lang="en">[https://www.w3.org/WAI/WCAG21/Techniques/general/G84 G84: Providing a text description when the user provides information that is not in the list of allowed values]</span></li>
<li><span lang="en">[https://www.w3.org/WAI/WCAG21/Techniques/general/G85 G85: Providing a text description when user input falls outside the required format or values]</span></li>
<li><span lang="en">[https://www.w3.org/WAI/WCAG21/Techniques/client-side-script/SCR18 SCR18: Providing client-side validation and alert]</span></li>
<li><span lang="en">[https://www.w3.org/WAI/WCAG21/Techniques/client-side-script/SCR32 SCR32: Providing client-side validation and adding error text via the DOM]</span></li>
</ul>
<li><span lang="en">[https://www.w3.org/WAI/WCAG22/Understanding/error-identification.html Understanding Success Criterion 3.3.1]</span></li>
<li><span lang="en">[https://www.w3.org/WAI/WCAG22/Understanding/error-identification.html Understanding Success Criterion 3.3.1]</span></li>
<li><span lang="en">[https://www.w3.org/WAI/WCAG22/quickref/#error-identification WCAG Quick Reference]</span></li>
<li>[https://webaim.org/techniques/forms/ WebAIM — Accessible Forms]</li>
<li>[https://www.w3.org/TR/WAI-ARIA-1.2/#aria-invalid WAI-ARIA — aria-invalid]</li>
</ul>
</ul>


|wcag_recursos=
|wcag_recursos=
<ul>
<ul>
<li>Mensaje textual junto al campo</li>
<li>[https://www.w3.org/WAI/tutorials/forms/notifications/ User Notification]</li>
<li><code>aria-describedby</code> para asociar error al campo</li>
<li><code>aria-invalid="true"</code></li>
<li>Mensajes rol="alert"</li>
</ul>
</ul>


Línea 61: Línea 60:
|wcag_pasos_evaluacion=
|wcag_pasos_evaluacion=
<ol class="paso-list">
<ol class="paso-list">
<li>Introducir valores erróneos</li>
<li><span class="paso-badge">Paso 1.</span>
<li>Verificar mensaje textual claro</li>
Localizar los formularios existentes.
<li>Confirmar vínculo al input (<code>aria-describedby</code>)</li>
</li>
<li>Verificar anuncio con lector de pantalla</li>
 
<li><span class="paso-badge">Paso 2.</span>
Intentar enviar el formulario sin haber completado los campos obligatorios.
</li>
 
<li><span class="paso-badge">Paso 3.</span>
Verificar que se informa a los usuarios mediante texto de qué campos obligatorios faltan por completar.
</li>
</ol>
</ol>


|wcag_resultado_evaluacion=
|wcag_resultado_evaluacion=
Línea 72: Línea 79:
|wcag_ejemplo_evaluacion=
|wcag_ejemplo_evaluacion=
<div class="accessibility-card">
<div class="accessibility-card">
<strong>✅ Ejemplo accesible: error claro y asociado</strong>
Se muestra el error claro y asociado al campo de texto donde se ha producido.
<pre class="wcag-codigo-html">
<pre class="wcag-codigo-html">
<label for="telefono">Teléfono (9 dígitos)</label>
<label for="telefono">Teléfono (9 dígitos)</label>
Línea 82: Línea 89:
|wcag_otras_herramientas_evaluacion=
|wcag_otras_herramientas_evaluacion=
<ul>
<ul>
<li>NVDA/JAWS/VoiceOver</li>
<li>'''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.</li>
<li>DevTools accesibilidad</li>
<li>'''Inspección del código''': verificar que los mensajes están asociados correctamente a cada campo (p. ej., mediante <code>aria-describedby</code>), y que se usan las propiedades nativas (p. ej. <code>type="email"</code>, <code>min</code>, <code>max</code>, <code>pattern</code>) junto con texto explicativo entendible.</li>
<li>Lighthouse / Axe</li>
<li>'''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.</li>
<li>'''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”).</li>
</ul>
</ul>
}}
}}

Revisión del 06:40 6 nov 2025

3.3.1-B. Descripción de errores

Discapacidades afectadas

Este criterio puede afectar a distintas personas con discapacidad. A continuación se indican las más relevantes.

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

Recursos de apoyo

Evaluación del criterio

Tipo de evaluación

Evaluación Manual

Procedimiento de evaluación

  1. Paso 1. Localizar los formularios existentes.
  2. Paso 2. Intentar enviar el formulario sin haber completado los campos obligatorios.
  3. 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...