Principio 4/4.1 Compatible/4.1.2-A

4.1.2-A. Nombre, función y valor

4_Robusto 4.1_Compatible

• Nivel: A
• Versión: 2.0
• Principio: 4_Robusto
• Pauta: 4.1_Compatible
• Grupo: Compatibilidad_tecnologica
• Subgrupo: Nombre_funcion_valor

Discapacidades afectadas

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

• Visual total – Barrera grave

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

• G108: Using markup features to expose the name and role, allow user-settable properties to be directly set, and provide notification of changes
• H91: Using HTML form controls and links
• H44: Using label elements to associate text labels with form controls
• H64: Using the title attribute of the frame and iframe elements
• H65: Using the title attribute to identify form controls when the label element cannot be used
• H88: Using HTML according to spec
• G135: Using the accessibility API features of a technology to expose names and notification of changes
• G10: Creating components using a technology that supports the accessibility notification of changes
• F59: Failure due to using script to make div or span a user interface control in HTML without providing a role for the control
• F15: Failure due to implementing custom controls that do not use an accessibility API for the technology, or do so incompletely
• 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

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.

Comentarios

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

Loading comments...