WCAG 2.1, recomendación hasta las WCAG 3.0

En el artículo "WCAG 2.0 Extensions. "WCAG Cognitive Extension", "WCAG Mobile Extension", y nueva versión de las WCAG 2.0" de noviembre de 2015, comentaba el mapa de ruta del Grupo de Trabajo de las WCAG (WCAG WG), que incluía publicar en 2018 dos extensiones de las WCAG 2.0 y los requisitos de la futura versión de las WCAG.

En este contexto, el 28 de febrero 2017 se publicó el primer Working Draft de las WCAG 2.1. Tras poco más de un año de trabajo, y 10 años después de la publicación de las WCAG 2.0, el 5 de junio de 2018 se ha hecho pública la versión definitiva de las WCAG 2.1: Web Content Accessibility Guidelines (WCAG) 2.1 W3C Recommendation 05 June 2018

Este artículo describe todas las novedades de las WCAG 2.1

Índice:

• Objetivos y organización de las WCAG 2.1
• Resumen de las novedades
• Descripción de cada criterio nuevo de las WCAG 2.1
• WCAG 3.0

Objetivos y organización de las WCAG 2.1

El objetivo de la nueva versión de las WCAG es mejorar las pautas de accesibilidad para tres grupos específicos de usuarios:

• las personas con discapacidad cognitiva o del aprendizaje
• las personas con baja visión
• las personas con discapacidad que acceden desde dispositivos móviles

Aunque se mejora en estas áreas, se subraya que no cubren todas las necesidades de estos usuarios.

Las WCAG 2.1 tienen un enfoque aditivo pensado para evidenciar que, si una página cumple con las WCAG 2.1, también está cumpliendo con las WCAG 2.0. Todos los criterios de conformidad de las WCAG 2.0 están incluidos en las WCAG 2.1. Esto era muy importante para que los sitios que se actualizan a las WCAG 2.1 no pierdan su conformidad con las WCAG 2.0 y sigan cumpliendo los requisitos legales de accesibilidad.

El documento recomienda anticiparse y aplicar las WCAG 2.1 en cuanto sean recomendación, aunque las obligaciones formales mencionen las WCAG 2.0. Esto es lógico, pues todo hace prever que las WCAG 2.1 serán rápidamente adoptadas por las normativas y legislaciones nacionales e internacionales.

No se han modificado ni reorganizado los criterios de conformidad de las WCAG 2.0 (salvo una pequeña corrección en el criterio 1.3.3 y 1.4.1)

Para los desarrolladores y evaluadores este planteamiento tiene una enorme ventaja, ya que así solo deben aprenderse los nuevos criterios de conformidad, con la seguridad de que los demás siguen siendo los mismos.

Sin embargo, este planteamiento aditivo también tiene otra consecuencia a la que hay que estar atento, y es que ahora los criterios ya no están ordenados por su nivel de conformidad (A, AA, AAA). Para no cambiar el número de criterio a los criterios existentes, los nuevos siempre se han añadido al final de los actuales.

Como ayuda, la "How to Meet WCAG 2 Quick Reference" permite ordenar o filtrar los criterios por nivel, según sean de las WCAG 2.0 o de las WCAG 2.1.

- How to Meet WCAG 2.1 Quick Reference -

Resumen de las novedades

Los requisitos estructurales heredados de las WCAG 2.0, la claridad e impacto de las propuestas recibidas y el estricto calendario marcado, han llevado a la inclusión finalmente de 17 nuevos criterios.

En resumen, las novedadades de las WCAG 2.1 son:

• 17 criterios nuevos:
  • 5 de nivel A;
  • 7 de nivel AA;
  • 5 de nivel AAA;
• Nuevas definiciones en el glosario.
• Una nueva pauta (2.5) para organizar algunos de los nuevos criterios. Esto aumenta el número de pautas de 12 a 13.
• Se añade en el enunciado del criterio 1.3.3 específicamente el color y se quita en consecuencia la nota del criterio 1.4.1
• Un par de adiciones a la sección de conformidad: una nota adicional en el requisito 5.2.2 "Full Pages"; y un punto adicional en "Componentes opcionales de la declaración de conformidad".

WCAG 2.1 (Recommendation 05/06/2018)

No se han modificado los criterios de conformidad de las WCAG 2.0, ni siquiera su numeración.

Como he indicado previamente, se han añadido 17 nuevos criterios de conformidad, que a continuación voy a describir en detalle.

Índice:

Nuevos criterios de las WCAG 2.1:

• 1.3.4 Orientation (AA)
• 1.3.5 Identify Input Purpose (AA)
• 1.3.6 Identify Purpose (AAA)
• 1.4.10 Reflow (AA)
• 1.4.11 Non-text Contrast (AA)
• 1.4.12 Text Spacing (AA)
• 1.4.13 Content on Hover or Focus (AA)
• 2.1.4 Character Key Shortcuts (A)
• 2.2.6 Timeouts (AAA)
• 2.3.3 Animation from Interactions (AAA)
• Guideline 2.5 Input Modalities
• 2.5.1 Pointer Gestures (A)
• 2.5.2 Pointer Cancellation (A)
• 2.5.3 Label in Name (A)
• 2.5.4 Motion Actuation (A)
• 2.5.5 Target Size (AAA)
• 2.5.6 Concurrent Input Mechanisms (AAA)
• 4.1.3 Status Messages (AA)
• Otros cambios:
  • Requisito 5.2.2 Full Pages, nota adicional
  • Componentes opcionales de la declaración de conformidad, punto adicional
  • Nuevos términos en el glosario
  • Pequeña modificación de los criterios actuales 1.3.3 y 1.4.1

1.3.4 Orientation (AA)

Relativo al principio "Perceptible" y a la pauta 1.3 "Adaptable: Crear contenido que pueda presentarse de diferentes formas (por ejemplo, con una disposición más simple) sin perder información o estructura."

Indica que, el contenido no restringe su vista y funcionamiento a una única orientación de visualización, como vertical u horizontal, a menos que una orientación de visualización específica sea esencial.

Algunos sitios o aplicaciones configuran automáticamente la pantalla para una orientación particular de la misma, esperando que el usuario gire su dispositivo, pero algunos usuarios tienen los dispositivos montados en una orientación fija, por ejemplo en el brazo de su silla de ruedas. Por lo tanto, los sitios y aplicaciones web deben admitir ambas orientaciones asegurándose de que el contenido y la funcionalidad estén disponibles en cada orientación, si bien se permite que el orden del contenido y la funcionalidad tengan diferencias.

Este criterio favorece el acceso desde dispositivos móviles, puesto que prohíbe bloquear la orientación de pantalla. El contenido debe ser operable en todas las orientaciones de pantalla (salvo cuando la orientación es esencial para el uso del contenido).

Ejemplos de una orientación de visualización particular que puede ser esencial: un cheque bancario, una aplicación de piano, diapositivas para un proyector o televisión, o un contenido de realidad virtual al que no se puedan aplicar ambas orientaciones de pantalla.

Cuando una orientación particular es esencial, se debe informar al usuario de los requisitos de orientación.

Como técnicas suficientes se incluyen el uso de las CSS para permitir la orientación vertical y horizontal; y el uso de controles que permitan acceder al contenido en diferentes orientaciones.

Understanding 1.3.4

1.3.5 Identify Input Purpose (AA)

Relativo al principio "Perceptible" y a la pauta 1.3 "Adaptable: Crear contenido que pueda presentarse de diferentes formas (por ejemplo, con una disposición más simple) sin perder información o estructura."

El criterio dice que el propósito de cada campo que recoge información del usuario se puede determinar por software cuando:

• el campo tiene un propósito identificado y concreto de los listados en el apartado 7. Input Purposes for User Interface Components ("name", "country", "postal-code", etc.), cuya lista está basada en la de HTML 5.2 Autofill field section; y además,

• el contenido está implementado usando una tecnología con soporte para identificar el significado esperado del dato introducido en un campo de formulario.

El objetivo es ofrecer más soporte a las preferencias y necesidades de los usuarios, dando mayor información sobre los controles, más allá del "nombre, función y valor (criterio 4.1.2)". Gracias a esta información:

• se puede proporcionar correctamente la función de autocompletar, que ayuda a rellenar los formularios de forma más rápida y sencilla, y evita cometer errores;
• las extensiones del navegador podrán agregar ayuda sensible al contexto;
• una barra de herramientas podría agregar a determinadas funciones símbolos familiares para el usuario;
• etc.

La técnica suficiente incluida es utilizar autocomplete con los atributos definidos en HTML 5.2 Autofill field section.

Understanding 1.3.5

1.3.6 Identify Purpose (AAA)

Relativo al principio "Perceptible" y a la pauta 1.3 "Adaptable: Crear contenido que pueda presentarse de diferentes formas (por ejemplo, con una disposición más simple) sin perder información o estructura."

Indica que, en el contenido implementado mediante lenguaje de marcas, el propósito de los componentes de la interfaz, los iconos y las regiones, puede ser determinado por software. De esta manera podríamos, por ejemplo, mostrar símbolos y términos personalizados en base a esa información.

Al igual que el criterio anterior, el objetivo es ofrecer más soporte a las preferencias y necesidades de los usuarios. Por ejemplo, si se identifica que es un botón para enviar un email, este tipo de botón se podrá personalizar con un icono o un término comprensible para un usuario en particular; se podrá mostrar ayuda relacionada con esa función; se podrá renderizar más grande (si se configura así porque es un botón relevante); etc.

Las técnicas suficientes que se incluyen son: agregar semántica a los elementos con COGA (Cognitive and Learning Disabilities Accessibility Task Force), microformatos o usar landmark roles ARIA.

Por ejemplo, si se marcan las zonas de la página con landmark roles de ARIA el usuario podría ocultar todo el contenido que no sea main.

Como técnicas recomendables se incluyen: permitir que los agentes de usuario encuentren la versión del contenido que mejor se adapte a sus intereses; el uso de los atributos ARIA aria-invalid y aria-required en los campos de formulario; o el uso de coga-simplification="simplest".

Understanding 1.3.6

1.4.10 Reflow (AA)

Relativo al principio "Perceptible" y a la pauta 1.4 "Distinguible: Facilitar a los usuarios ver y oír el contenido, incluyendo la separación entre el primer plano y el fondo."

Indica que, el contenido puede presentarse sin pérdida de información o funcionalidad y sin necesidad de hacer scroll en dos dimensiones*, para:

• Contenido con desplazamiento vertical con un ancho equivalente a 320 píxeles CSS;
• Contenido con desplazamiento horizontal con una altura equivalente a 256 píxeles CSS;

* excepto para partes del contenido que lo requieran para su uso o significado.

En las notas se indica que, 320 píxeles CSS es equivalente a un viewport width inicial de 1280 píxeles CSS con un zoom de 400%. Para el contenido diseñado para escrolar horizontalmente, 256 píxeles CSS es equivalente a un viewport height inicial de 1024px con un zoom de 400%.

Algunos ejemplos de contenidos que pueden requerir doble scroll son: imágenes, mapas, diagramas, vídeo, juegos, presentaciones, tablas de datos, o interfaces donde es necesario mantener las barras de herramientas a la vista mientras se manipula el contenido.

Está muy relacionado con el actual criterio de conformidad 1.4.4 "Cambio de tamaño del texto: A excepción de los subtítulos y las imágenes de texto, todo el texto puede ser ajustado sin ayudas técnicas hasta un 200 por ciento sin que se pierdan el contenido o la funcionalidad. (Nivel AA)"

Mientras que el criterio 1.4.4 habla de la opción de los navegadores de aumentar el tamaño de letra, este se centra en la opción de zoom, que es el método predeterminado de los navegadores para aumentar el tamaño del contenido, lo que ayuda a personas con problemas de visión.

Este nuevo criterio complementa al 1.4.4 porque una proporción significativa de personas con baja visión necesita un aumento superior al 200% (el 25% de los usuarios con baja visión de la encuesta de Webaim indicaron que necesitaban una ampliación de 400% o más).

Este criterio asegura que se puede hacer zoom de 400% sin pérdida de contenido o funcionalidad y se evitan los dobles scroll (salvo en los casos citados), pues el impacto del desplazamiento horizontal aumenta el esfuerzo de lectura 40-100 veces.

Este criterio también asegurará que no se restrinja el zoom en el viewport, mala práctica que comenté en el artículo Responsive Design y accesibilidad. Buenas y malas prácticas. Errores comunes.

Las técnicas suficientes que se incluyen son: usar media queries y CSS grids o CSS Flexbox para reajustar los contenidos; calcular por programación los tamaños y posiciones de los elementos de manera que escalen con el tamaño del texto; y dar la opción de cambiar a un diseño que no requiera scroll para leer una línea de texto.

Como técnicas recomendables se incluyen: ajustar el tamaño de las imágenes y las tablas al viewport; y dar un mecanismo que permita cambiar a la vista móvil en cualquier momento.

Como errores comunes se nombran: usar tamaños y posiciones fijas; impedir el zoom; y usar texto preformateado o tratarlo como una excepción.

El proceso de testeo que podemos seguir es:

1. Display content in a user agent capable of zooming 400% and start with a window width of 1280px at a 100% zoom level.
2. Increase zoom (for all content) to 400%
3. Check whether all content scales and is perceivable with no loss of content or functionality (e.g. boxes do not overlap, controls are not obscured or separated from their labels, etc.)
4. If horizontal scrolling is present, check that the content causing scrolling would not make sense without the scrolling.

Understanding 1.4.10

1.4.11 Non-text Contrast (AA)

Relativo al principio "Perceptible" y a la pauta 1.4 "Distinguible: Facilitar a los usuarios ver y oír el contenido, incluyendo la separación entre el primer plano y el fondo".

Indica que, la presentación visual de los siguientes elementos tiene una ratio de contraste de al menos 3:1 respecto a los colores adyacentes:

• Componentes de la interfaz de usuario: información visual utilizada para identificar los componentes de la interfaz de usuario y los estados, excepto para componentes inactivos o cuando la apariencia del componente es determinada por el agente de usuario y el autor no la modifica.
• Objetos gráficos: partes de los gráficos necesarias para comprender el contenido, excepto cuando una presentación particular de los gráficos es esencial para la información que se transmite (esencial como por ejemplo en los logotipos o en las banderas, en una captura de un sitio que muestra cómo es su apariencia, en un mapa de calor, en un diagrama médico que usa los colores utilizados en biología, etc.)

El criterio 1.4.3 solo abarca "la presentación visual de texto e imágenes de texto" y por tanto el criterio 1.4.11 lo complementa, porque el contraste sería también necesario para:

• los iconos (que no van con texto)
• los gráficos, por ejemplo, cada una de sus líneas
• el borde o límites visuales de un campo de formulario o botón, siempre que no estuviera disabled
• el indicador visual del valor actual en un control deslizante
• el indicador del foco
• etc.

Las técnicas suficientes para las gráficas son: que el contraste entre los colores de las gráficas sea suficiente así como el contraste de las líneas entre colores adyacentes.

Las técnicas suficientes para los textos de las gráficas son: que se incluyan en las gráficas etiquetas y valores; que las imágenes que transmiten información y los textos de las gráficas tengan suficiente contraste; o que haya un control con suficiente contraste que permita a los usuarios cambiar a una presentación que utilice suficiente contraste.

Como técnica recomendable, en el caso de los enlaces y controles que solo se identifican por el color, sería un ratio de contraste de 4,5:1 con el texto de alrededor y pistas visuales adicionales.

Understanding 1.4.11

1.4.12 Text Spacing (AA)

Relativo al principio "Perceptible" y a la pauta 1.4 "Distinguible: Facilitar a los usuarios ver y oír el contenido, incluyendo la separación entre el primer plano y el fondo."

El criterio se aplica a los lenguajes que, como HTML, permiten definir el espaciado entre líneas, párrafos, palabras o caracteres. En estos casos, si el usuario configura dichas propiedades de la manera que se enumera a continuación (y sin necesidad de tocar otros estilos), no se debe producir pérdida de contenido ni de funcionalidad:

• Espacio entre líneas: al menos 1.5 veces el tamaño de la fuente.
• Espacio entre párrafos: al menos 2 veces el tamaño de la fuente.
• Espacio entre las letras (tracking): al menos 0.12 veces el tamaño de la fuente.
• Espacio entre palabras: al menos 0.16 veces el tamaño de la fuente.

No significa que el texto deba tener esos espaciados, sino que debes comprobar que con esos espaciados no se produzcan solapamientos, textos cortados o desbordados que provoquen pérdida de contenido o funcionalidad.

No se aplica ni a las imágenes de texto ni a los subtítulos.

Este criterio asegurará que la distancia entre las líneas, los párrafos, las palabras o los caracteres seguirá siendo adecuada para la lectura aunque se modifique la presentación.

La técnica suficiente que se incluye es: el espaciado del texto se pueda cambiar, siendo un error habitual usar medidas fijas.

Como técnicas recomendables se indican: usar las propiedades CSS letter-spacing, line-height y definir el tamaño de los contenedores en em

Para saber más sobre este criterio y sobre cómo evaluarlo puedes leer mi artículo: WCAG 2.1. Criterio 1.4.12 (AA) Herramienta gratuita para evaluarlo

Understanding 1.4.12

1.4.13 Content on Hover or Focus (AA)

Relativo al principio "Perceptible" y a la pauta 1.4 "Distinguible: Facilitar a los usuarios ver y oír el contenido, incluyendo la separación entre el primer plano y el fondo."

Cuando el contenido se hace visible/oculto porque un componente de la interfaz coge/pierde el foco (pointer hover or keyboard focus) lo siguiente es verdad:

• Dismissable. Hay un mecanismo disponible para descartar el contenido adicional sin mover el puntero o el foco del teclado, a menos que el contenido adicional comunique un error en la entrada de datos, o no tape o reemplace otro contenido.
• Hoverable. Si el puntero del cursor puede activar el contenido adicional, entonces el puntero se puede mover sobre el contenido adicional sin que desaparezca el contenido adicional.
• Persistent. El contenido adicional permanece visible hasta que la activación del hover/focus se elimine, el usuario lo descarte o su información ya no sea válida.

La única excepción es cuando la presentación visual del contenido adicional es controlada por el agente de usuario y no es modificada por el autor, como sería, por ejemplo, el caso del uso del atributo "title".

Algunos ejemplos de contenidos a los que SÍ se aplica este criterio son: tooltips personalizados, submenús, pop-ups no modales que se muestran en el hover o en el focus, etc.

Las técnicas suficientes que se incluyen son: el uso del rol ARIA role=tooltip y el uso de las pseudo-clases hover y focus.

Como técnicas recomendables: no escondas los elementos que desencadenan los cambios; y no escondas los nuevos mensajes cuando se haga hover sobre ellos, o hasta que el usuario los descarte o sean incorrectos.

Understanding 1.4.13

2.1.4 Character Key Shortcuts (A)

Relativo al principio "Operable" y a la nueva pauta 2.1 "Accesible por teclado"

Indica que, si se implementa un atajo de teclado (keyboard shortcut) en el contenido usando una letra (incluidas mayúsculas y minúsculas), signo de puntuación, número o símbolo, entonces al menos una de las siguientes afirmaciones es cierta:

• Desactivar: hay un mecanismo para desactivar el atajo.
• Reasignar: hay un mecanismo para reasignar ese atajo de teclado, usando uno o más caracteres de teclado no imprimibles (Alt, Ctrl,...)
• Activo solo en el foco: el atajo de teclado de un componente de la interfaz solo está activo cuando ese componente tiene el foco.

Como se observa, no está relacionado con las accesskey, sino con los atajos de teclado personalizados.

Beneficia a los usuarios que utilizan programas de reconocimiento de voz que pueden activar varios atajos accidentalmente cuando estos están asociados a una sola tecla.

También puede evitar errores. Imagina que se implementa un atajo de teclado que consiste en que al pulsar la tecla "s" subes a la barra de búsqueda. El usuario de teclado puede pulsarla sin querer, especialmente aquellos que tienen problemas de movilidad.

Las técnicas suficientes se incluyen son: que los usuarios tengan una forma de desactivar los atajos de teclado de un solo carácter; o que exista un mecanismo que permite a los usuarios modificar los atajos de teclado y reasignarlos a caracteres no imprimibles.

Tengo un artículo específico sobre este criterio donde lo explico en detalle, con ejemplos de webs muy conocidas: WCAG 2.1 Comprender el criterio "2.1.4 Atajos de teclado" (A)

Understanding 2.1.4

2.2.6 Timeouts (AAA)

Relativo al principio "Operable" y a la pauta 2.2 "Tiempo suficiente: Proporcionar a los usuarios el tiempo suficiente para leer y usar el contenido."

Indica que se debe advertir a los usuarios de la duración de cualquier inactividad del usuario que pueda causar la pérdida de datos, a menos que los datos se conserven durante más de 20 horas cuando el usuario no realiza ninguna acción.

Se advierte que las normas de privacidad pueden requerir el consentimiento explícito del usuario antes de la identificación de usuario o de la conservación de los datos, y quizás esto no sea posible en el caso de los menores de edad. Por ello, en el caso de optar por guardar los datos del usuario, se debe tener en cuenta los requisitos legales y de privacidad correspondientes.

Las técnicas suficientes que se incluyen son: no expirar la sesión con menos de 20 horas de inactividad; almacenar los datos durante más de 20 horas; o advertir de la duración de la inactividad que provoca la expiración de sesión antes de comenzar el proceso.

Understanding 2.2.6

2.3.3 Animation from Interactions (AAA)

Relativo al principio "Operable" y a la pauta 2.3 "Convulsiones"

Indica que las animaciones de movimiento desencadenadas por una interacción pueden ser deshabilitadas, a menos que la animación sea esencial para la funcionalidad o la información que se transmite.

El actual criterio 2.2.2 se aplica cuando la página inicia una animación. Este criterio se aplica cuando una interacción del usuario inicia una animación inesperadamente.

Las WCAG definen una animación de movimiento como la adición de pasos entre posiciones o tamaños distintos para crear la ilusión de movimiento o transición suave. No hace referencia a los cambios de color o luminosidad, pues para tratar los destellos ya están los criterios 2.3.1 y 2.3.2.

Por ejemplo, que al escrolar la página se inicie una animación en la que los elementos de primer plano se mueven (aparte del movimiento normal asociado al desplazamiento) o giran. Esto puede provocar no solo distracción, sino incluso en algunos usuarios con desorden vestibular, nauseas y dolores de cabeza. Un disparador pueden ser los fondos que se mueven a una velocidad diferentes a los de primer plano, como en el efecto parallax scrolling o el scrolljacking.

Si quieres ampliar información, Scrolljacking y Parallax Scrolling en accesibilidad web. Peligro para personas con desordenes vestibulares, epilepsia y migrañas , Olga Carreras, 2017

Las técnicas suficientes que se incluyen son: que los usuarios puedan definir en sus preferencias que no haya animaciones; o utiliza la media query prefers-reduce-motion para evitar las animaciones en base a la configuración de accesibilidad del agente de usuario.

Understading 2.3.3

Nueva pauta propuesta 2.5 Input Modalities

Relativa al principio "Operable".

Make it easier for users to operate functionality through various inputs beyond keyboard

Es decir, facilita el uso de las funcionalidades a través de varias modalidades de introducción de datos, más allá del teclado. Esta pauta agrupa los nuevos criterios sobre la interacción táctil, por puntero, por voz u otras que pudieran surgir en el futuro.

2.5.1 Pointer Gestures (A)

Relativo al principio "Operable" y a la nueva pauta 2.5 "Input Modalities"

Este criterio está relacionado con las pantallas táctiles y cómo se opera con ellas.

Indica que, toda funcionalidad que usa gestos multipunto o basados en una trayectoria, puede ser operada con un solo gesto de puntero (single pointer) sin depender de un gesto basado en una trayectoria, a no ser que sea esencial un gesto multipunto o basado en una trayectoria.

No todo el mundo puede realizar gestos como el pinch o la rotación de tres dedos, o dibujar una trayectoria con un dedo de la manera precisa que se requiere. Este criterio no excluye la interacción basada en el gesto, sino que en caso de gestos complejos se debe dar una alternativa que incluya un solo toque.

Este criterio se aplica al contenido web que interpreta las acciones del puntero, es decir, no se aplica a las acciones que se requieren para operar el agente de usuario o el producto de apoyo.

Las técnicas suficientes que se incluyen son: no basar la interacción solo en recorridos gestuales o en varios toques; ofrecer controles alternativos que permitan realizar la misma función pero que no requieran gestos complejos; y utilizan un solo single-point.

Understanding 2.5.1

2.5.2 Pointer Cancellation (A)

Relativo al principio "Operable" y a la nueva pauta 2.5 "Input Modalities"

Indica que, para la funcionalidad que se puede operar con un "single pointer", al menos una de las siguientes afirmaciones es verdad:

• No Down-Event: el down-event del puntero no se usa para ejecutar ninguna parte de la función
• Abort or Undo: la finalización de la función está en el up-event, y hay un mecanismo disponible para abortar la función antes de completarse o deshacer la función una vez completada
• Up Reversal: el up-event invierte cualquier resultado del down-event anterior.
• Essential: completar la función en el down-event es esencial

¿Qué se entiende por "up-event" / "down-event"?

"Up-event" sería el "mouseup" o, en una interacción táctil, cuando se levanta el dedo al final del toque:

The activation of a component when the trigger stimulus is released. On different platforms the "up-event" may be called different things, such as "touchend" or "mouseup". Example: For touchscreen interaction, the event is triggered when a finger is lifted from the touchscreen at the end of a tap.

"Down-event", al revés, es el "mousedown" o, en una interacción táctil, cuando se presiona el dedo contra la pantalla.

Por otro lado, esencial sería una función que emula el teclado o un teclado numérico. Además, este criterio se aplica al contenido web que interpreta las acciones del puntero, es decir, no se aplica a las acciones que se requieren para operar el agente de usuario o el producto de apoyo.

Las técnicas suficientes se incluyen son: la activación de los controles en el up-event en HTML, iOS y Android; y que los eventos táctiles solo son activados cuando el toque se retira del control.

Como error a evitar, no actives un control en un down-event si el evento up-event no coincide con la misma localización del puntero.

Understanding 2.5.2

2.5.3 Label in Name (A)

Relativo al principio "Operable" y a la nueva pauta 2.5 "Input Modalities"

Indica que, para los componentes de la interfaz de usuario con etiquetas que incluyen texto o imágenes de texto, el nombre accesible contiene el texto que se presenta visualmente. Y añade en una nota que una buena práctica es poner el texto de la etiqueta al comienzo del nombre.

El nombre accesible es el nombre de un elemento de la interfaz de usuario. El valor del nombre accesible puede derivarse de una propiedad visible (por ejemplo el texto del botón) o de una propiedad invisible (propiedades como title, aria-label...)

Si la etiqueta visible no es igual que la etiqueta no visible (el nombre accesible) los usuarios que acceden con programas de reconocimiento de voz pueden tener problemas. Hay que tener en cuenta que estos usuarios pueden decir el menú, el vínculo o la etiqueta del botón para activarlos.

Imaginemos un botón de imagen en cuya imagen pone "Aceptar" pero que su texto alternativo es "OK". Cuando el usuario que utiliza la voz como medio de entrada dice el nombre del botón, dirá "Aceptar", pero no se activará porque su nombre accesible es "OK", por el contrario, puede estar activando otro botón diferente de la página cuyo nombre accesible sí sea "Aceptar" (aunque esta no sea su etiqueta visible).

Por otro lado, para los usuarios que utilizan un lector de pantalla pero visualizan la pantalla, también es mucho más claro que el nombre accesible que se les anuncia coincida con la etiqueta visual (o al menos esté incluida en el nombre accesible que se anuncia).

Puedes consultar el vídeo en el que explico la problemática que pretende evitar este criterio: WCAG 2.1 Comprende el criterio "2.5.3 Etiqueta en el nombre"

La técnica suficiente que se incluye es que las etiquetas visibles concuerden con los nombres accesibles.

Como técnica recomendable, si un icono no va acompañado de un texto, usa su texto "hover" como nombre accesible.

Los errores habituales que se listan:

• El nombre accesible no contiene el texto visible de la etiqueta.
• El nombre accesible contiene el texto de la etiqueta visible, pero las palabras de la etiqueta visible no están en el mismo orden.
• El nombre accesible contiene el texto de la etiqueta visible, pero una o más palabras se entremezclan en la etiqueta.
• El nombre accesible contiene el texto de la etiqueta visible, pero hay una o más palabras adicionales antes del texto de la etiqueta visible.

Understanding 2.5.3

2.5.4 Motion Actuation (A)

Relativo al principio "Operable" y a la nueva pauta 2.5 "Input Modalities"

Indica que, toda funcionalidad que puede ser operada por el movimiento del dispositivo o por el movimiento del usuario, también puede ser operada mediante los componentes de la interfaz de usuario, y la respuesta al movimiento se puede desactivar para evitar el accionamiento accidental.

Incluye dos excepciones:

• Supported Interface: el movimiento se utiliza para operar la funcionalidad a través de una interfaz compatible con la accesibilidad.
• Essential: el movimiento es esencial para la función o si no se invalidaría la actividad.

Este criterio hace referencia a los sensores del dispositivo que detectan y responden a algún tipo de entrada del entorno físico. Por ejemplo en un móvil o tablet, un movimiento como agitar el móvil, inclinar la tablet, etc.

No todos los dispositivos tendrán estos sensores, y aunque así fuera, no todos los usuarios pueden ser capaces de utilizarlos o hacerlo con la suficiente precisión. Por tanto, la funcionalidad debe ser implementada de tal manera que se puede activar por otros medios.

Este criterio no se aplica a los sensores de geolocalización, ni a los movimientos que no sean movimientos intencionales del usuario, ni a los asociados al uso del teclado, el puntero o productos de apoyo.

Las técnicas suficientes que se incluyen son: no usar el evento devicemotion para activar funcionalidades o contenidos; proporcionar formas alternativas de introducir información cuando se usan los sensores de movimiento para activar funcionalidades y contenidos; y que el usuario pueda desactivar la actuación por movimiento.

Understanding 2.5.4

2.5.5 Target Size (AAA)

Relativo al principio "Operable" y a la nueva pauta 2.5 "Input Modalities"

Define que el tamaño mínimo del "target" (región de la pantalla que acepta la acción del puntero) debe ser 44x44 píxeles CSS.

Incluye ciertas excepciones:

• Equivalent. Si el target está disponible a través de un enlace o un control equivalente, en la misma página, que tiene al menos 44x44 píxeles CSS.
• Inline. Si el target está en una frase o en un bloque de texto.
• User agent control. Si la apariencia del target es determinada por el agente de usuario y no es modificada por el autor.
• Essential. Si una presentación particular del target es esencial para la información que se transmite.

Este criterio favorece no solo a las personas con temblores, movilidad limitada, baja visión, etc. sino también a todos los usuarios en la interacción móvil. Hablé de ello en el artículo Responsive Design y accesibilidad. Buenas y malas prácticas. Errores comunes.

El tamaño 44x44 que se define es el mínimo, pero se recomienda utilizar tamaños mayores, esto es especialmente importante en los siguientes casos:

• El control se usa con frecuencia.
• El resultado de la interacción no se puede deshacer fácilmente.
• El control está situado en un lugar que será difícil de alcanzar o está cerca del borde de la pantalla.
• El control es parte de una tarea esencial.

Se incluyen muchas referencias, Android recomienda 48*48, otros estudios lo amplían hasta 57px. También habría que tener en cuenta que muchos usuarios, especialmente los jóvenes, utilizan más el pulgar que el índice.

Las técnicas suficientes que se incluyen son: que las áreas interactivas tengan al menos 44*44px; y ofrecer un mecanismo que permita cambiar el tamaño de las áreas.

Como técnica recomendable, el área interactiva de un párrafo que es un enlace también tiene al menos 44*44px.

Understanding 2.5.5

2.5.6 Concurrent Input Mechanisms (AAA)

Relativo al principio "Operable" y a la nueva pauta 2.5 "Input Modalities"

Indica que, el contenido web no restringe el uso de las modalidades de entrada (teclado, interfaz de teclado, ratón, pantalla táctil, habla, etc.) disponibles en una plataforma, excepto cuando la restricción es esencial, necesaria para garantizar la seguridad del contenido o respetar la configuración del usuario.

En la mayoría de los dispositivos, es posible que los usuarios cambien entre diferentes medios de entrada de datos en la misma sesión o interacción (por ejemplo, entre pantalla táctil y teclado).

La aplicación o sitio web no debe asumir que el usuario siempre comenzará o utilizará exclusivamente un mecanismo de entrada particular, y deberá permitir a los usuarios operar con cualquier mecanismo de entrada a su disposición.

Las técnicas suficientes que se incluyen son: usar solo manejadores de evento JS de alto nivel, independientes de la modalidad de entrada (focus, blur, click); o incluir manejadores de evento redundantes para las diferentes modalidades de entrada.

Understanding 2.5.6

4.1.3 Status Messages (AA)

Relativo al principio "Robusto" y a la pauta 4.1 "Compatible"

Indica que, en el contenido implementado mediante lenguaje de marcas, los mensajes de estado pueden ser determinado por software a través de roles y propiedades, de modo que puedan ser presentados a los productos de apoyo sin recibir el foco.

Se debe proporcionar una notificación para cada cambio del contenido de la página. No se trata tanto de que se vean esos mensajes, sino de que sean anunciados por el lector de pantalla. Esto se hace con el atributo aria-live de ARIA y sus roles específicos, como expliqué en Live Regions y WAI-ARIA. Cómo mejorar la accesibilidad de contenidos que se actualizan automáticamente.

Estos mensajes serán breves: "Su carrito se ha actualizado con 5 elementos"; "El formulario se ha enviado correctamente"; "Hay tres errores en este formulario", "El contenido se está actualizando, espere unos segundos", etc.

Este criterio no afecta a informaciones importantes que se presentan en diálogos modales, y que deben ser reconocidos por el usuario de forma inmediata.

Las técnicas suficientes que se incluyen son:

• Si el mensaje de estado advierte del éxito o el resultado de una acción o el estado de una aplicación: se usa role="status", informando de que el datos se ha enviado correctamente.
• Si el mensaje de estado transmite una sugerencia o una advertencia ante la existencia de un error: se usa role=alert, en combinación con alguna de otras técnicas ya existentes como dar una descripción textual para identificar los campos requeridos no completados, así como los campos con valores o formatos no permitidos; permitir saltar a los errores; dar sugerencias de corrección o proporcionar una revisión ortográfica y sugerencias para la entrada de datos.
• Si el mensaje de estado transmite información sobre el progreso de un proceso: se usa el role="log", role="progressbar" o role="status"

Como técnicas recomendadas están: el uso de otros roles (role="marquee", role="timer"); el uso de aria-live; mover el foco al nuevo contenido usando role="alertdialog" o role="dialog"; y ofrecer al usuario la posibilidad de definir sus preferencias sobre el contenido que se actualiza automáticamente.

Como errores a evitar está el uso de role="alert" o aria-live="assertive" para contenido que no es importante; o usar el evento visibilitychange para ocultar o mostrar un documento sin cambiar las live regions del documento a activas o inactivas.

Understanding 4.1.3

Nota adicional en el requisito de conformidad 5.2.2 Full pages

A full page includes each variation of the page that is automatically generated by the page for various screen sizes (e.g. variations in a responsive Web page). . Each of these variations needs to conform (or needs to have a conforming alternate version) in order for the entire page to conform.

Este requisito de conformidad trata de que una página es conforme si es conforme en su totalidad, lo cual incluye las alternativas a las que enlaza (como por ejemplo una página con descripciones extensas de imágenes o con presentaciones alternativas de un vídeo).

Esta nota añade que las distintas variaciones de la página, como las generadas automáticamente para diferentes resoluciones de pantalla, también forman parte de esa página y deben ser conformes todas ellas.

Esto hace referencia a los diseños Responsive Design y lo traté en el artículo Responsive Design y accesibilidad. Buenas y malas prácticas. Errores comunes.

Componentes opcionales de la declaración de conformidad, punto adicional

En el listado de componentes opcionales de la declaración de conformidad se añade el punto:

A list of specific accessibility characteristics of the content, provided in machine-readable metadata.

Términos añadidos al glosario

He ido haciendo mención a muchos de ellos en los criterios en los que se incluyen dichos términos:

• CSS pixel
• down-event
• Essential
• Keyboard shortcut
• Motion animation
• Pointer input
• Region
• Set of Web pages
• Single pointer
• State
• Status messages
• Style Property
• Target
• Up-event
• User inactivity

Modificaciones en los criterios 1.3.3 y 1.4.1

1.3.3 Sensory Characteristics

Actual (WCAG 2.0):

Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, size, visual location, orientation, or sound.

Modificación (WCAG 2.1)

Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, color, size, visual location, orientation, or sound.

Se añade que las instrucciones tampoco deben depender del color.

1.4.1 Uso del color

Actual (WCAG 2.0):

Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, size, visual location, orientation, or sound.

Note: This success criterion addresses color perception specifically. Other forms of perception are covered in Guideline 1.3 including programmatic access to color and other visual presentation coding.

En las WCAG 2.1 se elimina la nota, puesto que ya no es necesaria tras añadir al 1.3.3 el color.

WCAG 3.0

En el documento de las WCAG 2.1 se dice que esta nueva versión no abarca todas las cuestiones relativas a la accesibilidad web, y que se está trabajando en paralelo en una actualización mayor, que supondrá una reestructuración sustancial, las WCAG 3.0

La metodología de trabajo de su desarrollo implica un esfuerzo de varios años, de manera que las WCAG 2.1 son una medida provisional, y no se descarta unas WCAG 2.2:

In parallel with WCAG 2.1, the Accessibility Guidelines Working Group is working on requirements for a 3.0 version of accessibility guidelines, developed by the Silver Task Force. The result of this work is expected to be a more substantial restructuring of web accessibility guidance than would be realistic for dot-releases of WCAG 2.

The task force follows a research-focused, user-centered design methodology to produce the most effective and flexible outcome, including the roles of content authoring, user agent support, and authoring tool support. This is a multi-year effort, so WCAG 2.1 is needed as an interim measure to provide updated web accessibility guidance to reflect changes on the web since the publication of WCAG 2.0.

In order for WCAG 2.1 to achieve its goal to update web accessibility guidance in a time frame that is meaningful before the 3.0 project delivers results, WCAG 2.1 must be completed quickly. This inherently means that some proposed Success Criteria may prove too complex to include in WCAG 2.1, but nonetheless will be viewed as important accessibility guidance for current web content.

The larger 3.0 project is expected to incorporate such guidance, but the Working Group could also decide that another set of guidelines between WCAG 2.1 and 3.0 is needed. In that case, a new version, WCAG 2.2, could be proposed. A decision to develop WCAG 2.2 will need to balance the benefits of providing additional accessibility guidance earlier, versus the opportunity cost the work could have on the more substantially restructured and comprehensive 3.0 project.

En Web Content Accessibility Guidelines (WCAG) 2.1. W3C Candidate Recommendation 30 January 2018

---

Artículos relacionados:

• WCAG 2.1. Criterio 1.4.12 (AA) Herramienta gratuita para evaluarlo
• WCAG 2.1 Comprende el criterio "2.5.3 Etiqueta en el nombre"
• Audit Tool WCAG 2.1
• WCAG 2.0 Extensions. "WCAG Cognitive Extension", "WCAG Mobile Extension", y nueva versión de las WCAG 2.0 , noviembre 2015
• WCAG 2.0 , última actualización noviembre 2015
• EN 301 549: primera norma europea de Accesibilidad para productos y servicios de Tecnologías de la Información y Comunicación (TIC) , febrero 2014