Volver al blog

Inputs Huérfanos: La trampa de reemplazar etiquetas por Placeholders

Infografía detallada: Inputs Huérfanos: La trampa de reemplazar etiquetas por Placeholders

TL;DR (Too Long; Didn’t Read... o básicamente: mucho texto, dame el resumen rápido)
Todo campo de entrada (<input>, <textarea>, <select>) debe estar vinculado a una etiqueta explícita <label>. Depender exclusivamente del atributo placeholder es un error de diseño fatal: desaparece al escribir y muchos lectores de pantalla no lo anuncian de forma confiable.

La amnesia de la interacción moderna

El minimalismo en UI introdujo la moda de incrustar el nombre del campo dentro del mismo input usando texto atenuado (placeholder). En el momento en que una persona usuaria teclea su primer carácter, la instrucción desaparece. Si la persona usuaria se distrae, pierde el contexto de qué estaba llenando. Esto viola el Criterio WCAG 4.1.2 de forma crítica.

El patrón erróneo: Código Accesible Deficiente

El input existe desnudo en el DOM, confiando únicamente en un atributo visual efímero.

<!-- MAL: Campo anónimo en el árbol de accesibilidad -->
<input type="text" placeholder="Número de Identificación">

La Solución Accesible: Código Recomendado

Vincular un <label> estático o utilizar patrones de diseño avanzados como el "Floating Label", pero garantizando siempre la presencia del for/id en el código base.

<!-- BIEN: Etiqueta permanente y vinculada -->
<div class="form-group">
  <label for="doc-id">Número de Identificación</label>
  <input type="text" id="doc-id" placeholder="Ej: 123456789">
</div>

Metodología de Verificación y Testing

Pruebas Manuales con Lectores de Pantalla

Con NVDA activo, presionar F para saltar entre campos de formulario. Verificar que el lector de pantalla anuncie correctamente el nombre, tipo y estado del campo. Si el campo no posee una etiqueta vinculada programáticamente, el lector solo anunciará el tipo de control sin contexto. En VoiceOver (iOS), tocar el campo y confirmar que la descripción sea completa.

Inspección del Árbol de Accesibilidad

En Chrome DevTools, seleccionar el elemento afectado en el panel Elements, luego abrir la pestaña Accessibility. Verificar que las propiedades Role, Name y State reflejen correctamente la intención del componente según el criterio WCAG 4.1.2.

Herramientas Automatizadas

Ejecutar Axe DevTools: las reglas aria-* y *-name detectan violaciones del Criterio 4.1.2 (Nombre, Función, Valor). WAVE marca controles sin nombre accesible. Limitación: La sincronización de estados dinámicos (JS) no siempre es verificable de forma automatizada.

Compartir artículo:

Artículos relacionados

¿Necesitas ayuda con la accesibilidad de tus proyectos?

Descubre cómo nuestro ecosistema detecta y corrige las barreras de forma automática.

Hablar con un experto (Abre en una nueva ventana)