¿Qué cambió en WCAG 2.2? Introducción práctica a los nuevos criterios de éxito añadidos para la accesibilidad web

En el artículo anterior, vimos qué tipo de directriz es WCAG 2.2 y por qué necesitamos abordar ahora la accesibilidad web. En este segundo artículo, finalmente veremos de forma sencilla y práctica qué cambió en WCAG 2.2. Cuando escuchas que un estándar se ha actualizado, puedes sentir que las reglas han cambiado drásticamente. En realidad, WCAG 2.2 se basa en WCAG 2.1 y añade soporte más concreto para áreas donde las personas suelen tener dificultades en el uso real. Por eso, en lugar de pensar “todo lo que entendíamos antes ya no sirve”, es más natural ver esta actualización como una forma de refinar los esfuerzos existentes para acercarlos más a las necesidades reales de los usuarios.

Lo que aprenderás en este artículo

• Cómo cambió WCAG 2.2 respecto a WCAG 2.1
• Los puntos clave de los 9 nuevos criterios de éxito añadidos
• Cómo pensar sobre el criterio de éxito eliminado
• Puntos que deberían priorizarse en revisiones reales
• Áreas donde el servicio de accesibilidad web UUU funciona bien, y áreas donde no

WCAG 2.2 añadió 9 criterios de éxito a WCAG 2.1 y dejó obsoleto 1 criterio de éxito. La estructura básica no ha cambiado, y los cuatro principios de “perceptible”, “operable”, “comprensible” y “robusto” siguen siendo los mismos. En otras palabras, los elementos que siempre han sido importantes —estructura de encabezados, texto alternativo, operación con teclado, contraste y etiquetado adecuado de formularios— siguen siendo importantes. Además de eso, las nuevas incorporaciones se centran más profundamente en la usabilidad cotidiana de la interfaz, como hacer que el foco sea más fácil de ver, evitar depender de operaciones de arrastre, facilitar la entrada de datos, reducir la carga durante la autenticación y mejorar la usabilidad de los objetivos táctiles. Dicho de otra forma, WCAG 2.2 se entiende más fácilmente como una versión que presta aún más atención no solo a “si los usuarios pueden percibir algo”, sino también a “si pueden operarlo sin confusión” y “si pueden completar tareas sin una carga innecesaria”.

Una premisa importante que hay que tener presente es que muchos de los nuevos criterios de éxito añadidos en WCAG 2.2 no son “preocupaciones avanzadas del futuro”. Están directamente conectados con problemas que ya ocurren en sitios corporativos, sitios de servicios, sitios de contratación, sitios municipales, sitios de comercio electrónico y pantallas de registro. Por ejemplo, un encabezado fijo puede ocultar el elemento enfocado cuando un usuario presiona la tecla Tab; los botones pequeños pueden ser difíciles de tocar en un smartphone; las interfaces que dependen de operaciones de arrastre pueden ser difíciles de usar; y las pantallas de inicio de sesión pueden imponer autenticación compleja cada vez, creando una carga pesada. Probablemente muchos lectores han experimentado estas situaciones por sí mismos. WCAG 2.2 identifica este tipo de “incomodidades comunes” y proporciona criterios más concretos para mejorarlas.

Los 9 criterios de éxito añadidos en WCAG 2.2

Ahora revisemos los 9 nuevos criterios de éxito desde una perspectiva práctica. No necesitas memorizarlos todos de una vez. Primero, es importante entender qué tipo de dificultad de usuario aborda cada criterio.

2.4.11 Foco no oculto (mínimo)

Este criterio de éxito requiere que, cuando el foco se mueve mediante operación con teclado o métodos similares, el elemento enfocado no quede completamente oculto. Por ejemplo, cuando existe un encabezado fijo o un menú sticky en la parte superior de la pantalla, un botón o enlace enfocado puede deslizarse debajo de él mientras el usuario avanza con Tab por la página. Entonces el usuario no puede saber dónde está, lo que dificulta continuar operando la página. En la práctica, es importante tener en cuenta la altura de los encabezados fijos en el comportamiento de desplazamiento y comprobar cómo aparece el foco. Este problema es especialmente fácil de pasar por alto en formularios, modales, acordeones, navegación y otras áreas donde la operación con teclado es común.

2.4.12 Foco no oculto (mejorado)

Esta es una versión más estricta del criterio anterior. Requiere que el elemento enfocado no quede oculto por otro contenido. Mientras que 2.4.11 exige la condición mínima de que el elemento no esté completamente oculto, 2.4.12 garantiza con más firmeza que el elemento enfocado permanezca visible. En la práctica, muchas organizaciones se centran primero en el cumplimiento AA, por lo que es realista priorizar 2.4.11. Sin embargo, diseñar desde el principio para que el foco no quede oculto por elementos de interfaz superpuestos suele mejorar también la experiencia general del usuario.

2.4.13 Apariencia del foco

Este criterio de éxito requiere que el indicador de foco —la señal visual que muestra “dónde está actualmente el usuario”— sea suficientemente visible. En la producción web moderna, todavía a veces se eliminan los contornos por razones de diseño, pero hacerlo dificulta que los usuarios de teclado entiendan su posición actual. Incluso si técnicamente existe un indicador de foco, una línea fina o un color que se mezcla con el fondo puede hacerlo prácticamente invisible. En la práctica, es importante diseñar cuidadosamente los contornos de foco, los cambios de fondo, los subrayados, el grosor y el contraste. Diseño y accesibilidad no son opuestos. Un indicador de foco visible también genera tranquilidad y facilita la operación.

2.5.7 Movimientos de arrastre

Este criterio de éxito requiere que los usuarios no se vean obligados a depender únicamente de operaciones de arrastre. Por ejemplo, si el valor de un slider solo puede cambiarse arrastrando, si una ubicación en un mapa solo puede seleccionarse arrastrando un pin, o si los elementos solo pueden reordenarse mediante drag and drop, la interfaz puede convertirse en una gran carga para algunos usuarios. Las personas con dificultades de control motor fino, las personas que usan tecnologías de asistencia y las personas que utilizan principalmente un teclado pueden no poder completar la tarea en absoluto. En la práctica, deben proporcionarse alternativas como botones, entrada numérica, controles basados en selección y soporte de teclado. Arrastrar puede ser cómodo, pero no debería ser el único método disponible.

2.5.8 Tamaño del objetivo (mínimo)

Este criterio de éxito requiere una consideración mínima del tamaño de los objetivos operados mediante entrada táctil o de puntero. En smartphones, cuando enlaces o iconos pequeños están amontonados, es más probable que se produzcan toques erróneos. Esta es una incomodidad experimentada por muchos usuarios, independientemente de si tienen discapacidad o no. Tiene un impacto especialmente grande en usuarios mayores, personas que usan una sola mano y personas que operan mientras se desplazan. En la práctica, es necesario comprobar no solo el tamaño visual de botones y enlaces, sino también si el área realmente tocable es lo suficientemente grande. Botones pequeños de cierre, números de paginación y UI de tarjetas donde solo una zona diminuta es clicable son candidatos comunes para revisión.

3.2.6 Ayuda consistente

Este criterio de éxito requiere consistencia en la ubicación y facilidad de descubrimiento de las funciones de ayuda proporcionadas en varias páginas. Por ejemplo, si la información de contacto, el soporte por chat, los enlaces a preguntas frecuentes o los botones de ayuda aparecen en lugares diferentes según la página, los usuarios pueden tener dificultades para encontrar la asistencia que necesitan. Especialmente en procedimientos, solicitudes y flujos de registro donde puede surgir ansiedad, la consistencia en las rutas de ayuda afecta enormemente a si los usuarios pueden continuar. En la práctica, los fundamentos efectivos incluyen unificar enlaces de ayuda a nivel de plantilla de página, colocar enlaces de soporte importantes en la misma ubicación y usar una redacción consistente. Puede parecer simple, pero este criterio apoya firmemente una experiencia de usuario estable.

3.3.7 Entrada redundante

Este criterio de éxito requiere que, en general, no se pida a los usuarios que vuelvan a introducir información que ya han proporcionado dentro del mismo proceso. Por ejemplo, si un usuario introduce su nombre o dirección al principio de un formulario de solicitud y luego se le pide escribir la misma información nuevamente en una pantalla de confirmación o en otro paso, la carga es alta y es más probable que haya errores de entrada. Esto aumenta la carga cognitiva y de memoria, y simplemente toma más tiempo. En la práctica, las mejoras posibles incluyen trasladar la información desde pasos anteriores, usar adecuadamente el autocompletado y hacer que las pantallas de confirmación sean fáciles de editar. Este es un criterio donde accesibilidad y UX se solapan fuertemente, porque fundamentalmente se trata de no obligar a los usuarios a hacer trabajo innecesario.

3.3.8 Autenticación accesible (mínimo)

Este criterio de éxito requiere que la autenticación no imponga pruebas excesivas de función cognitiva a los usuarios. Por ejemplo, pedir a los usuarios que memoricen e introduzcan cadenas complejas, seleccionen ciertos elementos en imágenes o resuelvan CAPTCHAs tipo rompecabezas puede convertirse en una gran barrera para algunos usuarios. La seguridad es, por supuesto, importante, pero si una medida de seguridad impide que las personas usen el servicio, pierde su propósito. En la práctica, los puntos de revisión incluyen no bloquear gestores de contraseñas, no prohibir innecesariamente copiar y pegar, proporcionar alternativas y reconsiderar el diseño de enlaces de un solo uso o autenticación multifactor. Esta es una perspectiva muy importante para sitios que manejan inicio de sesión y registro de miembros.

3.3.9 Autenticación accesible (mejorada)

Este es un criterio más estricto relacionado con la autenticación. Pide, a un nivel superior, que los usuarios puedan autenticarse evitando la carga cognitiva tanto como sea posible. Como es de nivel AAA, no es obligatorio para todos los proyectos. Sin embargo, para servicios donde la autenticación y la verificación de identidad son centrales, es muy útil como dirección de diseño. Es un tema importante más allá de un simple número de criterio de éxito cuando se piensa tanto en la seguridad del usuario como en la usabilidad.

Cómo pensar sobre el criterio 4.1.1 Parsing, ahora obsoleto

En WCAG 2.2, 4.1.1 Parsing quedó obsoleto. A primera vista, esto puede hacerte preguntar: “¿Eso significa que ya no necesitamos preocuparnos por HTML válido?” Pero no es así. La razón por la que se eliminó Parsing tiene que ver con la evolución de los navegadores modernos y las tecnologías de asistencia. La comprobación formal de sintaxis por sí sola ya no es tan significativa para juzgar la accesibilidad como lo fue en el pasado. Sin embargo, esto no significa que la estructura HTML pueda romperse. La implementación adecuada de encabezados, etiquetas, botones, enlaces, landmarks y elementos de formulario sigue siendo extremadamente importante. En otras palabras, el énfasis se ha desplazado de “sintaxis por la sintaxis” hacia una pregunta más práctica: “¿La implementación se transmite correctamente a los usuarios?”

Puntos que priorizar en revisiones reales

Después de revisar todo esto, WCAG 2.2 puede parecer exigente porque se han añadido varios elementos nuevos. Sin embargo, las prioridades en el trabajo real pueden organizarse con bastante claridad. Las áreas más fáciles para empezar y con gran impacto son el comportamiento relacionado con el foco, el tamaño de los objetivos táctiles y el diseño de formularios/autenticación. Estas son áreas donde los problemas son relativamente fáciles de encontrar en sitios existentes, y donde las mejoras son fáciles de percibir para los usuarios. Incluso comprobaciones simples —como operar los flujos principales de usuario con teclado, probar la usabilidad de los botones en un smartphone real o comprobar si los formularios de inicio de sesión y consulta requieren reingreso innecesario— pueden revelar muchos problemas.

Por ejemplo, considera un formulario de solicitud de empleo. Un usuario introduce su nombre, dirección, número de teléfono y correo electrónico, pero la pantalla de confirmación es difícil de editar; volver atrás borra la entrada; los campos obligatorios se muestran solo mediante color; el botón de envío queda oculto detrás de un encabezado fijo cuando recibe foco; y las casillas de verificación son demasiado pequeñas para tocar en un smartphone. En este tipo de situación, los nuevos criterios de WCAG 2.2 se convierten en una guía útil para mejorar. Los estándares pueden parecer abstractos, pero en realidad existen para reducir este tipo de incomodidades concretas.

Dónde encaja bien el servicio de accesibilidad web UUU

También toquemos la compatibilidad con el servicio de accesibilidad web UUU, que forma parte del tema de esta serie. Servicios como UUU, que proporcionan funciones de apoyo a la navegación —como ajuste del tamaño del texto, ajuste del contraste, ajuste del espaciado de líneas y caracteres, detención de animaciones, lectura en voz alta, traducción y visualización de furigana— son compatibles con la accesibilidad como punto de entrada porque ayudan a los usuarios a acercarse a un entorno de navegación que se adapte a ellos. Especialmente para organizaciones que no pueden llevar a cabo de inmediato una renovación completa del sitio, estos servicios también son atractivos porque hacen más visible la consideración hacia los usuarios.

Por otro lado, muchos de los criterios de éxito recién introducidos no pueden satisfacerse plenamente simplemente instalando una herramienta. Por ejemplo, si el foco queda oculto detrás de un encabezado fijo, debe ajustarse la implementación de la propia página. Si una interfaz solo puede operarse arrastrando, deben diseñarse métodos de operación alternativos. Los problemas de tamaño de objetivo requieren cambios en el diseño de los botones y enlaces reales. Una autenticación más sencilla y una reducción de la entrada redundante también requieren revisar los formularios y el diseño del sistema. En otras palabras, servicios como UUU tienen una fuerte compatibilidad en el área de apoyo a la navegación, pero muchos de los requisitos de implementación y operación añadidos en WCAG 2.2 siguen requiriendo una mejora cuidadosa del contenido y de la propia interfaz. Entender esta distinción facilita equilibrar el apoyo basado en herramientas con mejoras esenciales.

Resumen de la Parte 2

WCAG 2.2 no sobrescribe drásticamente WCAG 2.1. Más bien, es una directriz que refuerza la usabilidad práctica de acuerdo con el entorno web actual. Los 9 nuevos criterios de éxito están todos profundamente conectados con la experiencia real del usuario: foco visible, alternativas a operaciones de arrastre, toques más fáciles, rutas de ayuda consistentes, reducción de entrada redundante y menor carga durante la autenticación. En ese sentido, esta actualización también es una oportunidad para repensar la accesibilidad no como “acomodación especial”, sino como una base para interfaces que las personas puedan usar sin perderse.

En la práctica, se recomienda revisar primero los flujos principales de los sitios existentes, especialmente situaciones importantes como operación con teclado, operación en smartphone, entrada en formularios, inicio de sesión y autenticación. Y aunque medidas de apoyo como el servicio de accesibilidad web UUU son valiosas para la asistencia a la navegación, también es importante recordar que muchos de los nuevos requisitos de WCAG 2.2 solo pueden cumplirse revisando cuidadosamente el diseño y la implementación originales. En el próximo artículo, nos centraremos en por qué los formularios se vuelven difíciles de usar y explicaremos los fundamentos del apoyo a la entrada de datos y el diseño de errores con ejemplos de pantalla más concretos.

Enlaces de referencia

• W3C: Web Content Accessibility Guidelines (WCAG) 2.2
• W3C WAI: What’s New in WCAG 2.2
• W3C WAI: Understanding WCAG 2.2
• W3C WAI: How to Meet WCAG 2.2 (Quick Reference)
• WAIC: Web Content Accessibility Guidelines (WCAG) 2.2 Japanese Translation
• WAIC: Announcement of WCAG 2.2 Japanese Translation Release
• WAIC: Resources