Fallo Común F68 de WCAG 2.1: Controles de interfaz sin nombre programático determinado

Jano Llorca Lis

La accesibilidad web garantiza que todos los usuarios, incluidos aquellos que utilizan tecnologías asistivas, puedan interactuar correctamente con formularios y controles de interfaz. WCAG 2.1 establece criterios clave para evitar problemas que afectan la usabilidad, como el fallo F68, que ocurre cuando los controles de formulario no tienen un nombre determinado mediante programación.

Según estudios de WebAIM, más del 60% de los formularios web presentan problemas de accesibilidad, siendo la ausencia de etiquetas correctamente asociadas una de las fallas más recurrentes.

Acerca de este fallo

El fallo F68 ocurre cuando un control de interfaz (como <input>, <textarea>, <select>) no tiene un nombre programático determinado, lo que impide que tecnologías asistivas como lectores de pantalla puedan identificar su propósito.

Esto incumple el Criterio de Éxito 4.1.2: Nombre, Rol y Valor, afectando principalmente a personas con discapacidad visual que dependen de etiquetas correctamente asociadas para comprender y completar formularios.

Escenarios comunes del fallo:

Formularios con etiquetas visibles pero sin asociación semántica.
Campos de búsqueda sin etiqueta accesible.
Botones de imagen sin texto alternativo.

Ejemplos

Ejemplo incorrecto 1: Formulario sin etiquetas asociadas

<form>
  Nombre:
  <input type="text" name="nombre">
  <br>
  Apellido:
  <input type="text" name="apellido">
</form>

🔴 Problema: Aunque visualmente los campos parecen etiquetados, no están programáticamente asociados, lo que impide que los lectores de pantalla los reconozcan.

Solución correcta: Asociación con `label for`

<form>
  <label for="nombre">Nombre:</label>
  <input type="text" id="nombre" name="nombre">
  <br>
  <label for="apellido">Apellido:</label>
  <input type="text" id="apellido" name="apellido">
</form>

✅ ¿Qué mejora?: Los lectores de pantalla pueden identificar correctamente el propósito de cada campo.

Ejemplo incorrecto 2: Campo de búsqueda sin nombre accesible

<input type="text" value="Escribe tu búsqueda aquí">
<input type="submit" value="Buscar">

🔴 Problema: El campo de texto no tiene un nombre accesible, dificultando su identificación por usuarios con discapacidad visual.

Solución correcta: Uso de `aria-label` o `label`

<input type="text" aria-label="Buscar en el sitio" value="Escribe tu búsqueda aquí">
<input type="submit" value="Buscar">

✅ ¿Qué mejora?: aria-label proporciona un nombre accesible sin necesidad de una etiqueta visual.

Ejemplo correcto: Solución ideal

<label for="buscar">Buscar en el sitio:</label>
<input type="text" id="buscar" name="buscar">
<button type="submit">Buscar</button>

✅ ¿Por qué es mejor?: Usa etiquetas semánticamente correctas y accesibles.

Errores comunes y cómo evitarlos

Errores frecuentes:

No asociar etiquetas correctamente con for e id.
Depender solo de title, ya que algunos lectores de pantalla lo ignoran.
Usar texto visible sin programar una asociación accesible.

Cómo evitar estos errores:

Siempre usa label for para asociar etiquetas a campos de formulario.
Si label no es viable, usa aria-label o aria-labelledby.
Verifica manualmente que los controles sean identificables con tecnologías asistivas.

Preguntas frecuentes sobre el fallo F68

¿Qué significa “nombre programático determinado”?
Es un nombre asignado a un control que las tecnologías asistivas pueden identificar y anunciar correctamente.

¿Cuál es la mejor forma de etiquetar un campo de formulario?
Usar el elemento <label> correctamente asociado con for.

¿Puedo usar solo title en lugar de label?
No se recomienda, ya que algunos lectores de pantalla no lo interpretan de manera consistente.

¿Qué pasa con los botones de imagen?
Deben incluir un atributo alt con una descripción clara.

¿El problema F68 afecta al SEO?
Sí, la accesibilidad mejora la experiencia del usuario y puede impactar en el posicionamiento en buscadores.

¿Cómo puedo comprobar si mi sitio tiene este problema?
Usa herramientas de validación de accesibilidad como Axe o WAVE.

Recursos relacionados

Pruebas y validación

Procedimiento

Para todos los elementos <input>, <textarea>, y <select> en la página web (excepto aquellos con los tipos hidden, submit, reset o button), asegúrese de que cada uno tenga un nombre accesible determinado programáticamente mediante una de las siguientes formas:

La etiqueta de texto está asociada programáticamente al elemento de control mediante el atributo aria-labelledby, donde cada id especificado en aria-labelledby coincide con el id del elemento de la etiqueta de texto correspondiente.
El elemento de control tiene un nombre definido a través del atributo aria-label.
La etiqueta de texto está contenida dentro de un elemento <label> correctamente asociado al control mediante el atributo for, cuyo valor coincide con el id del elemento de entrada.
El elemento de control está contenido dentro de un elemento <label>, que a su vez incluye el texto de la etiqueta.
Si el control es un <input> de tipo image, el atributo alt debe proporcionar una etiqueta de texto descriptiva.
También puede determinarse programáticamente mediante el valor del atributo title.

Resultados esperados

✅ Si todos los controles tienen nombres accesibles y correctamente asociados, entonces el contenido cumple con WCAG 2.1.
❌ Si un control carece de nombre accesible, el contenido falla el criterio 4.1.2 y debe corregirse.

Asegurar que todos los controles de interfaz tengan un nombre programático claro mejora la accesibilidad y la experiencia del usuario. Si quieres que tu sitio cumpla con WCAG 2.1 y sea más inclusivo, contáctanos ahora y optimiza tu accesibilidad web! 🚀

¿Tienes dudas? Solicita una consultoría inicial gratuita

Evaluamos tu sitio web para identificar barreras que dificultan el acceso a personas con discapacidad. Te entregamos un informe con errores detectados y soluciones para que tu web sea usable por todos.