El pasado 5 de octubre de 2023 se marcó un hito significativo en el ámbito de la accesibilidad web con la publicación de la tan esperada recomendación de la Web Content Accessibility Guidelines (WCAG).
Este conjunto de directrices ha sido durante mucho tiempo la guía global para garantizar la accesibilidad en línea, y su última actualización promete elevar aún más los estándares en la creación de contenido digital inclusivo.
Las WCAG 2.2 buscan ampliar la accesibilidad para usuarios con discapacidad cognitiva o del aprendizaje, mejorar la experiencia de aquellos con baja visión y optimizar la navegación desde dispositivos móviles.
La última versión incorpora nueve nuevos criterios mientras se despide al criterio 4.1.1: Parsing de nivel A. Este cambio se aplica debido a que los productos de asistencia ya no dependen del análisis directo del código HTML, eliminando así los problemas que originalmente motivaron la creación de este criterio.
Esta es la pregunta del día, la obligación legal aguarda la revisión de la EN 301 549, la cual aplica para la Unión Europea y España, dicha revisión se encuentra actualmente en proceso.
Pero para aclarar cualquier tipo de duda, la WC3 ha indicado que cumplir con los requisitos de la nueva WCAG 2.2 te posiciona en una situación de cumplimento total frente a la anterior WCAG 2.1.
Teniendo en cuenta todo esto, la recomendación es familiarizarse y comenzar a integrar los nuevos criterios. Para ello hemos preparado este artículo, un texto que explora las implicaciones de la actualización proporcionando insights sobre su aplicación práctica.
Así que toma nota y sumérgete en las claves de esta actualización, descubre cómo afectará a las políticas de accesibilidad y mantente siempre informado sobre el futuro de las pautas de accesibilidad web.
Tal y como hemos comentado, la nueva actualización involucra 9 puntos a considerar, los cuales fueron abiertos a revisión, comentarios y cambios; para finalmente quedar aprobados formando parte de la Recomendación Final. La lista de los nuevos criterios de éxito son:
La finalidad de este criterio es asegurar que el elemento que adquiere el foco del teclado esté siempre parcialmente visible en la ventana gráfica del usuario.
Para los usuarios con visión que navegan a través del teclado y para aquellas personas que dependen de dispositivos que operan mediante la interfaz del teclado, como interruptores o entrada de voz, conocer la ubicación del enfoque actual resulta fundamental.
De esta forma actúa como un indicador clave del punto de interacción en la página. Si los usuarios no pueden visualizar el elemento enfocado, podrían enfrentar dificultades para entender cómo proceder o incluso interpretar que el sistema no está respondiendo.
Este criterio comparte similitudes con el anterior pero adopta un enfoque más riguroso. En este caso, al recibir el foco del teclado, ningún contenido puede ocultar las partes del indicador de enfoque del componente en la interfaz de usuario.
En otras palabras, la distinción radica en la exigencia de que la totalidad del componente enfocado sea visible, sin ninguna parte obstruida.
Inicialmente, este criterio fue concebido como un criterio de nivel AA pero debido a su complejidad, se ha decidido dejarlo como nivel AAA actuando en sinergia con los criterios 2.4.7 y 1.4.11.
El criterio 2.4.7 “Foco visible” establece la exigencia de que el foco de teclado sea perceptible. La finalidad de este nuevo criterio es complementar dicha norma, asegurando que el foco de teclado no solo sea visible, sino también claramente discernible.
Además, el criterio 1.4.11 “Contraste no textual AA,” requiere que el foco de teclado tenga al menos un contraste de 3:1, y que el componente de interacción mantenga un contraste adecuado con el fondo tanto en su estado por defecto como en su estado enfocado.
Por lo tanto, el nuevo criterio 2.4.13 se presenta de manera simplificada, definiendo claramente que, cuando el indicador del foco de teclado es visible, debe cumplir con los siguientes requisitos:
Sabemos que aplicar la acción de arrastrar y soltar requiere un movimiento bastante preciso, el cual consiste en mantener el dedo en el botón sobre la pantalla sin soltarlo.
Dicha acción, puede resultar bastante difícil para personas con alguna discapacidad motora, por eso, este criterio busca que la acción de arrastrar y soltar pueda realizarse de una forma distinta a la que ya conocemos.
Esta pauta, propone una distancia mínima entre los elementos de interacción para que las personas que no tienen movimientos finos en las manos, puedan activar botones pequeños de una manera más fácil y sin riesgo de equivocarse.
Con la finalidad de que los usuarios puedan encontrar de manera fácil la ayuda que necesitan, este criterio establece que las funciones de ayuda que se encuentran en varias páginas del sitio web, aparezcan en el mismo lugar.
Esto, con la finalidad de poder ayudar a personas con discapacidad cognitiva, las cuales, en muchas oportunidades, deben seguir un patrón para completar sus tareas.
La finalidad de este criterio es asegurar que los usuarios puedan llevar a cabo con éxito procesos de múltiples pasos. Se orienta a disminuir la carga cognitiva al requerir información en más de una ocasión durante un proceso, reduciendo así la necesidad de recordar datos proporcionados en pasos anteriores.
La información que es crucial recordar puede representar un obstáculo significativo para usuarios que enfrentan dificultades cognitivas o de memoria. Este criterio busca aliviar esa carga, haciendo que los procesos sean más accesibles y menos demandantes para este grupo de usuarios.
Este criterio tiene como objetivo hacer que la autenticación sea más accesible, eliminando la necesidad de realizar pruebas de función cognitiva (como recordar contraseñas o resolver acertijos) en cada paso del proceso de autenticación.
A menos de que el paso en cuestión cumpla con lo siguiente:
Este criterio, a pesar de ser similar al anterior, adopta una postura más rigurosa. Aquí, se permite únicamente como alternativa a la prueba de función cognitiva la presencia de otro método de autenticación alternativo o un mecanismo de ayuda.
No se acepta la opción de que la prueba se base en el reconocimiento de objetos o en la identificación de contenido no textual por parte del usuario.
De esta forma, la WCAG 2.2 busca cubrir, cada vez más, las necesidades que puedan presentar las personas con discapacidad, ofreciéndoles una solución de accesibilidad web que les permita poder navegar de manera libre y autónoma por la red.
Desde inSuit, seguimos con nuestro compromiso de realizar constantes actualizaciones en nuestros productos y servicios en base a las novedades que van surgiendo en las Pautas de Accesibilidad al Contenido en la Web (WCAG).
Nuestro equipo de expertos en accesibilidad digital ya está trabajando al máximo para poder conseguir que nuestras soluciones estén alineadas con la nueva WCAG 2.2. Buscando siempre, poder ofrecer un servicio de accesibilidad web que se adapte a las normativas nacionales e internacionales, e intentado ir siempre un paso por delante.
Así que, si estás buscando una solución para que tu página sea accesible de manera que esté alineada con los requisitos especificados en la nueva WCAG 2.2, contáctanos sin ningún compromiso.