Diferencia entre revisiones de «Principio 4/4.1 Compatible/4.1.3-A»

De WCAG Wiki
Sin resumen de edición
Sin resumen de edición
 
(No se muestra una edición intermedia del mismo usuario)
Línea 1: Línea 1:
== '''4.1.3-A. Mensajes de estado''' ==
{{CriterioWCAG
|id_wcag_criterio=4.1.3
|id_wcag_subcriterio=4.1.3-A
|wcag_titulo_criterio=4.1.3-A. Mensajes de estado
|wcag_nivel=AA
|wcag_version=2.1
|wcag_principio=4_Robusto
|wcag_principio_url=Principio_4
|wcag_pauta=4.1_Compatible
|wcag_pauta_url=Principio_4/4.1_Compatible
|wcag_grupo=Informacion_dinamica
|wcag_subgrupo=Mensajes_de_estado


<!-- Análisis interno: Este criterio impacta principalmente a: Personas con discapacidad visual total y usuarios de lectores de pantalla. Problema grave: Si los mensajes de estado (como errores, confirmaciones o alertas) no son identificables por software, los usuarios no se enteran de cambios importantes (como “formulario enviado” o “error en el campo”). Gravedad: Barrera grave, porque puede impedir completar tareas o recibir información crítica. -->
|wcag_discapacidades=
<li class="discapacidad-item">
  [[Archivo:Sinvision.png|20px|class=icon-discapacidad|alt=Discapacidad visual total]]
  <span class="discapacidad-texto">[[:Categoría:Discapacidad visual total|Visual total]]</span> –
  <span class="gravedad gravedad-grave">Barrera grave</span>
</li>


<!-- criterio 4.1.3-A -->
|wcag_lista_discapacidades=
<html>
[[Categoría:Discapacidad visual total]]
<article class="wcag-card">
  <section class="wcag-info">
    <ul>
      <li><span class="label">Nivel:</span><span class="value">A</span></li>
      <li><span class="label">Versión:</span><span class="value">2.2</span></li>
      <li><span class="label">Principio:</span><span class="value">4. Robusto</span></li>
      <li><span class="label">Pauta:</span><span class="value">4.1 Compatible</span></li>
      <li><span class="label">Categoría:</span><span class="value">Mensajes e información dinámica</span></li>
      <li><span class="label">Subcategoría:</span><span class="value">Mensajes de estado</span></li>
    </ul>
  </section>


  <section class="wcag-users">
|wcag_texto_criterioOAW=
    <p>Usuarios más afectados</p>
Los mensajes de estado deben poder ser identificados por software a través de sus roles o propiedades de forma que se puedan transmitir a los usuarios sin necesidad de recibir el foco.
    <ul>
 
      <li>
|wcag_descripcion_resumida=
        <img src="/images/4/4d/Sinvision.png" alt="Icono discapacidad visual total" class="icono-discapacidad" />  
Cuando el contenido presenta información dinámica como confirmaciones, errores, avisos de progreso o resultados de búsqueda, dicha información debe ser anunciada por lectores de pantalla sin mover el foco. 
        Personas con discapacidad visual total – <span class="gravedad">Barrera grave</span>
Esto se consigue asignando roles y propiedades ARIA apropiadas (por ejemplo, <code>role="status"</code> o <code>role="alert"</code>).
      </li>
 
    </ul>
|wcag_objetivo=
  </section>
Garantizar que las personas usuarias sean informadas de cambios relevantes en el contenido sin perder su posición ni interrumpir su interacción, especialmente cuando utilizan lectores de pantalla.
</article>
 
</html>
|wcag_importancia=
Si los mensajes de estado no se identifican de forma programática, los usuarios con tecnologías de apoyo no sabrán que ocurrió un cambio importante, como un error en formulario, un envío exitoso o un mensaje de progreso.
Esto puede impedir completar tareas y comprender resultados de acciones.
 
|wcag_referencias=
<ul>
<li><span lang="en">[https://www.w3.org/WAI/WCAG21/Techniques/aria/ARIA22 ARIA22: Using role=status to present status messages]</span></li>
<li><span lang="en">[https://www.w3.org/WAI/WCAG21/Techniques/aria/ARIA19 ARIA19: Using ARIA role=alert or live regions to identify errors]</span></li>
<li><span lang="en">[https://www.w3.org/WAI/WCAG21/Techniques/aria/ARIA23 ARIA23: Using role=log to identify sequential information updates]</span></li>
<li><span lang="en">[https://www.w3.org/WAI/WCAG21/Techniques/aria/ARIA18 ARIA18: Using aria-alertdialog to identify errors]</span></li>
<li><span lang="en">[https://www.w3.org/WAI/WCAG21/Techniques/failures/F103 F103: Failure due to providing status messages that cannot be programmatically determined through role or properties]</span></li>
</ul>
 
Se incluyen también tecnicas de WAI-ARIA:
<ul>
<li><span lang="en">[https://www.w3.org/WAI/WCAG21/Techniques/aria/ARIA22 ARIA22: Using role="status" to present status messages]</span></li>
<li><span lang="en">[https://www.w3.org/WAI/WCAG21/Techniques/aria/ARIA19 ARIA19: Using ARIA role="alert" or live regions to identify errors]</span></li>
<li><span lang="en">[https://www.w3.org/WAI/WCAG21/Techniques/aria/ARIA23 ARIA23: Using role="log" to identify sequential information updates]</span></li>
<li><span lang="en">[https://www.w3.org/WAI/WCAG21/Techniques/aria/ARIA18 ARIA18: Using aria-alertdialog to identify errors]</span></li>
<li><span lang="en">[https://www.w3.org/WAI/WCAG21/Techniques/failures/F103 F103: Failure due to providing status messages that cannot be programmatically determined through role or properties]</span></li>
</ul>
 
 
|wcag_recursos=
<strong> Consejos </strong>
<ul>
<li>Usar <code>role="status"</code> para notificaciones pasivas</li>
<li>Usar <code>role="alert"</code> para errores inmediatos</li>
<li>Usar <code>role="progressbar"</code> para progreso</li>
<li>Usar <code>aria-live</code> adecuadamente en contenido dinámico</li>
</ul>
 
|wcag_tipo_evaluacion=Manual
 
|wcag_pasos_evaluacion=
Usa la herramienta  ''' [https://chromewebstore.google.com/detail/web-developer/bfbameneiokkgbdmiekhjnmfkcnldhhm?hl=es Web Developer Toolbar].'''
 
<ol class="paso-list">
<li><span class="paso-badge">Paso 1.</span>
Localizar los contenidos que se añaden de manera dinámica a la página y que proporcionan información sobre:
<ul>
<li>a. El éxito o resultado de una acción.</li>
<li>b. El estado de espera de una acción.</li>
<li>c. El progreso de un proceso.</li>
<li>d. La existencia de errores.</li>
</ul>
</li>
 
<li><span class="paso-badge">Paso 2.</span>
Comprobar que, cuando se actualiza esta información, el componente <strong>no recibe el foco</strong>. 
<small>(Si recibe el foco, este criterio no aplica y no se debe seguir comprobando).</small>
</li>
 
<li><span class="paso-badge">Paso 3.</span>
Comprobar si tiene un rol de WAI-ARIA definido. Para ello, seleccionar <strong>“Information → Display ARIA roles”</strong>.
</li>
 
<li><span class="paso-badge">Paso 4.</span>
Verificar que el rol es correcto de acuerdo con su función.
</li>
</ol>
 
 
|wcag_resultado_evaluacion=
Los mensajes de estado son detectados por software y anunciados sin mover el foco, permitiendo a usuarios con lectores de pantalla recibir la información de forma no intrusiva.
 
|wcag_ejemplo_evaluacion=
<div class="accessibility-card">
El lector de pantalla anuncia el cambio sin perder el foco.
<br/>
HTML:
<pre class="wcag-codigo-html">
<button id="add-btn">Añadir al carrito</button>
<div id="msg" role="status" aria-live="polite"></div>
</pre>
 
Javascript:
<pre class="wcag-codigo-html">
document.getElementById('add-btn').addEventListener('click', () => {
  document.getElementById('msg').textContent = 'Producto añadido al carrito';
});
</pre>
 
</div>
 
 
|wcag_otras_herramientas_evaluacion=
<ul>
<li>'''Inspección del navegador''': verificar que los mensajes de estado (confirmación, error, éxito, información) usan roles ARIA adecuados como <code>role="status"</code>, <code>role="alert"</code>, o atributos como <code>aria-live</code> sin requerir foco para ser detectados.</li>
<li>'''Lectores de pantalla''': (NVDA, JAWS, VoiceOver) comprobar que los mensajes se anuncian automáticamente cuando aparecen, sin mover el foco.</li>
<li>'''Consola y árbol accesible''': usar DevTools (panel Accessibility) para confirmar que el mensaje está presente en el árbol accesible y tiene región viva adecuada (p. ej., <code>aria-live="polite"</code> o <code>aria-live="assertive"</code>).</li>
<li>'''Pruebas de interacción''': disparar acciones que generen mensajes (envíos de formularios, cambios de estado, validaciones) y validar que los usuarios con productos de apoyo reciben la información.</li>
</ul>
 
}}

Revisión actual - 11:13 5 nov 2025

4.1.3-A. Mensajes de estado

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)

  • Los mensajes de estado deben poder ser identificados por software a través de sus roles o propiedades de forma que se puedan transmitir a los usuarios sin necesidad de recibir el foco.

Comprensión del criterio

Descripción resumida

Cuando el contenido presenta información dinámica como confirmaciones, errores, avisos de progreso o resultados de búsqueda, dicha información debe ser anunciada por lectores de pantalla sin mover el foco. Esto se consigue asignando roles y propiedades ARIA apropiadas (por ejemplo, role="status" o role="alert").

Objetivo

Garantizar que las personas usuarias sean informadas de cambios relevantes en el contenido sin perder su posición ni interrumpir su interacción, especialmente cuando utilizan lectores de pantalla.

Importancia de cumplir el criterio

Si los mensajes de estado no se identifican de forma programática, los usuarios con tecnologías de apoyo no sabrán que ocurrió un cambio importante, como un error en formulario, un envío exitoso o un mensaje de progreso. Esto puede impedir completar tareas y comprender resultados de acciones.

Referencias WCAG

Recursos de apoyo

Consejos
  • Usar role="status" para notificaciones pasivas
  • Usar role="alert" para errores inmediatos
  • Usar role="progressbar" para progreso
  • Usar aria-live adecuadamente en contenido dinámico

Evaluación del criterio

Tipo de evaluación

Evaluación Manual

Procedimiento de evaluación

Usa la herramienta Web Developer Toolbar.
  1. Paso 1. Localizar los contenidos que se añaden de manera dinámica a la página y que proporcionan información sobre:
    • a. El éxito o resultado de una acción.
    • b. El estado de espera de una acción.
    • c. El progreso de un proceso.
    • d. La existencia de errores.
  2. Paso 2. Comprobar que, cuando se actualiza esta información, el componente no recibe el foco. (Si recibe el foco, este criterio no aplica y no se debe seguir comprobando).
  3. Paso 3. Comprobar si tiene un rol de WAI-ARIA definido. Para ello, seleccionar “Information → Display ARIA roles”.
  4. Paso 4. Verificar que el rol es correcto de acuerdo con su función.

Resultado esperado

Los mensajes de estado son detectados por software y anunciados sin mover el foco, permitiendo a usuarios con lectores de pantalla recibir la información de forma no intrusiva.

Ejemplo

El lector de pantalla anuncia el cambio sin perder el foco.
HTML:

<button id="add-btn">Añadir al carrito</button>
<div id="msg" role="status" aria-live="polite"></div>

Javascript:

document.getElementById('add-btn').addEventListener('click', () => {
  document.getElementById('msg').textContent = 'Producto añadido al carrito';
});

Otras herramientas de evaluación

  • Inspección del navegador: verificar que los mensajes de estado (confirmación, error, éxito, información) usan roles ARIA adecuados como role="status", role="alert", o atributos como aria-live sin requerir foco para ser detectados.
  • Lectores de pantalla: (NVDA, JAWS, VoiceOver) comprobar que los mensajes se anuncian automáticamente cuando aparecen, sin mover el foco.
  • Consola y árbol accesible: usar DevTools (panel Accessibility) para confirmar que el mensaje está presente en el árbol accesible y tiene región viva adecuada (p. ej., aria-live="polite" o aria-live="assertive").
  • Pruebas de interacción: disparar acciones que generen mensajes (envíos de formularios, cambios de estado, validaciones) y validar que los usuarios con productos de apoyo reciben la información.










Ejemplos accesibles y no accesibles creados por alumnos

Comentarios

A continuación se muestran comentarios sobre el criterio 4.1.3-A. Mensajes de estado

Loading comments...