Volver al blog

Amnesia Inducida: El colapso cognitivo de depender del Placeholder

Infografía detallada: Amnesia Inducida: El colapso cognitivo de depender del Placeholder

TL;DR (Too Long; Didn’t Read... o básicamente: mucho texto, dame el resumen rápido)
Un texto atenuado de "placeholder" desaparece en el instante en que la persona usuaria escribe un carácter. Si este era el único indicador visual sobre la naturaleza del dato, la persona usuaria sufrirá desorientación si pierde el hilo de la tarea. Esto viola el Criterio WCAG 3.3.2 (Etiquetas o Instrucciones).

La priorización del estilo sobre la función

El afán de lograr interfaces ultralimpias ha llevado a la erradicación del <label> externo en favor del texto interno del input. El problema es inherente a la cognición humana: al voltear a mirar una tarjeta de crédito o un documento de identidad, el texto guía ya ha desaparecido de la pantalla.

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

Un campo desprotegido que castiga las interrupciones o la carga cognitiva alta.

<!-- MAL: Diseño efímero y hostil -->
<input type="email" placeholder="Ingresa tu correo institucional">
<!-- Al teclear la letra 'a', la persona usuaria olvida si era el correo personal o institucional -->

La Solución Accesible: Código Recomendado

Toda caja de texto debe tener una instrucción perenne. El placeholder solo debe usarse para ejemplos de formato, nunca como el rótulo principal.

<!-- BIEN: Etiqueta persistente y anclada al DOM -->
<label for="email-institucional">Correo Electrónico Institucional</label>
<input type="email" id="email-institucional" placeholder="ejemplo@entidad.gov.co">

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

Herramientas Automatizadas

Ejecutar Axe DevTools o WAVE sobre la vista afectada. Buscar violaciones relacionadas con el criterio WCAG 3.3.2. Complementar con una auditoría manual para los aspectos que las herramientas automatizadas no pueden verificar (interacción dinámica, calidad del contenido).

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)