Etiquetas, agrupación e instrucciones

Un campo de formulario sin etiqueta es, para un lector de pantalla, una casilla vacía de la que solo se conoce el tipo: «cuadro de edición». La persona no sabe si debe escribir su nombre, su DNI o su código postal. El criterio 3.3.2 Etiquetas o instrucciones (A) exige que haya etiquetas o instrucciones cuando el contenido requiere una entrada del usuario, y 1.3.1 Información y relaciones exige que la relación entre etiqueta y campo exista en el código, no solo en la pantalla. En esta lección veremos cómo conseguirlo con HTML nativo y cuándo hace falta algo más.

La etiqueta: label y for

La forma correcta de etiquetar un campo es el elemento <label> asociado por su atributo for al id del control. Esa asociación hace tres cosas: da nombre accesible al campo, amplía el área de pulsación (hacer clic en el texto enfoca el campo, algo valiosísimo en móvil y para personas con temblor) y permite a las herramientas de control por voz decir «pulsar Correo electrónico».

<p>Correo electrónico</p>
<input type="email" name="email">

<label for="email">Correo electrónico</label>
<input type="email" id="email" name="email" autocomplete="email">

Reglas que conviene grabarse:

• Cada id debe ser único en la página. Un id duplicado hace que el for apunte al primero y el segundo campo quede sin nombre.
• El placeholder no es una etiqueta: desaparece al escribir, suele tener poco contraste y no todos los lectores lo anuncian. Puede complementar («Ej.: 30001») pero no sustituir.
• Las etiquetas deben ser visibles de forma permanente. Si el diseño no deja sitio, usa aria-label solo como último recurso (campos de búsqueda con un botón «Buscar» al lado son el caso típico) y recuerda que el nombre debe coincidir con lo que la persona ve.
• Marca los campos obligatorios en la etiqueta visible («Nombre (obligatorio)») o con un asterisco explicado al principio del formulario, y añade el atributo required para que el estado sea programático.

Agrupar: fieldset y legend

Cuando varios controles comparten una misma pregunta (botones de radio, casillas de verificación, los tres campos de una fecha o de un teléfono), la pregunta no puede ser la etiqueta de cada uno. Se usa <fieldset> para agrupar y <legend> para la pregunta común. El lector anuncia la leyenda al entrar en el grupo y así cada opción tiene sentido.

<fieldset>
  <legend>¿Cómo quieres recibir la notificación?</legend>
  <input type="radio" id="n-email" name="notif" value="email">
  <label for="n-email">Por correo electrónico</label>
  <input type="radio" id="n-sms" name="notif" value="sms">
  <label for="n-sms">Por SMS</label>
  <input type="radio" id="n-postal" name="notif" value="postal">
  <label for="n-postal">Por correo postal</label>
</fieldset>

Sin el fieldset, la persona que llega con Tab al primer botón de radio oye «Por correo electrónico, botón de opción, 1 de 3» y no sabe de qué pregunta se trata. También conviene agrupar las secciones largas de un formulario (datos personales, dirección, datos bancarios) con fieldset o con encabezados, para que se pueda saltar entre ellas. Si no puedes usar fieldset por motivos de maquetación, el equivalente ARIA es role="group" con aria-labelledby apuntando al texto de la pregunta; para botones de radio personalizados, role="radiogroup".

Instrucciones y ayudas: aria-describedby

Muchos campos necesitan algo más que un nombre: el formato esperado («DD/MM/AAAA»), una restricción («máximo 500 caracteres»), una explicación de por qué se pide el dato. Esa información debe estar visible antes de que la persona empiece a escribir y asociada al campo con aria-describedby, que la convierte en su descripción accesible. El lector la anuncia después del nombre y del tipo, normalmente tras una breve pausa.

<label for="iban">IBAN de la cuenta</label>
<p id="iban-ayuda">24 caracteres, empieza por ES. Puedes escribirlo con o sin espacios.</p>
<input type="text" id="iban" name="iban" aria-describedby="iban-ayuda"
       autocomplete="off" inputmode="text" spellcheck="false">

aria-describedby admite varios id separados por espacios, lo que permite encadenar la ayuda y, cuando aparezca, el mensaje de error. Las instrucciones generales del formulario («Los campos con asterisco son obligatorios», «Tienes 20 minutos para completar la solicitud») van al principio, antes del primer campo, para que se lean antes de empezar.

Tipos de entrada y teclados

Elegir el type correcto (email, tel, number, url, date) mejora la accesibilidad de forma gratuita: en móvil aparece el teclado adecuado, el navegador valida el formato y el lector anuncia el tipo. Dos cautelas: type="number" no sirve para identificadores (DNI, códigos postales con cero inicial, tarjetas), porque descarta ceros y permite flechas que cambian el valor por accidente; usa type="text" con inputmode="numeric". Y type="date" tiene una accesibilidad desigual entre navegadores; lo trataremos en la lección sobre autenticación, CAPTCHA, selects y selectores de fecha.

Cómo comprobarlo

• Pulsa en el texto de cada etiqueta: el foco debe pasar al campo. Si no pasa, no está asociada.
• Con el lector de pantalla, recorre el formulario con Tab: cada campo debe anunciar nombre, tipo, si es obligatorio y su descripción.
• Abre la lista de campos de formulario (en NVDA, Insert+F7, pestaña de campos): los nombres deben entenderse sin contexto.
• Con axe o WAVE, revisa «campo sin etiqueta», «id duplicado» y «fieldset sin legend».

Resumen

• Cada campo necesita un <label> visible asociado con for/id; el placeholder no es una etiqueta.
• Los grupos de opciones relacionadas se envuelven en <fieldset> con <legend>; nunca ocultes la leyenda.
• Formato, restricciones y ayudas se muestran antes del campo y se asocian con aria-describedby.
• Indica la obligatoriedad de forma visible y con required.
• Elige bien el type e inputmode: el teclado móvil y la validación nativa son accesibilidad gratis.