Lección 2 de 12 · Lectura y práctica
Principios POUR de accesibilidad web
POUR: Los Pilares de la Accesibilidad Web Respuesta rápida: principios POUR: POUR resume los cuatro principios de WCAG: Perceptible, Operable, Comprensible y Robusto. Una interfaz accesible debe poder percibirse, usarse con.
Del concepto a la práctica
Taller de esta lección
Ejemplo resuelto
Un aviso de reserva aparece durante dos segundos, solo en verde y con el texto «OK». Clasifica las barreras por su efecto: puede pasar inadvertido, no explica qué ocurrió y quizá no se anuncia a la tecnología de asistencia. Una alternativa es mantener «Reserva confirmada: Sala Sur, viernes a las 10:00» junto al formulario y ofrecer un enlace para revisar la reserva. La clasificación ayuda a elegir correcciones distintas; no basta con cambiar el color.
Pruébalo
Copia el aviso original en una página de prueba.
Reescribe el mensaje con sala, fecha y resultado.
Mantén el texto disponible después del envío y permite revisarlo.
Prueba la actualización con teclado y un lector de pantalla, si está disponible.
Un error habitual es asignar una única etiqueta de principio a toda una pantalla. Un mismo componente puede crear varias barreras con soluciones diferentes.
Comprueba tu resultado
Elabora una tabla de cuatro filas: principio, observación, cambio y prueba. Cada cambio debe tener un resultado visible o comprobable. Marca como pendiente cualquier prueba que no hayas ejecutado.
Mapa de prácticaEl texto alternativo comunica el propósito de una imagen. La navegación por teclado necesita un foco visible; los campos necesitan etiquetas y la página una estructura semántica. Estas comprobaciones ayudan a detectar barreras y no sustituyen una auditoría completa.
Ver la infografía en tamaño completo ↗POUR: Los Pilares de la Accesibilidad Web
WCAG organiza sus criterios en 4 principios fundamentales conocidos como POUR. Todo criterio de accesibilidad cae bajo uno de estos principios. Si tu sitio cumple los 4, es accesible.
Perceptible: el usuario puede percibir el contenido
- Texto alternativo (alt text): toda imagen necesita una descripción textual para lectores de pantalla
- Subtítulos: todo video necesita subtítulos para personas sordas o en ambientes ruidosos
- Contraste de color: el texto debe tener suficiente contraste contra su fondo (ratio 4.5:1 para texto normal)
- No depender solo del color: si un campo de error solo se marca con borde rojo, un daltónico no lo verá — agrega texto e ícono
- Contenido adaptable: la información y la estructura deben ser determinables programáticamente (HTML semántico)
Operable: el usuario puede navegar e interactuar
- Navegación por teclado: toda funcionalidad debe ser accesible usando solo el teclado (Tab, Enter, Escape, flechas)
- Sin trampas de teclado: el usuario debe poder salir de cualquier componente usando el teclado
- Tiempo suficiente: si hay límites de tiempo (sesiones, formularios), el usuario debe poder extenderlos
- Contenido sin parpadeo: nada debe parpadear más de 3 veces por segundo (riesgo de ataques epilépticos)
- Skip links: un enlace oculto al inicio que permite saltar directamente al contenido principal
Comprensible: el usuario entiende el contenido
- Lenguaje claro: usa lenguaje simple y directo — evita jerga innecesaria y oraciones complejas
- Navegación consistente: los menús y la estructura deben ser iguales en todas las páginas
- Errores identificables: cuando hay un error en un formulario, explica claramente qué salió mal y cómo corregirlo
- Labels en formularios: cada campo de entrada necesita un label visible y asociado programáticamente
- Comportamiento predecible: los elementos interactivos deben comportarse como el usuario espera
Robusto: funciona en diferentes tecnologías
- HTML válido: código HTML sin errores de sintaxis para que los lectores de pantalla lo interpreten correctamente
- Roles ARIA correctos: cuando usas componentes personalizados, asegúrate de que tienen los roles semánticos apropiados
- Compatibilidad con tecnologías asistivas: prueba con lectores de pantalla (VoiceOver, NVDA) y navegación por teclado
- Estado y propiedades: los componentes dinámicos (modales, tabs, accordions) deben comunicar su estado a la tecnología asistiva
Consejo: Si tu sitio web es perceptible, operable, comprensible y robusto, es accesible. Usa POUR como checklist mental cada vez que diseñes o desarrolles un componente.
Checklist POUR para auditar una página real
Usá POUR como una revisión rápida antes de publicar una landing, checkout, curso, dashboard o formulario. No reemplaza una auditoría WCAG completa, pero ayuda a encontrar fallas visibles en minutos.
| Principio | Pregunta de auditoría | Ejemplo de mejora |
|---|---|---|
| Perceptible | ¿La información se entiende sin depender solo de vista, color o audio? | Agregar alt text, subtítulos, labels visibles y contraste suficiente. |
| Operable | ¿Se puede navegar con teclado y sin tiempos imposibles? | Orden de foco claro, botones reales, skip links y estados focus visibles. |
| Comprensible | ¿La interfaz explica qué hacer y cómo corregir errores? | Mensajes de error específicos, textos simples y formularios predecibles. |
| Robusto | ¿El HTML y ARIA funcionan con tecnologías actuales y futuras? | HTML semántico, nombres accesibles y ARIA solo cuando mejora la semántica. |
POUR y WCAG 2.2
POUR no es una lista paralela a WCAG: es la estructura conceptual que agrupa las pautas y criterios de éxito. W3C WAI explica que WCAG se organiza bajo los principios perceivable, operable, understandable and robust, y la especificación WCAG 2.2 mantiene esos principios como base del estándar.
Referencia oficial: W3C WAI: WCAG overview y WCAG 2 at a Glance.
POUR como habilidad laboral
Explicar los principios POUR sirve en entrevistas frontend, UX/UI, QA y producto porque muestra criterio de calidad más allá de lo visual. Convertí esta lección en evidencia auditando una página propia: documentá 8 problemas, priorizá impacto y subí capturas antes/después.
- Frontend: revisá semántica, foco, teclado, labels y estados de error.
- UX/UI: revisá contraste, jerarquía, lenguaje, instrucciones y prevención de errores.
- QA: armá casos de prueba con teclado, lector de pantalla, zoom y formularios.
- Freelance: ofrecé auditorías rápidas de accesibilidad para landings, ecommerce, cursos y SaaS.
Conectá esta habilidad con Desarrollador Frontend, buscá roles en empleos y ofrecé auditorías o mejoras de accesibilidad desde el marketplace de profesionales.
Sigue con Accesibilidad Web (WCAG)
Esta lección forma parte de un curso de Cursalo. Revisa su programa y elige entre la compra individual o el acceso a toda la escuela.
Si ya tenías acceso a este curso, entra con tu cuenta: tus derechos y tu progreso se conservan. No necesitas comprarlo de nuevo.