POUR en accesibilidad
POUR significa perceptible, operable, comprensible y robusto: los cuatro principios de cada criterio de conformidad de WCAG. Con ejemplos de cada uno.
¿Qué es POUR en accesibilidad?
POUR son las siglas en inglés de Perceivable, Operable, Understandable y Robust (perceptible, operable, comprensible y robusto). Son los cuatro principios con los que se organizan las Web Content Accessibility Guidelines. Cada criterio de conformidad de WCAG pertenece a uno de ellos, así que POUR es una forma rápida de preguntarse qué falla cuando alguien no puede usar una página. El estándar completo se explica en WCAG.
WCAG 2.2 tiene cuatro principios y 13 pautas. Los principios son el nivel superior, las pautas dicen qué lograr y los criterios de conformidad son las reglas comprobables.
Los cuatro principios POUR
Perceptible (Perceivable)
La información y los componentes de la interfaz deben presentarse de formas que los usuarios puedan percibir. Eso incluye alternativas de texto para las imágenes, subtítulos para audio y vídeo, contenido que conserve su sentido al cambiar la presentación, y contraste y colores distinguibles suficientes. Pautas 1.1 a 1.4. Consulta imágenes accesibles.
Operable (Operable)
Los componentes y la navegación deben poder manejarse. Todo tiene que funcionar con el teclado, los usuarios necesitan tiempo suficiente, nada debe parpadear de forma que pueda provocar convulsiones, las páginas necesitan formas claras de navegar y los controles deben funcionar con algo más que un clic preciso de ratón. Pautas 2.1 a 2.5.
Comprensible (Understandable)
El contenido y el comportamiento de la interfaz deben ser comprensibles. El idioma de la página está definido, la navegación se comporta de forma predecible y los formularios etiquetan sus campos y explican los errores con texto. Pautas 3.1 a 3.3. Consulta formularios accesibles.
Robusto (Robust)
El contenido debe ser lo bastante robusto para que navegadores y tecnologías de apoyo lo interpreten con fiabilidad. En la práctica, los controles exponen un nombre, un rol y un estado que un lector de pantalla puede leer, usando primero HTML nativo y ARIA donde HTML no tiene equivalente. Pauta 4.1, la única de este principio.
Ejemplo: un formulario de inicio de sesión, cuatro fallos
- Perceptible: el logotipo no tiene texto alternativo y el lector de pantalla anuncia un nombre de archivo.
- Operable: el botón «Iniciar sesión» es un
divcon estilo que solo responde al clic del ratón, así que quien usa teclado no puede enviar el formulario. - Comprensible: un inicio de sesión fallido muestra «Entrada no válida» sin decir qué campo es el erróneo.
- Robusto: un desplegable de idioma propio, hecho con elementos
divsin etiquetar, no expone ningún rol ni nombre a la tecnología de apoyo.
Cómo usar POUR
- Clasificar los hallazgos de una auditoría. Asigna cada problema a su principio para ver si se concentran, por ejemplo muchos fallos de operabilidad por widgets propios.
- Estructurar informes. Un Accessibility Conformance Report sigue los mismos principios, criterio a criterio.
- Revisar diseños pronto. Antes de construir, hazte las cuatro preguntas: ¿se puede percibir, manejar, entender e interpretar con tecnología de apoyo?
Errores habituales
- Tratar POUR como una lista de cuatro puntos. Sirve para agrupar los criterios, no sustituye a comprobarlos.
- Leer una puntuación perfecta de Lighthouse como «terminado». Las comprobaciones automáticas cubren solo una parte de WCAG y dejan a una persona cosas como el orden del tabulador o el foco atrapado. Consulta en el blog (en inglés) la comparativa de herramientas de pruebas de accesibilidad.
- Reducir «robusto» a «HTML válido». Robusto trata de nombres, roles y estados que la tecnología de apoyo pueda usar. WCAG 2.2 eliminó el antiguo criterio 4.1.1 Procesamiento (Parsing).
Para vigilar la parte automática a lo largo del tiempo, la monitorización de velocidad de página de LoadFocus ejecuta auditorías programadas de Lighthouse y registra la categoría Accessibility junto a Performance, de modo que una bajada tras una versión se vea. Es una alarma de regresión, no una comprobación de conformidad.
Preguntas frecuentes sobre POUR
¿Qué significa POUR?
Perceivable, Operable, Understandable y Robust: perceptible, operable, comprensible y robusto.
¿Quién definió los principios POUR?
Son los cuatro principios de WCAG, publicados por la Web Accessibility Initiative del W3C.
¿POUR es lo mismo que WCAG?
No. POUR es el nivel superior de la estructura de WCAG. Debajo están las pautas y los criterios de conformidad de los niveles A, AA y AAA contra los que realmente se prueba.
¿Una puntuación automática perfecta significa que un sitio cumple POUR?
No. Las herramientas automáticas comprueban solo una parte de los criterios. El uso del teclado, la gestión del foco y la claridad de los mensajes de error requieren pruebas manuales.
Términos relacionados
- ¿Qué es un lector de pantalla? Definición y pruebas
- Lista de verificación de accesibilidad del software (WCAG 2.2)
- ¿Qué es un VPAT (Voluntary Product Accessibility Template)?
- Web Accessibility Initiative (WAI): qué es y qué publica
- WCAG: Pautas de Accesibilidad para el Contenido Web
- ¿Qué son las paletas de colores accesibles?
- ¿Qué son los formularios accesibles?
- Imágenes accesibles: texto alternativo, decorativas y WCAG
Herramientas LoadFocus relacionadas
Lleva este concepto a la práctica con LoadFocus, la misma plataforma que potencia todo lo que acabas de leer.