Acerca de esta regla de accesibilidad
Cada elemento de formulario — como campos de texto, casillas de verificación, botones de opción y menús desplegables — debe tener una etiqueta asociada programáticamente para que las tecnologías de asistencia puedan identificar y anunciar el propósito de cada campo. Sin estas etiquetas, los usuarios de lectores de pantalla no pueden determinar qué información se espera, y los usuarios con discapacidades motoras pierden el beneficio de un área de clic más grande que proporciona un <label> correctamente asociado.
Por qué esto es importante
Cuando un elemento de formulario carece de una etiqueta programática, los lectores de pantalla lo anuncian de forma genérica (por ejemplo, “editar texto” o “casilla de verificación”) o se saltan completamente el contexto significativo. Esto deja a los usuarios ciegos, con baja visión y sordociegos sin poder entender qué datos espera un campo o qué opción representa una casilla de verificación. Deben adivinar basándose en el contenido circundante, lo cual no es confiable y es propenso a errores.
Las etiquetas también benefician a los usuarios con discapacidades motoras. Cuando un elemento <label> está correctamente asociado con una entrada, hacer clic en el texto de la etiqueta activa o enfoca el control asociado. Esto crea un objetivo de clic más grande, lo cual es especialmente útil para personas con destreza limitada.
Los usuarios videntes a menudo confían en la proximidad visual para inferir el propósito de un campo, pero las tecnologías de asistencia necesitan una relación programática explícita entre el texto de la etiqueta y el control del formulario para transmitir la misma información.
Estándares relevantes
Esta regla se corresponde con el Criterio de Éxito 4.1.2 de WCAG: Nombre, Función, Valor (Nivel A), que requiere que todos los componentes de la interfaz de usuario tengan un nombre accesible que pueda ser determinado programáticamente. Se aplica a WCAG 2.0, 2.1 y 2.2, así como a la Sección 508 (§1194.22(n)), EN 301 549 (9.4.1.2) y las pautas de Trusted Tester. El impacto en el usuario se considera crítico.
Cómo solucionarlo
Hay varias formas de asociar una etiqueta con un elemento de formulario. Usa el enfoque que mejor se adapte a tu situación, listados aquí desde el más recomendado hasta el menos recomendado.
1. <label> explícito con for e id (Recomendado)
El método más común y confiable es usar un elemento <label> cuyo atributo for coincida con el id del control del formulario. Esto crea una asociación programática inequívoca.
2. <label> implícito (Envolviendo)
Envuelve el control del formulario dentro de un elemento <label>. La asociación está implícita por la relación padre-hijo.
3. aria-label
Usa aria-label cuando el propósito del campo se transmita visualmente a través de un icono o diseño en lugar de texto visible. Esto crea una etiqueta invisible que solo anuncian los lectores de pantalla.
4. aria-labelledby
Usa aria-labelledby cuando el texto de la etiqueta ya existe en otra parte de la página, o cuando necesites combinar múltiples fragmentos de texto en una sola etiqueta. Referencia uno o más valores de id de elementos.
5. placeholder (No recomendado)
Un atributo placeholder técnicamente puede proporcionar un nombre accesible, pero desaparece una vez que el usuario comienza a escribir, eliminando la etiqueta visible. Esto crea problemas de usabilidad para todos y no es un enfoque recomendado.
Consejos generales
-
Asegúrate de que todos los valores de
idsean únicos en la página. - Haz que el texto de la etiqueta sea descriptivo y significativo cuando se lea en voz alta de forma aislada.
-
Recuerda que los botones (
<button>,<input type="submit">, etc.) se etiquetan a sí mismos a través de su contenido de texto o atributovaluey no necesitan un<label>separado. -
Las entradas ocultas (
<input type="hidden">) no necesitan etiquetas ya que no se presentan a los usuarios.
Ejemplos
Incorrecto: Entrada sin etiqueta
<div>Nombre:</div>
<input type="text" id="firstname">
El texto del <div> está visualmente cerca de la entrada, pero no hay relación programática. Un lector de pantalla anunciará solo “editar texto” sin contexto.
Correcto: Etiqueta explícita con for e id
<label for="firstname">Nombre:</label>
<input type="text" id="firstname">Correcto: Etiqueta implícita envolviendo
<label>
Nombre:
<input type="text">
</label>
Correcto: aria-label para campos implícitos visualmente
<input type="text" aria-label="Buscar">
<button type="submit">🔍</button>
Correcto: aria-labelledby referenciando texto existente
<div id="temp-label">Temperatura</div>
<div id="high-label">Máxima:</div>
<div id="low-label">Mínima:</div>
<input type="text" aria-labelledby="temp-label high-label">
<input type="text" aria-labelledby="temp-label low-label">La primera entrada se anuncia como “Temperatura Máxima:” y la segunda como “Temperatura Mínima:”, combinando el texto referenciado en orden.
Incorrecto: Depender solo de placeholder
<input type="text" placeholder="Introduce tu email">Aunque esto técnicamente proporciona un nombre accesible, la pista visible desaparece cuando el usuario comienza a escribir, haciendo difícil verificar el propósito del campo. Siempre prefiere una etiqueta visible persistente.
Correcto: Etiqueta visible con placeholder complementario
<label for="email">Dirección de correo electrónico</label>
<input type="text" id="email" placeholder="nombre@ejemplo.com">Incorrecto: Casilla de verificación sin etiqueta
<input type="checkbox" id="terms">
Acepto los términos y condicionesEl texto está adyacente pero no asociado con la casilla de verificación.
Correcto: Casilla de verificación etiquetada
<input type="checkbox" id="terms">
<label for="terms">Acepto los términos y condiciones</label>Learn more:
Ayúdanos a mejorar nuestras guías
Detecta problemas de accesibilidad automáticamente
Rocket Validator escanea miles de páginas con Axe Core y el W3C Validator, encontrando problemas de accesibilidad en todo tu sitio web.