Cómo asegurar la creación de contenido dinámico a través de código para que sea accesible

El aseguramiento de la accesibilidad web y de apps es una tarea en la que trabaja MTP a través de su departamento de UX. Conseguir ese objetivo requiere la aplicación de una serie de buenas prácticas de diseño y desarrollo, basadas en los criterios de accesibilidad de las WCAG 2.1.

A continuación, comentaremos los criterios de accesibilidad de las WCAG 2.1 relacionados con el apartado al que dedicamos este post de hoy, que es el de la creación de contenido dinámico.

Criterios WCAG 2.1. relacionados con contenido dinámico

Criterio 1.1.1. Contenido no textual: Hacer que el contenido no textual tenga alternativas textuales.

Criterio 1.3.1. Información y relaciones: Asegurar que la información y los elementos relacionados como encabezados, listas, tablas y formularios, se mantengan incluso cuando se cambie el formato de presentación.

Criterio 1.3.2. Secuencia con sentido: Mantener el orden de lectura correcto para su comprensión.

Criterio 1.4.13 Contenido en Hover o Focus: Asegurar que los contenidos que se muestran u ocultan cuando reciben o pierden el puntero o el foco del teclado pueden ser percibidos y descartados.

Criterio 2.1.1. Teclado: Garantizar que el usuario pueda operar a través de teclado, todo el contenido, tanto los iniciales como los generados dinámicamente.

Criterio 2.1.2. Sin trampas de teclado: Comprobar que la navegación mediante tabulador no quede atrapada en ninguna parte del contenido.

Criterio 2.2.1. Secuencia temporal ajustable: Cerciorarse que los usuarios con discapacidad tienen el tiempo suficiente para interactuar con el contenido.

Criterio 2.4.3. Orden del foco: Verificar que los usuarios pueden interactuar a través del teclado, navegar de forma secuencial por el contenido y encontrar la información en el orden que corresponde.

Criterio 2.4.4. Propósito de los enlaces (en contexto): Asegurar que el propósito de los enlaces sea comprensible de tal forma que el usuario pueda decir si seguir el enlace o no.

Criterio 2.4.7. Foco visible: Garantizar que el indicador del foco del teclado se pueda localizar visualmente en todo momento.

Criterio 3.2.1. Al recibir el foco: Verificar que cuando cualquier componente de la interfaz recibe el foco, no inicia un cambio.

Criterio 3.2.2. Al recibir entradas: Asegurar que el introducir datos o seleccionar un control no provoca un cambio automático de contexto o que, al menos, se informe al usuario previamente.

Criterio 4.1.2. Nombre, rol y valor: Cerciorarse que los productos de apoyo puedan obtener información, interactuar y saber el estado de los controles de interfaz de usuario como enlaces, formularios, etc.

Técnicas WCAG 2.1. relacionados con contenido dinámico

Las WCAG 2.1. contienen un apartado de técnicas que son orientativas/informativas, no obligatorias, pero complementarias para el contenido de los criterios. Hay que recordar que, para el cumplimiento de las WCAG, es necesaria la conformidad de los criterios, no de las técnicas.

Las técnicas relacionadas a Scripts las podemos encontrar en el apartado Client-Side Script Techniques, siendo las técnicas que empiezan con el código “SCR”.

A continuación, expondremos algunos de los aspectos más relevantes y las técnicas a las que están relacionados.

Independencia del dispositivo

Es importante tener en cuenta que no todas las personas navegan de la misma forma. Es posible que nos encontremos con usuarios que solamente usen teclado, que usen pantalla táctil o que usen periféricos adaptados como teclados y ratones adaptados, conmutadores, joystick, …

La técnica del SCR20: Uso del teclado y otras funciones específicas del dispositivo, está relacionada con el criterio 2.1.1. Teclado y el objetivo de esta técnica es proporcionar un evento de teclado que ejecute la misma función que los eventos de mouse. Por ejemplo:

La técnica SCR29: para añadir acciones accesibles desde teclado a elementos HTML estáticos está relacionada con el criterio 2.1.1. Teclado y el objetivo de esta técnica es mostrar como proporcionar acceso a través de teclado a elementos estáticos de HTML como son div o span, permitiendo que los elementos puedan recibir el foco del teclado y que se pueda desencadenar la acción desde teclado.

Cambios dinámicos de contexto

Los eventos pueden disparar acciones inesperadas sin que el usuario sea consciente de que se van a producir o que ya se han producido, por ejemplo, contenido que se actualiza dinámicamente, elementos que se muestran u ocultan, etc. Es importante no modificar el contexto de la pantalla sin anunciarlo a las tecnologías de asistencia para que avisen de los cambios.

La técnica del SCR19: Usar un evento de cambio en un elemento sin causar un cambio de contexto, está relacionada con los criterios 3.2.2. Al recibir entradas y el criterio 3.2.5. Cambio a petición (AAA) y el objetivo de esta técnica es mostrar cómo utilizar el evento onchange en un elemento select para actualizar elementos de una página sin que se cambie el contexto.

La técnica del SCR21: Uso de funciones del DOM para agregar contenido, está relacionada con el criterio 1.3.1. Información y relaciones y el objetivo de esta técnica es mostrar que funciones utilizar para agregar contenido dentro del DOM.

Esta técnica recomienda no utilizar los métodos document.write(), innerHTML, outsideHTML, innerText y outsideText por no ser métodos estándar de la especificación DOM y, en su defecto recomienda utilizar los métodos, createElement(), createTextNode(), appendChild(), removeChild(), insertBefore() y replaceChild().

La técnica del SCR26: Insertar contenido dinámico en el DOM inmediatamente después de su elemento disparador, está relacionada con el criterio 2.4.3. Orden del foco y el objetivo de esta técnica es colocar los elementos de la interfaz de usuario insertados en el DOM de tal manera que el orden de tabulación y el orden de lectura del lector de pantalla sea el correcto.

La técnica del SCR32: Proporcionar validación del lado del cliente y agregar texto de error a través del DOM, está relacionada con el criterio 3.3.1. Identificación del error y el criterio 3.3.3. Sugerencias de error y el objetivo de esta técnica es mostrar un mensaje de error cuando falla la validación de los campos de un formulario. El mensaje de error lo muestra en una lista que se encuentra antes del formulario. Los elementos de la lista están creados como enlaces que llevan a cada campo al que corresponde el error.

Ventanas emergentes

En el caso de las ventanas emergentes, nos podemos encontrar casos en los que la ventana se abra de forma automática o por la acción directa del usuario a través de la activación de un enlace o botón.

Pueden surgir diversas barreras, como que el usuario se mantenga ajeno a lo ocurrido porque la apertura de la ventana fue automática y no notificada. O que fue activado, pero no correctamente notificado que se abriría una nueva ventana. También puede ocurrir que la nueva ventana no tome foco y se convierta en una barrera para personas que naveguen con teclado y usuarios de lector de pantalla.

Lo más apropiado es que las ventanas aparezcan a petición del usuario como desencadenante de la acción de un botón o enlace, que éste tenga un nombre indique claramente su propósito y que notifique a los lectores de pantalla que se abrirá una nueva ventana. La nueva ventana también debe mantener su capacidad de redimensionarla para que las personas con baja visión puedan seguir navegando con su configuración sin tener pérdidas de información.

La técnica del SCR37: Creación de cuadros de diálogo personalizados de forma independiente del dispositivo, está relacionada con el criterio 2.4.3. Orden de foco y el objetivo de esta técnica es crear un cuadro de diálogo personalizado, alternativo al cuadro de diálogo proporcionado por el navegador.

La técnica del SCR39: Hacer que el contenido en “focus” o “hover” sea “hoverable”, descartable y persistente, está relacionada con el criterio 1.4.13. Contenido en “hover” o en “focus” y el objetivo de esta técnica es proporcionar tiempo a los usuarios para leer e interactuar con el contenido que se dispara al mover el puntero o moviendo el foco. Este contenido debe permanecer visible y debe permitir que el usuario pueda mover el puntero sobre el contenido adicional.

Tiempo

En ocasión, hay personas que requieren de tiempo adicional para poder interactuar con el contenido. Personas con movilidad reducida, personas con baja visión, personas ciegas que usen lector de pantalla, personas con limitaciones cognitivas o personas que no dominen el idioma, son algunos de los ejemplos que nos podemos encontrar entre los usuarios que visiten la página. Es por esta razón que es necesario proporcionar un tiempo razonable y/o proporcionar la posibilidad de extender el límite de tiempo.

La técnica del SCR1: Permitir al usuario extender el límite de tiempo predeterminado, está relacionada con el criterio 2.2.1. Secuencia de tiempo ajustable y el objetivo de esta técnica es permitir que el usuario pueda ampliar el tiempo predeterminado proporcionando una funcionalidad que permita solicitar un tiempo adicional.

La técnica del SCSR16: Proporcionar al usuario una advertencia de que el límite de tiempo está a punto de expirar, está relacionada con el criterio 2.2.1. Secuencia de tiempo ajustable y el objetivo de esta técnica es notificar al usuario de que el tiempo para completar la acción se está agotando.

Como hemos mencionado anteriormente, el uso de estas técnicas no asegura que nuestra página sea accesible, para eso deberemos cerciorarnos del cumplimiento de los criterios pero, aun así, la aplicación de estas técnicas será un gran aporte para la accesibilidad de nuestro espacio.

Melanie Caballero

Consultora de Accesibilidad de MTP

Ver más historias