martes, 1 de agosto de 2017

WCAG 2.1, medida provisional hasta las WCAG 3.0

Última actualización: 24/04/2018 (con la versión WCAG 2.1 (Proposed Recommendation ) de 24/04/18)

Resumen:

El objetivo de este artículo es ir documentando las novedades de los borradores de las WCAG 2.1 hasta su recomendación (prevista para junio de 2018), para que vayáis conociendo los nuevos criterios que se proponen y su posible implicación en futuros desarrollos.

Logo del W3C y de las WCAG 2.0 modificado con el texto 2.1 y una etiqueta new

Índice:

Estado del proceso

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. Actualmente, la última actualización es la Web Content Accessibility Guidelines (WCAG) 2.1 W3C Proposed Recommendation 24 April 2018, la última versión antes de la recomendación definitiva. Hasta ahora se ha cumplido el calendario marcado, así que es muy probable que en junio o julio veamos la versión final de las WCAG 2.1, 10 años después de la publicación de las WCAG 2.0.

Objetivos y organización de las WCAG 2.1

El objetivo de la nueva versión de las WCAG era 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, ni se hará (salvo la corrección de una errata en los criterios 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 "WCAG 2.1 Quick Reference" (todavía no disponible), permitirá ordenar o filtrar los criterios por nivel, según sean de las WCAG 2.0 o de las WCAG 2.1, etc.

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.
  • Corrección de una errata en los actuales criterios 1.3.3 y 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 (Proposed Recommendation 24/04/2018)

URL: versión WCAG 2.1 (Proposed Recommendation ) de 24/04/18

Es actualmente la última versión.

No se han modificado ni se van a modificar 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 en esta versión ya no están diferenciados visualmente de los actuales criterios de las WCAG 2.0, como si lo estaban en otros borradores anteriores.

Nota: en esta versión del documento de las WCAG 2.1, el índice de los nuevos criterios tiene erratas. Algunos de los criterios enumerados en ese índice tienen una numeración que no se corresponde con la que después tienen realmente en el documento. En el índice que yo incluyo a continuación se listan con su numeración correcta.

Índice:

Nuevos criterios de las WCAG 2.1:

1.3.4 Orientation (AA) (modificado 04/2008)

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

Respecto a la versión anterior solo ha cambiado el principio y pauta de los que depende, pero la redacción del criterio sigue siendo la misma.

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 pantalla, 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 web y las aplicaciones 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 orientación de visualización particular, que puede ser esencial, serían: un cheque bancario o una aplicación de piano.

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

Understanding 1.3.4

1.3.5 Identify Input Purpose (AA) (modificado 04/2018)

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 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 forma de identificar el propósito del control podría ser el uso de autocompletar, de ARIA, coga-* atributos o de microdatos.

Understanding 1.3.5

1.3.6 Identify Purpose (AAA) (modificado 04/2018)

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

Solo ha cambiado su numeración respecto a la versión anterior, pero la redacción del criterio es la misma.

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 así se configura por ser un botón relevante; etc.

Las técnicas para su cumplimiento, al igual que en el criterio anterior, se basan en el uso de autocompletar, coga-* atributos o microdatos.

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.

El proceso de testeo que se propone 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 indicar los estados y los límites de los componentes de la interfaz, 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 un pantallazo 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 bilogía, etc.)

En versiones anteriores estaba dividido en dos: 1.4.11 Graphics Contrast (AA) y 1.4.12 User Interface Component Contrast (Minimum) (AA), ahora unificados. Además, antes se diferenciaba entre líneas gruesas (3px o más) y finas (2px o menos) que necesitaban más contraste, pero ya no.

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.

Understanding 1.4.11

1.4.12 Text Spacing (AA) (modificado 04/2018)

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, en el contenido implementado con lenguaje de marcas que soporte las siguientes propiedades, no se pierde contenido o funcionalidad ni por configurarlas, ni por no cambiar ninguna otra propiedad de estilo:

  • line height (line spacing): al menos 1.5 veces el tamaño de fuente
  • espaciado debajo de los párrafos: al menos 2 veces el tamaño de fuente
  • letter spacing (tracking): al menos 0.12 veces el tamaño de fuente
  • word spacing: al menos 0.16 veces el tamaño de fuente

Excepción: los lenguajes humanos y scripts que no hacen uso de una o más de estas propiedades del estilo del texto en los textos escritos, pueden usar solo las propiedades que existen para esa combinación de lenguaje y script.

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

Understanding 1.4.12

1.4.13 Content on Hover or Focus (AA) (modificado 04/2018)

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 serían: tooltips personalizados, submenús, pop-ups no modales que se muestran en el hover o en el focus, etc.

Understanding 1.4.13

2.1.4 Character Key Shortcuts (A) (modificado 04/2018)

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

Solo ha cambiado la pauta de la que cuelga, pero la redacción del criterio es la misma.

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.

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

Se advierte 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 indica 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.

Understanding 2.2.6

2.3.3 Animation from Interactions (AAA) (modificado 04/2018)

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

Solo se ha modificado la pauta de la que cuelga, la redacción del criterio es la misma.

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.

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

Understading 2.3.3

Nueva pauta propuesta 2.5 Input Modalities (modificado 04/2018)

Relativa al principio "Operable".

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

2.5.1 Pointer Gestures (A) (modificado 04/2018)

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.

Gestos en pantallas táctiles que implican uno o varios dedos.

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

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.

Understanding 2.5.2

2.5.3 Label in Name (A) (modificado 04/2018)

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 contiene el texto que ese 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).

Understanding 2.5.3

2.5.4 Motion Actuation (A) (modificado 04/2018)

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

Solo cambia respecto a la versión anterior la pauta de la que cuelga, pero la redacción del criterio es la misma.

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.

Understanding 2.5.4

2.5.5 Target Size (AAA) (modificado 04/2018)

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

Solo cambia la numeración respecto a la versión anterior, la redacción del criterio es la misma.

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.

Understanding 2.5.5

2.5.6 Concurrent Input Mechanisms (AAA) (modificado 04/2018)

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

Solo cambia la numeración respecto a la versión anterior, la redacción del criterio es la misma.

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.

Understanding 2.5.6

4.1.3 Status Messages (AA) (modificado 04/2018)

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.

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 criterios actuales

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:

0 comentarios :
Publicar un comentario