martes, 1 de agosto de 2017

WCAG 2.1, medida provisional hasta las WCAG 3.0

Última actualización: 17/08/2017 (con la versión WCAG 2.1 de 16/08/17)

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

Las WCAG 2.1 y 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. Actualmente, la última actualización (1) es el Working Draft de 16 de agosto de 2017. Michael Cooper, en la nota de la actualización del 19 de abril de 2017(2), indica que el objetivo es publicar borradores actualizados mensualmente que solo incluirán los criterios de conformidad formalmente aceptados por el grupo de trabajo.

En la nota de la actualización del 28 de julio (3) se indica que se espera un única actualización más antes de cerrar la adicción de nuevos criterios y comenzar la optimización de la estructura de las WCAG 2.1 hasta su forma final.

En la nota de la actualización del 16 de agosto (4) se informa de que el plan es publicar en septiembre la versión con los criterios definitivos y centrarse para la versión de noviembre en la posible reorganización o renumeración de los criterios de éxito. La previsión sigue siendo publicar la recomendación para mediados de 2018.

En el documento WCAG 2.1 Status (5) se especifica efectivamente que el objetivo es que las WCAG 2.1 sean recomendación a mediados de 2018 (10 años después de la publicación de las WCAG 2.0). Se dice que, aunque es probable que no abarquen todas las cuestiones relativas a la accesibilidad web, se está trabajando en una actualización mayor.

En el propio documento de las WCAG 2.1 se indica que se está trabajando en paralelo en las WCAG 3.0, y que 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.

En Web Content Accessibility Guidelines (WCAG) 2.1. W3C Working Draft 19 April 2017

Todos los criterios de conformidad de las WCAG 2.0 están incluidos en las WCAG 2.1. De momento, no se ha modificado ningún criterio de conformidad de las actuales WCAG 2.0 (salvo la corrección de una errata) porque se centran en la revisión de los nuevos criterios, de manera que los posibles cambios en los criterios de las WCAG 2.0 se abarcarían más adelante, al final del proceso. Estos cambios serán, por ejemplo, relativos a su numeración, a evitar duplicidades con los nuevos criterios o a mejorar su claridad.

Recordad que es un proceso público, y que se pueden realizar comentarios al documento en la web del proyecto en GitHub (6).

WCAG 2.1 (Working Draft 16/08/2017)

URL: WCAG 2.1 (Working Draft 16/08/2017)

Es actualmente la última versión.

En la versión de julio de 2017 no se modificaron los criterios de conformidad de las WCAG 2.0 (salvo la corrección de una errata), solo se añadieron nuevos criterios, fáciles de identificar porque están recuadrados de verde y van acompañados del texto "NEW". Se añadieron también tres pautas nuevas, nuevos términos al glosario y una nota en un requisito de conformidad.

En la versión de agosto de 2017 se añaden 4 criterios nuevos (los señalo con "nuevo 08/17"), se incluyen dos términos al glosario y se modifica uno.

Los nuevos criterios incluidos hasta ahora son 15:

1.3.4 Contextual Information (AAA) (nuevo 08/17)

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, la información contextual para controles, símbolos y regiones se puede determinar por software utilizando un vocabulario disponible públicamente.

Se entiende por información contextual cualquiera que aclare el significado de un objeto (su propósito, su posición en un proceso, su relación con otros objetos o procesos).

Página del criterio 1.3.4 en GitHub: Support Personalization #6

1.4.10 Zoom content (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."

Content can be zoomed to an equivalent width of 320 CSS pixels without loss of content or functionality, and without requiring scrolling on more than one axis except for parts of the content which require two-dimensional layout for usage or meaning.

Note: 320 CSS pixels is equivalent to a starting viewport width of 1280 CSS pixels wide at 400% zoom. For web pages which are designed to scroll horizontally, the 320px should be taken as the height rather than width.

Note: Examples of content which require two-dimensional layout are images, maps, diagrams, video, games, presentations, data tables, and interfaces where it is necessary to keep toolbars in view while manipulating content."

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

Como he comentado, será posteriormente en el proceso cuando se decida qué número de criterio darle o las posibles modificaciones en los criterios actuales con los cuales pueda haber duplicidades.

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.

Página del criterio 1.4.10 en GitHub: Zoom Content #77

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

The visual presentation of graphical objects that are essential for understanding the content or functionality have a contrast ratio of at least 4.5:1 against the adjacent color(s), except for the following:

  • Thicker: For graphical objects with a minimum width and height of at least 3 CSS pixels, the graphic has a contrast ratio of at least 3:1;
  • Sensory: Non-text content that is primarily intended to create a visual sensory experience has no contrast requirement;
  • Logotypes: Graphics that are part of a logo or brand name have no minimum contrast requirement;
  • Essential: A particular presentation of the graphical is essential to the information being conveyed.

Este criterio hace referencia al contraste y está íntimamente relacionado con el actual criterio 1.4.3 (AA), exigiendo el mismo ratio de contraste:

  • 4,5:1 para los gráficos más finos: 2px o menos,
  • 3:1 para los más gruesos: 3px o más

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 o los gráficos, si estos son necesarios para comprender el contenido o la funcionalidad.

¿Qué se entiende por "graphical objects"?

The term "graphical object" is intended to apply to stand-alone icons such as a print icon (with no text), and the important parts of a more complex diagram such as each line in a graph. Not every graphical object needs to have sufficient contrast with its surroundings, only those that are required to understand what the graphic is conveying.

Página del criterio 1.4.11 en GitHub: Graphics Contrast #9

1.4.12 User Interface Component Contrast (Minimum) (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."

Essential visual identifiers of user interface components have a contrast ratio of at least 4.5:1 against the immediate surrounding color(s), except for the following situations:

  • Thicker: A contrast ratio of at least 3:1 is required where the minimum width and height are at least 3 CSS pixels, for the essential visual identifier;
  • Inactive: Disabled or otherwise inactive user interface components;
  • User agent control: The color(s) of the user interface component and any adjacent color(s) are determined by the user agent and are not modified by the author.

Note:

  • Examples of essential visual identifiers of user interface components may include (a border, edge, or icon), current value (such as non-text visual indication of aria-valuenow on a slider) and current state (such as selection indicator, focus indicator) or other essential visual indication (which do not rely on color alone).
  • Under consideration: simplify this Success Criterion by setting the minimum color contrast requirement to 3:1 and removing any need for measuring thickness.
  • Under consideration: will review to see if it is possible to combine with proposed WCAG 2.1 SC 1.4.11 Graphics Contrast.

Este criterio complementa al anterior y se va a considerar unificarlos. Hace referencia a los identificadores visuales esenciales de los componentes de la interfaz de usuarios, como puede ser un borde, el indicador visual del valor actual en un control deslizante, el indicador del foco, etc. Por ejemplo, si el indicador del foco tiene 3 px su color deberá tener un contraste de 3:1, y si es menor de 3px un contraste de 4:5

Se incluyen diferentes ejemplos, como botones submit con colores que ofrecen diferente contraste y con/sin borde de diferente ancho y contraste.

Página del criterio 1.4.12 en GitHub: User Interface Component Contrast (Mínimum) #10

1.4.13 Adapting Text (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."

If the technologies being used allow the user agent to adapt style properties of text, then no loss of essential content or functionality occurs by adapting all of the following:

  1. line height (line spacing) to at least 1.5 times the font size
  2. spacing underneath paragraphs to at least 2 times the font size
  3. letter spacing (tracking) to at least 0.12 times the font size
  4. word spacing to at least 0.16 times the font size

Note: Editor's note: The Working Group seeks to include overriding text color, background color, and font-family as part of this SC, but is not yet able to identify a way to do so that is sufficiently testable.

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.

1.4.14 Content on Hover or Focus (AA) (nuevo 08/17)

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 porque un componente de la interfaz coge el foco (receiving keyboard focus or pointer hover) lo siguiente es verdad:

  • Visible trigger. El contenido adicional que se hace visible no oculta un contenido esencial, o bien puede ser cerrado o posicionado por el usuario.
  • Hover. Si el contenido adicional se activa en el hover, el contenido permanece visible mientras el puntero se mueve sobre él.
  • Focus. El contenido adicional permanece visible mientras el componente que activó su visibilidad siga teniendo el foco, a menos que el usuario descarte el contenido adicional.

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

Ejemplos de contenidos a los que 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.

Página del criterio 1.4.14 en GitHub: Popup Visibility #75

2.2.6 Interruptions (minimum) (AA)

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

There is an easily available mechanism to postpone and suppress interruptions and changes in content unless they are initiated by the user or involve an emergency.

Íntimamente relacionado con el actual criterio 2.2.4 "Interrupciones: El usuario puede postergar o suprimir las interrupciones, excepto cuando las interrupciones implican una emergencia. (Nivel AAA)".

Se añade que el mecanismo para postergar o suprimir las interrupciones esté "easily available" (fácilmente disponible), se añade a las interrupciones los cambios en el contenido, y se especifica como excepción, "a menos que hayan sido iniciadas por el usuario".

¿Qué se entiende por "easily available" (fácilmente disponible)?

one or more of the following are true:

  • can be set one time with as wide a scope as possible (such as using the standards of the operating system, from ISO 9241-112 [[ISO_9241-112]] or GPII [GPII] when available)
  • has the option to save or change the setting, where available interoperably, but also for the scope of the set of web pages
  • is reachable from each screen where it may be needed, and the path and the control conforms to all of this document

Página del criterio 2.2.6 en GitHub: Interruptions #47

2.2.7 Accessible Authentication (A)

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

Essential steps of an authentication process, which rely upon recalling or transcribing information, have one of the following:

  • alternative essential steps, which do not rely upon recalling and transcribing information; or
  • an authentication-credentials reset process, which does not rely upon recalling and transcribing information

Exceptions:

  • Authentication process involves basic identifying information to which the user has easy access, such as name, address, email address and identification or social security number.
  • This is not achievable due to legal requirements.

Este criterio asegura que el método de autenticación de usuario no depende de la capacidad de memorizar o recuperar la información memorizada, o de la capacidad de hablar o de realizar gestos de forma fiable, o de reconocer caracteres presentados en pantalla y luego introducirlos en un campo de entrada, o de realizar cálculos, o de procesar mentalmente la información presentada o recordada más allá de los procesos mentales que se requieren para usar una página sencilla (una página con texto y búsqueda sencilla y botones y enlaces claramente marcados).

De lo contrario, y a menos que se puede demostrar que todos los usuarios pueden acceder de esa manera, se ofrece una autenticación de usuario alternativa que no se base en ninguna de las habilidades enumeradas.

En definitiva, se trata de evitar que los diferentes tipos de captcha que existen puedan ser un impedimento para que algún usuario acceda.

Página del criterio 2.2.7 en GitHub: Accessible Authentication #23

2.4.11 Character Key Shortcuts (A)

Relativo al principio "Operable" y a la pauta 2.4 "Navegable: Proporcionar medios para ayudar a los usuarios a navegar, encontrar contenido y determinar dónde se encuentran."

If a keyboard shortcut consisting entirely of one or more character keys is implemented by the content, then a mechanism is available to turn it off or to remap it to a shortcut that uses at least one non-character key.

Se entiende por "keyboard shortcut" un medio alternativo para activar una acción presionando una o más teclas.

Se entiende por "character keys" cualquier caracter del teclado que se pueda imprimir (letras, -incluyendo mayúsculas-, signos de puntuación, números, símbolos) Las teclas de Espacio y Enter no son "character keys".

Este criterio asegura que, si el sitio tiene implementados atajos de teclado, el usuario pueda desactivarlos o sustituirlos por otros que utilicen al menos una tecla que no sea una "character keys".

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.

También 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.

Página del criterio 2.4.11 en GitHub: Character Key Shortcuts #69

Nueva pauta propuesta 2.5 Pointer Accessible

Relativa al principio "Operable".

Make it easier for users to operate pointer functionality

2.5.1 Target Size (AA) (nuevo 08/17)

Relativo al principio "Operable" y a la nueva pauta 2.5 "Pointer Accessible"

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

Incluye ciertas excepciones:

  • Customizable. Si hay un mecanismo para cambiar el tamaño del target independientemente del nivel de ampliación de la página.
  • 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.
  • Essential. Si una presentación particular del target es esencial para la información que se transmite.
  • In-Page. Si el target es un enlace de texto cuyo destino es la misma página.
  • Inline. Si el target está en un bloque de texto.
  • Grouped. Si los targets están en grupos de más de 5, tienen al menos 44 px en una dimensión y 22 px al menos en la otra.
  • User agent control. Si la apariencia del target es determinada por el agente de usuario y no es modificada por el autor.

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.

Página del criterio 2.5.1 en GitHub: Target Size #60

2.5.2 Target Size (AAA) (no exception) (nuevo 08/17)

Relativo al principio "Operable" y a la nueva pauta 2.5 "Pointer Accessible"

Para alcanzar el nivel AAA el target siempre debe medir como mínimo 44x44 píxeles CSS, sin excepciones (sí permitidas para alcanzar el nivel AA, ver criterio 2.5.1)

Página del criterio 2.5.1 en GitHub: Target Size #60

Nueva pauta propuesta 2.6 Additional sensor inputs

Relativa al principio "Operable".

No incluye de momento descripción, pero sí un nuevo criterio, el 2.6.1 (ver a continuación)

2.6.1 Orientation (AA)

Relativo al principio "Operable" y a la nueva pauta 2.6 "Additional sensor inputs"

Content is not locked to a specific display orientation, and functionality of the content is operable in all display orientations, except where display orientation is essential for use of the content.

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

Página del criterio 2.6.1 en GitHub: Orientation #70

Nueva pauta 2.7 Speech

Relativa al principio "Operable".

No incluye de momento descripción, pero sí un nuevo criterio, el 2.7.1 (ver a continuación)

2.7.1 Accessible Name (A)

Relativo al principio "Operable" y a la nueva pauta 2.7 "Speech"

Where an active control has a visible label, the accessible name for the control includes the text string used for its visible label.

Note: best practice is to place the text string at the start of the text string.

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

Página del criterio 2.7.1 en GitHub: Orientation #68

3.2.6 Accidental Activation (A)

Relativo al principio "Comprensible" y a la pauta 3.2 "Predecible: Hacer que las páginas web aparezcan y operen de manera predecible."

For single pointer activation, at least one of the following is true:

  • Activation is on the up-event, either explicitly or implicitly as a platform's generic activation/click event;
  • A mechanism is available that allows the user to choose the up-event as an option;
  • Confirmation is provided, which can dismiss activation;
  • Activation is reversible;
  • Down-event activation event is essential and waiting for the up-event would invalidate the activity.

¿Qué se entiende por "single pointer activation"?

Un punto de contacto con la pantalla:

One point of contact with the screen (vs. multi-touch). A pointer can be any point of contact on the screen made by a mouse cursor, pen, touch (including multi-touch), or other pointing input device. This model makes it easier to write sites and applications that work well no matter what hardware the user has. For scenarios when device-specific handling is desired, this specification also defines properties for inspecting:

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

Sería el "mouseup" o, en una interacción táctil, cuando se levante 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.

Por tanto, cuando la acción se produce por un contacto con la pantalla, el evento debe dispararse al levantar el dedo, o bien el usuario puede modificar las preferencias para que sea así, o se pide confirmación, o la activación es reversible. A no ser que sea esencial que la activación sea en el evento descendente y esperar al evento ascendente invalidaría la actividad (por ejemplo en un juego).

Los ejemplos que se proponen son:

  • For interface elements that have a single tap or long press as input, the corresponding event is triggered when the finger is lifted inside that element.
  • A phone dialling application has number keys that are activated on touch down. A user can undo an unwanted number by hitting the backspace button to delete a mistaken digit.

Página del criterio 3.2.6 en GitHub: No Accidental Activation #65

3.2.7 Change of Content (AA)

Relativo al principio "Comprensible" y a la pauta 3.2 "Predecible: Hacer que las páginas web aparezcan y operen de manera predecible."

Programmatic notification is provided for each change of content that indicates a user action was taken or that conveys information, unless one or more of the following is true:

  • There is a programmatically determined relationship between the new content and the control that triggers it;
  • The user has been advised of the change of content before or as a result of using the control;
  • The change of content is not a result of a user action AND not related to the primary purpose of the page.

The Working Group is including this proposed Success Criteria for comment, but has not reached consensus on how to best handle web pages and applications with continual changes of content such as games and simulations and seeks additional input from reviewers on this point.

Se debe proporcionar una notificación para cada cambio del contenido de la página, lo cual favorecerá a los usuarios que acceden con un lector de pantalla, de manera que los cambios no les pasen desapercibidos. Traté este tema en el artículo 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.

No son necesarios cuando existe una relación determinada por programación entre el nuevo contenido y el control que lo activa; o el usuario haya sido informado del comportamiento antes de usar el control; o el cambio en el contenido no sea resultado de una acción del usuario y no esté relacionado con el propósito principal de la página (esto es, si se quita la página no pierde su significado o razón principal de existir, como pueden ser cambios en contenidos publicitarios).

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, como expliqué en Live Regions y WAI-ARIA. Cómo mejorar la accesibilidad de contenidos que se actualizan automáticamente.

Página del criterio 3.2.7 en GitHub: Change of Content #2

Nota adicional en el requisito de conformidad 5.1.2 Full pages

A full page includes each variation of the page that is automatically generated by the page for various screen sizes. 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.

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:

  • Accessible Name
  • Adapt
  • Character key
  • Change of content
  • Contextual information
  • CSS pixel
  • Display orientation
  • Easily available (or easily available mode or setting)
  • Essential
  • Keyboard shortcut
  • Primary purpose of the page
  • Set of Web pages (modificado)
  • Single pointer activation
  • Style Properties
  • Target
  • Up-event

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.


Notas:

Artículos relacionados: