WCAG 2.2. Novedades del último borrador publicado (Candidata a recomendación - enero 2023)

Última actualización del artículo: 26 de enero de 2023

El objetivo de este artículo es recoger las novedades de la nueva versión de las WCAG, las Web Content Accessibility Guidelines (WCAG) 2.2, actualmente en versión candidata a recomendación. Iré actualizando el artículo con la publicación de cada borrador hasta que las WCAG 2.2 sean recomendación.

Actualmente, la última versión de las WCAG 2.2 es del 25 de enero de 2023.

Sobre las WCAG 2.2

El objetivo de las WCAG 2.2 es continuar el trabajo de las WCAG 2.1, esto es, mejorar la accesibilidad para los usuarios con discapacidad cognitiva o de aprendizaje, la accesibilidad para los usuarios con baja visión y la accesibilidad desde dispositivos móviles.

Así como las WCAG 2.1 fueron una ampliación de 17 criterios respecto a las WCAG 2.0, las WCAG 2.2 serán una nueva ampliación de criterios, de modo que si se cumple con las WCAG 2.2 se cumplirá también con las WCAG 2.1.

Criterios que elimina

Una de las grandes novedades es que se elimina el criterio "4.1.1: Parsing" de nivel A.

La justificación es que este criterio se adoptó originalmente para abordar los problemas que tenía la tecnología de asistencia al analizar el HTML directamente. Pero los productos de apoyo ya no tienen la necesidad de analizar el HTML directamente y, en consecuencia, estos problemas ya no existen.

Los errores de accesibilidad en este criterio también provocan la no conformidad en otros criterios, como puede ser en el caso de los ids repetidos. Por tanto, este criterio ya no tiene utilidad y se elimina.

Nuevos criterios

1. Criterio 2.4.11 Focus Appearance (AA)
2. Criterio 2.4.12 Focus Not Obscured (Minimum) (AA)
3. Criterio 2.4.13 Focus Not Obscured (Enhanced) (AAA)
4. Criterio 2.5.7 Dragging Movements (AA)
5. Criterio 2.5.8 Target Size (Minimum) (AA)
6. Criterio 3.2.6 Consistent Help (A)
7. Criterio 3.3.7 Redundant entry (A)
8. Criterio 3.3.8 Accessible Authentication (AA)
9. Criterio 3.3.9 Accessible Authentication (Enhanced) (AAA)

Es decir, de momento se propone añadir 9 criterios nuevos: 2 de nivel A, 5 de nivel AA y 2 de nivel AAA.

Además, el criterio 2.4.7 Foco Visible pasa del nivel AA al nivel A.

2.4.11 Focus Appearance (AA)

Este criterio complementa a los criterios 2.4.7 y 1.4.11

El criterio 2.4.7 Foco visible, que ahora pasa a ser de nivel A, exige que el foco de teclado sea visible. El objetivo de este nuevo criterio es complementarlo, asegurando que el foco de teclado sea además claramente visible y discernible, por ello, el nuevo criterio 2.4.11 define un nivel mínimo de visibilidad, basado en el tamaño y en el contraste.

El criterio 1.4.11 Contraste no textual AA, incluido en las WCAG 2.1, requiere además que el foco de teclado tenga al menos un contraste de 3:1, y que un componente de interacción tenga un contraste adecuado con el fondo, tanto en su estado por defecto como en su estado con el foco; de forma complementaria, el nuevo criterio 2.4.11 requiere un contraste suficiente entre los dos estados del componente, su estado con el foco y su estado sin el foco.

El nuevo criterio 2.4.11 especifica que, cuando el indicador del foco de teclado es visible, uno o ambos de estos dos requisitos se cumplen:

1. Todo el indicador del foco cumple tres condiciones:
   • rodea al componente que tiene el foco. Se refiere a un borde sólido, normalmente un recuadro, pero que también puede tener la forma del elemento (por ejemplo, forma de estrella). Para esta condición no se admite el borde puntuado.
   • hay una ratio de contraste de al menos 3:1 entre los mismos píxeles en su estado con y sin el foco.
   • hay una ratio de contraste de al menos 3:1 con los colores adyacentes que no forman parte del indicador del foco. Por ejemplo, si una estrella al coger el foco tiene un borde negro pegado a la estrella, este debe contrastar no solo con el fondo sino también con la estrella.
2. Un área del indicador del foco cumple tres condiciones:
   • es al menos tan grande como el área de un perímetro de 1 píxel CSS de grosor del componente sin el foco, o es al menos tan grande como una línea de 4 píxeles CSS de grosor a lo largo del lado más corto de la caja delimitadora mínima del componente sin el foco. Es decir, define un área mínima mediante el perímetro y un mínimo secundario basado en el lado más corto.
   • hay una ratio de contraste de al menos 3:1 entre los mismos píxeles en su estado con y sin el foco;
   • hay una ratio de contraste de al menos 3:1 con los colores adyacentes que no forman parte del indicador del foco, o no es más delgado que 2 píxeles CSS.

Hay dos excepciones:

• Si el indicador del foco lo determina el agente de usuario y no puede ser ajustado por el autor.
• El indicador del foco y el color de fondo del indicador no son modificados por el autor.

Se añaden varias notas, siendo las más relevantes:

• Lo que se percibe como el componente o subcomponente de la interfaz de usuario para determinar su tamaño depende de su presentación visual. La presentación visual incluye el contenido visible, el borde y el fondo específico del componente. No incluye efectos, como una sombra del contenido o de su borde.
• Los cálculos de contraste se pueden basar en colores definidos dentro de la tecnología (como HTML, CSS y SVG). Los píxeles modificados por las mejoras de resolución del agente de usuario y el suavizado se pueden ignorar.

Es preferible definir un estilo de foco de teclado personalizado que cumpla con todas las condiciones exigidas, mejor que dejar el enfoque predeterminado del navegador, porque el foco por defecto puede no ser suficientemente visible en todos los navegadores.

Por otra parte, se indica que solo aplica a los elementos que cogen el foco y son operables con el teclado. Si, por ejemplo, un encabezado es el objetivo de un ancla y coge el foco de teclado sin ser operable (al pulsarlo no va a ocurrir nada), no le aplica este criterio.

Ejemplo del cálculo del perímetro

En la segunda opción del criterio, se indica que el área mínima del indicador del foco debe ser al menos tan grande como el área de un perímetro de 1 píxel CSS de grosor del componente sin el foco, o al menos tan grande como una línea de 4 píxeles CSS de grosor a lo largo del lado más corto de la caja delimitadora mínima del componente sin el foco.

Es decir, se proporcionan dos métodos, definir un área mínima para el indicador del foco utilizando un cálculo para el perímetro y un mínimo secundario basado en el lado más corto del control.

Para el primer cálculo, el indicador no tiene que ser un borde, pero el área del indicador debe ser al menos igual de grande.

Por ejemplo, si un control es un rectángulo de 90 píxeles de ancho y 30 píxeles de alto, el tamaño del borde exterior es 90 + 90 + 30 + 30 = 240 píxeles CSS. Luego se restan los 4 píxeles de las esquinas (que se cuentan dos veces, tanto horizontal como verticalmente), y nos sale un área mínima total de 236 píxeles CSS. El área del indicador del foco debe ser al menos de 236px.

En los siguientes ejemplos de las WCAG 2.2 de botones de 90px por 30px, el botón central con el foco cumple el criterio:

En el primer caso, el contorno interior del botón con el foco es ligeramente más pequeño que el borde exterior, pero su grosor es de 2 px, lo que significa que el área de ese recuadro amarillo está muy por encima del requisito mínimo de un área de 236px.

En el segundo caso, el subrayado amarillo ocupa casi todo el ancho, en concreto, 80 px. Como tiene 3 px de alto, el cálculo de su área (80*3=240) también excede el requisito de un área mínima de 236 px.

Si tus controles cambian de tamaño en la versión responsive, debes tenerlo en cuenta a la hora de revisar el criterio.

Ejemplo del cálculo del área basado en el grosor del lado más corto

Este cálculo se incluye para permitir indicadores del foco más pequeños pero más gruesos y, por tanto, igual de visibles. Un ejemplo correcto sería el siguiente:

El área del recuadro amarillo que indica que el botón tiene el foco cumple con los mínimos requeridos.

Ejemplos de tipos de focos de teclado que pasarían o no esta condición del tamaño

SÍ pasaría:

• Un contorno sólido alrededor de todo el componente.
• Cambiar el color del fondo del componente.

NO pasaría:

• Un contorno punteado de un 1px alrededor del componente, porque su área es un 50% del mínimo requerido. En algunos tamaños y navegadores, el contorno punteado puede sumar un área menor de la mitad, y habrá que tenerlo en cuenta para calcular qué grosor debería tener el punteado.
• Una línea vertical de 1px, como un cursor parpadeante en el campo del formulario, no cumpliría el criterio; debería ser grueso o complementarse con un borde más ancho del campo

Cuando un indicador del foco se define en el código, por ejemplo, con 2px, el suavizado se puede ignorar a efectos del cálculo.

Como regla general, si tienes que hacer operaciones matemáticas complejas para averiguar si estás o no cumpliendo, es que seguramente deberías aumentar la visibilidad del foco. Pero es verdad que, si el componente tiene una forma inusual (como una estrella) y el foco se refleja en su borde, o se juega con las sombras, los cálculos se puedan complicar. En la página de explicación del criterio se ponen más ejemplos de cálculo de formas inusuales o del foco en un enlace que está en dos líneas.

Contraste

En el criterio también se indica, en la segunda opción, que debe haber una ratio de contraste de al menos 3:1 con los colores adyacentes que no forman parte del indicador del foco, o no ser más delgado que 2 píxeles CSS.

Es decir, debe contrastar 3:1 con los colores adyacentes (incluido el componente), o bien estar separado del componente, o bien tener al menos 2 píxeles de grosor, aunque sea del mismo color que el componente, porque el grosor permitirá diferenciarlo de los que no tienen el foco:

El menú que tiene el foco es más grande porque tiene un borde de 2 píxeles del mismo color.

Más información: Understanding Success Criterion 2.4.11: Focus Appearance (AA)

Documentación de apoyo

Vídeo y más información sobre el criterio en "Focus Appearance thoughts (blog Alastair Campbell)"

2.4.12 Focus Not Obscured (Minimum) (AA)

Cuando un componente de la interfaz de usuario recibe el foco de teclado, el componente no puede estar completamente oculto por un contenido creado por el autor.

El típico ejemplo de contenido que se superpone a un elemento con el foco son los pies y encabezados fijos o las capas no modales.

Si la interfaz se puede configurar para que el usuario pueda mover las barras de herramientas y los cuadros de diálogo no modales, solo se considerarán las posiciones iniciales del contenido que puede mover el usuario para probar y cumplir con este criterio.

Más información: Understanding Success Criterion 2.4.12 Focus Not Obscured (Minimum) (AA)

2.4.13 Focus Not Obscured (Enhanced) (AAA)

Es igual al criterio anterior pero más estricto. Cuando un componente de la interfaz de usuario recibe el foco del teclado, el contenido creado por el autor no oculta ninguna parte del indicador del foco.

Es decir, la diferencia es que requiere que la totalidad del componente con el foco esté visible.

Más información: Understanding Success Criterion 2.4.13 Focus Not Obscured (Enhanced) (AAA)

2.5.7 Dragging Movements (AA)

Toda funcionalidad que utiliza un movimiento de arrastre para la operación (por ejemplo, controles deslizantes o interfaces de arrastrar y soltar) se puede operar con un "single pointer" sin arrastrar, a menos que arrastrar sea esencial, o a menos que la funcionalidad sea determinada por el agente de usuario y no sea modificada por el autor. No aplica a las acciones necesarias para operar con el agente de usuario o el producto de apoyo.

"Single pointer", igual que en el criterio "2.5.1 Gestos del puntero" de las WCAG 2.1, es la activación mediante un solo punto: un toque (clic), doble toque (doble clic) o una pulsación larga.

Hay que tener en cuenta que algunas personas no pueden realizar movimientos de arrastre de forma precisa. Otras, utilizan un dispositivo de entrada, como un puntero de cabeza, control por voz o de seguimiento ocular, que hace que el arrastre sea complicado, propenso al error o totalmente imposible.

Más información: Understanding Success Criterion 2.5.7: Dragging Movements (AA)

2.5.8 Target Size (Minimum) (AA)

El tamaño de la zona interacción con el puntero tiene un área con un ancho y alto de al menos 24 píxeles CSS, excepto cuando:

• Espaciado: la zona de interacción no se superpone a ninguna otra y tiene una zona de interacción offset (la distancia entre el punto más lejano de una zona de interacción al punto más cercano de la segunda zona de interacción) de al menos de 24 píxeles CSS, respecto a cada zona de interacción adyacente. Es decir, si la zona de interacción es menor de 24 px pero, junto al margen, hasta la siguiente zona de interacción suma 24 px, es válido.
• Equivalente: la función se puede lograr a través de un control diferente en la misma página que cumpla con este criterio.
• En línea: el área de interacción está dentro de una oración, o está en una lista (numerada o con viñetas), o su tamaño está restringido por la altura de línea del texto que no forma parte del área de interacción.
• Control de agente de usuario: el tamaño del área de interacción lo determina el agente de usuario y el autor no lo modifica .
• Esencial: una presentación particular del área de interacción es esencial o es legalmente requerida para la información que se transmite.

Este requisito es independiente del zoom de la página. Cuando los usuarios hacen zoom, el tamaño de píxel CSS de los elementos no cambia. Esto significa que los autores no pueden cumplirlo afirmando que el objetivo tendrá suficiente espacio o tamaño si el usuario hace zoom en la página.

Es, por tanto, la versión menos estricta para el nivel AA del criterio "2.5.5 Tamaño del área de interacción" de nivel AAA, que establece el tamaño mínimo en 44 x 44 píxeles.

A continuación, algunos de los ejemplos que ponen:

Imagen del W3C.

Imagen del W3C.

Imagen del W3C.

Más información: Understanding Success Criterion 2.5.8: Target Size (Minimum) (AA)

3.2.6 Consistent Help (A)

Si una página web contiene algunos de los mecanismos de ayuda que se van a listar, y estos mecanismos de ayuda se repiten en varias páginas web dentro de un conjunto de páginas web, se ofrecen en el mismo orden relativo, a menos que un cambio sea iniciado por el usuario:

• Datos de contacto humano (número de teléfono, dirección de correo electrónico, horario de atención, etc.)
• Mecanismo de contacto humano (chat, formulario de contacto, canal de redes sociales, etc.)
• Opción de autoayuda (una página de preguntas frecuentes)
• Un mecanismo de contacto totalmente automatizado (un chatbot)

El acceso a los mecanismos de ayuda se puede proporcionar directamente en la página, o se puede proporcionar a través de un enlace directo a una página diferente que contiene la información.

El objetivo NO es exigir opciones de ayuda, sino garantizar que, si las hay, los usuarios puedan encontrarlas para completar las tareas del sitio web porque se incluyen en una ubicación consistente en todas las páginas.

Es por tanto un criterio muy similar al "3.2.3 Navegación consistente", pero aplicado a los mecanismos de contacto y ayuda en vez de a los mecanismos de navegación.

Más información: Understanding Success Criterion 3.2.6: Consistent Help (A)

3.3.7 Redundant entry (A)

La información ingresada previamente por el usuario o proporcionada al usuario y que debe ingresar nuevamente en el mismo proceso, debe rellenarse automáticamente o estar disponible para que el usuario la seleccione.

Hay tres excepciones:

• Volver a ingresar la información es esencial.
• La información es necesaria para garantizar la seguridad del contenido.
• La información ingresada anteriormente ya no es válida.

Más información: Understanding Success Criterion 3.3.9: Redundant entry (A)

3.3.8 Accessible Authentication (AA)

El propósito de este criterio es garantizar que exista un método accesible, fácil de usar y seguro para iniciar sesión y acceder al contenido, y beneficia especialmente a las personas con discapacidad cognitiva.

Si un proceso de autenticación se basa en una "cognitive function test" (como recordar una contraseña o resolver un puzzle) no se requiere para ningún paso en un proceso de autenticación a menos que ese paso proporcione al menos uno de los siguientes:

• Alternativa: otro método de autenticación que no se basa en una prueba de función cognitiva.
• Mecanismo: hay un mecanismo disponible para ayudar al usuario a completar la prueba cognitiva
• Reconocimiento de objetos: la prueba de función cognitiva consiste en reconocer objetos (pueden ser imágenes, vídeos o audios).
• Contenido personal: la prueba de función cognitiva es para identificar contenido no textual que el usuario proporcionó al sitio web (pueden ser imágenes, vídeos o audios).

Ejemplos de mecanismos que satisfacen este criterio

• soporte para la entrada de contraseñas por administradores de contraseñas para reducir la necesidad de memoria,
• copiar y pegar para reducir la carga cognitiva de volver a escribir.

Se entiende por "prueba de función cognitiva" una tarea que requiere que el usuario recuerde, manipule o transcriba información, por ejemplo:

• Memorización, como recordar un nombre de usuario, contraseña, conjunto de caracteres, imágenes o patrones. Los identificadores comunes de nombre, correo electrónico y número de teléfono no se consideran pruebas de función cognitiva, ya que son personales para el usuario y coherentes en todos los sitios web;
• Transcripción, como escribir caracteres;
• Uso de ortografía correcta;
• Realización de cálculos;
• Resolución de rompecabezas.

Más información: Understanding Success Criterion 3.3.7: Accessible Authentication (AA)

3.3.9 Accessible Authentication (Enhanced) (AAA)

Es igual al criterio anterior pero más estricto, puesto que solo se admite como alternativa a la prueba de función cognitiva otro método de autenticación alternativo o un mecanismo de ayuda, pero no que la prueba consista en el reconocimiento de objetos o la identificación de contenido personal no textual.

Más información: Understanding Success Criterion 3.3.8: Accessible Authentication (No Exception) (AAA)

Artículos relacionados:

• WCAG 2.1, recomendación hasta las WCAG 3.0
• Audit Tool WCAG 2.1
• Libro Accesibilidad web. WCAG 2.1 de forma sencilla. Ya a la venta.
• WCAG 3.0 - Novedades del último borrador
• EN 301 549: Norma Europea de Accesibilidad para Productos y Servicios de Tecnologías de la Información y Comunicación (TIC) V3.1.1 (2019-11)
• Validador del Observatorio de Accesibilidad Web - Rastreador OAW. Presentación, Instalación y uso, Metodología e Informes. (Parte I)
• Reseña "Guía todo en uno sobre la accesibilidad web en España"