>

Accesibilidad y Menús

Elena Torro     Colaboraciones    07/10/2016

Introducción

En internet encontramos multitud de menús: barras de navegación, menús laterales, menús inferiores, horizontales, verticales, menús que se despliegan, menús con submenús… El objetivo principal de este post es el de mostrar cómo aplicar pautas de accesibilidad en los menús de las páginas y aplicaciones web. Antes de continuar, es necesario aclarar que este post se centra en accesibilidad, y no en usabilidad. Estos conceptos están muy relacionados entre sí, por lo que es conveniente aclarar la distinción antes de seguir leyendo.

La diferencia entre estos dos conceptos, en el caso de hablar de la accesibilidad y la usabilidad de un menú, sería la siguiente: si hablamos de cómo conseguir que el usuario sepa que ha de hacer click en un botón para mostrar un menú desplegable, estamos hablando de usabilidad (recomiendo leer el capítulo de ‘No me hagas pensar’ de Steve Krug sobre la usabilidad en los menús) Por otro lado, si lo que quieres es que un usuario que utilice tecnologías asistivas pueda hacer click en un link de un menú, entonces se trata de accesibilidad. Una vez dicho esto, ¡empezamos!

Desarrollo

Un menú es, según este documento del W3C, un widget que ofrece una lista de opciones al usuario. En la definición apunta que un menú se encuentra normalmente abierto o se hace visible al hacer click en un botón de menú o haciendo click en una opción para abrir un submenú.

A la hora de añadir un menú, como buen programador preocupado por la accesibilidad, te preguntas, ¿y qué tengo que hacer para que mi menú sea accesible? Voy a empezar por explicar cuáles son las características a tener en cuenta para crear un menú accesible, y después veremos un ejemplo de uso.

Añadiendo atributos

Los atributos ARIA (las siglas de Accessible Rich Internet Applications) son unos atributos que siguen el formato aria- , y que se pueden añadir a las etiquetas HTML. Estos atributos permiten a las tecnologías asistivas, como por ejemplo, los lectores de pantalla que utilizan personas con problemas visuales, conocer información útil y adicional sobre un elemento. Del mismo modo, el atributo role proporciona también información adicional, concretamente sobre el tipo de objeto que representa (es decir, el rol del elemento). El último atributo a tener en cuenta en esta lista es el atributo tabindex, que es lo que verdaderamente permite que el usuario navegue utilizando el tabulador. Este atributo se puede aplicar en cualquier elemento HTML que se pueda renderizar, para así añadir información adicional que permita al programador hacer que un widget sea accesible. Veamos la relación de estos atributos con los menús.

Roles:

  • role=navigation: elemento que contiene una serie de elementos que se utilizan para navegar por el documento HTML.

  • role=menu: elemento que es un tipo de widget que ofrece una lista de elecciones al usuario.

  • role=menubar: este elemento es una subclase de role=menu. Suele representar una barra horizontal y visible.

  • role=menuitem: elemento que representa una de las opciones dentro de un role=menu o un role=menubar.

  • role=menuitemcheckbox: se trata de un elemento de role=menuitem que tiene implícito un estado de 'checked' (marcado o seleccionado), cuyo valor puede ser verdadero, falso o mixto. Este rol debe tener, por lo tanto, el atributo aria-checked.

  • role=menuitemradio: se trata de un elemento de role=menuitem que, al igual que un checkbox, puede estar 'checkeado' o no. La diferencia es que dentro de un grupo de elementos con role=menuitemradio, sólo uno de ellos puede estar seleccionado. Es decir, no puede haber varios items seleccionados a la vez. Conviene por esto que, si dentro de un role=menu (o menubar) existe más de un grupo de role=menuitemradio, estos estén agrupados en un elemento con role=group para poder ser diferenciados, y que entre estos exista un elemento con role=separator

  • role=separator: se trata de un elemento que separa, como se ha visto en el punto anterior, grupos de elementos, para así poder identificar distintas regiones dentro de un mismo elemento.

En algunas ocasiones no es necesario que un elemento tenga un rol si la etiqueta del elemento ya describe la funcionalidad del mismo. Por ejemplo, una etiqueta nav no necesita un atributo role=navigation.

Otro ejemplo de un uso incorrecto de roles sería el de utilizar en el menú de navegación principal los roles role=menu y role=menuitem en una lista de links que actúen de menú principal. El hecho de añadir roles hace que las tecnologías asistivas cambien su manera de interpretar un elemento. Un rol de menú contiene ítems que han de 'hacer cosas', ya sea seleccionar una opción o ejecutar una acción. Si cambiamos el rol del menú de navegación y de los links que contienen, estos links dejan de ser links para las tecnologías asistivas. No se espera de ellos que lleven a otro lugar, que es lo que hacen, ¡sino que ejecuten una acción!.

Atributos ARIA:

  • aria-haspopup: indica si un elemento tiene relacionado un grupo de elementos que serán mostrados al realizar alguna acción sobre éste. Se utiliza para indicar que, por ejemplo, un role=menuitem despliega un submenú al hacer click sobre él.

  • aria-expanded: indica si un elemento está en un estado expandido o colapsado.

  • aria-checked: indica si un elemento está seleccionado o no. Dicho atributo es similar a aria-selected.

  • aria-disabled: permite deshabilitar, por ejemplo, un role=menuitem si una opción dentro de un menú está desactivada.

  • aria-owns: permite identificar si un elemento con role=menuitem no está situado jerárquicamente dentro de un role=menu o role=menuitem, a qué elemento del documento pertenece.

  • aria-controls: identifica el elemento o elementos cuyo contenido es controlado por este elemento.

  • aria-atomic: indica si, en el caso de que toda la región del elemento haya cambiado, queremos que se notifique al usuario a través de tecnologías asistivas de sólo ciertas partes. Un ejemplo de uso algo más ilustrativo sería el siguiente: vamos a imaginar que tengo un chat. En mi cuenta tengo un total de cinco amigos, pero sólo tres están conectados. La lista de amigos conectados aparece en un menú lateral. Cuando hago click sobre el nombre de un amigo, me aparece un pop up que muestra su email. Lo que quiero que suceda es que, si se conecta un cuarto amigo, el lector de pantalla escuche este cambio y me liste todos los amigos que están conectados, no sólo el nombre del amigo que se acaba de conectar.

Hay muchos otros atributos aria que se pueden utilizar para mejorar la accesibilidad de los menús, siendo los anteriores destacados en el post por su relación directa con los elementos de navegación. Por ejemplo, el atributo aria-labelledby se puede utilizar en una etiqueta para indicar que el 'título' o 'nombre' que identifica al menú de navegación se encuentra, por ejemplo, en una etiqueta

Ejemplo:

Navegacion

Tabindex

Cuando se renderizan todos los tags HTML, la navegación por estos sigue un orden. Se puede alterar el orden por defecto de los elementos con el atributo tabindex, de manera que al pulsar el tabulador, el usuario salte de un elemento a otro siguiendo dicho orden. Un tag HTML puede contener un atributo tabindex con los siguientes valores:

  • tabindex=0: El elemento se añade a la secuencia de tabulaciones siguiendo el orden del documento HTML.

  • tabindex>0: El elemento se añade a la secuencia de tabulaciones en el orden indicado en el atributo.

  • tabindex

Ejemplo: Barra de navegación

Una vez vistos los atributos principales, toca poner en práctica la teoría. El siguiente ejemplo consiste en crear una barra de navegación que permita al usuario acceder a cada uno de los links utilizando el teclado mediante la tecla tabulador, incluyendo un submenú desplegable, y que además sea interpretado correctamente por un lector de pantalla.

Para conseguir esto, necesitarás:

  • CSS para conseguir que el menú desplegable sea visible o invisible según su atributo ARIA:

CSS

  • JavaScript, para cambiar este atributo según donde esté el foco:

JavaScript

El código HTML del menú de navegación sería el siguiente:

Menu Accesible

El ejemplo completo lo podéis encontrar en el repositorio de GitHub que he creado para realizar ejemplos de accesibilidad web. Si quieres probar, puedes utilizar un lector de pantalla para ver qué sucede cuando navegas por el menú. Yo lo he probado con la herramienta ChromeVox en Chrome, y la transcripción es la siguiente (nótese que todos los links a los que hago referencia se encuentran en el mismo documento, por eso el lector de pantalla los reconoce como enlaces internos):

"HTML5 Accesible menú bar. Home. Enlace interno. Elemento de Lista. About Us. Enlace interno. Elemento de Lista. Our Work. Enlace interno tiene un componente emergente. Lista ampliado con cuatro elementos. Graphic Design. Enlace Interno. Web Development. Enlace Interno. Elemento de Lista. Visual Art. Enlace Interno. Elemento de Lista. Augmented Reality. Enlace Interno. Elemento de Lista. Contact. Enlace Interno. Elemento de Lista."

Conclusión

Esto es sólo un ejemplo de un caso en el que la accesibilidad facilita a los usuarios que no pueden interactuar con una página o aplicación web a través de elementos como el ratón o la pantalla. Como puedes comprobar, es necesario un poco de esfuerzo para comprender y utilizar la accesibilidad web. La documentación es extensa, pero puedes encontrar multitud de ejemplos en internet que te orienten a la hora de realizar aplicaciones accesibles.

Bibliografía

  • [WAI - Menu Structure] "Menu Structure." Menus, WAI Web Accessibility Tutorials. http://www.w3.org/WAI/tutorials/menus/structure

  • [WAI - Web Application Menus] “Web Application Menus”, Menus, WAI Web Accessibility Tutorials. https://www.w3.org/WAI/tutorials/menus/application/

  • [Steve Krug, 2005] - “No me hagas pensar”, Capítulo 7, El problema con los menús desplegables. http://www.sensible.com/dmmt.html

  • [WAI-ARIA Practices - Menu] “WAI-ARIA Authoring Practices 1.1”, W3C Working Draft 17 March 2016, https://www.w3.org/TR/wai-aria-practices/#menu

  • [WAI-ARIA Practices - Keyboard Navigation between Widgets (tabindex)] “WAI-ARIA Authoring Practices 1.1”, W3C Working Draft 17 March 2016, https://www.w3.org/TR/wai-aria-practices/#kbd_general_between

  • [WAI-ARIA Roles] https://www.w3.org/TR/wai-aria/roles

  • [html5accessibility] http://www.html5accessibility.com/

  • [WAI - Using Aria Label] https://www.w3.org/WAI/tutorials/menus/structure/#using-aria-label

Más ejemplos:

  • http://www.oaa-accessibility.org/examplep/menubar1/

  • http://www.oaa-accessibility.org/examplep/menubar2/

  • http://olgacarreras.blogspot.com.es/2013/11/live-regions-y-wai-aria-como-mejorar-la.html

  • http://heydonworks.com/practical_aria_examples/

  • https://adobe-accessibility.github.io/Accessible-Mega-Menu/

  • http://www.html5accessibility.com/


Sobre el autor