Mejorar la accesibilidad con regiones activas y WAI-ARIA

0
81
Vista cenital de tablero de ajedrez digital


Índice

1 – Introducción

Las regiones activas o live regions son fundamentales para la accesibilidad en las aplicaciones modernas. Hace años, la web se componía de documentos estáticos y los únicos cambios en el contenido se producían al cargar nuevas páginas. Hoy en día, estos cambios son completamente dinámicos. Este tipo de comportamiento es especialmente problemático cuando tratamos con usuarios con algún tipo de discapacidad sensorial. Al no percibir las alteraciones del contenido, puede costarles entender qué está pasando y cómo deben actuar en cada momento.

Las regiones activas vienen a solventar este problema. Los cambios en el contenido de una región activa son notificados a las tecnologías de asistencia según las preferencias seleccionadas. En ocasiones, es necesario crear regiones activas específicas para anunciar ciertos mensajes de estado a los usuarios que lo necesiten.

En este tutorial, vamos a ampliar la aplicación de muestra ChessBoard que ya vimos en otro tutorial. Vamos a añadir la capacidad de mover las piezas por el tablero y vamos a crear una región activa que anuncie al usuario los movimientos que se llevan a cabo. Por supuesto, esta funcionalidad se va a implementar a grandes rasgos, sin entrar en la validación de los movimientos. Además, vamos a ver cuestiones adicionales de accesibilidad.

Aquí tenéis el enlace al repositorio en GitHub.

2 – Entorno

  • Windows 10
  • SlimBook Pro X (Intel I7, 32GB RAM)
  • Visual Studio Code

3 – Planteando la funcionalidad

Como recordaréis, ChessBoard era una prueba de concepto sobre la reutilización de web components utilizando el framework Stencil JS. Ofrecía la posibilidad de navegar por el tablero con el teclado y anunciaba al usuario el contenido de cada casilla en caso de que no pudiera verlo directamente.

Ahora vamos a añadir la funcionalidad para mover las piezas. Queremos que, ya sea con un clic de ratón o con la pulsación de una tecla de activación, enter o la barra espaciadora, se seleccione una casilla. Si ya hay una casilla seleccionada y se selecciona otra, entonces se intenta ejecutar el movimiento. Por supuesto, en la casilla inicial tendrá que haber una pieza.

Además, queremos anunciar la jugada para que cualquiera pueda entenderla. Vamos a crear una región activa invisible donde haremos estos anuncios.

Por supuesto, seguiremos la idea de dividir nuestra lógica en emitter-listener-handler para encapsular y poder reutilizar el código. Veréis que con este esquema que ya vimos en el tutorial anterior, es muy sencillo añadir este comportamiento sin miedo a que cause problemas con los otros que ya habíamos implementado.

4 – Manejo de la activación

Lo primero que vamos a hacer es crear un conjunto de emitter-listener-handler que se responsabilice de este comportamiento. Si esta idea no es familiar, os recomiendo leer antes el tutorial previo que mencionaba antes.

4.1. – El componente ActivableItem

Este componente se encargará de detectar los clics y las pulsaciones de teclas de activación. Recibe por propiedad la posición del elemento, para poder adjuntarla cuando emita su propio evento activatedItem. Además, también podremos elegir mediante propiedades si queremos que capture las pulsaciones de la barra espaciadora, la tecla enter o ambas. Esto se ha pensado así porque no siempre nos puede interesar el mismo comportamiento.

4.2 – El componente ActivatedItemListener

A continuación, implementamos el listener para nuestro emitter. Como en el caso del FocusedItemListener, sólo notificará al handler de que ha recibido el evento, pasándole la posición.

4.3 – La interfaz ActivatedItemHandler

Igual que antes, creamos la interfaz que se relaciona con nuestro listener. Se compone sólo de un método sencillo que permite notificar la activación.

5 – Integrar la activación

Ahora vamos a integrar estos elementos que hemos creado en nuestros componentes principales. Como veréis, el esquema de separación por comportamientos facilita mucho la labor. No tendremos que modificar nada de lo que ya teníamos anteriormente. Sólo habrá que añadir nuestro emitter y listener mediante composición, e implementar el handler.

5.1 – Las casillas

Os habréis dado cuenta de que en ningún momento estamos controlando con nuestro emitter o listener si hay alguna casilla seleccionada. El motivo es que ellos sólo se ocupan de manejar las activaciones. El estado en que queda el componente padre o hijo después de eso escapa a su responsabilidad.

Vamos a añadir una propiedad al componente ChessSquare que indique si la casilla está seleccionada o no. En función de esto, añadiremos una clase CSS adicional para marcar visualmente la selección. Además, utilizaremos el atributo aria-pressed. Este atributo indica si un botón de conmutación (toggle button) está pulsado o no. De esta forma, el usuario que no pueda ver la marca visual, podrá saber si la casilla está seleccionada a través de una tecnología de asistencia como un lector de pantalla.

Y el CSS para la clase selected:

5.2 – El tablero

Como la vez anterior, nuestro componente ChessBoard implementará la interfaz ActivatedItemHandler. En este caso, vamos a almacenar en un estado interno la casilla seleccionada si no hay otra. En ese caso, comprobaremos si el movimiento es válido y lanzaremos un evento de movimiento. Si no lo es, lanzaremos un evento de movimiento inválido.

Como notaréis, hay algunas diferencias de implementación con el tutorial anterior. Algunas son simples mejoras de rendimiento. Otras, como pasar el atributo boardModel de estado a propiedad, tienen implicaciones más profundas. En este caso, lo que intentamos es que nuestro componente tablero sea lo más agnóstico posible. Él se limita a representar lo que otros le dicen que haga y a manejar la lógica interna. Por eso emitimos el evento, para que sea otro quien lo maneje. En este caso, sólo vamos a modificar la posición y a anunciar la jugada, pero cabría la posibilidad de enviarlo a un servidor o tratarlo de alguna manera. Todo esto es irrelevante para nuestro tablero. Cuanto más ignorante se mantenga, más fácil será integrarlo dentro de cualquier aplicación.

También cambiaremos la forma de renderizar. Ahora tendremos en cuenta si hay una casilla seleccionada para añadir dicha propiedad a los componentes ChessSquare. De este modo, cuando la posición seleccionada que se almacena como estado en ChessBoard cambie, el tablero se renderizará de nuevo.

6 – Ejecutando los movimientos

La responsabilidad de ejecutar los movimientos y anunciar ls jugadas al usuario queda del lado del componente app-root. Este es quien se encarga de mantener el boardModel y cambiar el mensaje de la región activa.

Tenemos un par de listener que escuchan los eventos move e invalidMove que emite el componente ChessBoard. Es importante tener en cuenta que primero debemos anunciar la jugada, pues si lo hacemos después de ejecutar el movimiento en el boardModel , no tendremos la información necesaria disponible.

Las regiones activas anuncian cambios al usuario cuando su contenido se modifica. Estos cambios pueden anunciarse de forma parcial o atómica. En el segundo caso, se anuncia todo el contenido, mientras que en el primero sólo se anuncian las partes de este que cambian. En nuestro caso, nos interesa anunciar toda la jugada, aunque sea la misma pieza que la anterior, así que usamos el atributo aria-atomic a true.

En cuanto al atributo aria-live , es el que se encarga de definir la región activa. Tenemos los posibles valores assertive y polite. El primero se utiliza sobre todo para mensajes de alerta, ya que interrumpe la cola de anuncios establecida. En el segundo caso, se encola el mensaje, que se anunciará cuando llegue su turno.

El contenido de la región activa se actualizará en cuanto el atributo moveNotificationMsg cambie, ya que es un estado. El mensaje contiene la pieza, la acción (mover o capturar) y la casilla de destino.

7 – Conclusiones

La especificación WAI-ARIA incluida en HTML 5 es muy potente. Hemos visto cómo podemos transmitir al usuario el estado de ciertos elementos, como botones de conmutación. También hemos explorado de forma superficial las características de las regiones activas, que son fundamentales para la accesibilidad en páginas altamente dinámicas.

Además, hemos constatado lo que dijimos en el tutorial anterior en que comenzamos a crear esta aplicación: la composición de comportamientos mediante web components facilita enormemente la labor de integrar funcionalidades nuevas a nuestros componentes.

Dejar respuesta

Please enter your comment!
Please enter your name here