Fallo Común F86 de WCAG 2.1: No proporcionar nombres en campos de formularios de varias partes

Jano Llorca Lis

La accesibilidad web garantiza que todas las personas puedan interactuar correctamente con los formularios en línea, incluidas aquellas que utilizan tecnologías de asistencia. Un error frecuente es no proporcionar nombres programáticos a cada parte de un campo de formulario dividido, como los números de teléfono en formularios.

Este problema incumple el Criterio de Conformidad 4.1.2 de WCAG 2.1 (Nombre, Función, Valor), lo que puede impedir que los usuarios con lectores de pantalla comprendan el propósito de cada campo y completen el formulario de manera efectiva.

En este artículo, analizaremos el Fallo F86, su impacto en la accesibilidad y las mejores prácticas para solucionarlo.

Acerca de este fallo

El Fallo F86 ocurre cuando un formulario incluye un campo de entrada dividido en varias partes (por ejemplo, un número de teléfono con código de área, prefijo y número) sin proporcionar un nombre accesible para cada subcampo.

El criterio 4.1.2 de WCAG 2.1 establece que cada campo de un formulario debe tener un nombre programáticamente determinable, asegurando que las tecnologías de asistencia puedan identificar su función correctamente.

Escenarios comunes donde ocurre este fallo

Formularios que solicitan un número de teléfono en partes (código de área, prefijo, número) pero solo etiquetan el primer campo.
Formularios que dividen fechas (día, mes y año) sin etiquetas individuales para cada campo.
Formularios que dependen solo del diseño visual para indicar la relación entre los campos, sin asociación programática.

Ejemplos

Ejemplo incorrecto 1: Campo de teléfono sin nombres en los subcampos

<label for=»telefono»>Número de teléfono:</label>
(<input type=»text» size=»3″>) <input type=»text» size=»3″>-<input type=»text» size=»4″>

🔴 Problema: En este caso, la etiqueta <label> solo está asociada al primer campo, dejando los otros dos sin identificación accesible. Los lectores de pantalla podrían interpretar los subcampos como simples caracteres de puntuación, sin contexto claro.

Solución correcta: Uso de etiquetas `<label>` individuales y agrupación con `<fieldset>`

✅ ¿Qué mejora?:

Agrupación con <fieldset> y <legend>: Permite que los usuarios comprendan que los campos están relacionados.
Etiquetas <label> individuales: Garantizan que cada campo sea identificado correctamente por los lectores de pantalla.

Ejemplo incorrecto 2: Etiqueta sin asociación programática

<p>Número de teléfono: (<input type=»text» size=»3″>) <input type=»text» size=»3″>-<input type=»text» size=»4″></p>

🔴 Problema: Aquí, la etiqueta del número de teléfono es un <p>, lo que significa que no está asociada de forma programática con los campos de entrada. Como resultado, los lectores de pantalla no pueden identificar que estos campos pertenecen a un número de teléfono, interpretándolos como campos independientes sin propósito claro.

Solución correcta: Uso de `aria-labelledby` para asociar los subcampos

<label id=»phone-label»>Número de teléfono:</label>
<input type=»text» size=»3″ aria-labelledby=»phone-label area»>
<input type=»text» size=»3″ aria-labelledby=»phone-label prefijo»>
<input type=»text» size=»4″ aria-labelledby=»phone-label numero»>

✅ ¿Qué mejora?: aria-labelledby vincula cada subcampo con la etiqueta principal, asegurando que las tecnologías de asistencia comprendan su función.

Ejemplo correcto: Solución ideal con `aria-labelledby` y agrupación con `<fieldset>`

<fieldset>
<legend id=»phone-label»>Número de teléfono</legend>
<label for=»area»>Código de área:</label>
<input id=»area» type=»text» size=»3″ aria-labelledby=»phone-label area»>

<label for=»prefijo»>Prefijo:</label>
<input id=»prefijo» type=»text» size=»3″ aria-labelledby=»phone-label prefijo»>

<label for=»numero»>Número:</label>
<input id=»numero» type=»text» size=»4″ aria-labelledby=»phone-label numero»>
</fieldset>

✅ ¿Qué mejora?:

Uso de <fieldset> y <legend> para una agrupación clara.
Cada campo tiene su <label> y se vincula con aria-labelledby para mayor accesibilidad.

Errores comunes y cómo evitarlos

Errores frecuentes

Usar una sola etiqueta <label> para un grupo de campos sin asignar nombres individuales.
Omitir el uso de aria-labelledby o <label> en campos compuestos.
Confiar únicamente en el diseño visual para indicar la relación entre los campos.

Cómo evitar estos errores

Usa fieldset y legend para agrupar subcampos relacionados.
Proporciona etiquetas <label> individuales para cada campo.
Usa aria-labelledby cuando los campos sean parte de un conjunto mayor.

Preguntas frecuentes sobre el fallo F86

¿Por qué es importante etiquetar cada parte de un campo de formulario compuesto?

Porque sin etiquetas accesibles, los usuarios de lectores de pantalla no pueden comprender correctamente la función de cada campo ni su relación con los demás.

¿Puedo usar solo placeholder en los campos en lugar de label?

No. Los placeholder no son sustitutos de las etiquetas <label>, ya que desaparecen al escribir y no son leídos de manera consistente por los lectores de pantalla.

¿Cuál es la mejor forma de agrupar subcampos en un formulario?

Usar <fieldset> y <legend> para proporcionar contexto y relación entre los campos.

¿title en los inputs es una alternativa a <label>?

No. Aunque title puede proporcionar información adicional, no sustituye a un <label> y no es leído consistentemente por las tecnologías de asistencia.

¿Cómo puedo verificar si mis formularios cumplen con accesibilidad?

Puedes usar herramientas como WAVE, axe DevTools o Lighthouse para analizar la accesibilidad de los formularios en tu sitio web.

Recursos relacionados

Pruebas y validación

Procedimiento

Verifica que cada subcampo tenga un nombre accesible usando <label>, aria-labelledby, o aria-label.
Comprueba que los grupos de campos relacionados estén dentro de un <fieldset> con un <legend> adecuado.
Usa un lector de pantalla (NVDA, JAWS o VoiceOver) para comprobar si los subcampos tienen nombres claros.
Usa herramientas como axe DevTools, WAVE, o Lighthouse para detectar problemas de accesibilidad.

Resultados esperados

✅ Si todas las pruebas son exitosas:

Cada subcampo tiene un nombre accesible programáticamente determinado.
Los campos están organizados de manera lógica con <fieldset> y <legend>.
El lector de pantalla reconoce correctamente cada parte del formulario.

❌ Si alguna prueba falla:

Alguno de los subcampos no tiene un label o aria-labelledby.
Los campos no están agrupados correctamente, dificultando su comprensión.
El lector de pantalla no describe correctamente la relación entre los campos.

⚡ Si tu formulario no pasa estas pruebas, es necesario corregirlo para garantizar que sea accesible para todos los usuarios.

Los formularios de varias partes pueden ser confusos si no se implementan correctamente. El Fallo F86 afecta a los usuarios con tecnologías de asistencia, impidiéndoles completar los formularios de manera efectiva.

👉 Solución clave: Etiquetar cada subcampo correctamente con <label> y aria-labelledby, y agruparlos con <fieldset> y <legend>.

🔍 Haz la prueba ahora: Usa herramientas de validación y lectores de pantalla para asegurarte de que tu formulario cumple con WCAG 2.1.

🚀 ¡Haz que tu web sea más accesible hoy! 🚀

¿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.