El borrador WCAG 2.2

Hoy 11 de agosto el AG WG (Accessibility Guidelines Working Group) ha liberado el nuevo borrador de las WCAG 2.2. Imagino que ya sabes qué son las Guías de Accesibilidad del Contenido Web (WCAG), así que me centraré en escribir sobre las novedades de esta versión.

El contexto del borrador WCAG 2.2

Primero nos ponemos en contexto, durante la redacción de la versión 2.1 algunas cosas se quedaron en el tintero y no les dio tiempo para incluirlas adecuadamente. Para poder incluir un criterio de éxito (los puntos de la WCAG que son evaluables) es necesario que se aprueben tres cosas:

• El criterio de éxito propiamente dicho («la frase»)
• El understanding (documento en el que se explica cuál es el propósito del criterio, los beneficios, ejemplos, recursos relacionados y técnicas)
• Al menos una técnica (ejemplo sobre cómo valorar el cumplimiento del criterio de éxito)

Una vez se han redactado todos los documentos asociados al criterio de éxito se añaden al borrador de WCAG 2.2 y se publica para que podamos expresar nuestra opinión al respecto y en caso necesario hacer las modificaciones que sean necesarias en los criterios y documentos.

Los nuevos criterios de éxito

En este borrador se han añadido 9 criterios respecto al borrador anterior. He traducido los nombres por mi cuenta, como no es una traducción oficial dejo también el nombre original entre paréntesis:

• Autenticación accesible (Accessible Authentication)
• Arrastrar (Dragging)
• Ayuda encontrable (Findable Help)
• Puntos de referencia fijos (Fixed Reference Points)
• Aspecto del foco (mínimo) (Focus Appearance (Minimum))
• Aspecto del foco (mejorado) (Focus Appearance (Enhanced))
• Controles ocultos (Hidden Controls)
• Espacio en los elementos accionables (Pointer Target Spacing)
• Entradas redundantes (Redundant Entry)

Autenticación accesible

«Si el proceso de autenticación se basa en una función cognitiva se proporciona al menos de otro método que no se base en la misma función»

Con los logins hemos topao. La autenticación en la web debe de ser accesible, fácil de usar y segura. Principalmente se usan nombres de usuario y contraseñas, pero este método puede ser imposible de usar para personas con ciertas discapacidades cognitivas.

Cuando el proceso de autenticación se basa en funciones cognitivas estaremos generando una barrera para personas con problemas de memoria, dislexia, discalculia, etc. Para evitarla deberemos proporcionar métodos alternativos como son la autenticación con otros dispositivos o servicios de terceros.

Este nuevo criterio es de nivel A, es decir, imprescindible.

Arrastrar

«Toda funcionalidad que use un movimiento de arrastrar se puede operar con toques a no ser que el movimiento de arrastre sea esencial»

Aquí me he tomado mi licencia interpretativa porque el criterio dice explícitamente «single pointer«. El criterio se refiere a que cuando se diseña una UI para que arrastremos un elemento de una posición a otra esta misma función se debe de poder hacer sin tener que arrastrar físicamente el periférico o el dedo por la pantalla, es decir, tocar el elemento en su posición inicial y en su posición final.

Este criterio va a ayudar especialmente a las personas con problemas de movilidad, que no cuenten con la destreza necesaria o que usen ayudas técnicas muy específicas que no sean compatibles con el arrastre, por ejemplo los eye-trackers.

Este nuevo criterio es de nivel AA, es decir, necesario.

Ayuda encontrable

Otra de mis licencias en la traducción para «findable help». El criterio dice: «Para una aplicación en una única página o cualquier conjunto de páginas web, si alguno de los siguientes puntos está disponible lo deberá estar en el mismo orden relativo en cada página:

• Datos de contacto
• Mecanismo de contacto
• Opciones de auto ayuda
• Mecanismo de contacto automatizado»

Forma parte de la coherencia que debe mantener un sitio web. El orden de los menús, los enlaces, etc. debe de seguir una estructura coherente maximizando así la usabilidad una vez el usuario se ha acostumbrado.

Este nuevo criterio es de nivel A, es decir, imprescindible.

Puntos de referencia fijos

«Cuando una página web o un conunto de páginas webs es una publicación electrónica con puntos de referencia, está disponible un mecanismo para navegar a cada punto y cada punto mantiene su posición dentro del contenido incluso cuando se modifica el aspecto del formato o la plataforma».

Esto significa que el contenido debe de estar estructurado de la misma forma independientemente de la forma de acceder al mismo. Si la estructura de un contenido es una en concreto en versión de escritorio y tiene sus puntos de referencia a nivel programático y visual deberá de ser coherente en otros formatos de visualización como es el móvil o la versión impresa. Por ejemplo, si tenemos un contenido distribuido por páginas es crítico que la página 1 sea la misma en todas las plataformas.

Este nuevo criterio es de nivel A, es decir, imprescindible.

Aspecto del foco (mínimo y mejorado)

Uno estos dos criterios porque básicamente son el mismo difiriendo solo en el nivel de contraste exigido.

«Para el indicador del foco de teclado de cada componente de la interfaz de usuario todos lo siguiente es cierto:

• Área mínima: el área del foco es igual o mayor que 1 píxel CSS cuando el elemento tiene el foco, o tiene un grosor de al menos 8 píxeles CSS a lo largo del lado más corto del elemento
• Cambio de contraste: el cambio de color para indicar el foco tiene un contraste de 3:1 (mínimo) ó 4.5:1 (mejorado) respecto al estado sin foco.
• Contraste adyacente: el aspecto del foco tiene un contraste de al menos 3:1 o tiene un grosor de al menos 2 píxeles (solo se aplica al mínimo)
• No ocultado: el elemento con el foco no se encuentra oculto completamente por otro contenido.»

El foco del teclado, ese gran olvidado cuando reseteamos la hoja de estilo predefinida del navegador (que tampoco suelen tener un estilo del foco del teclado demasiado allá). Navegar usando el teclado es algo básico y esencial y junto a ello lo es el estilo del elemento que tiene el foco en ese momento y por ello tiene que ser lo más visible posible.

No es imprescindible que se trate de un borde alrededor del elemento, también puede ser un cambio en el color del fondo del elemento o incluso un subrayado. Sea como sea estos criterios fijan unos tamaños y contrastes mínimos para el área que servirá para indicar que el elemento tiene el foco.

Este nuevo criterio (mínimo) es de nivel AA, es decir, necesario mientras que el criterio mejorado es de nivel AAA, es decir, recomendable.

Controles ocultos

«Los controles necesarios para progresar o completar un proceso son visibles siempre sin necesitar activar su estado hover o focus, o hay un mecanismo para que se mantengan visibles».

Si ocultamos los controles que están activos dificultamos la comprensión del proceso. En cambio, por ejemplo, en un formulario que no está relleno completamente el botón de enviar podría permanecer oculto.

La intención es que el usuario sepa en todo momento qué acciones puede realizar sin tener que ir buscando en la página.

Este nuevo criterio es de nivel AA, es decir, necesario.

Espacio en los elementos accionables

«Para cada elemento accionable hay un área de anchura y altura mínima de 44 píxels CSS que contiene al elemento y a ninguno más a excepción de:

• Aumento: hay un mecanismo que permite modificar el tamaño del píxel CSS de cada elemento accionable. (La redacción de este punto es un tanto confusa: «Enlarge: A mechanism is available to change the CSS pixel size of each target, or its spacing, so there is an area with a width and height of at least 44 CSS pixels that includes it, and no other targets;»)
• En línea: el elemento accionable es una frase o bloque de texto.
• Agente de usuario: el tamaño del elemento accionable lo controla el agente de usuario y no puede ser modificado por el autor.
• Esencial: Ciertas formas de presentar los elementos accionables son esenciales para transmitir correctamente la información.»

Vaya, es un punto más complejo de traducir que de entender. El objetivo es que se aumente el área de aquellos elementos accionables de menor tamaño para facilitar su activación y evitar activar otro por error en la coordinación y precisión de los movimientos.

Curiosamente, el grupo de trabajo solicita feedback de personas involucradas en la fabricación y diseño de pantallas táctiles para saber si hay alguna forma más óptima de formular este criterio.

Este nuevo criterio es de nivel AA, es decir, necesario.

Entradas redundantes

«Para los pasos en un proceso, la información que el usuario ha proporcionado previamente y que sea necesaria en los pasos posteriores será:

• Rellenada automáticamente.
• Disponible para que el usuario la seleccione.
• Excepción: que volver a introducir la información sea esencial.»

Este nuevo criterio es de nivel AA, es decir, necesario.

---

Como puedes ver los nuevos criterios se centran mucho en usuarios con discapacidades a nivel cognitivo y también en usuarios de dispositivos táctiles sin olvidarse tampoco de la parte visual.

Tal vez algunos criterios te puedan parecer un tanto exagerados o incluso innecesarios, pero te puedo asegurar que para muchas personas pueden marcar la diferencia entre poder acceder a una web o no. Si se trata de un blog personal el impacto en la vida de las personas que no pueden acceder es relativamente bajo, pero si se trata de una web de un organismo oficial el impacto sería inaceptable. Todos debemos tener las mismas oportunidades.

El beneficio de aplicar las normas es que siempre se mejora la usabilidad para el resto de usuarios. ¿Cómo no van a ser más usables iconos más grandes y más separados entre si?, ¿te imaginas que las webs no permitiesen usar la autenticación de Google o Facebook?

¿Y ahora qué pasa con el borrador WCAG 2.2?

La intención del grupo de trabajo es no añadir más criterios, centrarse en el borrador actual y recibir sugerencias respecto a estos nueve criterios. En particular quieren confirmar que los textos son comprensibles, los criterios útiles y las formas de evaluarlos adecuadas.

El grupo de trabajo recopilará todos los comentarios a través del Github de WCAG y public-agwg-comments@w3.org hasta el 18 de septiembre de 2020. Después los analizarán y si se producen los suficientes cambios en el borrador se podría generar un nuevo borrador y repetir este ciclo.

El objetivo es poder publicar la versión final de la WCAG 2.2 a mediados de 2021 y también nos avisan de que su idea no es trabajar en una WCAG 2.2 porque están trabajando en un nuevo estándar, ¿WCAG 3.0?