Diferencia entre revisiones de «Principio 4/4.1 Compatible/4.1.2-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.2-A. Nombre, función, valor''' ==
{{CriterioWCAG
|id_wcag_criterio=4.1.2
|id_wcag_subcriterio=4.1.2-A
|wcag_titulo_criterio=4.1.2-A. Nombre, función y valor
|wcag_nivel=A
|wcag_version=2.0
|wcag_principio=4_Robusto
|wcag_principio_url=Principio_4
|wcag_pauta=4.1_Compatible
|wcag_pauta_url=Principio_4/4.1_Compatible
|wcag_grupo=Compatibilidad_tecnologica
|wcag_subgrupo=Nombre_funcion_valor


<!-- Análisis interno: Este criterio impacta principalmente a: Personas con discapacidad visual total. Problema grave: Si los controles o elementos personalizados no exponen su nombre, función o estado a través de las APIs de accesibilidad, los lectores de pantalla no pueden informar al usuario ni permitir la interacción. Gravedad: Barrera grave, ya que impide la interacción con la interfaz. -->
|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.2-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">Compatibilidad tecnológica</span></li>
      <li><span class="label">Subcategoría:</span><span class="value">Nombre, función, valor</span></li>
    </ul>
  </section>


  <section class="wcag-users">
|wcag_texto_criterioOAW=
    <p>Usuarios más afectados</p>
Los elementos de la interfaz de usuario (formularios, enlaces, componentes personalizados con scripts, etc.) deben ser accesibles. Es decir, los productos de apoyo deben poder reconocer cuál es su nombre, su función y su valor o estado y pueden interactuar con ellos.
    <ul>
 
      <li>
|wcag_descripcion_resumida=
        <img src="/images/4/4d/Sinvision.png" alt="Icono discapacidad visual total" class="icono-discapacidad" />  
Todos los controles deben exponer nombre, rol y estado de forma programática. 
        Personas con discapacidad visual total – <span class="gravedad">Barrera grave</span>
 
      </li>
Los elementos nativos de HTML cumplen esto automáticamente. 
    </ul>
Para componentes personalizados (widgets, botones creados con <code>&lt;div&gt;</code>, etc.), se debe usar WAI-ARIA correctamente para ofrecer esta información.
   </section>
 
</article>
|wcag_objetivo=
</html>
Garantizar que lectores de pantalla y otros productos de apoyo puedan identificar cada control, saber qué hace y conocer su estado y cambios, permitiendo interacción accesible.
 
|wcag_importancia=
Si un control no expone su nombre, función o estado, las tecnologías de apoyo no pueden usarlo. 
 
Este criterio es esencial para páginas modernas con componentes interactivos creados con JavaScript y frameworks (Vue, React, etc.).
 
|wcag_referencias=
<ul>
<li><span lang="en">[https://www.w3.org/WAI/WCAG21/Techniques/general/G108 G108: Using markup features to expose the name and role, allow user-settable properties to be directly set, and provide notification of changes]</span></li>
<li><span lang="en">[https://www.w3.org/WAI/WCAG21/Techniques/html/H91 H91: Using HTML form controls and links]</span></li>
<li><span lang="en">[https://www.w3.org/WAI/WCAG21/Techniques/html/H44 H44: Using label elements to associate text labels with form controls]</span></li>
<li><span lang="en">[https://www.w3.org/WAI/WCAG21/Techniques/html/H64 H64: Using the title attribute of the frame and iframe elements]</span></li>
<li><span lang="en">[https://www.w3.org/WAI/WCAG21/Techniques/html/H65 H65: Using the title attribute to identify form controls when the label element cannot be used]</span></li>
<li><span lang="en">[https://www.w3.org/WAI/WCAG21/Techniques/html/H88 H88: Using HTML according to spec]</span></li>
<li><span lang="en">[https://www.w3.org/WAI/WCAG21/Techniques/general/G135 G135: Using the accessibility API features of a technology to expose names and notification of changes]</span></li>
<li><span lang="en">[https://www.w3.org/WAI/WCAG21/Techniques/general/G10 G10: Creating components using a technology that supports the accessibility notification of changes]</span></li>
<li><span lang="en">[https://www.w3.org/WAI/WCAG21/Techniques/failures/F59 F59: Failure due to using script to make div or span a user interface control in HTML without providing a role for the control]</span></li>
<li><span lang="en">[https://www.w3.org/WAI/WCAG21/Techniques/failures/F15 F15: Failure due to implementing custom controls that do not use an accessibility API for the technology, or do so incompletely]</span></li>
<li><span lang="en">[https://www.w3.org/WAI/WCAG21/Techniques/failures/F79 F79: Failure due to the focus state of a user interface component not being programmatically determinable or no notification of change of focus state available]</span></li>
</ul>
 
 
|wcag_recursos=
<strong> Consejos </strong>
<ul>
<li>Usar controles nativos de HTML siempre que sea posible</li>
<li>Asociar etiquetas con <code>&lt;label&gt;</code> o <code>aria-label</code></li>
<li>Usar <code>role</code>, <code>aria-labelledby</code>, <code>aria-expanded</code>, <code>aria-checked</code> según corresponda</li>
<li><code>title</code> en <code>&lt;iframe&gt;</code> y elementos embebidos</li>
</ul>
 
|wcag_tipo_evaluacion=Manual
 
|wcag_pasos_evaluacion=
<ol class="paso-list">
<li><span class="paso-badge">Paso 1.</span>
Localizar los componentes de interacción.
</li>
 
<li><span class="paso-badge">Paso 2.</span>
Comprobar que se han creado teniendo en cuenta la accesibilidad. Por ejemplo, que se utilizan enlaces y controles de formulario en HTML siguiendo los requisitos de accesibilidad aplicables (texto significativo, etiquetas descriptivas, etc.).
</li>
 
<li><span class="paso-badge">Paso 3.</span>
Localizar los marcos o marcos en línea existentes.
</li>
 
<li><span class="paso-badge">Paso 4.</span>
Verificar que se proporciona un título en el atributo <code>title</code> que describa de forma breve la finalidad o contenido de cada marco. 
Para ello, con la herramienta <strong>Web Developer Toolbar</strong> seleccionar:
<ul>
<li>a. <strong>Information → Display title attributes</strong></li>
<li>b. <strong>Outline → Outline Frames</strong></li>
</ul>
</li>
</ol>
 
|wcag_resultado_evaluacion=
Todos los componentes exponen de forma programática su nombre, función y estado, y notifican los cambios.
 
|wcag_ejemplo_evaluacion=
<div class="accessibility-card">
El lector de pantalla reconoce "Botón — Menú — Colapsado".
<strong>Correcto:</strong>
<pre class="wcag-codigo-html">
<button aria-expanded="false" id="menuBtn">
   Menú
</button>
</pre>
</div>
 
|wcag_otras_herramientas_evaluacion=
<ul>
<li>'''Inspección del navegador''': revisar que todos los controles tienen un nombre accesible mediante <code>&lt;label&gt;</code>, atributos como <code>aria-label</code> o <code>aria-labelledby</code>, y que su función y estado están correctamente definidos.</li>
<li>'''Lectores de pantalla''': (NVDA, JAWS, VoiceOver) navegar por los controles para comprobar que se anuncian nombre, rol (botón, enlace, cuadro de texto, etc.) y estado/valor (marcado, expandido, requerido, etc.).</li>
<li>'''Inspección del árbol accesible''': usar DevTools (Accessibility panel) para verificar que los componentes personalizados exponen correctamente sus roles, propiedades y estados (p. ej., mediante ARIA).</li>
<li>'''Pruebas con teclado''': asegurarse de que los componentes son operables mediante teclado, manteniendo foco visible y correcto comportamiento al cambiar valores o estados.</li>
</ul>
}}

Revisión actual - 11:07 5 nov 2025

4.1.2-A. Nombre, función y valor

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 elementos de la interfaz de usuario (formularios, enlaces, componentes personalizados con scripts, etc.) deben ser accesibles. Es decir, los productos de apoyo deben poder reconocer cuál es su nombre, su función y su valor o estado y pueden interactuar con ellos.

Comprensión del criterio

Descripción resumida

Todos los controles deben exponer nombre, rol y estado de forma programática.

Los elementos nativos de HTML cumplen esto automáticamente.

Para componentes personalizados (widgets, botones creados con <div>, etc.), se debe usar WAI-ARIA correctamente para ofrecer esta información.

Objetivo

Garantizar que lectores de pantalla y otros productos de apoyo puedan identificar cada control, saber qué hace y conocer su estado y cambios, permitiendo interacción accesible.

Importancia de cumplir el criterio

Si un control no expone su nombre, función o estado, las tecnologías de apoyo no pueden usarlo. Este criterio es esencial para páginas modernas con componentes interactivos creados con JavaScript y frameworks (Vue, React, etc.).

Referencias WCAG

Recursos de apoyo

Consejos
  • Usar controles nativos de HTML siempre que sea posible
  • Asociar etiquetas con <label> o aria-label
  • Usar role, aria-labelledby, aria-expanded, aria-checked según corresponda
  • title en <iframe> y elementos embebidos

Evaluación del criterio

Tipo de evaluación

Evaluación Manual

Procedimiento de evaluación

  1. Paso 1. Localizar los componentes de interacción.
  2. Paso 2. Comprobar que se han creado teniendo en cuenta la accesibilidad. Por ejemplo, que se utilizan enlaces y controles de formulario en HTML siguiendo los requisitos de accesibilidad aplicables (texto significativo, etiquetas descriptivas, etc.).
  3. Paso 3. Localizar los marcos o marcos en línea existentes.
  4. Paso 4. Verificar que se proporciona un título en el atributo title que describa de forma breve la finalidad o contenido de cada marco. Para ello, con la herramienta Web Developer Toolbar seleccionar:
    • a. Information → Display title attributes
    • b. Outline → Outline Frames

Resultado esperado

Todos los componentes exponen de forma programática su nombre, función y estado, y notifican los cambios.

Ejemplo

El lector de pantalla reconoce "Botón — Menú — Colapsado". Correcto:

<button aria-expanded="false" id="menuBtn">
  Menú
</button>

Otras herramientas de evaluación

  • Inspección del navegador: revisar que todos los controles tienen un nombre accesible mediante <label>, atributos como aria-label o aria-labelledby, y que su función y estado están correctamente definidos.
  • Lectores de pantalla: (NVDA, JAWS, VoiceOver) navegar por los controles para comprobar que se anuncian nombre, rol (botón, enlace, cuadro de texto, etc.) y estado/valor (marcado, expandido, requerido, etc.).
  • Inspección del árbol accesible: usar DevTools (Accessibility panel) para verificar que los componentes personalizados exponen correctamente sus roles, propiedades y estados (p. ej., mediante ARIA).
  • Pruebas con teclado: asegurarse de que los componentes son operables mediante teclado, manteniendo foco visible y correcto comportamiento al cambiar valores o estados.










Ejemplos accesibles y no accesibles creados por alumnos

Comentarios

A continuación se muestran comentarios sobre el criterio 4.1.2-A. Nombre, función y valor

Loading comments...