TL;DR (Too Long; Didn’t Read... o básicamente: mucho texto, dame el resumen rápido)
Todo campo de formulario que solicite información personal o repetitiva de la persona usuaria (nombre, email, dirección, teléfono) debe definir su propósito mediante el atributo autocomplete. Omitirlo, o peor aún, usar autocomplete="off" indiscriminadamente, es una infracción severa de la WCAG 1.3.5 (Identificación del Propósito de la Entrada).
La carga de la transcripción manual
Para una persona usuaria con dislexia, problemas de motricidad fina, o simplemente alguien realizando su quinto trámite del mes desde un celular, volver a escribir su correo electrónico es propenso a errores y genera fatiga masiva. El navegador posee una bóveda segura de datos de la persona usuaria, pero necesita "llaves" semánticas para saber en qué campo inyectarlos.
El patrón erróneo: Código Accesible Deficiente
Bloqueo explícito o ignorancia del atributo, forzando trabajo manual.
<!-- MAL: Omitiendo la especificación de propósito -->
<input type="email" id="correo" name="correo">
<!-- PEOR: Bloqueo explícito hostil (salvo en contraseñas temporales) -->
<input type="text" id="direccion" name="direccion" autocomplete="off">La Solución Accesible: Código Recomendado
Proveer a cada input su token exacto definido por la especificación HTML5 (given-name, email, tel, street-address, etc).
<!-- BIEN: Activación del autocompletado nativo del sistema -->
<div class="form-group">
<label for="correo">Correo Electrónico</label>
<input type="email" id="correo" name="correo" autocomplete="email">
</div>
<div class="form-group">
<label for="dir">Dirección de Residencia</label>
<input type="text" id="dir" name="dir" autocomplete="street-address">
</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 1.3.5.
Herramientas Automatizadas
Ejecutar Axe DevTools o WAVE sobre la vista afectada. Buscar violaciones relacionadas con el criterio WCAG 1.3.5. Complementar con una auditoría manual para los aspectos que las herramientas automatizadas no pueden verificar (interacción dinámica, calidad del contenido).
