La accesibilidad web garantiza que todos los usuarios, incluidas las personas con discapacidades visuales o cognitivas, puedan completar formularios sin confusión. Un problema común es el uso de campos de entrada para números de teléfono con un formato visual reconocible, pero sin una etiqueta de texto clara.
Este fallo, identificado como F82 en las WCAG 2.1, incumple el Criterio de Conformidad 3.3.2: Etiquetas o instrucciones, dificultando la comprensión de los campos para los usuarios que dependen de lectores de pantalla o tienen dificultades cognitivas.
💡 Dato relevante: En un estudio de accesibilidad, el 35% de los usuarios con discapacidades informaron dificultades para completar formularios en línea debido a la falta de etiquetas claras.
Acerca de este fallo
El error F82 ocurre cuando un conjunto de campos de entrada de un número de teléfono se formatea visualmente para indicar su estructura, pero no tiene una etiqueta de texto clara que indique su propósito.
Escenarios comunes del fallo:
- Formularios con tres campos de entrada (código de área, prefijo y extensión) sin una etiqueta de texto.
- Uso de paréntesis y guiones como indicación visual sin explicaciones textuales.
- Falta de instrucciones sobre cómo ingresar los datos correctamente.
Ejemplos
Ejemplo incorrecto 1: Campos sin etiqueta de texto
<form>
(<input type=»text» size=»3″>)
<input type=»text» size=»3″> –
<input type=»text» size=»4″>
</form>

🔴 Problema:
- No hay una etiqueta de texto clara indicando que estos campos corresponden a un número de teléfono.
- Los lectores de pantalla solo leen «(«, «)», y «-«, sin contexto adicional.
Solución correcta: Uso de una etiqueta de texto
<form>
<label for=»telefono»>Número de teléfono:</label>
(<input type=»text» id=»telefono-area» size=»3″>)
<input type=»text» id=»telefono-prefijo» size=»3″> –
<input type=»text» id=»telefono-linea» size=»4″>
</form>

✅ ¿Qué mejora?:
- Se añade un label que identifica el grupo de campos.
- Permite que los lectores de pantalla identifiquen correctamente el propósito de los campos.
Ejemplo incorrecto 2: Falta de instrucciones de formato
<label for=»telefono»>Teléfono:</label>
<input type=»text» id=»telefono»>

🔴 Problema: No se indica cómo debe introducirse el número (con o sin guiones, espacios, etc.).
Solución correcta: Uso de instrucciones claras
<label for=»telefono»>Número de teléfono (formato: XXX-XXX-XXXX):</label>
<input type=»text» id=»telefono» placeholder=»Ej: 123-456-7890″>

✅ ¿Qué mejora?:
- Se proporciona una instrucción explícita sobre el formato requerido.
- El placeholder ofrece un ejemplo visual para orientar a los usuarios.
Ejemplo correcto: Solución ideal
<fieldset>
<legend>Número de teléfono</legend>
<label for=»telefono-area»>Código de área:</label>
<input type=»text» id=»telefono-area» size=»3″>
<label for=»telefono-prefijo»>Prefijo:</label>
<input type=»text» id=»telefono-prefijo» size=»3″>
<label for=»telefono-linea»>Número:</label>
<input type=»text» id=»telefono-linea» size=»4″>
</fieldset>

✅ ¿Qué mejora?:
- Uso de fieldset y legend para agrupar campos relacionados.
- Cada campo tiene su propia etiqueta, facilitando su comprensión y uso.
- Compatible con lectores de pantalla y usuarios con dificultades cognitivas.
Errores comunes y cómo evitarlos
Errores frecuentes:
- Usar solo el formato visual para indicar que los campos corresponden a un número de teléfono.
- No proporcionar una etiqueta de texto para identificar el grupo de campos.
- No incluir instrucciones sobre el formato esperado.
Cómo evitar estos errores:
- Siempre usa etiquetas de texto claras para identificar el conjunto de campos.
- Proporciona instrucciones sobre el formato del número de teléfono.
- Considera el uso de fieldset y legend para agrupar campos relacionados.
Preguntas frecuentes sobre el fallo F82
¿Puedo usar solo el placeholder como indicación del formato?
No, los placeholders desaparecen cuando el usuario comienza a escribir y no son accesibles para algunos lectores de pantalla.
¿Es obligatorio usar fieldset y legend?
No es obligatorio, pero es una mejor práctica cuando hay varios campos relacionados.
¿Qué pasa si uso íconos en lugar de etiquetas?
Los íconos pueden complementar, pero no reemplazar etiquetas de texto, ya que no son accesibles para todos los usuarios.
¿Cómo puedo probar si mi formulario cumple con WCAG?
Puedes usar herramientas como WAVE, axe DevTools o el inspector de accesibilidad de Chrome para verificar etiquetas y estructura.
¿Es necesario indicar el formato si solo hay un campo de entrada?
Sí, es recomendable proporcionar instrucciones sobre el formato esperado.
¿Los lectores de pantalla pueden leer los campos sin etiquetas?
No correctamente. Si solo hay un formato visual sin etiquetas, los usuarios de lectores de pantalla no podrán identificar los campos de manera adecuada.
Recursos relacionados
- Guía oficial WCAG 2.1 para el fallo común F82: Incumplimiento del Criterio de Conformidad 3.3.2 al formatear visualmente un conjunto de campos de números de teléfono pero sin incluir una etiqueta de texto
- Comprender el criterio de éxito 3.3.2: Etiquetas o Instrucciones
- H71: Proporcionar una descripción para grupos de controles de formulario que utilizan elementos de leyenda y de conjunto de campos
Pruebas y validación
Procedimiento
- Verifica si el grupo de campos de número de teléfono tiene una etiqueta visible.
- Asegúrate de que haya instrucciones claras sobre el formato esperado.
- Usa un lector de pantalla para confirmar que los campos sean identificables.
Resultados esperados
- ✅ Si los campos tienen etiquetas e instrucciones, el contenido cumple con WCAG.
- ❌ Si solo dependen del formato visual, el contenido falla el criterio 3.3.2 y debe corregirse.
Garantizar que los formularios sean accesibles beneficia a todos los usuarios, incluidos aquellos con discapacidades visuales o cognitivas. Implementar etiquetas claras y proporcionar instrucciones explícitas facilita la usabilidad y evita errores en el ingreso de datos.
🚀 ¿Quieres mejorar la accesibilidad de tus formularios? Contáctanos para una auditoría y optimización accesible. 💡