Ya sabemos que el contenido debe percibirse (03-01) y que la interfaz debe operarse (03-02). Pero una web puede ser perceptible y operable y aun así resultar incomprensible: idioma no declarado, comportamientos que cambian sin avisar, o un formulario de matrícula que rechaza los datos sin explicar por qué. El tercer principio POUR, Comprensible, exige que la información y el manejo de la interfaz se puedan entender. Es el principio que más ayuda a Hugo (dislexia/TDAH), a quien un texto predecible y unos errores bien explicados le marcan la diferencia entre terminar la matrícula o abandonar; pero también beneficia a Marta, cuyo lector necesita saber el idioma para pronunciar bien.
Contenido
- Qué exige el principio Comprensible
- Pauta 3.1: Legible
- Pauta 3.2: Predecible
- Pauta 3.3: Asistencia a la entrada
- Tabla resumen de criterios
- Errores comunes y consejos
- Ejercicios
- Conclusión
Qué exige el principio Comprensible
Comprensible significa que el usuario pueda entender la información y entender cómo funciona la interfaz: sin sorpresas, con ayuda cuando la necesita y con la posibilidad de detectar y corregir sus errores. Tres pautas lo estructuran.
graph TD
C[3. Comprensible] --> A[3.1 Legible]
C --> B[3.2 Predecible]
C --> D[3.3 Asistencia a la entrada]
Pauta 3.1: Legible
Hacer que el contenido de texto sea legible y comprensible, empezando por decirle a la máquina en qué idioma está.
- 3.1.1 Idioma de la página (A): declarar el idioma principal (
<html lang="es">). Sin él, el lector de Marta puede leer el español con fonética inglesa, resultando ininteligible. - 3.1.2 Idioma de las partes (AA): los fragmentos en otro idioma se marcan (
lang). Si una lección de Cursalia cita un término en inglés, ese fragmento se etiqueta para que se pronuncie correctamente.
<!-- Ilustrativo: idioma de página y de un fragmento -->
<html lang="es">
...
<p>El principio se llama <span lang="en">Robust</span> en el original.</p>Los criterios más avanzados de legibilidad y traducción (i18n) se retoman en el Módulo 7: i18n.
Pauta 3.2: Predecible
Hacer que las páginas aparezcan y funcionen de forma previsible. Nada debe cambiar de contexto de forma inesperada.
- 3.2.1 Al recibir el foco (A): que un elemento reciba el foco no debe provocar un cambio de contexto (abrir una ventana, enviar un formulario). Si al tabular hasta el selector de idioma del filtro la página se recarga sola, Lucía se pierde.
- 3.2.2 Al recibir entradas (A): cambiar el valor de un control (elegir una opción del desplegable) no debe, por sí solo, cambiar el contexto sin avisar. Debe haber un botón "Aplicar", o advertir del comportamiento.
- 3.2.3 Navegación coherente (AA): los elementos de navegación que se repiten aparecen en el mismo orden en todas las páginas. La cabecera de Cursalia no cambia de sitio entre catálogo y ficha.
- 3.2.4 Identificación coherente (AA): los componentes con la misma función se identifican igual en todo el sitio. El icono de "buscar" no puede llamarse "Buscar" en una vista y "Lupa" en otra.
- 3.2.6 Ayuda coherente (A) — nuevo en WCAG 2.2: si hay mecanismos de ayuda (contacto, chat, FAQ), aparecen en un orden relativo coherente entre páginas. Hugo encuentra siempre la ayuda en el mismo sitio.
Pauta 3.3: Asistencia a la entrada
Ayudar a los usuarios a evitar y corregir errores. Es la pauta central del formulario de matrícula.
- 3.3.1 Identificación de errores (A): si se detecta un error, se identifica y se describe en texto (no solo un borde rojo). "El correo no es válido" junto al campo.
- 3.3.2 Etiquetas o instrucciones (A): los campos llevan etiquetas e instrucciones cuando hacen falta ("Formato: DD/MM/AAAA"). Sin etiqueta, Marta no sabe qué escribir.
- 3.3.3 Sugerencia ante errores (AA): cuando se conoce cómo corregir, se ofrece la sugerencia. "El correo debe incluir @" ayuda más que "campo inválido".
- 3.3.4 Prevención de errores (legal, financiero, datos) (AA): en acciones con consecuencias (un pago del curso, un compromiso legal), la operación debe ser reversible, verificada o confirmada antes de ejecutarse.
- 3.3.7 Entrada redundante (A) — nuevo en 2.2: no pedir dos veces la misma información en el mismo proceso; reutilizarla o dejar elegirla. Si el registro ya pidió el correo, el paso de pago no lo vuelve a exigir a mano. Alivia la carga cognitiva de Hugo.
- 3.3.8 Autenticación accesible (mínimo) (AA) — nuevo en 2.2: el inicio de sesión no debe depender de una prueba cognitiva (recordar, transcribir, resolver un puzle) sin alternativa. Un CAPTCHA de texto retorcido sin opción accesible incumple; permitir pegar la contraseña o usar gestor sí ayuda.
<!-- Ilustrativo: etiqueta + instrucción + error en texto -->
<label for="email">Correo</label>
<input id="email" type="email" aria-describedby="ayuda-email err-email">
<p id="ayuda-email">Usaremos este correo para tu acceso.</p>
<p id="err-email">El correo debe incluir una @.</p>La construcción real de formularios accesibles (etiquetas,
aria-describedby, anuncio de errores) es el Módulo 4: Formularios Accesibles.
Tabla resumen de criterios
| Criterio | Nivel | Qué exige |
|---|---|---|
| 3.1.1 Idioma de la página | A | Declarar el idioma principal (lang) |
| 3.1.2 Idioma de las partes | AA | Marcar fragmentos en otro idioma |
| 3.2.1 Al recibir el foco | A | Enfocar no cambia el contexto |
| 3.2.2 Al recibir entradas | A | Cambiar un valor no cambia el contexto sin avisar |
| 3.2.3 Navegación coherente | AA | Navegación repetida en el mismo orden |
| 3.2.4 Identificación coherente | AA | Igual función, misma identificación |
| 3.2.6 Ayuda coherente | A (2.2) | Mecanismos de ayuda en orden coherente |
| 3.3.1 Identificación de errores | A | Errores descritos en texto |
| 3.3.2 Etiquetas o instrucciones | A | Etiquetas/instrucciones en los campos |
| 3.3.3 Sugerencia ante errores | AA | Ofrecer cómo corregir el error |
| 3.3.4 Prevención de errores | AA | Reversible/verificado/confirmado en acciones críticas |
| 3.3.7 Entrada redundante | A (2.2) | No repedir datos ya proporcionados |
| 3.3.8 Autenticación accesible (mínimo) | AA (2.2) | Login sin prueba cognitiva obligatoria |
Errores Comunes y Consejos
- Olvidar
langen el<html>. Es un fallo de nivel A muy frecuente y muy fácil de corregir; afecta a toda la síntesis de voz. - Señalar errores solo con color rojo. Incumple 3.3.1 (y 1.4.1 del principio Perceptible): el error debe estar también en texto.
- Autoenviar el formulario al elegir una opción. Rompe 3.2.2; usa un botón explícito o advierte del cambio.
- CAPTCHAs cognitivos sin alternativa. Con WCAG 2.2 y 3.3.8, exigir transcribir texto deformado sin otra vía es un incumplimiento.
- Pedir el mismo dato en cada paso del checkout. 3.3.7 pide reutilizarlo; además reduce abandono.
- Consejo: para Hugo, la coherencia es tan importante como la claridad. Mantén etiquetas, iconos y ubicación de la ayuda idénticos en todas las vistas de la SPA.
Ejercicios
Ejercicio 1. El formulario de matrícula marca los campos con error solo pintando su borde de rojo, sin ningún texto. Indica qué criterios se incumplen y qué exige cada uno.
Ejercicio 2. En el catálogo, al elegir una categoría en el desplegable del filtro la página se recarga y salta a otra vista sin que el usuario pulse nada. ¿Qué criterio se incumple y cuál es el requisito?
Ejercicio 3. El acceso a Cursalia obliga a resolver un CAPTCHA que pide transcribir letras deformadas, sin alternativa. ¿Qué criterio de WCAG 2.2 aplica y qué exige como mínimo?
Soluciones
Solución 1. Se incumple 3.3.1 Identificación de errores (A) —el error debe describirse en texto, no solo con color— y, por depender del color, también 1.4.1 Uso del color (A) del principio Perceptible. Requisito: añadir un mensaje textual junto al campo (idealmente con sugerencia de corrección, 3.3.3). La implementación se ve en el Módulo 4.
Solución 2. Se incumple 3.2.2 Al recibir entradas (A): cambiar el valor de un control no debe provocar un cambio de contexto inesperado. Requisito: aplicar el filtro con un botón "Aplicar", o advertir claramente de que seleccionar recargará la vista.
Solución 3. Aplica 3.3.8 Autenticación accesible (mínimo) (AA), nuevo en WCAG 2.2. Exige que exista un método de autenticación que no requiera una prueba cognitiva; como mínimo, ofrecer una alternativa accesible al CAPTCHA (p. ej. permitir gestores de contraseñas, no bloquear el pegado, o una vía distinta).
Conclusión
El principio Comprensible cierra la parte "humana" de POUR: idioma declarado, comportamiento predecible y coherente, y un manejo de errores que previene, identifica y sugiere correcciones. Con Perceptible, Operable y Comprensible cubrimos lo que la persona necesita directamente. Falta la base técnica que sostiene todo lo demás: que el código sea robusto, que las tecnologías de asistencia lo interpreten de forma fiable hoy y mañana. Ese es el cuarto principio, y en la lección 03-04 Robusto veremos qué exige el árbol de accesibilidad para que un componente personalizado exista de verdad para Marta y su NVDA.
Curso de Accesibilidad Web
Módulo 1: Introducción a la Accesibilidad Web
- ¿Qué es la Accesibilidad Web?
- Importancia de la Accesibilidad Web
- Visión General de las Leyes y Normas de Accesibilidad
- Introducción a WCAG
Módulo 2: Comprensión de Discapacidades y Tecnologías de Asistencia
- Tipos de Discapacidades
- Visión General de Tecnologías de Asistencia
- Cómo las Personas con Discapacidades Usan la Web
Módulo 3: Principios del Diseño Accesible
- Perceptible: Hacer el Contenido Disponible a los Sentidos
- Operable: Interfaz de Usuario y Navegación
- Comprensible: Información y Operación
- Robusto: Compatibilidad con Tecnologías Actuales y Futuras
Módulo 4: Implementación de Accesibilidad en HTML y CSS
- HTML Semántico
- Formularios Accesibles
- Uso de Roles y Propiedades ARIA
- Contraste de Color y Redimensionamiento de Texto
Módulo 5: Accesibilidad en JavaScript y Multimedia
- Creación de Widgets de JavaScript Accesibles
- Accesibilidad del Teclado
- Contenido de Video y Audio Accesible
- Proporcionar Alternativas de Texto para Imágenes
Módulo 6: Pruebas y Evaluación de la Accesibilidad
- Técnicas de Pruebas Manuales
- Herramientas de Pruebas Automatizadas
- Pruebas de Usuario con Tecnologías de Asistencia
- Interpretación de Informes de Accesibilidad