WCAG 2.2 (recomendación - octubre 2023) Todas las novedades de la nueva versión de las WCAG.

El 5 de octubre de 2023, después de un proceso de varios años, se ha publicado la recomendación de la nueva versión de las WCAG, las Web Content Accessibility Guidelines (WCAG) 2.2.

Las WCAG son el estándar de accesibilidad reconocido a nivel mundial. En la Unión Europea, y por tanto en España, nos guíamos por el estándar de accesibilidad EN 301 549, que engloba los requisitos de las WCAG más otros requisitos adicionales.

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 del 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 son una nueva ampliación de 9 criterios, donde además se elimina el criterio 4.1.1.

Importante: si se cumple con las WCAG 2.2 se cumple también con las WCAG 2.1.

En paralelo, se está trabajando en las WCAG 3.0, que podéis seguir en el artículo WCAG 3.0 - Novedades del último borrador, que actualizo con cada versión que se publica.

¿Tengo que aplicar ya las WCAG 2.2?

Esto es lo más preguntado hoy (6/10/2023). Lo más recomendable es que empieces ya a familiarizarte y a incluir los nuevos criterios de conformidad en los requisitos y las evaluaciones.

Pero si nos referimos a la obligación legal, hay que esperar a la revisión de la EN 301 549 (actualmente en proceso).

Cuando se publique en el Diario Oficial de la Unión Europea la nueva versión de la EN 301 549 que recoja los nuevos requisitos de las WCAG 2.2, entonces serán de obligado cumplimiento en España y la Unión Europea.

Por ejemplo, el Real Decreto 1112/2018, que regula la accesibilidad en el sector público, indica que la norma a aplicar será: la última actualización de la norma de referencia EN 301 549 publicada en el Diario Oficial de la Unión Europea. Se entiende que, desde ese momento, la plantilla para el informe IRA (Informe de Revisión de Accesibilidad) del Observatorio de Accesibilidad Web (OAW) también se adaptará a los nuevos requisitos.

Este proceso ya lo hemos vivido en el pasado. La actualización de la EN 301 549 de 2018 incluyó los nuevos requisitos de las WCAG 2.1, ya que anteriormente la EN 301 549 incluía solo los requisitos de las WCAG 2.0

Como siempre, os informaré cuando todo esto ocurra.

Criterio que se elimina en la WCAG 2.2

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

Se añaden 9 criterios nuevos: 2 de nivel A, 4 de nivel AA y 3 de nivel AAA.

1. Criterio 2.4.11 Focus Not Obscured (Minimum) (AA)
2. Criterio 2.4.12 Focus Not Obscured (Enhanced) (AAA)
3. Criterio 2.4.13 Focus Appearance (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)

2.4.11 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.

Los ejemplos más habituales de contenidos que se superponen a un elemento con el foco son los pies y encabezados fijos o las capas no modales, por ejemplo, la capa de aceptación de cookies.

Si la superposición es semiopaca estaría cumpliendo el criterio, porque no ocultaría por completo el foco, pero podría incumplir el criterio 1.4.11 de contraste no textual, si el foco de teclado no alcanza una ratio de contraste de 3:1.

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

El contenido abierto por el usuario puede ocultar el componente que recibe el foco. En estos casos, si el usuario puede revelar el componente con el foco sin avanzar el foco del teclado, el componente con el foco no se considera que esté oculto debido al contenido creado por el autor y, por tanto, cumplirá el criterio. Las acciones que permiten revelar el elemento con el foco podrían ser:

• pulsar ESC para descartar el contenido abierto;
• usar las teclas para desplazar el contenido;
• pulsar una tecla para moverte entre las superposiciones.

Los menús desplegables, los campos desplegables, los calendarios de selección de fecha o los tooltips son componentes que tapan el contenido, pero no son persistentes, es decir, no se espera que persistan después de que se actúe sobre ellos o una vez que ya no sean el punto principal de interacción del usuario, por lo tanto, no incumplen este criterio. Sin embargo, si el autor permite que persistan después de que el usuario haya activado uno de los elementos abiertos o quitado el foco del elemento activador y el contenido adicional, sí que pueden estar incumpliendo el criterio.

Por ejemplo, si abres un menú desplegable y, cuando lo abandonas con el foco del teclado, no se cierra, si el foco de teclado acaba en un contenido oculto por ese menú desplegable no cerrado, se estaría incumpliendo el criterio.

Por ejemplo, en una ventana modal bien construida, donde el foco de teclado se queda dentro de la ventana, no se incumplirá este criterio.

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

2.4.12 Focus Not Obscured (Enhanced) (AAA)

Es igual que el 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.12 Focus Not Obscured (Enhanced) (AAA)

2.4.13 Focus Appearance (AAA)

Este criterio se planteó en un principio como nivel AA, pero, dada su complejidad, se ha optado por simplificarlo y dejarlo como nivel AAA.

Este criterio complementa a los criterios 2.4.7 y 1.4.11

El criterio 2.4.7 Foco visible 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.13 queda simplificado y redactado de tal manera que especifica que, cuando el indicador del foco de teclado es visible, el indicador del foco cumple lo siguiente:

• es al menos tan grande como el área de un perímetro de 2 píxel CSS de grosor del componente o subcomponente sin el foco; y
• tiene una ratio de contraste de al menos 3:1 entre los mismos píxeles en el estado con el foco y sin el foco

Hay dos excepciones:

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

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. Subcomponentes que pueden recibir un indicador del foco serían, por ejemplo, los elementos de menú en un menú desplegable abierto o las celdas interactivas de una grid.

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.

Más información y ejemplos: Understanding Success Criterion 2.4.13: Focus Appearance (AA)

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.

Atención: no es lo mismo "deslizar" que "arrastrar". Que necesites gestos simples para deslizar un carrusel (por ejemplo, incluyendo botones de flecha), ya está cubierto por el criterio 2.5.1 Gestos del puntero.

Hablamos de "arrastrar" cuando en el evento de bajada un elemento, o una representación de su posición, sigue al puntero hasta el evento de subida.

También hay que aclarar que un componente con drag&drop ya tiene que ser actualmente accesible por teclado gracias al criterio 2.1.1, pero esto no implica que esa solución funcione mediante toques simples, eso lo cubre este nuevo criterio.

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

2.5.8 Target Size (Minimum) (AA)

Este criterio es la versión menos estricta para el nivel AA del criterio "2.5.5 Tamaño del área de interacción (AAA)", que establece el tamaño mínimo del área de interacción en 44 x 44 píxeles CSS. En el nivel AA, este nuevo criterio establece el tamaño mínimo en 24 x 24 píxeles CSS.

La intención de este criterio es que los elementos interactivos se puedan activar fácilmente sin pulsar por accidente uno adyacente. Cuando la zona de interacción de un objeto es pequeña, las personas con temblores en las manos, o con dificultad con el movimiento motor fino, tienen problemas para activarlos con precisión. Proporcionar un tamaño suficiente, o un espaciado suficiente entre las zonas de interacción, reducirá la probabilidad de activar por accidente el control incorrecto.

El criterio indica que el tamaño de la zona interacción con el puntero debe tener un área con un ancho y alto de al menos 24 píxeles CSS, EXCEPTO cuando:

• Espaciado: las zonas de interacción que tienen un tamaño menor de 24 x 24 píxeles CSS se colocan de tal modo que, si dibujas un círculo de 24 píxeles CSS de diámetro centrado en el cuadro delimitador de cada una, los círculos no intersecan con otro objeto o con el círculo de otra zona de interacción de un tamaño menor de 24x24px CSS.
• 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 su tamaño está restringido por la altura de línea del texto que no forma parte del área de interacción. La altura de la línea debe interpretarse como perpendicular al flujo de texto. Por ejemplo, en un idioma que se escribe verticalmente, la altura de la línea sería horizontal.
• 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. Por ejemplo, podrían ser los días del calendario del mes en un input type="date".
• Esencial: una presentación particular del área de interacción es esencial o es legalmente requerida para la información que se transmite. Por ejemplo, en los mapas, los pines que indican los lugares pueden presentarse muy juntos, pero es esencial mostrarlos en la ubicación correcta del mapa.

Para comprender la primera excepción, se ofrecen algunos ejemplos:

Imágenes de "Understanding SC 2.5.8: Target Size (Minimum) (Level AA)" del W3C

A efectos de este criterio de conformidad, se considera también como zona de interacción aquella que permite que los valores se seleccionen espacialmente en función de la posición dentro de la zona de interacción. Por ejemplo, controles deslizantes con valores granulares, selectores de color que muestran un degradado de colores o las áreas editables donde colocas el cursor.

Como se indica en la excepción "en línea", no se aplica a las zonas de interacción en línea en oraciones, listas de viñetas o numeradas, o donde el tamaño del área de interacción está limitado por la altura de la línea del texto que no forma parte de la zona de interacción.

Esta excepción está permitida porque el reflujo de texto basado en el tamaño de la ventana hace imposible que los autores anticipen dónde se pueden ubicar los enlaces entre sí. Cuando se incrustan varios enlaces en bloques de texto con tamaños de texto más pequeños, mantener un desplazamiento de 24 píxeles CSS entre los enlaces en líneas de texto adyacentes requeriría una gran altura de línea que puede ser indeseable en muchos contextos de diseño. Además, las notas numéricas en línea pueden tener un tamaño muy por debajo de los 24 píxeles CSS.

Se indica que los enlaces marcados como lista en una estructura de navegación NO cuentan como enlaces en línea, y por tanto NO son una excepción. Los autores pueden anticipar la posición relativa de estos enlaces y proporcionar suficiente espacio para la zona de interacción.

Imagen de "Understanding SC 2.5.8: Target Size (Minimum) (Level AA)" del W3C

AXE ya ofrece la validación de criterios WCAG 2.2 como este, de momento solo en la versión PRO. Puedes seleccionarlo en "Settings > Experimental rules > Select accessibility standard".

AXE: error de validación en el criterio 2.5.8

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

3.2.6 Consistent Help (A)

Es 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.

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 el usuario inicie un cambio (como cambiar el nivel de zoom, la orientación o el tamaño de la ventana):

• 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 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.

Si el elemento de ayuda está visualmente en una ubicación diferente, pero en el mismo orden de relativo, no incumplirá este criterio, pero será menos útil, menos usable, empeorando así la experiencia de usuario.

Importante: la ubicación puede cambiar en la versión responsive. Este criterio se refiere al orden relativo de los elementos de contacto y ayuda entre las páginas mostradas en la misma variación de página (por ejemplo, el mismo nivel de zoom y la misma orientación).

Por otra parte, hay portales que constan de múltiples conjuntos diferentes de páginas con diferentes propósitos. Este criterio de conformidad permitiría que los diferentes conjuntos de páginas web utilicen diferentes ubicaciones de mecanismos de ayuda. Sin embargo, es mejor si los mecanismos de ayuda están ubicados de la manera más consistente posible incluso entre diferentes conjuntos de páginas web relacionadas.

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, puede autocompletarse 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 (por ejemplo, incluir dos veces la nueva contraseña).
• La información ingresada anteriormente ya no es válida.

El objetivo es no obligar a introducir la información dos veces, reutilizando la información ya incluida. Esto favorece especialmente a las personas con movilidad reducida y con discapacidad cognitiva, pero mejora la usabilidad para todos los usuarios.

Un ejemplo típico es la casilla de verificación "Dirección de facturación igual a la dirección de envío" en los formularios de compra, para no obligar a introducir la dirección dos veces.

Es importante insistir que se refiere solo a la información introducida en el mismo proceso o sesión.

Más información: Understanding Success Criterion 3.3.7: 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.

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

• Alternativa: otro método de autenticación que no depende de 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 tiene como objetivo 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 el ingreso de contraseñas por parte de 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 consistentes 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.8: Accessible Authentication (AA)

3.3.9 Accessible Authentication (Enhanced) (AAA)

Es igual que el 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.9: 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"