viernes, 14 de mayo de 2021

WCAG 2.2. Novedades del último borrador publicado

Última actualización del artículo: 14 de mayo de 2021

WCAG 2.2

El objetivo de este artículo es recoger las novedades de la nueva versión de las WCAG, las Web Content Accessibility Guidelines (WCAG) 2.2, actualmente en borrador. Iré actualizando el artículo con la publicación de cada borrador hasta que las WCAG 2.2 sean recomendación.

Actualmente, el último borrador de las WCAG 2.2 es del 13 de mayo de 2021.

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 de 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 serán una nueva ampliación de criterios, de modo que si se cumple con las WCAG 2.2 se cumplirá también con las WCAG 2.1.

Nuevos criterios

  1. Criterio 2.4.11 Focus Appearance (Minimum) (AA)
  2. Criterio 2.4.12 Focus Appearance (Enhanced) (AAA)
  3. Criterio 2.4.13 Page Break Navigation (A)
  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.2.7 Visible Controls (AA)
  8. Criterio 3.3.7 Accessible Authentication (A)
  9. Criterio 3.3.8 Redundant entry (A)

Es decir, de momento se propone añadir 9 criterios nuevos: 4 de nivel A, 4 de nivel AA y 1 de nivel AAA.

Además, el criterio 2.4.7 Foco Visible, ya presente desde las WCAG 2.0, pasa del nivel AA al nivel A.

2.4.11 Focus Appearance (Minimum) (AA)

Este criterio complementa a los criterios 2.4.7 y 1.4.11

El criterio 2.4.7 Foco visible, que ahora pasa a ser de nivel A, 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 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 un componente tenga un contraste adecuado con el fondo, tanto en su estado por defecto como en su estado con el foco; de forma complementaria, este 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.

En el criterio se aconseja definir siempre un estilo de foco de teclado personalizado que cumpla con todas las condiciones exigidas, mejor que dejar el enfoque predeterminado del navegador, porque el foco por defecto puede no ser suficientemente visible en todos los navegadores.

Por otra parte, se indica que solo aplica a los elementos que cogen el foco y son operables con el teclado. Si, por ejemplo, un encabezado es el objetivo de un ancla y coge el foco de teclado sin ser operable (al pulsarlo no va a ocurrir nada), no le aplica este criterio.

Dicho esto, el criterio especifica que, cuando los componentes de la interfaz de usuario reciben el foco de teclado, se cumplen todas estas condiciones:

Condición 1: Área de contraste

Hay un área del indicador del foco en la que existe una relación de contraste de al menos 3:1 entre los colores del estado con el foco y el estado sin el foco.

Por ejemplo, si cuando un control recibe el foco cambia su color, y ese nuevo color contrasta menos de 3:1 con el color original, no pasaría el criterio.

Condición 2: Área mínima

El área de contraste es al menos tan grande como:

  • contorno: el área de un perímetro de 1 píxel CSS (px) de grosor del componente sin el foco, o
  • forma: el área de 4 píxeles CSS (px) de grosor a lo largo del lado más corto de una caja delimitadora mínima del componente sin el foco, y no más delgada de 2 píxeles CSS (px).

Es decir, define un área mínima mediante el perímetro y un mínimo secundario basado en el lado más corto.

Ejemplo del cálculo del perímetro

El área mínima del indicador del foco debe ser al menos tan grande como el área de un perímetro (borde) de 1 píxel CSS de grosor del control en su estado sin el foco. El indicador no tiene que ser un borde, pero el área del indicador debe ser al menos igual de grande.

Por ejemplo, si un control es un rectángulo de 90 píxeles de ancho y 30 píxeles de alto, el tamaño del borde exterior es 90 + 90 + 30 + 30 = 240 píxeles CSS. Luego se restan los 4 píxeles de las esquinas (que se cuentan dos veces, tanto horizontal como verticalmente), y nos sale un área mínima total de 236 píxeles CSS. El área del indicador del foco debe ser al menos de 236px.

En los siguientes ejemplos de las WCAG 2.2 de botones de 90px por 30px, el botón central con el foco cumple el criterio:

tres botones de 90 píxeles de ancho por 30 píxeles de alto azul marino, el botón que tiene el foco tiene un borde interior ligeramente inferior que el borde exterior de color amarillo de 2px

tres botones de 90 píxeles de ancho por 30 píxeles de alto azul marino, el botón que tiene el foco tiene un subrayado amarillo de 3px

En el primer caso, el contorno interior del botón con el foco es ligeramente más pequeño que el borde exterior, pero su grosor es de 2 px, lo que significa que el área de ese recuadro amarillo está muy por encima del requisito mínimo de un área de 236px.

En el segundo caso, el subrayado amarillo ocupa casi todo el ancho, en concreto, 80 px. Como tiene 3 px de alto, el cálculo de su área (80*3=240) también excede el requisito de un área mínima de 236 px.

Si tus controles cambian de tamaño en la versión responsive, debes tenerlo en cuenta a la hora de revisar el criterio.

Ejemplo del cálculo del área basado en el grosor del lado más corto

Este cálculo se incluye para permitir indicadores del foco más pequeños pero más gruesos y, por tanto, igual de visibles. Un ejemplo correcto sería el siguiente:

2 botones azul marino, el que tiene el foco tiene un borde amarillo en el lateral izquierdo muy grueso

El área del recuadro amarillo que indica que el botón tiene el foco cumple con los mínimos requeridos.

Ejemplos de tipos de focos de teclado que pasarían o no esta condición del tamaño

SÍ pasaría:

  • Un contorno sólido alrededor de todo el componente.
  • Cambiar el color del fondo del componente.

NO pasaría:

  • Un contorno punteado de un 1px alrededor del componente, porque su área es un 50% del mínimo requerido. En algunos tamaños y navegadores, el contorno punteado puede sumar un área menor de la mitad, y habrá que tenerlo en cuenta para calcular qué grosor debería tener el punteado.
  • Una línea vertical de 1px, como un cursor parpadeante en el campo del formulario, no cumpliría el criterio; debería ser grueso o complementarse con un borde más ancho del campo

Cuando un indicador del foco se define en el código, por ejemplo, con 2px, el suavizado se puede ignorar a efectos del cálculo.

Como regla general, si tienes que hacer operaciones matemáticas complejas para averiguar si estás o no cumpliendo, es que seguramente deberías aumentar la visibilidad del foco. Pero es verdad que, si el componente tiene una forma inusual (como una estrella) y el foco se refleja en su borde, o se juega con las sombras, los cálculos se puedan complicar. En la página de explicación del criterio se ponen más ejemplos de cálculo de formas inusuales o del foco en un enlace en dos líneas.

Condición 3: Contraste adyacente

El área de contraste también tiene una relación de contraste de al menos 3:1 respecto a todos los colores adyacentes al componente con el foco, o el área de contraste tiene un grosor de al menos 2 píxeles CSS.

Es decir, debe contrastar 3:1 con los colores adyacentes (incluido el componente), o bien estar separado del componente, o bien tener al menos 2 píxeles de grosor, aunque sea del mismo color que el componente, porque el grosor permitirá diferenciarlo de los que no tienen el foco:

Tres elementos de menú con fondo negro. El que tiene el foco tiene un borde de dos píxeles negros por lo que es más grande que el resto.

El menú que tiene el foco es más grande porque tiene un borde de 2 píxeles del mismo color.

Condición 4: No completamente oculto

El elemento con el foco no está completamente oculto por otro contenido creado por el autor (como elementos fijos, diálogos no modales, ...).

Otras consideraciones

El criterio incluye dos notas:

  • Un indicador de enfoque de teclado que tiene un patrón o degradado puede tener partes que no cumplan con la relación de contraste de 3:1 para el cambio de contraste, siempre que un área igual al mínimo cumpla con la relación de contraste.
  • Si el componente tiene un límite visible más pequeño que el área de pulsación, o el tamaño del componente no está disponible, el área mínima se puede tomar del límite visible.

Tres botones azules. Uno tiene un borde interior amarillo de dos píxeles. Dos estrellas, una tiene una sombra en un lado de 8 íxeles de grosor.

Dos ejemplos de controles que cumplen con el criterio 2.4.11

Más información: Understanding Success Criterion 2.4.11: Focus Appearance (Minimum)

2.4.12 Focus Appearance (Enhanced) (AAA)

Es similar al criterio anterior pero más estricto.

Para el indicador del foco de teclado de cada componente de la interfaz de usuario, se cumplen todas estas condiciones:

  • Área de contraste: hay un área del indicador del foco en la que hay una relación de contraste de al menos 4.5:1 entre los colores del estado con el foco y el estado sin el foco.
  • Área mínima: el área de contraste es al menos igual al área del perímetro de 1 píxel CSS del elemento sin el foco.
  • Despejado: el contenido creado por el autor no oculta ninguna parte del indicador de foco.

Más información: Understanding Success Criterion 2.4.12: Focus Appearance (Enhanced)

2.4.13 Page Break Navigation (A)

Para el contenido web con localizadores de saltos de página, hay un mecanismo disponible para navegar a cada localizador.

La numeración de páginas ha sido durante mucho tiempo una forma fundamental de identificar y comunicar la ubicación del contenido escrito. Se utiliza constantemente en referencias, notas a pie de página, notas al final y bibliografías. En particular, son fundamentales en entornos académicos y de aprendizaje.

La publicación electrónica ha proporcionado un acceso valioso al contenido para las personas ciegas, con baja visión, dislexia y con discapacidades cognitivas. Hay que tener en cuenta que, a la hora de consumir la información, el contenido puede adaptarse para adoptar un diseño diferente, o puede utilizarse una tecnología de asistencia.

Si, por ejemplo, no hay una forma clara de encontrar una página específica de la versión impresa a la que hizo referencia un profesor en clase, porque en la versión electrónica ese párrafo está en otra página, el usuario perderá información valiosa y, a veces, crítica para comprender la referencia.

Un ejemplo correcto de cumplimiento del criterio sería un ePub que incluya navegación a referencias de números de página que coinciden con la versión impresa de la publicación (ver técnica H99: Providing a Page List).

Más información: Understanding Success Criterion 2.4.13: Page Break Navigation

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

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

2.5.8 Target Size (Minimum) (AA)

Cada zona de interacción tiene un área con un ancho y alto de al menos 24 píxeles CSS, excepto cuando:

  • Espaciado: la zona de interacción offset (la distancia entre el punto más lejano de una zona de interacción al punto más cercano de la segunda zona de interacción) es al menos de 24 píxeles CSS, respecto a cada zona de interacción adyacente. Es decir, si la zona de interacción es menor de 24 px pero junto al margen hasta la siguiente zona de interacción suma 24 px, es válido.
  • En línea: el área de interacción está dentro de una oración o bloque de texto.
  • Esencial: una presentación particular del área de interacción es esencial para la información que se transmite.

Es, por tanto, la versión menos estricta para el nivel AA del criterio 2.5.5 Tamaño del área de interacción de nivel AAA, que establece el tamaño mínimo en 44*44.

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

3.2.6 Consistent Help (A)

Para cada página dentro de un conjunto de páginas web que proporciona una o más de las siguientes formas de encontrar ayuda, el acceso a, por lo menos, una forma de ayuda se incluye en el mismo orden relativo en cada página:

  • 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.) o automatizado (un chatbot)
  • Opción de autoayuda (una página de preguntas frecuentes)
  • Un mecanismo de contacto totalmente automatizado

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 directo 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 coherente en todas las páginas.

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

Más información: Understanding Success Criterion 3.2.6: Consistent Help

3.2.7 Visible Controls (AA)

La intención de este criterio es ayudar a las personas con discapacidades cognitivas y de aprendizaje a ubicar los controles que necesitan para completar con éxito la tarea deseada.

El criterio se resume en que los controles que se necesitan para avanzar o completar un proceso están visibles en el momento en el que se necesitan, sin requerir para ello que cojan el foco de teclado o de ratón, o hay un mecanismo disponible para hacerlos permanentemente visibles.

Sí que se permite que, en un proceso de varios pasos o en un formulario con varias partes, el control esté oculto hasta que se pueda avanzar, momento en el cual estará visible de manera persistente, sin que el usuario haya tenido que interactuar con el control.

Es decir, este criterio no obliga a que los controles inactivos sean visibles de manera persistente hasta que el usuario puede avanzar. Por ejemplo, cuando un formulario incluye campos obligatorios que se deben completar antes de que el botón de envío se active, no es necesario que el botón de envío permanezca visible mientras está inactivo.

Los controles de los reproductores de vídeo, de chat o de carruseles, cuando incluyen controles solo visibles al pasar el ratón, no entran dentro del ámbito de este criterio, salvo que sea necesario interactuar con esos controles para completar un proceso, por ejemplo, en un curso, ver un vídeo antes de continuar con el siguiente paso.

El criterio dice exactamente que cuando el puntero o el foco de teclado hacen que los componentes de la interfaz de usuario sean visibles, la información necesaria para identificar que los componentes de la interfaz de usuario están disponibles es visible, salvo cuando:

  • La información necesaria para identificar los componentes de la interfaz de usuario está disponible a través de un componente equivalente que está visible en la misma página, o en un paso diferente en un proceso de varios pasos, sin que sea necesario el foco del puntero o del teclado.
  • El componente se proporciona específicamente para mejorar la experiencia de navegación con el teclado.
  • Se dispone de un mecanismo para hacer que la información sea visible de forma persistente.
  • Es esencial ocultar la información necesaria para identificar el componente.

Los componentes de la interfaz de usuario pueden estar disponibles a través de otros componentes visibles como submenús, botones de edición, pestañas o miniaturas.

Más información: Understanding Success Criterion 3.2.7: Visible Controls

3.3.7 Accessible Authentication (A)

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.

Si un proceso de autenticación se basa en una "prueba de función cognitiva", también debe estar disponible al menos otro método que no dependa de una "prueba de función cognitiva", o bien puede haber un mecanismo disponible para ayudar al usuario a completar la prueba.

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;
  • transcripción, como escribir caracteres;
  • uso de ortografía correcta;
  • realización de cálculos;
  • resolución de rompecabezas.

Las personas con discapacidad cognitiva pueden tener problemas para recordar cadenas aleatorias de caracteres, un patrón para una pantalla táctil o las imágenes que incluyen un objeto en particular.

El criterio admite que haya un mecanismo de ayuda. Un mecanismo de ayuda podría ser:

  • soporte para el ingreso de contraseñas por parte de los administradores de contraseñas para abordar la prueba de función cognitiva de memorización;
  • funcionalidad de copiar y pegar para ayudar a abordar la prueba de función cognitiva de transcripción.

Por tanto, se puede usar el acceso mediante usuario (o correo electrónico) y contraseña si se cumple con el criterio "1.3.5 Propósito de entrada", el criterio 1.3.1 Información y relaciones, y no se bloquea la funcionalidad de copiar y pegar, de modo que las funciones del navegador o los administradores de contraseñas pueden guardar la información del usuario y volver a completar los campos de inicio de sesión.

Más información: Understanding Success Criterion 3.3.7: Accessible Authentication

3.3.8 Redundant entry (A)

La información ingresada o proporcionada previamente por el usuario, y que es requerida nuevamente en el mismo proceso y en la misma sesión de usuario, está autocompletada o disponible para que el usuario la seleccione, a menos que volver a incluir la información sea necesario para garantizar la seguridad del contenido (por ejemplo, ingresar de nuevo la contraseña por seguridad) o la información ingresada previamente ya no sea válida.

Más información: Understanding Success Criterion 3.3.8: Redundant entry

Artículos relacionados:

0 comentarios :
Publicar un comentario