Nuevas pautas de accesibilidad en las WCAG 2.2

Accesibilidad
21/2/2024
|
Torresburriel Estudio
Señalización de 'Entrada accesible' fijada en una pared de ladrillos multicolor, mostrando el símbolo internacional de acceso y texto en contraste para indicar un acceso sin barreras.

Las WCAG son una serie de pautas de accesibilidad para el contenido web, suponen un estándar de accesibilidad reconocido a nivel mundial. En la Unión Europea, y por ende en España, seguimos el estándar EN 301 549 que comprende los requisitos de las WCAG así como otros adicionales.

Las WCAG 2.2 son la continuidad de las WCAG 2.1, nos indican mejoras de la accesibilidad para usuarios con discapacidad cognitiva o del aprendizaje, y usuarios con baja visión. Así como mejoras en la accesibilidad desde dispositivos móviles. 

Las WCAG 2.2 amplían las pautas, sumando 9 criterios nuevos, y eliminando el criterio 4.1.1 de las WCAG 2.1.

Legalmente hablando aún no es obligatorio aplicar las WCAG 2.2, ya que deben incluirse en la EN 301 549, que actualmente está en proceso de revisión. Cuando se publique en el Diario Oficial de la Unión Europea la nueva versión de la EN 301 549 con los criterios de las WCAG 2.2, entonces sí serán de obligado cumplimiento para España y la Unión Europea.

Estas son las novedades:

Criterio 4.1.1 eliminado

El criterio 4.1.1 “Procesamiento” (A) proviene de las WCAG 2.1, y se descarta con las WCAG 2.2. 

El motivo es que se adoptó inicialmente para paliar los problemas que tenía la tecnología de asistencia al analizar el HTML directamente. Sin embargo, las tecnologías asistivas ya no analizan el HTML directamente, por ello este criterio ya no aplica.

Los fallos de accesibilidad en este criterio tienen como consecuencia la no conformidad en otros criterios, por estos motivos no resulta útil.

Nuevos criterios

En esta última versión, tenemos las siguientes ampliaciones: 2 criterios de nivel A, 4 de nivel AA y 3 criterios de nivel AAA

Novedades de la directriz 2.4 Navegable

La directriz 2.4 se encuentra dentro del principio número dos: operabilidad, que dice que los componentes de la interfaz de usuario y la navegación deben ser operables.

Criterio 2.4.11 “Foco no oculto” (AA)

El elemento que posee el foco de teclado no puede quedar totalmente oculto por un contenido creado por el autor del sitio (pie o cabecera fijos, capas no modales – cookies-, menú o desplegable que permanece abierto al perder el foco, etc).

Captura de pantalla de un aviso de cookies en un sitio web con botones para 'Denegar', 'Personalizar' y 'Permitir todas', destacados en un diseño de interfaz clara con encabezados de 'Empresa', 'Contenido destacado' y 'Asuntos legales'.
Ejemplo de elemento oculto. Fuente: elaboración propia.

Si la superposición es semiopaca se cumpliría este criterio. Sin embargo, podría incumplir el 1.4.11 que trata del contraste no textual, si el foco de teclado no alcanza el ratio de contraste de 3:1.

Se permite el caso de que el contenido abierto por el usuario oculte el elemento enfocado, si el usuario puede volver al elemento enfocado sin avanzar el foco de teclado. Dentro de las acciones que permiten regresar al componente con el foco, encontramos las siguientes:

  • Pulsar ESC para descartar el contenido abierto
  • Usar las teclas para desplazar el contenido
  • Pulsar una tecla para moverse entre las superposiciones
Captura de pantalla de una interfaz de usuario mostrando dos estados de un botón de chat online, uno inactivo y otro activo con una ventana modal y una foto de perfil de asistencia al cliente.
1. Se muestra un botón que al hacer clic nos dará acceso a un chat online. 2. Una vez se hace clic en el botón de la imagen anterior, la modal del chat se superpone al botón ocultándolo. Fuente: Elaboración propia.

Referencia: Understanding Success Criterion 2.4.11 Focus Not Obscured (Minimum) (AA)

Criterio 2.4.12 “Foco no oculto” (Mejorado) (AAA)

Este criterio es igual al anterior pero más estricto. El criterio 2.4.11 decía que un elemento que posee el foco de teclado no puede quedar totalmente oculto por un contenido creado por el autor del sitio, el 2.4.12 matiza que no puede quedar ni parcial ni totalmente oculto.

Referencia: Understanding Success Criterion 2.4.12 Focus Not Obscured (Enhanced) (AAA)

Criterio 2.4.13 “Apariencia del foco” (AAA)

Este criterio viene a complementar a los criterios 2.4.7 y 1.4.11. Su objetivo es garantizar que la apariencia del foco del teclado sea claramente visible y discernible.

El criterio 2.4.7 “Foco visible” exige que el foco del teclado sea visible. En el 2.4.13 se define un nivel mínimo de visibilidad, basado en el tamaño y el contraste.

El criterio 1.4.11 “Contraste no textual” fija que el foco de teclado tenga un contraste de al menos 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 focus. El criterio 2.4.13 requiere un contraste suficiente entre los dos estados del componente: son foco y sin foco.

Cuando el indicador del foco de teclado es visible, debe cumplir lo siguiente:

  • Tamaño: es al menos tan grande como el área de un perímetro de 2px CSS de grosor del componente o subcomponente sin el foco.
  • Contraste: tiene una relación de contraste de al menos 3:1 entre los mismos píxeles para los estados con y sin foco. 

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

Los cálculos de contraste pueden basarse en colores definidos dentro de la tecnología (como HTML, CSS y SVG). Se pueden ignorar los píxeles modificados por las mejoras en la resolución del agente de usuario y el suavizado.

Comparación de botones con el texto 'EXAMPLE', mostrando dos estilos diferentes de enfoque visual para accesibilidad AAA en diseño web.
El indicador de foco es un contorno sólido de 2 píxeles de grosor. Fuente: WCAG 2.2 Understanding Docs.
Ejemplo de estilos de enfoque para botones en diseño web, mostrando las variantes 'UNFOCUSED', 'OUTSET', 'OUTLINE', 'BORDER' e 'INSET' para cumplir con criterios de accesibilidad AAA.
En la segunda fila de botones se utiliza un contorno de 2px de grosor para indicar el foco, los tres primeros son correctos y cumplen con el criterio 2.4.13. El cuarto no pasa el requisito de tamaño mínimo ya que debería tener un grosor superior a 2px CSS. Fuente: WCAG 2.2 Understanding Docs.

Referencia: Understanding Success Criterion 2.4.13: Focus Appearance (AA)

En definitiva, las WCAG 2.2 son un pilar fundamental en la construcción de un internet más accesible para todos. En este artículo hemos explorado sus bases y cómo se integran en el marco legal europeo. 

En el próximo artículo, hablaremos del resto de ampliaciones de los criterios 2.5, 3.2 y 3.3.


Foto de portada de Daniel Ali en Unsplash.

¿Quieres darnos tu impresión sobre este post?

Deja una respuesta

Aquí va tu texto personalizado.

Blog

Nos encanta compartir lo que sabemos sobre diseño de producto y experiencia de usuario.
Ver todo el blog
Puedes consultarnos lo que necesites
Envíanos un mensaje
Nombre
Email
Mensaje
Gracias por escribirnos. Nuestro equipo se pondrá en contacto contigo tan pronto como sea posible.
Ha ocurrido un error. Estamos trabajando para resolverlo. Puedes escribirnos al chat.
Mastodon