Principios POUR de WCAG en producto real

Cómo usar POUR (Perceptible, Operable, Comprensible y Robusto) para revisar interfaces con criterio técnico.

¿Cuánto sabes de Accesibilidad Web?

📘 Teoría

Claves teóricas

Traducción práctica de POUR a decisiones concretas de frontend.

Perceptible

Contenido visible y audible: contraste, alternativas textuales y jerarquía clara.

Operable

Todo debe poder usarse con teclado y sin tiempos imposibles de cumplir.

Comprensible

Etiquetas claras, mensajes directos y comportamiento predecible para no desorientar.

Robusto

HTML válido y semántico para mantener compatibilidad con tecnologías de asistencia.

Priorización real

Empieza por recorridos críticos y bloqueadores funcionales, no por detalles cosméticos.

Uso en equipo

Asocia cada incidencia a un principio POUR para comunicar mejor en diseño, desarrollo y QA.

Aplicación en proyectos reales

Cómo pasar de teoría WCAG a tickets accionables.

Cuando revises una pantalla, formula cuatro preguntas: ¿se percibe?, ¿se opera?, ¿se entiende?, ¿es robusta?

No intentes corregir todo a la vez: clasifica por impacto en la tarea y frecuencia de uso.

La calidad sube cuando cada hallazgo trae evidencia, criterio WCAG y propuesta técnica concreta.

Etiqueta cada bug con el principio POUR afectado.
Diferencia bloqueadores de mejoras progresivas en el backlog.
Incluye ejemplo reproducible y estado esperado en cada incidencia.
Revalida tras el fix con teclado y lector de pantalla.

Patrón de código

Formulario mínimo para ver POUR en acción: etiqueta, ayuda, validación y anuncio de error.

Ejemplo base con criterios POUR

<form>
  <label for="email">Correo</label>
  <input id="email" type="email" required aria-describedby="ayuda-email error-email" />
  <p id="ayuda-email">Usa tu correo de acceso.</p>
  <p id="error-email" role="alert"></p>
  <button type="submit">Entrar</button>
</form>