{"id":7752,"date":"2023-10-06T10:51:00","date_gmt":"2023-10-06T08:51:00","guid":{"rendered":"https:\/\/www.insuit.net\/?p=7752"},"modified":"2024-06-13T12:40:25","modified_gmt":"2024-06-13T10:40:25","slug":"wcag-2-2","status":"publish","type":"post","link":"https:\/\/www.insuit.net\/es\/wcag-2-2\/","title":{"rendered":"Publicaci\u00f3n de las WCAG 2.2 y su impacto en la accesibilidad web"},"content":{"rendered":"\n
El pasado 5 de octubre de 2023 <\/strong>se marc\u00f3 un hito significativo en el \u00e1mbito de la accesibilidad web con la publicaci\u00f3n de la tan esperada recomendaci\u00f3n de la<\/strong> Web Content Accessibility Guidelines (WCAG)<\/a>. <\/p>\n\n\n\n Este conjunto de directrices ha sido durante mucho tiempo la gu\u00eda global para garantizar la accesibilidad en l\u00ednea<\/strong>, y su \u00faltima actualizaci\u00f3n promete elevar a\u00fan m\u00e1s los est\u00e1ndares en la creaci\u00f3n de contenido digital inclusivo.<\/p>\n\n\n\n Las WCAG 2.2<\/a> buscan ampliar la accesibilidad<\/strong> para usuarios con discapacidad cognitiva o del aprendizaje<\/strong>, mejorar la experiencia de aquellos con baja visi\u00f3n <\/strong>y optimizar la navegaci\u00f3n desde dispositivos m\u00f3viles.\u00a0<\/p>\n\n\n\n La \u00faltima versi\u00f3n incorpora nueve nuevos criterios mientras se despide al<\/strong> criterio 4.1.1: Parsing de nivel A<\/a>. Este cambio se aplica debido a que los productos de asistencia ya no dependen del an\u00e1lisis directo del c\u00f3digo HTML, eliminando as\u00ed los problemas que originalmente motivaron la creaci\u00f3n de este criterio. <\/p>\n\n\n\n Esta es la pregunta del d\u00eda, la obligaci\u00f3n legal aguarda la revisi\u00f3n de la<\/strong> EN 301 549<\/a>, la cual aplica para la Uni\u00f3n Europea y Espa\u00f1a, dicha revisi\u00f3n se encuentra actualmente en proceso. <\/p>\n\n\n\n Pero para aclarar cualquier tipo de duda, la WC3 ha indicado que cumplir con los requisitos de la nueva WCAG 2.2<\/strong> te posiciona en una situaci\u00f3n de cumplimento total frente a la anterior WCAG 2.1<\/strong>.<\/p>\n\n\n\n Teniendo en cuenta todo esto, la recomendaci\u00f3n es familiarizarse y comenzar a integrar los nuevos criterios<\/strong>. Para ello hemos preparado este art\u00edculo, un texto que explora las implicaciones de la actualizaci\u00f3n proporcionando insights sobre su aplicaci\u00f3n pr\u00e1ctica<\/strong>.<\/p>\n\n\n\n As\u00ed que toma nota y sum\u00e9rgete en las claves de esta actualizaci\u00f3n, descubre c\u00f3mo afectar\u00e1 a las pol\u00edticas de accesibilidad y mantente siempre informado<\/strong> sobre el futuro de las pautas de accesibilidad web. <\/p>\n\n\n\n Tal y como hemos comentado, la nueva actualizaci\u00f3n involucra 9 puntos a considerar, los cuales fueron abiertos a revisi\u00f3n, comentarios y cambios<\/strong>; para finalmente quedar aprobados formando parte de la Recomendaci\u00f3n Final. La lista de los nuevos criterios de \u00e9xito son:<\/strong><\/p>\n\n\n\n La finalidad de este criterio es asegurar que el elemento que adquiere el foco del teclado est\u00e9 siempre parcialmente visible<\/strong> en la ventana gr\u00e1fica del usuario. <\/p>\n\n\n\n Para los usuarios con visi\u00f3n que navegan a trav\u00e9s del teclado y para aquellas personas que dependen de dispositivos que operan mediante la interfaz del teclado<\/strong>, como interruptores o entrada de voz, conocer la ubicaci\u00f3n del enfoque actual resulta fundamental<\/strong>. <\/p>\n\n\n\n De esta forma act\u00faa como un indicador clave del punto de interacci\u00f3n en la p\u00e1gina<\/strong>. Si los usuarios no pueden visualizar el elemento enfocado, podr\u00edan enfrentar dificultades para entender c\u00f3mo proceder o incluso interpretar que el sistema no est\u00e1 respondiendo.<\/p>\n\n\n\n Este criterio comparte similitudes con el anterior pero adopta un enfoque m\u00e1s riguroso<\/strong>. En este caso, al recibir el foco del teclado, ning\u00fan contenido puede ocultar las partes del indicador de enfoque del componente en la interfaz de usuario<\/strong>. <\/p>\n\n\n\n En otras palabras, la distinci\u00f3n radica en la exigencia de que la totalidad del componente enfocado sea visible<\/strong>, sin ninguna parte obstruida.<\/p>\n\n\n\n Inicialmente, este criterio fue concebido como un criterio de nivel AA pero debido a su complejidad, se ha decidido dejarlo como nivel AAA<\/strong> actuando en sinergia con los criterios 2.4.7 y 1.4.11. <\/p>\n\n\n\n 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\u00e9n claramente discernible<\/strong>. <\/p>\n\n\n\n Adem\u00e1s, 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\u00f3n mantenga un contraste adecuado con el fondo<\/strong> tanto en su estado por defecto como en su estado enfocado. <\/p>\n\n\n\n Por lo tanto, el nuevo criterio 2.4.13 se presenta de manera simplificada, definiendo claramente que<\/strong>, cuando el indicador del foco de teclado es visible, debe cumplir con los siguientes requisitos:<\/p>\n\n\n\n Sabemos que aplicar la acci\u00f3n de arrastrar y soltar requiere un movimiento bastante preciso<\/strong>, el cual consiste en mantener el dedo en el bot\u00f3n sobre la pantalla sin soltarlo.<\/p>\n\n\n\n Dicha acci\u00f3n, puede resultar bastante dif\u00edcil para personas con alguna discapacidad motora<\/strong>, por eso, este criterio busca que la acci\u00f3n de arrastrar y soltar pueda realizarse de una forma distinta<\/strong> a la que ya conocemos.<\/p>\n\n\n\n Esta pauta, propone una distancia m\u00ednima entre los elementos de interacci\u00f3n<\/strong> para que las personas que no tienen movimientos finos en las manos, puedan activar botones peque\u00f1os de una manera m\u00e1s f\u00e1cil<\/strong> y sin riesgo de equivocarse.<\/p>\n\n\n\n Con la finalidad de que los usuarios puedan encontrar de manera f\u00e1cil la ayuda que necesitan<\/strong>, este criterio establece que las funciones de ayuda <\/strong>que se encuentran en varias p\u00e1ginas del sitio web, aparezcan en el mismo lugar<\/strong>.<\/p>\n\n\n\n Esto, con la finalidad de poder ayudar a personas con discapacidad cognitiva<\/strong>, las cuales, en muchas oportunidades, deben seguir un patr\u00f3n para completar sus tareas.<\/p>\n\n\n\n La finalidad de este criterio es asegurar que los usuarios puedan llevar a cabo con \u00e9xito procesos de m\u00faltiples pasos.<\/strong> Se orienta a disminuir la carga cognitiva al requerir informaci\u00f3n en m\u00e1s de una ocasi\u00f3n durante un proceso<\/strong>, reduciendo as\u00ed la necesidad de recordar datos proporcionados en pasos anteriores.<\/p>\n\n\n\n La informaci\u00f3n que es crucial recordar puede representar un obst\u00e1culo significativo<\/strong> para usuarios que enfrentan dificultades cognitivas o de memoria. Este criterio busca aliviar esa carga<\/strong>, haciendo que los procesos sean m\u00e1s accesibles y menos demandantes para este grupo de usuarios.<\/p>\n\n\n\n Este criterio tiene como objetivo hacer que la autenticaci\u00f3n sea m\u00e1s accesible, eliminando la necesidad de realizar pruebas de funci\u00f3n cognitiva<\/strong> (como recordar contrase\u00f1as o resolver acertijos) en cada paso del proceso de autenticaci\u00f3n. <\/p>\n\n\n\n A menos de que el paso en cuesti\u00f3n cumpla con lo siguiente<\/strong>:<\/p>\n\n\n\n Este criterio, a pesar de ser similar al anterior, adopta una postura m\u00e1s rigurosa<\/strong>. Aqu\u00ed, se permite \u00fanicamente como alternativa a la prueba de funci\u00f3n cognitiva la presencia de otro m\u00e9todo de autenticaci\u00f3n alternativo o un mecanismo de ayuda. <\/p>\n\n\n\n No se acepta la opci\u00f3n de que la prueba se base en el reconocimiento de objetos o en la identificaci\u00f3n de contenido no textual<\/strong> por parte del usuario.<\/p>\n\n\n\n De esta forma, la WCAG 2.2 busca cubrir, cada vez m\u00e1s, las necesidades que puedan presentar las personas con discapacidad<\/strong>, ofreci\u00e9ndoles una soluci\u00f3n de accesibilidad web que les permita poder navegar de manera libre y aut\u00f3noma por la red.<\/p>\n\n\n\n Desde inSuit, seguimos con nuestro compromiso de realizar constantes actualizaciones<\/a> en nuestros productos y servicios en base a las novedades que van surgiendo en las Pautas de Accesibilidad al Contenido en la Web (WCAG)<\/strong>.<\/p>\n\n\n\n Nuestro equipo de expertos en accesibilidad digital ya est\u00e1 trabajando al m\u00e1ximo para poder <\/strong>conseguir que nuestras soluciones est\u00e9n alineadas con la nueva WCAG 2.2<\/strong>. <\/strong>Buscando siempre, poder ofrecer un servicio de accesibilidad web<\/a> que se adapte a las normativas nacionales e internacionales<\/strong>, e intentado ir siempre un paso por delante.<\/p>\n\n\n\n As\u00ed que, si est\u00e1s buscando una soluci\u00f3n para que tu p\u00e1gina sea accesible de manera que est\u00e9 alineada con los requisitos especificados en la nueva WCAG 2.2<\/strong>, cont\u00e1ctanos<\/a> sin ning\u00fan compromiso.<\/p>\n\n\n\n\u00bfEs el momento de implementar las WCAG 2.2? <\/h2>\n\n\n\n
Nuevos criterios de \u00e9xito actualizados en la WCAG 2.2<\/h2>\n\n\n\n
2.4.11 Enfoque no oscurecido (M\u00ednimo) (Nivel AA)<\/h3>\n\n\n\n
2.4.12 Enfoque no oscurecido (Mejorado) (Nivel AA)<\/h3>\n\n\n\n
2.4.13 Apariencia de enfoque (Nivel AAA)<\/h3>\n\n\n\n
\n
2.5.7 Movimientos de arrastre (Nivel AA)<\/h3>\n\n\n\n
2.5.8 Tama\u00f1o del objetivo (M\u00ednimo) (Nivel AA)<\/h3>\n\n\n\n
3.2.6 Ayuda consistente (Nivel A)<\/h3>\n\n\n\n
3.3.7 Entrada redundante (A)<\/h3>\n\n\n\n
3.3.8 Autenticaci\u00f3n accesible (M\u00ednimo) (Nivel AA)<\/h3>\n\n\n\n
\n
3.3.9 Autenticaci\u00f3n accesible (Mejorada) (AAA)<\/h3>\n\n\n\n
inSuit toma en cuenta la nueva WCAG 2.2 de cara a sus actualizaciones en su plataforma de accesibilidad y servicios 360<\/h2>\n\n\n\n