Addaw, ir a inicio Donar

Técnica Técnicas generales WCAG 2.2

G131Proporcionar etiquetas descriptivas

En resumen

Esta técnica pide que la etiqueta de cada control interactivo (campo, botón, control de mapa) deje claro para qué sirve, incluyendo si procede la indicación de obligatorio o el atajo de teclado. Combinada con las técnicas de asociación de etiquetas de cada tecnología, permite que las tecnologías de asistencia anuncien el propósito del control. Beneficia a todos y en especial a quien usa lector de pantalla.

Ejemplo práctico

Aparece en formularios largos de administración electrónica, reservas o compras, donde varios campos comparten una etiqueta corta («Fecha», «Número», «Teléfono») que solo se entiende viendo el diseño completo.

Así no: Etiquetas ambiguas en un formulario de cita previa

Todos los campos tienen label asociado, pero dos se llaman «Fecha» y otro «Número», sin decir qué fecha ni qué número se pide, ni cuáles son obligatorios. El lector de pantalla anuncia «Fecha» dos veces y en la lista de campos de formulario no hay forma de distinguirlos.

<form action="#">
  <h2>Datos del solicitante</h2>
  <p><label for="doc">Número</label><br>
    <input id="doc" type="text" required></p>
  <p><label for="nac">Fecha</label><br>
    <input id="nac" type="date" autocomplete="bday"></p>
  <p><label for="cita">Fecha</label><br>
    <input id="cita" type="date" required></p>
  <p><label for="tel">Teléfono</label><br>
    <input id="tel" type="tel" autocomplete="tel"></p>
  <button type="submit">Continuar</button>
</form>
Captura de pantalla del ejemplo incorrecto: Etiquetas ambiguas en un formulario de cita previa
Así se ve el ejemplo incorrecto.

La demostración contiene, a propósito, el error de accesibilidad que se explica.

Así sí: Etiquetas que dicen qué dato se pide

Solo cambia el texto de las etiquetas: cada una identifica el dato concreto y las de los campos obligatorios lo indican con «(obligatorio)». Leídas fuera de contexto, en la lista de campos del lector, siguen siendo comprensibles.

<form action="#">
  <h2>Datos del solicitante</h2>
  <p><label for="doc">Número de DNI o NIE (obligatorio)</label><br>
    <input id="doc" type="text" required></p>
  <p><label for="nac">Fecha de nacimiento</label><br>
    <input id="nac" type="date" autocomplete="bday"></p>
  <p><label for="cita">Fecha preferida para la cita (obligatorio)</label><br>
    <input id="cita" type="date" required></p>
  <p><label for="tel">Teléfono de contacto</label><br>
    <input id="tel" type="tel" autocomplete="tel"></p>
  <button type="submit">Continuar</button>
</form>

Pruébelo aquí:

Cómo comprobarlo

Lector de pantalla (NVDA o VoiceOver)

  1. Recorrer el formulario con Tab y escuchar el nombre de cada campo sin mirar la pantalla.
  2. Abrir la lista de elementos (Insert + F7 en NVDA, opción Campos de formulario; rotor con VO + U en VoiceOver) y comprobar que cada campo se distingue de los demás solo por su nombre.

Debería anunciar: «Teléfono de contacto, editar»

Herramientas del navegador

  1. Abrir las herramientas de desarrollo (F12), seleccionar cada input y revisar en el panel Accesibilidad el campo Nombre (Name).
  2. Comprobar que no hay dos controles con el mismo nombre que pidan datos diferentes y que el nombre coincide con lo que realmente se pide.

Validación automática

  1. axe DevTools y WAVE detectan los campos sin etiqueta (regla label de axe), pero dan por buena cualquier etiqueta asociada, aunque sea «Fecha» o «Campo 1».
  2. Que la etiqueta describa el propósito del control (criterio 2.4.6) se evalúa siempre a mano.

Errores frecuentes en auditorías

  • Etiquetas genéricas repetidas («Fecha», «Número», «Dirección») en campos que piden datos distintos.
  • Campos obligatorios marcados solo con un asterisco sin explicar su significado, o solo con color rojo.
  • Etiquetas que no coinciden con lo que se pide, como «Nombre» en un campo donde se espera nombre y apellidos.
  • Botones con textos que no dicen qué hacen («Aceptar», «Enviar») en páginas con varios formularios.

Técnica completa: traducción al español del texto del W3C

Aplicabilidad

Todas las tecnologías.

Descripción

El objetivo de esta técnica es garantizar que la etiqueta de cualquier componente interactivo del contenido web deje claro el propósito del componente. Utilizar las técnicas específicas de cada tecnología apropiadas para asociar etiquetas a los controles interactivos permite que la tecnología de asistencia reconozca la etiqueta y la presente al usuario, lo que le permite identificar el propósito del control. La etiqueta también puede utilizarse para incluir un texto o un símbolo textual que indique que la entrada es obligatoria.

Ejemplos

Mapas en línea con controles para acercar y alejar

Una aplicación web presenta mapas de una ciudad. Los usuarios pueden «acercar» para ver una parte del mapa con más detalle y «alejar» para que muestre una parte mayor de la ciudad. Los controles pueden manejarse tanto con el ratón como con el teclado. Los controles están etiquetados como «Zoom in (Ctrl + Shift + L)» («Acercar (Ctrl + Mayús + L)») y «Zoom out (Ctrl + Shift + R)» («Alejar (Ctrl + Mayús + R)»).

Un formulario que pide el nombre del usuario

Un formulario pide el nombre del usuario. Consta de dos campos de entrada para pedir el nombre y los apellidos. El primer campo está etiquetado como «First name» («Nombre») y el segundo como «Last name» («Apellidos»).

Un formulario con campos obligatorios

Un formulario de compra incluye varios campos que son obligatorios. Además de identificar el campo, la etiqueta de cada campo obligatorio incluye la palabra «required» («obligatorio») entre paréntesis.

Pruebas

Procedimiento

Para cada componente de la interfaz que tenga una etiqueta:

  1. Identificar el propósito del componente de la interfaz.
  2. Comprobar que cada etiqueta deja claro el propósito del componente.

Resultados esperados

  • La comprobación n.º 2 es verdadera.

Cómo lo comprobamos en ADDAW

En las auditorías de accesibilidad de ADDAW revisamos cada criterio de conformidad siguiendo este catálogo de técnicas: comprobamos si la web aplica una técnica suficiente y documentamos cada fallo común con capturas y el código afectado, para que el equipo de desarrollo sepa exactamente qué corregir. Los informes siguen la metodología del Observatorio de Accesibilidad y la norma UNE-EN 301 549.

Solicitar una auditoría

Fuente y licencia

Traducción al español, no oficial, realizada por ADDAW a partir de la técnica G131 del documento «Techniques for WCAG 2.2» del W3C (versión del repositorio público del W3C a 22/10/2026). Copyright © W3C® (MIT, ERCIM, Keio, Beihang). Se publica conforme a la licencia de documentos del W3C. El texto normativo de referencia es el original en inglés; si detecta un error en la traducción, escríbanos.

Financiado por la unión europea Gobierno de españa red.es Plan de recuperación transformación y resilencia kit digital