Criterios de éxito de las WCAG · Level A

WCAG 4.1.2: Nombre, Función, Valor

Las WCAG 4.1.2 requieren que todos los componentes de la interfaz de usuario tengan un nombre y una función determinables mediante programación, y que los estados, propiedades y valores puedan ser tanto leídos como establecidos por las tecnologías de asistencia. Esto garantiza que los lectores de pantalla y otras herramientas puedan identificar, describir e interactuar con precisión con cada elemento de la página.

Qué Significa Esta Regla

WCAG 4.1.2 — Nombre, Rol, Valor es un criterio de éxito de Nivel A bajo el principio de Robustez. Exige que para cada componente de la interfaz de usuario —incluidos elementos de formulario, botones, enlaces, widgets personalizados, marcos y controles interactivos— se cumplan las siguientes tres condiciones:

Nombre: Cada componente debe tener un nombre accesible que las tecnologías de asistencia puedan leer en voz alta o mostrar a través de una pantalla braille. El nombre puede provenir del contenido del elemento (por ejemplo, el texto dentro de un <button>), de un elemento label, de un atributo aria-label, de una referencia aria-labelledby o de un atributo title.
Rol: Cada componente debe tener un rol que comunique su propósito a las tecnologías de asistencia. Los elementos HTML nativos llevan roles implícitos (un <button> tiene el rol button, un <input type='checkbox'> tiene el rol checkbox). Los widgets personalizados construidos a partir de elementos genéricos como <div> o <span> deben declarar explícitamente un rol usando el atributo ARIA role.
Valor (Estados y Propiedades): Cualquier estado o valor actual que sea significativo para la persona usuaria —si una casilla está marcada, si un widget de divulgación está expandido, si un campo es obligatorio— debe exponerse de forma programática para que las tecnologías de asistencia puedan informarlo y para que las personas usuarias puedan cambiarlo cuando corresponda.

Un componente cumple este criterio cuando su nombre accesible no está vacío, su rol es válido y semánticamente apropiado, y todos los estados relevantes (como aria-checked, aria-expanded o aria-required) se aplican correctamente y se mantienen sincronizados con la interfaz visual. Un componente incumple cuando cualquiera de estos tres elementos está ausente, es incorrecto o está desincronizado; por ejemplo, un botón de alternancia personalizado que cambia de color visualmente pero nunca actualiza su estado aria-pressed.

La excepción oficial de WCAG cubre componentes que intencionalmente no se exponen a las API de accesibilidad; por ejemplo, elementos puramente decorativos o contenido oculto con aria-hidden='true'. Sin embargo, ocultar contenido activo o enfocable con aria-hidden (por ejemplo, aplicándolo al elemento <body>) es en sí mismo una infracción, porque elimina todo el contenido de la página del árbol de accesibilidad.

Por Qué Importa

Aproximadamente 2.2 mil millones de personas en todo el mundo tienen algún tipo de discapacidad visual, según la Organización Mundial de la Salud. Para las personas ciegas y con baja visión que dependen de lectores de pantalla como JAWS, NVDA o VoiceOver, el nombre accesible y el rol de cada componente interactivo son el medio principal —y a menudo el único— para entender qué hace un control y cómo usarlo. Si un botón no tiene nombre accesible, una persona usuaria de lector de pantalla solo escucha "button" sin ninguna indicación de su propósito. Si un desplegable personalizado no tiene rol, la persona usuaria no puede distinguirlo de un texto estático.

Las personas con discapacidad motriz que operan el software mediante acceso por pulsadores, herramientas de control por voz como Dragon NaturallySpeaking o navegación por teclado también dependen de este criterio. El software de control por voz asigna los comandos hablados ("click Submit") a nombres accesibles. Si el nombre accesible de un botón no coincide con su etiqueta visible, los comandos de voz fallan por completo.

La accesibilidad cognitiva es igualmente relevante. Un etiquetado coherente y predecible reduce la carga cognitiva para personas con dislexia, problemas de memoria o discapacidades relacionadas con la atención. Cuando los cambios de estado —como la apertura de un modal o que un campo de formulario pase a ser obligatorio— no son anunciados por las tecnologías de asistencia, las personas usuarias pueden desorientarse e incapaces de completar tareas.

Considere un escenario concreto del mundo real: una plataforma de comercio electrónico turca muestra un botón "Add to Cart" construido como un <div> con un controlador de clic y un icono de carrito de compras. Visualmente parece un botón. Pero como carece de role='button', de un nombre accesible y de tabindex='0', una persona usuaria de lector de pantalla que navega con el teclado no encuentra nada: el elemento es completamente invisible para su tecnología de asistencia. No puede añadir productos a su carrito, quedando efectivamente excluida de toda la experiencia de compra.

Más allá de la accesibilidad, los componentes correctamente nombrados y estructurados mejoran el SEO porque los rastreadores de motores de búsqueda dependen del marcado semántico para entender la estructura de la página y la intención interactiva. También mejoran la capacidad de prueba, ya que los marcos de pruebas automatizadas pueden localizar e interactuar de forma más fiable con elementos que tienen roles y etiquetas significativos.

Reglas Relacionadas de Axe-core

Las siguientes reglas de axe-core están directamente asociadas con WCAG 4.1.2. Cada una se dirige a una categoría específica de fallos de nombre, rol o valor:

aria-allowed-attr: Verifica que los atributos ARIA aplicados a un elemento estén permitidos para el rol de ese elemento. Por ejemplo, aplicar aria-checked a un elemento con role='link' es inválido y se marca, porque el rol link no admite aria-checked.
aria-command-name: Garantiza que los elementos con roles de comando ARIA (link, button, menuitem) tengan un nombre accesible no vacío. Un botón solo con icono, sin texto de etiqueta y sin aria-label, se marcaría aquí.
aria-hidden-body: Señala el caso específico en el que se ha aplicado aria-hidden='true' al elemento <body>, lo que elimina toda la página del árbol de accesibilidad y hace que todo el contenido sea invisible para los lectores de pantalla.
aria-input-field-name: Verifica que los elementos con roles de entrada ARIA (textbox, searchbox, spinbutton, slider, combobox) tengan un nombre accesible. Un campo de búsqueda personalizado construido con role='textbox' pero sin etiqueta se marcaría.
aria-meter-name: Verifica que los elementos con role='meter' tengan un nombre accesible, para que las personas usuarias de lectores de pantalla entiendan qué cantidad está midiendo el medidor (por ejemplo, uso de almacenamiento o nivel de batería).
aria-progressbar-name: Garantiza que los elementos con role='progressbar' tengan un nombre accesible, para que las personas usuarias sepan qué proceso u operación está en curso en lugar de escuchar solo "progress bar".
aria-required-attr: Verifica que los elementos que usan un rol ARIA determinado incluyan todos los atributos que la especificación ARIA exige para ese rol. Por ejemplo, role='slider' requiere aria-valuenow, aria-valuemin y aria-valuemax; omitir cualquiera de estos se marca.
aria-roles: Valida que todos los valores asignados al atributo role sean roles ARIA válidos y no abstractos. Los errores tipográficos, roles inventados o roles abstractos (como role='widget') usados directamente en elementos se marcan todos.
aria-tooltip-name: Verifica que los elementos con role='tooltip' tengan un nombre accesible. Un elemento de tooltip vacío no aporta ningún valor a las personas usuarias de lectores de pantalla y representa un fallo de etiquetado.
button-name: Verifica que los elementos <button> y los elementos con role='button' tengan un nombre accesible no vacío. Esto detecta botones de icono sin aria-label y botones vacíos usados como disparadores decorativos.
frame-title: Exige que los elementos <iframe> y <frame> tengan un atributo title no vacío que describa el contenido del marco. Sin él, las personas usuarias de lectores de pantalla no pueden determinar el propósito del contenido incrustado y pueden no saber si deben entrar o saltar el marco.
input-button-name: Verifica que los elementos <input> de tipo submit, reset, button e image tengan un nombre accesible, ya sea mediante un atributo value o, en el caso de entradas de imagen, un atributo alt.

Es importante señalar que, aunque las herramientas automatizadas detectan muchos fallos de nombre, rol y valor, algunas infracciones requieren pruebas manuales. Los escáneres automatizados no pueden verificar si un nombre accesible es significativo; un botón etiquetado como "click here" técnicamente supera la comprobación automatizada de tener un nombre, pero no comunica su propósito real. Del mismo modo, si los cambios de estado (como el cambio de aria-expanded cuando se abre un menú) se anuncian correctamente durante la interacción en vivo solo puede confirmarse mediante pruebas prácticas con lectores de pantalla.

Cómo Probar

Análisis automatizado con axe DevTools o Lighthouse: Instale la extensión de navegador axe DevTools (Chrome o Firefox) o ejecute una auditoría de Lighthouse en las Chrome DevTools en la pestaña Accessibility. Active el análisis de página completa y filtre los resultados por la etiqueta WCAG 4.1.2. Busque específicamente infracciones de button-name, frame-title, aria-required-attr, aria-roles y aria-input-field-name. Cada hallazgo incluirá el elemento infractor, una descripción del fallo y una solución sugerida. Exporte los resultados y priorice primero los elementos con gravedad Critical y Serious.
Prueba de navegación por teclado: Desconecte el ratón y navegue por toda la página usando la tecla Tab. Confirme que cada elemento enfocable recibe un foco visible, que el indicador de foco nativo del navegador (o uno personalizado) es claramente visible y que puede activar todos los controles usando Enter o Space. Cualquier elemento al que llegue y que no pueda identificar solo por el contexto —sin mirar la pantalla— indica un probable fallo de nombre accesible.
Pruebas con lector de pantalla usando NVDA y Firefox: Abra NVDA (Windows, gratuito), inicie Firefox y navegue por la página usando Tab para moverse por los elementos interactivos y la Lista de Elementos de NVDA (Insert+F7) para explorar todos los botones, enlaces y campos de formulario. Para cada elemento interactivo, escuche lo que anuncia NVDA. Debe leer el nombre del elemento, su rol y cualquier estado relevante (por ejemplo, "Subscribe, button" o "Email address, required, edit text"). Marque cualquier elemento anunciado sin nombre o con un rol incorrecto.
Pruebas con lector de pantalla usando VoiceOver y Safari (macOS/iOS): Active VoiceOver (Command+F5 en macOS), abra Safari y use VO+Flecha derecha para navegar por los elementos. Use el Rotor de VoiceOver (VO+U) para listar todos los controles de formulario y botones. Verifique que los nombres sean descriptivos, que los roles sean apropiados y que los estados se actualicen dinámicamente cuando interactúe (por ejemplo, al alternar un acordeón personalizado, VoiceOver debería anunciar "expanded" o "collapsed").
Pruebas con lector de pantalla usando JAWS y Chrome: Inicie JAWS y abra Chrome. Use la tecla Tab para navegar por los elementos interactivos y el Cursor Virtual de JAWS (Insert+F3 para una lista de campos de formulario) para revisar las etiquetas. Preste especial atención a los widgets personalizados construidos con ARIA; confirme que los cambios de estado desencadenados por la interacción con el teclado se reflejan en lo que JAWS anuncia en tiempo real.
Verificación del estado de widgets personalizados: Para cualquier widget personalizado (acordeón, panel de pestañas, combobox, modal), interactúe completamente con él usando solo el teclado. En cada paso, verifique que el lector de pantalla anuncie la actualización de estado correcta; por ejemplo, abrir un widget de divulgación debería desencadenar un anuncio de "expanded" y cerrarlo debería anunciar "collapsed". Si el estado visual cambia pero el lector de pantalla permanece en silencio, aria-expanded está ausente o no se está alternando de forma programática.

Cómo Corregir

Botón Solo con Icono Sin Nombre Accesible — Incorrecto

<!-- Icon button with no accessible name: screen readers announce only "button" -->
<button>
  <svg aria-hidden='true' focusable='false'>
    <use href='#icon-search'></use>
  </svg>
</button>

Botón Solo con Icono Sin Nombre Accesible — Correcto

<!-- aria-label provides the accessible name when no visible text is present -->
<button aria-label='Search'>
  <svg aria-hidden='true' focusable='false'>
    <use href='#icon-search'></use>
  </svg>
</button>

Widget de Alternancia Personalizado Sin Rol ni Estado — Incorrecto

<!-- A div used as a toggle: no role, no state, not keyboard accessible -->
<div class='toggle' onclick='toggleDarkMode()'>
  Dark Mode
</div>

Widget de Alternancia Personalizado Sin Rol ni Estado — Correcto

<!-- role='switch' communicates purpose; aria-checked reflects current state;
     tabindex='0' makes it keyboard reachable; keydown handler enables Space/Enter -->
<div
  role='switch'
  aria-checked='false'
  tabindex='0'
  onclick='toggleDarkMode(this)'
  onkeydown='if(event.key==="Enter"||event.key===" "){toggleDarkMode(this);event.preventDefault();}'
>
  Dark Mode
</div>

<script>
function toggleDarkMode(el) {
  const isOn = el.getAttribute('aria-checked') === 'true';
  el.setAttribute('aria-checked', String(!isOn));
  document.body.classList.toggle('dark-mode', !isOn);
}
</script>

iframe Sin Etiqueta — Incorrecto

<!-- iframe with no title: screen reader users cannot determine what is inside -->
<iframe src='https://maps.example.com/embed?q=istanbul'></iframe>

iframe Sin Etiqueta — Correcto

<!-- title describes the frame's content so users can decide whether to enter it -->
<iframe
  src='https://maps.example.com/embed?q=istanbul'
  title='Interactive map showing our Istanbul office location'
></iframe>

Barra de Progreso Personalizada Sin Atributos ARIA Requeridos — Incorrecto

<!-- role='progressbar' without aria-valuenow, aria-valuemin, aria-valuemax:
     screen readers cannot determine the current progress -->
<div role='progressbar' style='width:60%'></div>

Barra de Progreso Personalizada Sin Atributos ARIA Requeridos — Correcto

<!-- All required attributes present; aria-label provides the accessible name -->
<div
  role='progressbar'
  aria-valuenow='60'
  aria-valuemin='0'
  aria-valuemax='100'
  aria-label='File upload progress'
>
  60%
</div>

Errores Comunes

Usar role='button' en un <div> sin añadir tabindex='0': el elemento pasa a ser anunciado como botón por los lectores de pantalla pero sigue siendo inalcanzable mediante la navegación con la tecla Tab, lo que lo hace inutilizable para personas que solo usan el teclado.
Aplicar aria-label a un elemento no interactivo: añadir aria-label a un <div> o <span> sin rol no tiene efecto; la etiqueta es ignorada por la mayoría de los navegadores porque el elemento no tiene un rol al que nombrar.
Dejar aria-expanded estático tras implementar un widget de divulgación: establecer aria-expanded='false' en HTML y no alternarlo nunca con JavaScript significa que el atributo siempre es incorrecto después del primer clic, anunciando el estado opuesto a las personas usuarias de lectores de pantalla.
Usar aria-hidden='true' en un contenedor que contiene elementos enfocables: esto oculta el contenedor del árbol de accesibilidad pero no del foco del teclado, de modo que las personas usuarias de lectores de pantalla pueden llegar con Tab a elementos que no pueden oír, causando una confusión extrema.
Proporcionar un placeholder como única etiqueta para un <input>: el texto del placeholder desaparece al introducir datos, no siempre se anuncia de forma fiable como etiqueta por todos los lectores de pantalla y no satisface el requisito de nombre accesible para los campos de formulario.
Usar un rol ARIA inválido o abstracto como role='widget' o role='structure': estos son roles base en la especificación ARIA y no están pensados para uso directo; no proporcionan información semántica significativa y pueden ser ignorados o causar errores en las tecnologías de asistencia.
Referenciar un ID de elemento inexistente en aria-labelledby: si el ID señalado por aria-labelledby no existe en el DOM, el cálculo del nombre accesible falla y el elemento se queda sin nombre.
Usar value en lugar de aria-label para <input type='image'>: los botones de entrada de imagen requieren un atributo alt para su nombre accesible; el atributo value se ignora para el cálculo del nombre en entradas de tipo imagen.
Omitir el atributo title en elementos <iframe> que cargan contenido de terceros: las personas desarrolladoras suelen asumir que los elementos incrustados muy conocidos (mapas, widgets de pago, reproductores de vídeo) se describen por sí mismos, pero las personas usuarias de lectores de pantalla deben conocer el propósito del marco antes de decidir si entran en él.
Olvidar actualizar los nombres accesibles dinámicamente cuando cambia el contenido: si la etiqueta de un botón cambia visualmente de "Play" a "Pause" pero el aria-label sigue siendo "Play", las personas usuarias de lectores de pantalla reciben información incorrecta sobre el estado y la acción actuales.

Relación con las Regulaciones de Accesibilidad de Turquía

La Circular Presidencial 2025/10 de Turquía, publicada en el Boletín Oficial n.º 32933 el 21 de junio de 2025, establece requisitos obligatorios de accesibilidad digital alineados con WCAG 2.2. WCAG 4.1.2 — Nombre, Rol, Valor es un criterio de Nivel A, lo que significa que se sitúa en el nivel más fundamental de conformidad. Según la circular, la conformidad de Nivel A no es opcional: es la base que todas las entidades cubiertas deben alcanzar.

La circular se aplica a una amplia gama de tipos de entidades que operan en Turquía. Las instituciones públicas —incluidos ministerios, municipios y organismos estatales— deben lograr la conformidad en el plazo de un año desde la fecha de publicación de la circular. Las entidades del sector privado —incluidas plataformas de comercio electrónico, bancos e instituciones financieras, hospitales y proveedores de salud privados, empresas de telecomunicaciones con 200,000 o más abonados, agencias de viajes, empresas de transporte privado y escuelas privadas autorizadas por el Ministerio de Educación Nacional (MoNE)— deben lograr la conformidad en el plazo de dos años.

WCAG 4.1.2 es particularmente trascendental para las organizaciones turcas porque muchos sitios web turcos modernos dependen de componentes interactivos personalizados —carruseles de productos, secciones de preguntas frecuentes en acordeón, flujos de pago paso a paso y paneles bancarios— que con frecuencia se implementan sin roles ARIA adecuados, nombres o gestión de estado. Un botón de pago personalizado que no tiene nombre accesible, o un control deslizante de calculadora de préstamos que carece de aria-valuenow, no es simplemente una mala experiencia de usuario: según la circular, constituye un incumplimiento legal.

Para los bancos y las plataformas de comercio electrónico sujetas a la circular, las infracciones de WCAG 4.1.2 en flujos críticos de transacción —formularios de pago, modales de autenticación, paneles de cuentas— son especialmente de alto riesgo. Un combobox personalizado con estilo visual para seleccionar una sucursal bancaria que carece de marcado ARIA adecuado puede impedir por completo que una persona usuaria de lector de pantalla complete una transacción, exponiendo a la institución tanto a acciones regulatorias como a reclamaciones por discriminación.

Las organizaciones que utilizan el SDK de superposición de Accsible pueden beneficiarse de la detección automatizada y la corrección en tiempo de ejecución de muchas infracciones de Nombre, Rol, Valor, incluida la inyección de nombres accesibles faltantes, la corrección de roles ARIA inválidos en patrones de widgets conocidos y la sincronización de atributos de estado en componentes interactivos. Sin embargo, las organizaciones deben tratar el soporte automatizado de superposición como un complemento y no como un sustituto del desarrollo adecuado con HTML semántico, especialmente para widgets personalizados complejos en los que la gestión programática del estado debe integrarse en la lógica de la aplicación desde el principio.

Fuentes y referencias

Articulos relacionados

AWCAG 1.1.1: Contenido no textual AWCAG 1.2.1: Solo audio y solo video (pregrabado)AWCAG 1.2.2: Subtítulos (pregrabados)