WCAG 3.3.2: Etiquetas o instrucciones

Qué significa esta regla

El Criterio de Éxito 3.3.2 de las WCAG — Etiquetas o instrucciones (Nivel A) establece: «Se proporcionan etiquetas o instrucciones cuando el contenido requiere la introducción de datos por parte del usuario.» En términos prácticos, cada campo de formulario, control de entrada, área de texto y elemento select que pida a una persona que introduzca o seleccione información debe tener una etiqueta visible y significativa o un conjunto de instrucciones que deje claro el propósito del campo antes de que la persona interactúe con él.

El criterio es deliberadamente amplio en su alcance. Cubre cualquier mecanismo mediante el cual una persona proporciona datos: elementos <input> de todo tipo (text, email, password, number, date, checkbox, radio, file upload), elementos <textarea> para texto de varias líneas y menús desplegables <select>. También se aplica a controles interactivos personalizados construidos con roles ARIA como role='combobox' o role='listbox'.

Una etiqueta puede proporcionarse de varias maneras que satisfacen este criterio. La más sólida es un elemento <label> asociado de forma programática que esté presente visualmente y vinculado al control mediante un par coincidente for/id. De forma alternativa, se puede asociar un texto de etiqueta visible usando aria-labelledby apuntando a un elemento existente, o se pueden conectar instrucciones complementarias con aria-describedby. El requisito clave es que la etiqueta o instrucción esté proporcionada: debe existir en alguna forma que la persona pueda percibir. El texto de marcador de posición (placeholder) por sí solo no satisface este criterio porque desaparece en cuanto la persona empieza a escribir y no es transmitido de forma fiable por todas las tecnologías de apoyo como etiqueta persistente.

Un cumplimiento requiere que cada entrada tenga una etiqueta que sea visible (o como mínimo determinable de forma programática), esté presente antes de que la persona se comprometa a rellenar el campo y sea lo suficientemente descriptiva como para transmitir qué datos se esperan. Se produce un incumplimiento cuando un campo no tiene ninguna etiqueta, cuando la única etiqueta es un atributo placeholder, cuando la etiqueta está presente visualmente pero no está asociada de forma programática, o cuando las instrucciones sobre el formato requerido (por ejemplo, «Introduzca la fecha como DD/MM/YYYY») están completamente ausentes.

Las WCAG señalan una excepción limitada: cuando un formulario contiene un único campo evidente —como una barra de búsqueda de todo el sitio con un botón de envío claramente etiquetado justo al lado— el propio contexto puede proporcionar instrucciones suficientes. Sin embargo, esta excepción es muy limitada y no debe utilizarse como justificación general para omitir etiquetas en formularios con varios campos.

Por qué es importante

Las etiquetas de los formularios son la característica de accesibilidad más impactante para un amplio espectro de personas usuarias. Su ausencia crea barreras que pueden hacer imposible que muchas personas completen transacciones, se registren en servicios o contacten con una organización.

Para las personas ciegas y con baja visión que dependen de lectores de pantalla, un campo sin etiqueta se anuncia simplemente como «edit text» o «blank» sin contexto. La persona no tiene forma de saber si debe introducir su nombre, su dirección de correo electrónico o su número de tarjeta de crédito. Según la Organización Mundial de la Salud, aproximadamente 2.2 mil millones de personas en todo el mundo tienen algún tipo de discapacidad visual, y millones de ellas utilizan lectores de pantalla como su principal medio de interacción con la web.

Para las personas con discapacidades cognitivas y de aprendizaje, incluidas la dislexia, el TDAH y afecciones relacionadas con la memoria, el texto de marcador de posición es especialmente perjudicial. Como los marcadores de posición desaparecen al enfocar o introducir datos, una persona que se detiene a mitad de un formulario no tiene referencia de lo que se esperaba en un campo que ya ha empezado a rellenar. Esto la obliga a vaciar el campo para volver a leer la instrucción, lo que introduce confusión y frustración. Las etiquetas visibles y persistentes eliminan por completo esta carga cognitiva.

Para las personas con discapacidad motriz que navegan con teclado, dispositivos de conmutación o control por voz, las etiquetas cumplen una función adicional: proporcionan las palabras habladas que se utilizan para activar un campo mediante software de control por voz como Dragon NaturallySpeaking. Si el texto de la etiqueta visible no coincide con el nombre accesible programático, la orden por voz falla silenciosamente.

Considere un escenario concreto del mundo real: una persona con baja visión está solicitando una prestación pública en el portal de una institución pública turca. El formulario utiliza texto de marcador de posición en lugar de etiquetas. A medida que la persona amplía la pantalla al 200% para leerla, los marcadores de posición desaparecen antes de que puedan leerse. La persona rellena los campos adivinando y envía un formulario con errores, solo para recibir un mensaje de error genérico sin indicación de qué campos son incorrectos. Este escenario da lugar a la exclusión de un servicio público crítico, y es completamente evitable.

Más allá de la accesibilidad, los formularios etiquetados mejoran el SEO porque los rastreadores de motores de búsqueda pueden entender mejor el propósito del formulario, y mejoran la usabilidad para todas las personas, incluidas aquellas en dispositivos móviles donde los objetivos táctiles pequeños se benefician de áreas de etiqueta pulsables que amplían la zona de activación de la entrada asociada.

Reglas relacionadas de Axe-core

• label — Esta regla comprueba que cada elemento <input> (excepto aquellos con type='hidden', type='image', type='button', type='submit' y type='reset'), cada <textarea> y cada <select> tenga un nombre accesible. La regla marca los elementos que carecen de un <label> asociado, un atributo aria-label, una referencia aria-labelledby o un atributo title. Esta es la señal automatizada principal de infracciones del 3.3.2 en controles de formulario estándar.
• select-name — Esta regla se dirige específicamente a los elementos desplegables <select> y verifica que tengan un nombre accesible no vacío. A veces las personas desarrolladoras suponen que las opciones de un desplegable hacen que su propósito sea evidente por sí mismo, pero sin una etiqueta, las personas usuarias de lectores de pantalla solo escuchan el valor de la opción actualmente seleccionada —que puede ser un valor genérico por defecto como «Select one»— sin indicación de la categoría que están eligiendo. Axe marca los elementos <select> que carecen de cualquiera de los mecanismos estándar de etiquetado.
• textarea-label — Esta regla comprueba que los elementos <textarea> tengan un nombre accesible. Las áreas de texto de varias líneas se utilizan con frecuencia para comentarios, mensajes o entradas detalladas, pero a menudo se dejan sin etiquetar bajo la falsa suposición de que el contexto circundante es suficiente. Axe marca cualquier <textarea> que no pueda asociarse de forma programática con una etiqueta mediante <label for>, aria-label, aria-labelledby o title.

Es importante entender los límites de las pruebas automatizadas para este criterio. Axe-core puede detectar la ausencia de una etiqueta programática, pero no puede determinar si una etiqueta presente es realmente significativa o precisa. Un campo etiquetado como «Field 1» o una etiqueta que simplemente diga «*» superará las comprobaciones automatizadas mientras falla por completo a las personas usuarias. Siempre se requiere una revisión manual para confirmar que las etiquetas describen claramente la entrada esperada, que las instrucciones de formato están presentes cuando se necesitan (por ejemplo, formatos de fecha, requisitos de contraseña) y que los campos obligatorios están identificados, idealmente tanto visual como programáticamente.

Cómo hacer las pruebas

1. Escaneo automatizado con axe DevTools o Lighthouse: Abra la página que contiene el formulario en Chrome o Firefox. Ejecute la extensión de navegador axe DevTools y filtre los resultados por las reglas label, select-name y textarea-label. Anote cada elemento marcado. Ejecute Google Lighthouse (auditoría de Accesibilidad) como comprobación secundaria. Exporte o haga capturas de pantalla de todas las infracciones. Recuerde que un informe automatizado limpio no garantiza el cumplimiento; continúe con los pasos manuales.
2. Inspección visual: Sin utilizar ninguna tecnología de apoyo, revise cada campo de formulario de la página. Confirme que cada campo tenga una etiqueta visible y estática —no solo un marcador de posición— colocada claramente cerca del campo (normalmente encima o a la izquierda). Confirme que los requisitos de formato (por ejemplo, «La contraseña debe tener al menos 8 caracteres») se muestren antes o en el momento de la entrada, no solo después de un envío fallido. Confirme que los campos obligatorios se identifiquen por algo más que el color.
3. Prueba de navegación con teclado: Recorra cada campo del formulario con la tecla Tab. Asegúrese de que, a medida que cada campo recibe el foco, su propósito sea inmediatamente claro a partir de la etiqueta visible. No debe ser posible llegar a ningún campo con el teclado sin que una etiqueta adyacente y persistente sea visible en ese momento.
4. Prueba con lector de pantalla usando NVDA y Firefox: Abra el formulario con NVDA en ejecución. Pulse Tab para desplazarse por cada control interactivo. NVDA debe anunciar la etiqueta, el rol (por ejemplo, «edit», «combo box») y cualquier estado (por ejemplo, «required»). Si NVDA anuncia solo el rol y el estado sin etiqueta, el campo no cumple. Utilice el modo de formularios de NVDA (se activa automáticamente en elementos interactivos) para simular una navegación realista de la persona usuaria.
5. Prueba con lector de pantalla usando VoiceOver y Safari (macOS/iOS): Active VoiceOver (Command + F5 en Mac). Use Tab o deslice el dedo para navegar a cada campo del formulario. VoiceOver debe anunciar la etiqueta antes del rol. En iOS, toque cada campo y confirme que la etiqueta se lee en voz alta antes de que aparezca el teclado. Los campos que solo tienen marcador de posición normalmente se leerán como el marcador de posición al primer enfoque, pero quedarán en silencio una vez que se introduzca texto.
6. Prueba con lector de pantalla usando JAWS y Chrome: Abra JAWS y navegue por el formulario usando Tab. Use el modo de formularios de JAWS. Confirme que el nombre anunciado de cada campo corresponda exactamente a su etiqueta visible. Use Insert + F1 de JAWS (ayuda de campo) para comprobar si hay descripciones adicionales mediante aria-describedby.
7. Prueba de control por voz con Dragon NaturallySpeaking: Active Dragon e intente interactuar con cada campo pronunciando su etiqueta visible. Si la etiqueta hablada no coincide con el nombre accesible programático, el campo no responderá a la orden por voz, lo que indica una discrepancia que incumple tanto el 3.3.2 como criterios relacionados.

Cómo solucionarlo

Falta la etiqueta en una entrada de texto — Incorrecto

<!-- No se proporciona etiqueta; el marcador de posición es la única pista -->
<input type='text' name='email' placeholder='Email address' />

Falta la etiqueta en una entrada de texto — Correcto

<!-- <label> visible asociada mediante atributos for/id coincidentes.
     El marcador de posición puede seguir utilizándose como pista complementaria,
     pero la etiqueta es el identificador principal y persistente. -->
<label for='email'>Email address</label>
<input type='text' id='email' name='email' placeholder='[email protected]' />

Menú desplegable select sin etiqueta — Incorrecto

<!-- Sin etiqueta; los lectores de pantalla solo anunciarán el valor de la opción seleccionada -->
<select name='city'>
  <option value=''>Select a city</option>
  <option value='istanbul'>Istanbul</option>
  <option value='ankara'>Ankara</option>
</select>

Menú desplegable select sin etiqueta — Correcto

<!-- La etiqueta asociada de forma programática deja claro el propósito del campo
     antes de que la persona usuaria abra el desplegable. -->
<label for='city'>City</label>
<select id='city' name='city'>
  <option value=''>Select a city</option>
  <option value='istanbul'>Istanbul</option>
  <option value='ankara'>Ankara</option>
</select>

Textarea sin etiqueta — Incorrecto

<!-- El textarea no tiene etiqueta; el texto del párrafo circundante no está
     asociado de forma programática y no será leído por los lectores de pantalla
     como etiqueta del campo. -->
<p>Please describe your issue:</p>
<textarea name='message' rows='5'></textarea>

Textarea sin etiqueta — Correcto

<!-- Uso de aria-labelledby para asociar el encabezado visible existente
     con el textarea, o alternativamente envolverlo con un elemento <label>. -->
<label for='message'>Please describe your issue</label>
<textarea id='message' name='message' rows='5'></textarea>

Instrucciones de formato ausentes en un campo de fecha — Incorrecto

<!-- La etiqueta está presente pero no hay instrucciones sobre el formato de fecha esperado;
     las personas deben adivinar si introducir 01/06/2025 o 2025-06-01. -->
<label for='dob'>Date of birth</label>
<input type='text' id='dob' name='dob' />

Instrucciones de formato presentes en un campo de fecha — Correcto

<!-- La instrucción de formato es visible y está vinculada mediante aria-describedby
     para que los lectores de pantalla la anuncien cuando el campo reciba el foco. -->
<label for='dob'>Date of birth</label>
<span id='dob-hint'>Enter as DD/MM/YYYY, e.g. 15/06/1990</span>
<input type='text' id='dob' name='dob' aria-describedby='dob-hint' />

Errores comunes

• Usar placeholder como única etiqueta: El texto de marcador de posición desaparece al introducir datos, no se anuncia de forma fiable como etiqueta por todos los lectores de pantalla y falla a las personas con discapacidades cognitivas que necesitan texto de referencia persistente. Proporcione siempre un <label> visible además de cualquier marcador de posición.
• Colocar visualmente una etiqueta cerca de un campo sin asociación programática: Un <p> o <span> colocado visualmente encima de una entrada parece una etiqueta para las personas videntes, pero es ignorado por los lectores de pantalla. Use <label for='id'>, aria-labelledby o envuelva la entrada dentro de un elemento <label>.
• Usar aria-label con texto que no coincide con la etiqueta visible: Cuando el nombre accesible programático difiere del texto visible, las personas usuarias de control por voz no pueden activar el campo pronunciando lo que leen en pantalla, lo que incumple el criterio 2.5.3 (Etiqueta en el nombre) y además crea confusión para las personas usuarias de lectores de pantalla.
• Etiquetar un grupo de botones de opción pero omitir la leyenda del grupo: Los botones de opción individuales pueden estar etiquetados con su texto de opción, pero si la pregunta general (por ejemplo, «Método de pago») no se proporciona mediante un <fieldset> y un <legend>, las personas que navegan con teclado escuchan cada opción de forma aislada sin entender entre qué están eligiendo.
• Identificar campos obligatorios solo mediante color o un asterisco, sin explicación: Un asterisco (*) junto a una etiqueta no transmite nada a las personas usuarias de lectores de pantalla a menos que se explique su significado (por ejemplo, una nota al principio del formulario que indique «Los campos marcados con * son obligatorios») y los campos obligatorios también tengan el atributo required o aria-required='true'.
• Omitir las instrucciones de formato hasta después de un envío fallido: Mostrar las reglas de contraseña o los requisitos de formato de fecha solo en mensajes de error posteriores al envío obliga a las personas a cometer un error antes de poder saber qué se espera. Las instrucciones deben estar presentes antes o en el momento en que la persona interactúa con el campo.
• Ocultar etiquetas usando display:none o visibility:hidden: Estas propiedades CSS eliminan las etiquetas por completo del árbol de accesibilidad. Si es necesario ocultar visualmente una etiqueta (por ejemplo, para un diseño minimalista), use una clase CSS de ocultación visual que mantenga el elemento en el árbol de accesibilidad mientras lo desplaza fuera de la pantalla.
• Usar el atributo title como única etiqueta y asumir que es suficiente: Aunque axe-core puede no marcar una etiqueta basada solo en title, el atributo title aparece solo como un tooltip al pasar el ratón y es inaccesible para las personas que solo usan teclado y para las personas usuarias de dispositivos móviles. Debe utilizarse como descripción complementaria, no como etiqueta principal.
• Aplicar un único aria-label a un <div> contenedor y esperar que etiquete las entradas hijas: Las etiquetas ARIA en elementos contenedores no se heredan a sus controles de formulario hijos. Cada control interactivo debe estar etiquetado individualmente.
• No volver a asociar etiquetas después de actualizaciones dinámicas de contenido: Cuando los campos de formulario se insertan dinámicamente mediante JavaScript (por ejemplo, al añadir una fila de dirección), las nuevas entradas a menudo carecen de etiquetas asociadas porque la persona desarrolladora solo añadió el texto de la etiqueta visible como elemento hermano sin la vinculación adecuada for/id.

Relación con la normativa 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 web alineados con las WCAG 2.2. El Criterio de Éxito 3.3.2 de las WCAG — Etiquetas o instrucciones es un requisito de Nivel A, lo que significa que se sitúa en la base de la conformidad y se encuentra entre las disposiciones más estrictamente aplicadas en virtud de la circular.

La circular abarca una amplia gama de tipos de entidades, y los plazos de cumplimiento difieren según el sector. Las instituciones públicas, incluidos ministerios, municipios, organismos estatales y organizaciones financiadas con fondos públicos, deben lograr la conformidad total de Nivel A en el plazo de un año desde la publicación de la circular. Las entidades del sector privado incluidas en el ámbito deben cumplir en un plazo de dos años. Las entidades del sector privado explícitamente cubiertas incluyen plataformas de comercio electrónico, bancos e instituciones financieras, hospitales y proveedores de atención sanitaria 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).

Para todas estas entidades, la falta de etiquetado de los campos de formulario no es simplemente una deficiencia de usabilidad: constituye un incumplimiento normativo directo. Los formularios son omnipresentes en todos los servicios digitales cubiertos: la ciudadanía presenta solicitudes en portales gubernamentales, las personas pacientes reservan citas en sitios web de hospitales, las personas clientas completan compras en plataformas de comercio electrónico y el alumnado se matricula a través de portales escolares. Cada uno de estos recorridos depende de formularios, y cada campo sin etiqueta en esos formularios es una infracción demostrable del 3.3.2 de las WCAG que las personas auditoras pueden documentar e informar.

Las organizaciones sujetas a la circular deben tratar el cumplimiento del SC 3.3.2 como un requisito previo para cualquier proceso de auditoría o certificación de accesibilidad. Dado que se trata de un criterio de Nivel A, no puede ser objeto de exención ni aplazamiento; no se reconocen declaraciones de conformidad parcial que excluyan elementos de Nivel A. Las entidades que no puedan demostrar entradas etiquetadas en todos sus formularios de cara al público se arriesgan a hallazgos regulatorios, a la publicación de informes de incumplimiento y a daños reputacionales en un mercado donde la confianza digital está cada vez más vinculada al diseño inclusivo.

Desde un punto de vista práctico, lograr el cumplimiento del 3.3.2 es uno de los pasos de menor esfuerzo y mayor impacto que puede dar una organización. Asociar etiquetas con controles de formulario existentes suele requerir solo cambios menores en el HTML y no tiene efecto en el diseño visual cuando se implementa correctamente. Para las organizaciones que utilizan el SDK de superposición de Accsible, la detección automatizada de etiquetas faltantes puede sacar a la luz estas infracciones durante los escaneos rutinarios, proporcionando a los equipos de desarrollo orientación de remediación accionable antes de que lleguen los plazos regulatorios.