Nombre, función, valor

Qué exige este criterio

Todo elemento interactivo de la página — botones, enlaces, campos de formulario, pestañas, controles deslizantes, widgets personalizados — debe exponer tres datos a la tecnología de apoyo:

• Nombre — ¿cómo se llama este control? («Enviar», «Cerrar diálogo», «Volumen»)
• Función — ¿qué tipo de control es? (botón, enlace, casilla de verificación, pestaña, control deslizante)
• Valor / estado — cuando el componente lo tiene: ¿está pulsado, expandido, marcado, seleccionado? ¿Cuál es el valor actual?

La exposición debe ser programática — definida en el DOM, no pintada con CSS. Los lectores de pantalla, las pantallas braille, el software de control por voz y los escáneres de conmutación leen el árbol de accesibilidad, no los píxeles.

Cómo cumplirlo

• Usar el elemento HTML nativo siempre que exista uno. <button> incluye de serie la función correcta, el foco, la gestión del teclado y un nombre accesible derivado de su contenido de texto, sin coste adicional.
• Para los botones de solo icono, añadir aria-label (o texto visualmente oculto). <button aria-label="Cerrar">×</button>.
• Para los campos de formulario, asociar un <label for> al id del campo, o envolver el campo dentro del <label>. El texto de marcador de posición no es una etiqueta.
• Cuando sea imprescindible construir un widget personalizado con <div> y <span>, añadir role="…", gestionar tabindex, gestionar las teclas Enter y Espacio, y reflejar el estado mediante aria-pressed, aria-expanded, aria-checked, aria-selected y aria-valuenow.
• Ejecutar la página renderizada a través del inspector del árbol de accesibilidad del navegador (Chrome DevTools → Elements → Accessibility) y comprobar cada control: todos deberían anunciarse con nombre, función y estado.

Fallos habituales

• <div onclick="…"> con apariencia de botón — sin función, sin teclado, sin nombre. Los lectores de pantalla lo omiten. El control por voz no puede decir «pulsar Guardar».
• <div role="button"> sin tabindex="0", sin gestores de Enter/Espacio — parece accesible, pero no lo es.
• Botones de solo icono (<button><svg /></button>) sin aria-label, aria-labelledby ni texto visualmente oculto. Se anuncian como un simple «botón».
• Desplegables personalizados construidos con <div> y JavaScript sin role="combobox", aria-expanded, aria-controls, ni los roles de listbox y opción en el interior.
• Botones de alternancia (silencio, favorito, seguir) que cambian de estado visualmente pero nunca actualizan aria-pressed. Los usuarios con visión ven el cambio; los usuarios de lector de pantalla no perciben ninguna diferencia.
• Campos de formulario con una etiqueta visual adyacente pero sin enlace for/id ni <label> envolvente.
• Casillas de verificación personalizadas dibujadas con <svg> y un campo nativo oculto que nunca refleja :checked en la interfaz visible — los estados del lector de pantalla y los visuales se desincronzan.

Por qué es importante

Este es el criterio de conformidad más citado de la especificación. Prácticamente toda queja de «este sitio es inutilizable con un lector de pantalla» se reduce a un fallo en 4.1.2 — habitualmente un <div> que simula ser un botón, o un botón de icono sin nombre. Es también donde aparece el coste de construir widgets personalizados: todo elemento HTML nativo ya cumple 4.1.2; todo widget <div> artesanal tiene que ganárselo línea a línea. La auditoría de 4.1.2 más rápida consiste en navegar con el teclado por la página con un lector de pantalla activo y escuchar — cualquier elemento que se anuncie como «en blanco» o simplemente «botón» es un hallazgo.