sábado, 1 de marzo de 2014

Landmark Roles (WAI-ARIA). Navegación más accesible y semántica en 2 minutos.

En este artículo os explicaré cómo en 2 minutos podéis mejorar la accesibilidad de vuestra página, de manera que sea más fácil de "ojear", comprender y navegar para las personas que usan un lector de pantalla.

Cuando una página web está correctamente marcada permitimos que los usuarios que usan un lector de pantalla no tengan que hacer una lectura lineal de toda la página. Utilizando determinadas teclas podrán "ojear" el documento y acceder directamente a las partes del mismo que les interesan.

Por ejemplo, si tenemos una correcta estructura de encabezados, marcados como tales, un usuario de lector de pantalla (como JAWS o NVDA) podrá pulsar la tecla “h” para “ojear” los encabezados. Cada vez que pulse dicha tecla el lector le leerá el siguiente encabezado y podrá seguir leyendo a partir del que le interese.

De esta manera, los usuarios de lector de pantalla, pulsando diferentes teclas, pueden ojear los encabezados de distintos niveles, las listas, las tablas, las imágenes, etc. de la página o sacar un listado de dichos elementos.

Actualmente los lectores de pantalla también pueden anunciar, acceder y saltar por los bloques de la página relevantes: la cabecera, la zona de navegación, el contenido principal, el buscador o el pie de la página.

Sin embargo, para que esto sea posible, debemos marcar dichas zonas en el código HTML como puntos de referencia (landmark), de manera que pulsando la tecla “d” en NVDA o la tecla “r” en JAWS, el lector de pantalla pueda identificarlas, navegar por ellas y anunciar de qué tipo son.

¿Cómo se hace esto? Con WAI-ARIA y los Landmark Roles.

Es algo muy sencillo de hacer, que no solo mejorará la accesibilidad de tu sitio, sino que en un futuro los navegadores podrán implementar teclas de acceso rápido para acceder a estas partes de la página, puesto que se definen igual en todos los sitios y de forma independiente del dispositivo. Existe por ejemplo actualmente una extensión para Firefox: Firefox Landmark Extension.

Son también más consistentes que los enlaces de "saltar contenido" que se incluyen en las páginas, pues como digo, se definen igual en todas las páginas y dan más información semántica que estos. Este es también un punto importante, estamos añadiendo información semántica sobre la estructura de nuestra página. Sin embargo, aunque hay un soporte generalizado de los landmark roles, se pueden mantener los enlace "saltar al contenido" por compatibilidad con versiones antiguas (ir a Soporte de Landmark Roles)

¿Cómo se hace? Landmark roles

La especificación WAI-ARIA define un tipo especial de aria roles, los landmark roles, que se usan para identificar áreas separadas de tu página y transmitir la naturaleza de la mismas. De esta manera añadimos características útiles de navegación global, consistentes en cualquier documento (X)HTML, que transmiten información de la estructura de la página e información semántica sobre estas zonas.

Es tan fácil como añadir al elemento contenedor (el “div” por ejemplo) el código role=”[tipo_landmark]”. Por ejemplo, div role=”main” para marcar el "div" que contiene la zona de contenido principal. Incluirlos en las plantillas de vuestras páginas no os llevará ni 2 minutos.

Se pueden añadir en HTML 4, (X)HTML y HTML 5.

En HTML4 y (X)HTML tendrás que usar un DTD específico para que el validador de sintaxis del W3C no te dé errores de validación al usar WAI-ARIA:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+ARIA 1.0//EN" "http://www.w3.org/WAI/ARIA/schemata/xhtml-aria-1.dtd">

Los landmark roles son:

  • Banner
  • Complementary
  • Contentinfo
  • Form
  • Main
  • Navigation
  • Search
  • Application (eliminado de los Landmark Roles en ARIA 1.1, que pasa a ser un rol de estructura)
  • Region (añadido en los Landmark Roles en ARIA 1.1)

role="banner"

Debería haber solo uno por página.

Es la zona, normalmente en la parte superior, que contiene el logo o título principal de la página, que tiene no propiamente contenido específico de la página sino contenido orientado al sitio, lo que podría ser la cabecera de la página.

Referencia del role "banner" en WAI-ARIA.

Es lo que en HTML5 podríamos tener marcado como <header>, pero solo podremos tener uno marcado así.

En la especificación de HTML 5 se indica que los roles que admite <header> son efectivamente “banner” (o “presentation”1 ).

role="complementary"

Es una sección diseñada para ser complementaria del contenido principal y relevante para el mismo, pero que sigue siendo significativa cuando se separa de la misma. Por ejemplo sería una zona de artículos relacionados, de información del tiempo, etc.

Referencia del role "complementary" en WAI-ARIA.

Es lo que en HTML 5 marcaríamos como <aside>. En la especificación de HTML 5 se indica que puede tener los roles de "complementary", pero también de "search"; o de "note" o "presentation" (que no son landmark roles), según la función que esté realizando.

role="contentinfo"

Debería haber solo uno por página.

Es una zona que contiene información sobre el documento, como por ejemplo la información de copyright y enlaces de privacidad, en definitiva suele ser el pie de la página.

Referencia del role "contentinfo" en WAI-ARIA.

Es lo que en HTML5 podríamos marcar como <footer> . En la especificación HTML5 se indica que admite efectivamente los roles “contentinfo” (y “presentation”)

Pero en HTML5 solo deberíamos tener marcado un <footer> con el role=”contentinfo”.

role="form"

Es una zona que contiene una colección de elementos y objetos que se combinan para crear un formulario (si es de búsqueda se usaría “search”)

Referencia del role "form" en WAI-ARIA.

En HTML5 añadiríamos este rol a un elemento “form” o a un elemento semánticamente neutro como un “div”.

role="main"

Debería haber solo uno por página.

Es el contenido principal de un documento, un buen apoyo al enlace “saltar contenido”.

Referencia del role "main" en WAI-ARIA.

En HTML5 sería el elemento <main>, que como se indica en la especificación admite los roles “main” y “presentation”.

role="navigation"

Es una colección de enlaces para navegar por la página, es decir, sería un menú de navegación. Puedes tener varios, por ejemplo el principal y el secundario en una columna izquierda.

En la especificación se indica que si hay un menú en el pie no es necesario marcarlo, basta con marcar el role=”contentinfo” en el pie.

Referencia del role "navigation" en WAI-ARIA.

En HTML 5 sería lo que marcaríamos como <nav>, como se indica en la especificación admite los role “navigation” (y “presentation”)

role="search"

Es una colección de elementos y objetos que en su conjunto se combinan para crear una herramienta de búsqueda, lo que sería la zona del buscador del sitio.

Referencia del role "search" en WAI-ARIA.

No hay un elemento equivalente en HTML5, el rol se incluiría en el “form” de la búsqueda o el “div” contenedor.

role="application"

El 14/12/2017 se publicó la recomendación WAI-ARIA 1.1. En ella, role="application" ya no se incluye en los Landmark Roles sino en los Document Structure Roles.

Puedes consultar todas las novedades de WAI-ARIA 1.1 en el artículo: Novedades WAI-ARIA 1.1

Declara una zona como aplicación web en contraposición a documento web.

Los lectores de pantalla tienen un modo formulario (o aplicación) diferente del modo de lectura normal. Cuando navegan a un elemento con el role “application” las tecnologías de apoyo, que normalmente interceptan eventos de teclado estándar, deben cambiar a modo de navegación de aplicaciones, para permitir a la página funcionar como una aplicación. Por ejemplo las flechas arriba y abajo habituales para navegar por el documento puede ser un comportamiento nativo que impida usarlas en una aplicación web.

Hay que tener mucho cuidado con <body role="application"> porque el usuario no podrá fácilmente abandonar el modo aplicación.

El mejor consejo es que se use con moderación y muy seguro de lo que se está haciendo, probando siempre su comportamiento con un lector de pantalla.

Referencia del role "application" en WAI-ARIA. Otro enlace de interés es Using aria=application del W3C.

Podéis ver un ejemplo correcto de aplicación del role="application" en la presentación de Ramón Corominas: "Using WAI-ARIA to create accessible web apps"

No hay un equivalente en HTML5, se usaría un elemento semánticamente neutro como un “div”.

En WAI-ARIA hay otro tipo de roles aparte de los landmark roles, por ejemplo roles de estructura que sirven para organizar el contenido de la página: "article", "document", "región", "toolbar", etc.

Sin embargo, a pesar de no ser landmark roles, JAWS (no así NVDA) también anuncia y lista los role="region" y los role="article" como landmarks:

Listado de landmark roles de JAWS. Dentro de la zona 'main' se lista una 'region': Region prueba region

Listado de JAWS de landmarks de una de mis página donde incluí un role="region" aria-label="Region prueba" para mostrar que los listaba

El 14/12/2017 se publicó la recomendación WAI-ARIA 1.1. En ella, role="region" ya no se incluye en los Document Structure Roles sino en los Landmark Roles.

Puedes consultar todas las novedades de WAI-ARIA 1.1 en el artículo: Novedades WAI-ARIA 1.1

Veamos unos ejemplos

Hay muchos sitios que incluyen en el código landmark roles: store.apple.com, Google, BBC, Yahoo, Samsung o mi propia web Usable y accesible.

Por ejemplo, estos son los landmark roles en una página interior de samsung.com:

El logo es marcado con banner, el menú de navegación principal con navigation, la búsqueda con search, la zona de contenido con main y la zona del pie con contentinfo. El menú secundario de navegación no está englobado en ninguna de las áreas.

Imagen de Samsung> Landmarks

La página de Samsung hace una cosa mal: deja zonas de contenido huérfanas. Si el usuario usa los landmarks para "ojear" la página no accederá al menú secundario de navegación (que como vemos está fuera de las áreas definidas). Debería haberse marcado también con un role="navigation", pues como hemos dicho puede haber más de uno en la página.

Para saber si una página usa landmark roles podemos usar el lector de pantalla para comprobarlo, o podemos mirar el código, o podemos usar una extensión habitual para revisar la accesibilidad de la página, como es "Web Developer" en Chrome o Firefox. En "Information>ARIA Roles" nos los marcará en pantalla:

Página de accesible, encima de cada zona de la página se indica el landmark role con la que está marcada.

Página de "Usable y accesible" con los landmark roles marcados mediante la herramienta "Web Developer" de Firefox.

¿Cómo acceden los usuarios de lector de pantalla a los Landmark Roles?

Pueden pulsar una tecla ("d" en NVDA, "r" en JAWS15) como he explicado al principio, "ojeándolos" como si fueran cualquier otro tipo de elemento.

También pueden sacar una lista de todos los landmark roles de la página. En NVDA con "Insert+F7", o en JAWS con "Insert+Control+r":

Lista con 5 elementos: banner, navegación, buscar, principal, información de contenido

Lista de landmark roles (puntos de referencia en español) de NVDA

En un iPad, por ejemplo, los tendrán también disponibles en el "rotor" (si indican en la configuración del "rotor" que los muestre, pues por defecto no están). El "rotor", cuando tienes activo VoiceOver, permite seleccionar un tipo de elemento y navegar por los elementos de dicho tipo:

Pantalla de Usable y accesible con el rotor superpuesto en el modo 'puntos de referencia'

Captura de "Usable y accesible" en un iPad con el "rotor" en "puntos de referencia" (landmarks)

Podéis ver el vídeo "How ARIA landmark roles help screen reader users" para comprobar cómo anuncia el lector de pantalla los landmark roles.

Complementarlos con "aria-label" o "aria-labelledby"

Se recomienda etiquetar el elemento al que añades el rol, especialmente cuando hay dos del mismo tipo, para diferenciarlos.

Puedes hacerlo con los atributos "aria-label" y "aria-labelledby". La diferencia es que en el primero pones directamente la etiqueta dentro del atributo: aria-label="Menú principal", y en el segundo solo indicas el ID del elemento que hace de título o etiqueta a esa zona.

Podéis consultar los ejemplos en "Using ARIA landmarks to identify regions of a page", del W3C.

JAWS anuncia las diferentes áreas con la etiqueta indicada en estos atributos, y también la incluye en el listado de landmarks (como se veía en la imagen de ejemplo del role="region")

Sin embargo NVDA2013 las ignora, por ejemplo para un role="complementary", lee "Complementario. Panel de referencia. [el primer elemento, por ejemplo Histórico de artículos. Nivel 2]", independientemente de si le he puesto o no un "aria-label" o una "aria-labelledby". Por ello es importante que el primer contenido de la zona sea significativo.

Buenas prácticas

Las buenas prácticas son por tanto:

  • Usar el rol según la especificación, es decir, respetar si solo puede haber uno de un determinado tipo, o que el contenido de la zona se corresponda realmente con el rol asignado.
  • Que todo el contenido esté englobado dentro de elementos identificados con un rol, que no haya contenido que se quede huérfano. De esta manera el usuario de lector de pantalla puede navegar de forma segura de “landmark” y “landmark” sin perderse nada de la página.
  • Añadir "aria-label" o "aria-labelledby" para diferenciar varias zonas con el mismo rol asignado.
  • El primer contenido de un zona marcada con un landmark role debe ser lógico, por ejemplo, el primer contenido que esperas en un landmark "main" es un encabezado. Ten en cuenta que es lo primero que le anuncia el lector de pantalla de esa área.
  • Revisa en la versión móvil, si se tiene menos contenido, si siguen teniendo sentido.

Soporte

Yo os he comentado el soporte en JAWS15, NVDA 2013 y VoiceOver.

El soporte más detallado según el W3C es:

  • Jaws V.11 and greater has complete support.
  • ChromeVox V.1 and greater has complete support
  • VoiceOver V.3 and greater supports all landmarks except “form”.
  • NVDA 2 supports all landmarks except it will not support navigation to “application”
  • Window Eyes as of V.7 does not support ARIA landmarks.

Paciello Group indica que el soporte es:

  • En Using WAI-ARIA Landmarks – 2013: landmark roles are supported in JAWS (version 10 and above), NVDA, ORCA, Chromevox, Window Eyes and VoiceOver and via a FireFox addon for keyboard users.
  • En Latest ARIA landmark support data, noviembre 2011: Jaws 11/12/13 has complete support; ChromeVox has complete support; VoiceOver supports all landmarks except “form”; NVDA supports all landmarks except “application” and “form”; Window Eyes does not support ARIA landmarks.
  • En HTML5 Accessibility Chops: ARIA landmark support, julio 2011: NVDA and JAWS when using Internet Explorer 9 or Firefox 3+; VoiceOver when using Safari on iOS 4+; Orca (Linux screen reader) using Firefox 3+ supports landmarks (not tested).

En ARIA Landmark role support tests - 21/11/2011 de html5accessibility.com se puede consultar una tabla muy detallada por cada tipo de rol testeado con JAWS 9-13; NVDA 2011.2; Voice Over (en OSx Lion, iPAd2, iPhone4); ChromeVox y Windows Eyes 7.5.

En resumen, indica que salvo el role="application" y el role="form", el resto de roles son soportados por todas la versiones testeadas de los lectores de pantalla salvo por Windows Eyes.

Landmark Roles y HTML5

Ya he comentado que se pueden incluir landmark roles en HTML5 y que tienen semejanzas con algunos de sus nuevos elementos semánticos, aunque no es siempre una correspondencia exacta.

La relación queda bien expresada en esta imagen de carmenwiki.osu.edu.

Header se corresponde con role=banner; Nav se corresponde con role=navigation; main se corresponde con role=main; footer se corresponde con role=contentinfo; aside se corresponde con role=complementary

La pregunta es, ¿el lector de pantalla nos anunciará los elementos semánticos de HTML5 y los landmark roles, y por tanto la información será redundante y anunciada por duplicado?

Lucica Ibanescu hizo la prueba en 2011 y nos lo cuenta en "Cómo leen los lectores de pantalla una página con HTML5 y ARIA". En resumen, comprobó que ni NVDA, ni JAWS ni Windows Eyes anunciaban los elementos semánticos de HTML5, lo trataban como si fueran simplemente "divs". Sin embargo sí que los anunciaron incluyendo los landmark roles (salvo Windows Eyes que ya hemos dicho que no los soporta).

En marzo de 2011 Jason Kiss publicó también sus resultados "HTML5, ARIA Roles, and Screen Readers in March 2011". En resumen, solo NVDA con FF4 anunciaba algún elemento semántico de HTML5.

Se puede ver una tabla más actualizada del soporte de los elementos en html5accesibility.com en la que se ve que el soporte dista mucho del que tienen los landmark roles.

Por tanto, hasta que los elementos semánticos de HTML5 tengan un soporte generalizado en los lectores de pantalla es recomendable incluir los landmark roles.

Podéis ver varios vídeos de cómo en HTML5 distintos lectores de pantalla anuncian los landmark roles, como se observa, no se anuncia la información por duplicado:

Nota de soporte julio 2015

Actualmente el soporte ha mejorado. NVDA 2015.2 con Chrome 44, Firefox 39 y Opera 30 anunciará las etiquetas semánticas de HTML5 (header, nav, etc.) sin necesidad de incluir el rol ARIA equivalente, y lo hará tanto en la lectura lineal, como en la navegación mediante la tecla "d" como mostrándolas en el listado con "insert+f7".

Sin embargo, NVDA 2015.2 con Explorer 11 va ignorar las etiquetas semánticas HTML5, en este caso, incluir los roles ARIA permitirá a las personas que utilizan está combinación de navegador y lector de pantalla poder ojear, moverse y saltar por las diferentes zonas de la página. Como esta redundancia (etiqueta HTML5 + role ARIA) "no molesta", es decir, Chrome por ejemplo no las va a anunciar dos veces, sigue siendo todavía recomendable incluirlas.

Se puede ir siguiendo la evolución del soporte en: html5accesibility.com

Criterio de conformidad de las WCAG 2.0 asociados

La inclusión de landmark roles en las páginas está relacionado con los siguientes criterios de conformidad de las WCAG 2.0

  • 1.3.1 Información y relaciones: La información, estructura y relaciones comunicadas a través de la presentación pueden ser determinadas por software o están disponibles como texto. (Nivel A)
  • 2.4.1 Evitar bloques: Existe un mecanismo para evitar los bloques de contenido que se repiten en múltiples páginas web. (Nivel A)
  • 4.1.2 Nombre, función, valor: Para todos los componentes de la interfaz de usuario (incluyendo pero no limitado a: elementos de formulario, enlaces y componentes generados por scripts), el nombre y la función pueden ser determinados por software; los estados, propiedades y valores que pueden ser asignados por el usuario pueden ser especificados por software; y los cambios en estos elementos se encuentran disponibles para su consulta por las aplicaciones de usuario, incluyendo las ayudas técnicas. (Nivel A)

¿Qué opinan de los Landmark Roles los usuarios de lectores de pantalla?

En la última encuesta de 2014 de Webaim "Screen Reader User Survey #5 Results" solo un 13% de los encuestados decía no usarlos nunca. Comparado con encuestas previas el conocimiento y uso de los landmarks incrementa significativamente año tras año: el 48% de los usuarios de JAWS los usan siempre o a menudo; así como el 41.4% de los usuarios de NVDA y el 34.9% de los usuarios de VoiceOver.

Mi duda es si el porcentaje que contesta "algunas veces" (28%) o "raramente" (15.1%) en realidad quieren decir "algunas veces o raramente porque solo algunas veces o raramente los sitios que navego tienen landmark roles".

A la pregunta de cuántos landmark por página piensan que son los óptimos, el 40.2% no responde, de los que sí responden, el 28.7% dice que 4-6.

Enlaces de interés:


Nota 1: role=presentation, no es un landmark role. Es un rol que oculta los roles nativos de los elementos y sus descendientes a los productos de apoyo, y por tanto se usa solo para marcar elementos puramente decorativos.

Otros artículos de WAI-ARIA

En artículos anteriores he explicado cómo mejorar de forma muy sencilla la accesibilidad de las páginas aplicando WAI-ARIA:

Servicios de accesibilidad que ofrezco como consultora freelance

* Como todos los artículos de este blog, este es un artículo NO promocionado.

Autor: Olga Carreras Montoto

Etiquetas: , ,

Compártelo en:

Histórico de artículos:

< < Página de inicio

Subir al comienzo de la página



6 comentarios :
Olga Carreras dijo...

Con JAWS13+IE9 hay un bug si pones role="main" directamente en un div que contiene un formulario, ver alternativa en: http://www.html5accessibility.com/tests/div-landmark.html

Fecha: 2 de marzo de 2014, 15:33


Eliminar comentario de ' Olga Carreras ' con fecha de 2 de marzo de 2014, 15:33
Anónimo dijo...

Muy buen artículo!

Fecha: 2 de noviembre de 2014, 7:03


Eliminar comentario de ' Anónimo ' con fecha de 2 de noviembre de 2014, 7:03
Anónimo dijo...

Un gran aporte para todos con su extraordinario articulo

Soy Alberto Hidalgo y quisiera solicitarle si por favor pudiera contestarme lo sigiente
1.- como deberia ser una pag. Web Accesible que incluya a personas con discapacidad auditiva que solo entienden lengua de senas?
2.- Que metodologias o estrategias deberia utilizarse en un curso virtual para personas con discapacidad auditiva que solo utilizan lengua de senas y que al no utilizar chat no pueden presentrase ni hacer un aprendizaje colaborativo con esta herramienta

mil gracias por su atencion

Fecha: 21 de diciembre de 2014, 0:17


Eliminar comentario de ' Anónimo ' con fecha de 21 de diciembre de 2014, 0:17
Delita dijo...

Gracias Olga por tu artículo es genial! Tengo una pregunta un carousel qué role se le asignaría ? Gracias de nuevo.

Fecha: 14 de julio de 2016, 10:16


Eliminar comentario de ' Delita ' con fecha de 14 de julio de 2016, 10:16
Olga Carreras dijo...

Hola, puedes consultar el artículo sobre WAI-ARIA http://olgacarreras.blogspot.com.es/2007/02/ajax-accesible-ii-wai-aria.html

Fecha: 18 de julio de 2016, 16:58


Eliminar comentario de ' Olga Carreras ' con fecha de 18 de julio de 2016, 16:58
Guz747 dijo...

Que tranquilidad saber que sigues por aquí. Hacía mucho que no me pasaba para aprender ¡Mil gracias por tus buenos artículos!

Fecha: 20 de julio de 2016, 20:30


Eliminar comentario de ' Guz747 ' con fecha de 20 de julio de 2016, 20:30

Publicar un comentario