Etiquetas, atributos y estilos HTML / CSS que no debes usar o debes usar bien

En cada fila de la siguiente tabla encontrarás una etiqueta, atributo o estilo y las observaciones al respecto. Están listados alfabéticamente y agrupados por tipo.

Etiquetas, atributos y estilos que no debes usar o debes usar bien

Etiquetas HTML	Observaciones
<b>	El estándar HTML5 mantiene la etiqueta <b> para marcar texto resaltado pero que no transmite mayor importancia, pero en la práctica se sigue usando de manera incorrecta para resaltar contenido relevante en negrita. Se debe separar el diseño de la presentación y evitar las etiquetas no semánticas. Si quieres destacar una palabra, o conjunto de palabras, importante usa <strong>. No destaques demasiada cantidad de texto o, de lo contrario, no solo no se destacará sino que producirá fatiga y ralentizará la velocidad de lectura.
<basefont>	Obsoleta. Usa estilos para definir las fuentes.
<blink>	Obsoleta. No se debe provocar parpadeos en pantalla.
<br>	Usa estilos para definir la separación entre líneas y párrafos. Puede usarse en <address>
<center>	Obsoleta. Usa estilos para centrar.
<font>	Obsoleta. Usa estilos para definir las fuentes.
<i>	Puedes usarlo con su verdadero valor semántico, es decir, para marcar una designación taxonómica, un término técnico o un término en otro idioma (sin olvidar acompañarlo de lang). En castellano puede sustituirse por el uso de comillas. No debe usarse para simular un encabezado. Tampoco debe usarse para enfatizar el texto, para ello se usa en su lugar <em>. No uses <i> con background-image para incluir iconos. Si se quiere formatear el texto en itálica por diseño, se deben usar estilos, pero recuerda que el texto en itálica se lee peor y debería evitarse.
<marquee>	Obsoleta. No provoques movimiento si no puede pararse.
<s>	Su función semántica en el estándar HTML5 es marcar texto que ya no es preciso o relevante. Si lo que quieres es indicar texto corregido, debes usar <del> y <ins>
<strike>	Obsoleto. En HTML 4 definía texto tachado.
<u>	Puede usarse con su verdadero valor semántico en HTML5, es decir, para marcar un texto con una anotación no textual, por ejemplo, con un estilo diferente para reflejar una falta ortográfica: <p>Un error ortográfico común es <u>llendo</u> Un error ortográfico común es llendo Pero no debe usarse para subrayar un texto simplemente para resaltarlo o para simular un encabezado. Solo deberías subrayar de manera estándar los enlaces, pues cualquier texto subrayado se tiende a identificar como enlace.
Atributos HTML	Observaciones
align	No uses <p align="center"> sino el estilo CSS text-align
bgcolor	No uses <p bgcolor="#000"> sino el estilo CSS background-color
border	No uses <table border="1"> sino el estilo CSS border
cellspacing	No uses <table cellspacing="1"> sino el estilo CSS border-spacing / border-collapse
cellpadding	No uses <table cellpadding="1"> sino el estilo CSS padding
frameborder	No uses <frame frameborder="1"> sino el estilo CSS border
height	Es mejor que definas el alto en los estilos.
summary	Obsoleto en HTML5. Consultar artículo Descripción de las tablas en HTML5. Alternativa a "summary"
width	Es mejor que definas el ancho en los estilos.
Estilos CSS	Observaciones
::after/::before content:	No debes usarlos para incluir contenido informativo en la página, por ejemplo, el asterisco de los campos obligatorios, pues sin CSS o con CSS personales no estará disponible esa información.
outline:0/none	No debes ocultar el foco visual de los elementos de interacción.

Artículos relacionados:

• Cheat Sheet HTML 4.01, HTML 5, XHTML Elements
• HTML5 y accesibilidad: nuevos tipos de input, atributos asociados y validación nativa
• Descripción de las tablas en HTML5. Alternativa a "summary"
• Landmark Roles (WAI-ARIA). Navegación más accesible y semántica en 2 minutos.
• LONGDESC. Soporte y alternativas (WCAG 2.0, ARIA, HTML5)

Ocultar contenido visualmente y/o para el lector de pantalla (tabla resumen)

En HTML/CSS existen muchas técnicas para ocultar contenido, pero no todas tienen las mismas consecuencias. Este artículo muestra un cuadro resumen que sirve de consulta rápida sobre las consecuencias de usar una u otra técnica para ocultar el contenido.

Las posibles consecuencias de las técnicas para ocultar el contenido son tres:

• Oculto visualmente- Disponible para el lector de pantalla: unas técnicas ocultan el contenido visualmente, pero este contenido sigue estando disponible para los productos de apoyo. Por ejemplo, es útil para incluir alguna información destinada a clarificar el acceso para los usuarios de lector de pantalla o línea braille (productos de apoyo utilizados fundamentalmente por las personas invidentes). Podría servir para ocultar un texto explicativo en los enlaces: Leer más <span class="ocultovisual">sobre el artículo "Accesibilidad y HTML5"</span>).
• Oculto visualmente - Oculto para el lector de pantalla: otras técnicas ocultan el contenido visualmente pero también para el lector, por ejemplo, es útil para ocultar un menú plegado.
• Visible - Oculto para el lector de pantalla: en otros casos, la técnica permite que el contenido se vea pero el lector de pantalla lo ignore y no lo anuncie, por ejemplo, es útil para evitar contenido redundante y repetitivo al usuario de lector de pantalla.

Tabla resumen de las consecuencias de ocultar el contenido con diferentes técnicas

En cada fila de la siguiente tabla se incluye una técnica para ocultar el contenido, indicando si oculta visualmente el contenido y si el lector de pantalla lo anuncia. La respuesta puede ser: Sí (visto verde); No (cruz roja); o una Advertencia (exclamación naranja) que se explicará en una nota.

Consecuencias de ocultar contenido con diferentes técnicas

Técnica para ocultar contenido	Tipo de técnica	¿Se ve el contenido?	¿El lector anuncia el contenido?
display:none (1)	CSS
visibility:hidden (1)	CSS
height:0 (2)	CSS
aria-hidden=true (3)	atributo ARIA
hidden (3)	atributo HTML5
role=presentation / role=none (4)	rol ARIA		Si es una imagen: Cualquier otro contenido lo lee como texto plano (5):
text-indent:-999em	CSS
clip: rect (...)	CSS
opacity:0	CSS
transform: scale (0)	CSS

Si necesitáis saber las consecuencias de ocultar el contenido con otra técnica, dejadme un comentario y lo añadiré a la tabla.

Notas de interés sobre el cuadro resumen

(1) display:none oculta el elemento y sus descendientes no solo visualmente, sino también para los lectores de pantalla. Aunque es el comportamiento habitual, no es cierto para todos los lectores de pantalla, en todos los casos y con todos los navegadores. Por su parte, el contenido con el estilo visibility:hidden no se anuncia en muchos contextos, pero la aplicación de esta técnica en determinadas etiquetas y con cierta combinación de navegadores y lectores de pantalla, provoca que el lector sí anuncie el contenido. Como el lector de pantalla no interpreta igual ambas técnicas, se pueden usar combinadas para mayor soporte. 

Artículos de interés: 

• “JAWS, Window-Eyes and display:none: Return to 2007” de Jason Kiss, 2011
• “Do not use display:none to visually hide content intended for screen readers”, de Roger Johansson, 2011.
• Empty Links and Screen Readers

(2) Esta técnica se aplicaría por ejemplo así: .element-invisible { height: 0; overflow: hidden; position: absolute;}. Los lectores de pantalla NVDA y Jaws leerán el contenido, pero Voice Over (en dispositivos Apple) no lo lee. Por tanto, es mejor usar otras técnicas con un soporte más homogéneo, por ejemplo, text-indent:-999em si lo que se quiere es ocultar contenido visualmente pero no para el lector de pantalla. 

Artículo de interés:

• "Using CSS clip as an Accessible Method of Hiding Content" de Jeff Burnz.

(3) Artículo de interés: Screen reader support for hidden content

(4) WAI-ARIA 1.1 añade un nuevo role=none que es sinónimo de role=presentation y al que espera sustituir cuando esté ampliamente soportado. Mientras esto no ocurra es preferible seguir usando role=presentation. Artículo relacionado: Novedades WAI-ARIA 1.1).

(5) La consecuencia de aplicar role=presentation es diferente según el elemento al que se aplica. En una imagen (<img role=presentation ...>) el lector ignorará la imagen y no la anunciará. En cualquier otro elemento, lo leerá solo como texto, ignorando la información semántica. Por ejemplo, <h1 role="presentation">Ventas</h1> será anunciado como "Ventas", en vez de como "Ventas encabezado de nivel 1". Este rol es muy útil para aplicarlo a las tablas de presentación.

Artículos relacionados

• Ocultar contenido sin comprometer la accesibilidad ni el posicionamiento de la página
• Recursos: Descargas gratuitas
• Test, estadísticas, encuestas y estudios sobre lectores de pantalla

Créditos: los iconos utilizados son de Freepik

HTML5 y accesibilidad: nuevos tipos de input, atributos asociados y validación nativa

Una de las novedades de HTML5 son los nuevos tipos de input en los formularios y los nuevos atributos de los mismos.

En (X)HTML tenemos input de tipo text, password, checkbox, radio, submit, image, reset, button, hidden, file. Consultar Elemento input en la especificación HTML 4.01 del W3C.

En HTML5 tenemos además input de tipo search, tel, url, email, datetime, date, month, week, time, datetime-local, number, range, color.

Además hay nuevos atributos bastante útiles como: pattern (el valor del campo debe cumplir un patrón que se define mediante expresiones regulares), placeholder (para incluir un texto por defecto en el campo), required (campo obligatorio), autofocus (el campo tiene por defecto el foco), etc.

Consultar Elemento input en la especificación HTML5 del W3C.

Dos ventajas importantes que supone utilizar estos nuevos tipos y atributos de campos de formulario son:

• En los dispositivos móviles el teclado que se muestre para rellenar cada campo se adaptará al tipo de input, como comentaba en iPad, recomendaciones de usabilidad para tu web

  En el artículo "Nuevos tipos de input en HTML5" de htmlcinco.com podéis repasar, de forma rápida e introductoria, ejemplos de visualización de los diferentes input y sus teclados asociados (luego veremos un recurso mucho más completo):

  

  Imagen de "Nuevos tipos de input en HTML5" de htmlcinco.com

• La validación de los campos se realiza sin necesidad de javascript, ahora la validación la hace de forma nativa el navegador. Por ejemplo, si el campo tiene el atributo required se validará si se ha rellenado; si se ha incluido un atributo pattern se validará que el dato introducido cumpla ese patrón; si el campo es de tipo email se validará que se haya incluido una dirección de correo válida, etc.

  En el artículo "Validación de formularios nativos con HTML5" de html5facil.com podéis consultar, de nuevo de forma rápida e introductoria, algún ejemplo de cómo se muestran estas validaciones nativas y de cómo se puede personalizar su estilo mediante CSS3 (luego veremos un recurso mucho más completo):

  

  Imagen de "Validación de formularios nativos con HTML5" de html5facil.com

En este artículo voy a hablaros de la accesibilidad en relación con estos nuevos tipos de input de HTML5 y algunos de sus atributos asociados, y para ello tendremos que tener en cuenta:

• El soporte de los mismos por los diferentes navegadores y versiones, tanto de los campos y sus atributos como de sus validaciones nativas, pues en ciertos casos se reconocerá el campo pero no se realizará la validación. Ir al apartado Soporte en diferentes navegadores y versiones
• El soporte de los mismos por los productos de apoyo, ¿anuncian o cómo anuncian estos campos y atributos? ¿anuncian o cómo anuncian las validaciones nativas de los mismos? Ir al apartado Soporte en diferentes lectores de pantalla con diferentes navegadores

Y en base a ello extraeremos unas conclusiones para hacer los formularios de HTML5 accesibles para todos.

Soporte en diferentes navegadores y versiones

Lo primero que hay que decir, y que es bastante relevante, es que si el navegador no comprende uno de los nuevos input lo interpreta como un campo de type="text" y por tanto siempre podremos rellenarlo.

Para consultar el actual soporte de los nuevos tipos y atributos de campos de formulario de HTML5 podéis consultar dos webs:

• "The Current State of HTML5 Forms" (wufoo.com), de la que está tomada la siguiente imagen:

  

  Imagen de "The Current State of HTML5 Forms" (wufoo.com). En rojo si no se soporta. En verde si se soporta. En naranja un soporte parcial.

  En esta web, por cada tipo y atributo, encontraréis un ejemplo, el detalle del soporte en los diferentes navegadores y versiones (aunque se ha quedado ya algo desactualizada), cómo se visualiza la validación en cada navegador y el teclado asociado.

• Can I use... Compatibility tables for support of HTML5, CSS3, SVG and more in desktop and mobile browsers, más actualizada que la anterior y con recursos asociados, aunque más complicada de consultar. En la siguiente imagen se ve por ejemplo la tabla del soporte general de las nuevas características de los formularios en HTML5.



Imagen de Can I use... Compatibility tables for support of HTML5, CSS3, SVG and more in desktop and mobile browsers

Como se puede comprobar en estas webs, en las últimas versiones de los navegadores se comienza a soportar la mayoría de los nuevos tipos de campos, pero el soporte no es generalizado ni total, especialmente en los dispositivos móviles. En versiones anteriores el soporte puede ser nulo (por ejemplo en Explorer 9 o anterior) o reducido. Lo mismo pasa con los nuevos atributos. En algunos casos el soporte es parcial, por ejemplo se puede reconocer un nuevo tipo de campo pero no realizarse la validación nativa.

Soporte en diferentes lectores de pantalla con diferentes navegadores

Un recurso imprescindible es html5accessibility.com, que se actualiza periódicamente.

Imagen de html5accessibility.com

Os voy a poner varios ejemplos de soporte en NVDA 2014.1, JAWS15 y VoiceOver para Explorer 11, Firefox 27 y Chrome 33 en un formulario sencillo implementado en HTML5:

El código es:

    <label for="telefono">Ejemplo de campo teléfono, obligatorio, con patrón de datos, 
          ayuda contextual asociada:  </label>
    <input type="tel" id="telefono" name="telefono" required  aria-describedby="descripcionContra" 
          pattern='[\+]\d{2}[\(]\d{2}[\)]\d{4}[\-]\d{4}' >
    <p id="descripcionContra" class="ayuda">Formato: +99(99)9999-9999</p>

    <label for="url">Ejemplo de campo url obligatorio: </label>
    <input type="url" id="url" name="url" required size="50">
  
    <label for="email">Ejemplo de campo email obligatorio y texto por defecto: </label>    
    <input type="email" id="email" name="correo" required placeholder="midireccion@gmail.com" size="50">
    
    <input type="submit" name="Enviar" id="Enviar" value="Enviar">

NVDA 2014.1

Chrome 33

Los campos son leídos de la siguiente manera:

• Campo teléfono: [label] edición requerido formato +99(99)9999-9999 en blanco
• Campo URL: [label] edición requerido en blanco
• Campo email: [label] edición requerido midireccion@gmail.com en blanco

En cuanto a la validación, no lee el texto del mensaje de error, simplemente vuelve a leerme el campo (tal y como la he indicado antes) que ha cogido el foco por dar un error.

Por tanto:

• No me anuncia de que tipo es el campo (teléfono, url, email)
• Sí me anuncia que es un campo requerido.
• Sí me anuncia el contenido de ejemplo del campo incluido con placeholder, aunque no me da información concreta de que es un ejemplo.
• No me anuncia que el campo requiere un formato específico incluido con el atributo pattern, pero sí que me lee la ayuda contextual incluida al pie del campo y asociada mediante aria-describedby.
• No me anuncia el mensaje de error de la validación, solo vuelve al leer el campo porque ha cogido el foco.

Explorer 11

Los campos son leídos de la siguiente manera:

• Campo teléfono: [label] edición formato +99(99)9999-9999 en blanco
• Campo URL: [label] edición en blanco
• Campo email: [label] edición en blanco

En cuanto a la validación, no lee el texto del mensaje de error, simplemente vuelve a leerme el campo (tal y como la he indicado antes) que ha cogido el foco por dar error.

En resumen:

• No me anuncia de que tipo es el campo (teléfono, url, email)
• No me anuncia que es un campo requerido.
• No me anuncia el contenido de ejemplo del campo incluido con placeholder.
• No me anuncia que el campo requiere un formato específico incluido con el atributo pattern, pero sí que me lee la ayuda contextual incluida al pie del campo y asociada mediante aria-describedby.
• No me anuncia el mensaje de error de la validación, solo vuelve al leer el campo porque ha cogido el foco

Firefox 27

Los campos son leídos de la siguiente manera:

• Campo teléfono: [label] edición entrada inválida requerido tiene autocompletado formato +99(99)9999-9999 en blanco
• Campo URL: [label] edición entrada inválida requerido tiene autocompletado en blanco
• Campo email: [label] edición entrada inválida requerido tiene autocompletado blanco

En cuanto a la validación, lee el texto del mensaje de alerta "Alerta Rellene este campo", "Alerta Ajuste el formato al solicitado" pero no me indica qué campo ha cogido el foco y por tanto ha dado error.

Por tanto:

• No me anuncia de que tipo es el campo (teléfono, url, email)
• Sí me anuncia que es un campo requerido.
• No me anuncia el contenido de ejemplo del campo incluido con placeholder.
• No me anuncia que el campo requiere un formato específico incluido con el atributo pattern, pero sí que me lee la ayuda contextual incluida al pie del campo y asociada mediante aria-describedby.
• Me anuncia el mensaje de error de la validación pero no me indica qué campo ha dado el error y ha cogido por tanto el foco.

JAWS

El comportamiento es muy similar al visto con NVDA:

• Chrome 33 y Firefox anuncian el atributo required pero Explorer 11 no.
• Chrome 33 y Explorer 11 no anuncian el mensaje de error, solo leen en campo que coge el foco. Firefox 27 lee el mensaje de alerta pero no identifica el campo que ha dado error (aunque sí que le devuelve el foco)
• Chrome 33 lee el contenido del atributo placeholder.
• Ninguno indica de que tipo es el campo (email, url, teléfono)
• Ninguno me indica que teléfono tiene un formato asociado con pattern, pero sí leen la ayuda contextual asociada con aria-describedby.

Voice Over

En un iPad, tanto en Chrome como en Safari, lee los campos de la siguiente manera:

• Campo teléfono: [label] campo de texto para varias líneas obligatorio formato +99(99)9999-9999 pulse dos veces para editar
• Campo URL: [label] campo de texto para varias líneas obligatorio pulse dos veces para editar
• Campo email: [label] midireccion@gmail.com campo de texto para varias líneas obligatorio pulse dos veces para editar

En este caso ninguno de los navegadores hace la validación nativa, simplemente envían el formulario.

Por tanto:

• No me anuncia de que tipo es el campo (teléfono, url, email)
• Sí me anuncia que es un campo requerido.
• Sí me anuncia el contenido de ejemplo del campo incluido con placeholder aunque no me indica concretamente que es un texto de ejemplo.
• No me anuncia que el campo requiere un formato específico incluido con el atributo pattern, pero sí que me lee la ayuda contextual incluida al pie del campo y asociada mediante aria-describedby.
• No se produce validación nativa del navegador.

Conclusiones

• No podemos confiar solo en el atributo required de HTML5 para indicar que un campo es obligatorio. Deberemos apoyarnos también en aria-required. Si incluimos los dos required aria-required="true", Chrome y Firefox NO dan la información por duplicado y Explorer sí nos anunciará que el campo es obligatorio. No está de más recordar que la forma de que a ningún usuario le pase desapercibido que el campo es obligatorio es incluir en el texto de la etiqueta (obligatorio), aunque en este caso la información sí se daría por duplicado.
• Si incluimos un patrón de datos con pattern deberemos siempre incluir como ayuda contextual el patrón requerido y asociar esta ayuda con el campo mediante el atributo aria-describedby.
• En muchos casos no se anuncia el texto por defecto del campo incluido con placeholder, por lo que sigue siendo mejor práctica incluirlo como un texto de ejemplo bajo el campo, asociado igualmente al campo con aria-describedby
• Hemos visto que en ningún caso se anuncia de que tipo es el nuevo campo (url, email, teléfono) pero esto no tiene porque suponer un problema (incluso si el navegador no soporta el nuevo tipo de input, pues lo interpretará como un type="text") si la etiqueta es clara y por supuesto, siempre incluida en un label y asociada al ID del campo que etiqueta mediante el atributo for.

• No podemos confiar únicamente en las validaciones nativas del navegador, tanto por compatibilidad con los navegadores y versiones de navegadores que no las soportan, como porque no siempre los productos de apoyo anuncian los mensajes de error o los campos que los han producido.

  Recordemos que las WCAG 2.0 indican como requisito de nivel A (criterio de conformidad 3.3.1) que hay que identificar el campo que ha dado el error y describir el error con texto, y de ser posible proporcionar sugerencias para su corrección (criterio de conformidad 3.3.3).

  Por ello, debemos tener en cuenta:

  • Existen maneras de detectar si el navegador soporta la validación nativa con librerías como Modernizr, y en caso contrario usar la validación javascript.

  • Tenemos que asegurarnos de que todos los usuarios podrán saber qué campo dio error, el mensaje de error y sus posibles sugerencias de corrección.

    Las WCAG 2.0 admiten diferentes técnicas como el uso de alerts que informen del error y retornen el foco al campo que lo ha provocado; o desde mi punto de vista más recomendable insertar una zona de errores al comienzo del formulario implementada como se indica en la SCR32: Providing client-side validation and adding error text via the DOM, a la que se debe remitir el foco o asegurarse de que será anunciada a los usuarios de lector de pantalla mediante el uso de role="alert" (ver descripción y ejemplo en la técnica ARIA19: Using ARIA role=alert or Live Regions to Identify Errors)

    Podéis ver ejemplos de la aplicación de role="alert" y aria-invalid en la validación de formularios en: Easy ARIA tip #3: aria-invalid and role “alert”, marcozehe.de o en Using the aria-invalid attribute, MDN

  • Y por supuesto, siempre es una buena práctica, no solo por accesibilidad sino por seguridad, hacer también después la validación desde la parte servidor.

Artículos relacionados

• HTML 5 y accesibilidad
• Reseña de “Pro HTML5 Accessibility”
• Navegación más accesible y semántica en 2 minutos con Landmark Roles (WAI-ARIA)
• WAI-ARIA. Introducción, referencias, ejemplos, herramientas
• LONGDESC. Soporte y alternativas (WCAG 2.0, ARIA: "aria-describedby" y "aria-describedat", HTML5: <figure> y <picture>)

Servicios de accesibilidad que ofrezco como consultora freelance

• Consultoría y formación. WCAG 2.0 y WAI-ARIA
• PDF accesibles

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

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

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

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.

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:

• NVDA 2011.2 in Firefox 6 with HTML5 y ARIA Landmark Roles, AccessibleCulture
• JAWS 13 in Explorer 9 with HTML5 y ARIA Landmark Roles, AccessibleCulture
• VoiceOver in Safari 5.1 with HTML5 y ARIA Landmark Roles, AccessibleCulture
• Windows-Eyes 7.5.0 in Explorer 9 with HTML5 y ARIA Landmark Roles, AccessibleCulture

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:

• ARIA Landmarks Example, W3C
• WAI- ARIA: Landmark Roles, W3C
• Using WAI-ARIA in HTML, W3C
• Using ARIA landmarks to identify regions of a page, W3C
• Using WAI-ARIA Landmarks – 2013, Paciello Group, 2013
• HTML5 Accessibility Chops: ARIA landmark support, Paciello Group, julio 2011
• Latest ARIA landmark support data, Paciello Group, noviembre 2011
• Using ARIA to Enhance Web Application Accessibility, Webaim, 2012
• Usable landmarks across desktop and mobile, Henny Swan, 2012
• Cómo leen los lectores de pantalla una página con HTML5 y ARIA, Lucica Ibanescu, 2011
• How–to: Use role="application" , a11project, 2013

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:

• WAI-ARIA. Introducción, referencias, ejemplos, herramientas
• Live Regions y WAI-ARIA. Cómo mejorar la accesibilidad de contenidos que se actualizan automáticamente
• Ayuda contextual de los formularios más accesible con "aria-describedby" (WAI-ARIA)
• Nuevas técnicas ARIA en las WCAG 2.0. Novedades de la actualización del documento "Techniques for WCAG 2.0" del 11 de marzo de 2014
• LONGDESC. Soporte y alternativas (WCAG 2.0, ARIA: "aria-describedby" y "aria-describedat", HTML5: <figure> y <picture>)
• Novedades WAI-ARIA 1.1

Servicios de accesibilidad que ofrezco como consultora freelance

• Consultoría y formación. WCAG 2.x y WAI-ARIA
• PDF accesibles

Live Regions y WAI-ARIA. Cómo mejorar la accesibilidad de contenidos que se actualizan automáticamente

Última actualización: 01/08/2017, he añadido la novedad de WAI-ARIA 1.1, los Live Regions Roles (alert, log, marquee, status, timer)

En este artículo explico:

• el problema de accesibilidad que pueden suponer las zonas de nuestras páginas que se añaden, eliminan, actualizan o modifican automáticamente sin intervención del usuario (llamadas Live Regions)
• lo fácil que es solucionar este problema con el uso del atributo aria-live de WAI-ARIA en dicha región.
• el uso correcto del atributo aria-live y otros relacionados: aria-atomic, aria-relevant y aria-busy.
• incluyo un ejemplo detallado para que podáis ver las diferencias según los valores que indicamos en estos atributos
• la compatibilidad con diferentes lectores de pantalla y navegadores

Comprender el problema para entender la solución

Imaginemos que tenemos una zona o varias zonas de nuestra página web cuyo contenido se añade, elimina, actualiza o modifica sin intervención del usuario. Es lo que llamamos una live region, una zona viva de la página.

Os enumero algunos ejemplos, podemos tener una zona en la cual...

• ... se actualicen los resultados de determinados eventos deportivos, por ejemplo, cada vez que un equipo marca un gol,
• ... haya un banner publicitario que vaya mostrando cada x minutos un anuncio diferente,
• ... haya un contador, por ejemplo indicando los minutos que restan para que termine el tiempo de un examen,
• ... se muestren mensajes importantes al usuario, por ejemplo errores de validación de un formulario a medida que el usuario rellena los campos del mismo,
• ... se muestren los usuarios que están conectados en ese momento, por ejemplo los alumnos en línea en un curso online,
• ... se muestren los nuevos mensajes de un chat, de Twitter o las últimas noticias desde una fuente RSS.

Podríamos seguir poniendo ejemplos, lo que tienen en común todas ellas es que se actualizan automáticamente mediante un evento externo, no porque el usuario lo solicite explícitamente, y cuando se realiza dicha actualización el usuario puede tener el foco en cualquier otra parte de la página.

Si puedes ver la página seguramente no tendrás problemas para percatarte del cambio que se efectúe en una live region. El problema surge cuando accedes a la página mediante un lector de pantalla, pues no serás conscientes de la actualización a menos que el lector de pantalla te la anuncie.

Este es por tanto el problema que queremos solucionar: queremos que el lector de pantalla pueda anunciarle al usuario que se ha producido un cambio en una zona dinámica de la página (live region), qué cambio ha sido y decidir cómo y cuándo queremos que se lo anuncie.

No está de más recordar que es además un requisito de accesibilidad necesario para alcanzar el nivel de adecuación A de acuerdo a las WCAG 2.0. El criterio de conformidad 4.1.2 Nombre, función, valor (nivel A), indica:

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)

WAI-ARIA como solución

WAI-ARIA (WAI - Accessible Rich Internet Applications) es una especificación del W3C que proporciona una ontología de roles, estados y propiedades que se pueden utilizar para mejorar la accesibilidad y la interoperabilidad de los contenidos y aplicaciones web.

WAI-ARIA provides a collection of accessibility states and properties which are used to support platform accessibility APIs on various operating system platforms. Assistive technologies may access this information through an exposed user agent DOM or through a mapping to the platform accessibility API. When combined with roles, the user agent can supply the assistive technologies with user interface information to convey to the user at any time. Changes in states or properties will result in a notification to assistive technologies, which could alert the user that a change has occurred.

Accessible Rich Internet Applications (WAI-ARIA) 1.0

WAI-ARIA nos proporciona pues mecanismos para transmitir a los productos de apoyo la información sobre la función, los estados y las propiedades (y sus valores) de los componentes de interacción personalizados, así como las notificaciones sobre los cambios producidos en los mismos.

Los atributos de WAI-ARIA que nos permitirán identificar las live regions y definir cómo queremos que se anuncien las modificaciones que en ellas se llevan a cabo son:

• aria-live: para identificar la live region y, mediante su valor, indicar cuándo queremos que se anuncien sus actualizaciones al usuario.
• aria-atomic: para definir si queremos que se anuncie toda la región o solo las partes que han cambiado.
• aria-relevant: para establecer qué tipo de actualización en la región queremos que se anuncie al usuario.
• aria-busy: para detener o activar temporalmente el anuncio de la actualización cuando muchas partes de un mismo elemento van a ser modificadas, y de este modo esperar a que terminen de realizarse las modificaciones antes de anunciar el cambio.

Cómo usar correctamente aria-live, aria-atomic, aria-relevant y aria-busy

aria-live

Este atributo se añade a un elemento para indicar que es una live region, es decir, que su contenido se modifica y actualiza dinámicamente.

Mediante el valor del atributo podemos indicar cuándo queremos que el lector de pantalla anuncie los cambios al usuario:

• aria-live="off": los cambios se anunciarán al usuario solo cuando el foco esté en esa región. Será adecuado usarlo cuando la actualización no es relevante, por ejemplo una rotación de imágenes en la cabecera.
• aria-live="polite": los cambios se anunciarán al usuario pero sin interrumpirle, anunciará el cambio cuando termine la tarea que está llevando a cabo, por ejemplo cuando termine de escribir en un campo o termine de leer un contenido.
• aria-live="assertive": los cambios se anuncian de inmediato, independientemente de lo que el usuario esté haciendo. Teniendo en cuenta que el anuncio puede desorientar a los usuarios o que estos no terminen la tarea que están realizando, solo debe utilizarse para mensajes y advertencias importantes, por ejemplo los mensajes de error de validación en un formulario.

aria-atomic

Con aria-atomic especificamos si queremos que se anuncie toda la región o solo las partes de la misma que han cambiado.

Si el valor del atributo es "true" el lector de pantalla anunciará la región como un todo, por el contrario, si es "false" (el valor por defecto) solo anunciará el nodo que ha cambiado.

aria-relevant

Con este atributo indicamos qué tipo de actualización de la live region deseamos que se anuncie al usuario:

• aria-relevant="additions": anuncia los elementos que se añaden al DOM. Si el contenido que se añade es semánticamente relevante será importante anunciarlo, por el contrario, si es meramente decorativo no tiene sentido que se anuncie.
• aria-relevant="removals": anuncia los elementos que se eliminan del DOM. Igual que en el caso anterior, es importante tener en cuenta si el elemento eliminado es relevante o solo decorativo. Por ejemplo, en un listado de amigos en línea, si un amigo se desconecta sería interesante anunciar que se ha eliminado de la lista.
• aria-relevant="text": anuncia las modificaciones de texto.
• aria-relevant="all": anunciará todo, es decir, los elementos añadidos, eliminados y las modificaciones de texto.

Si no se incluye el atributo aria-relevant, por defecto se anunciarán los nodos añadidos y las modificaciones de texto.

aria-busy

Por defecto su valor es "false". Este atributo se utiliza cuando muchas partes de un mismo elemento van a ser modificadas, entonces puedes poner el valor a "true" para que temporalmente no anuncie las modificaciones y, una vez que se hayan llevado a cabo, volver a ponerlo a "false" para que las anuncie.

Ejemplo ARIA: Live Region

Ir a "Ejemplo ARIA: Live Region"

Nuestra live region es una zona de "Últimas noticias" que se actualiza de forma automática, sin intervención del usuario. Cada 10 segundo se elimina la última noticia de la lista y se incluye una nueva al comienzo de la misma.

La página está en HTML5, pero no es obligatorio, puedes utilizar WAI-ARIA en (X)HTML también. El código HTML de la live region es:

<div id="#contenedor" role="complementary">
   <div id="noticias">
   <h2 id="liveLabel">Últimas noticias</h2>
   <p class="peq">Se actualizan cada 10 segundos</p>
           <div id="liveDiv"  role="log" aria-labelledby="liveLabel" 
                 aria-live="assertive" 
                 aria-atomic="true" 
                 aria-relevant="additions">
              [5 div con cada una de las noticias]
          </div>
    </div>
[...]
</div>           

Como se observa, al DIV que contiene las noticias se le han añadido los atributos:

• aria-live="assertive", indica que es una live region y que queremos que anuncie sus modificaciones de forma inmediata.
• aria-atomic="true", indica que queremos que nos anuncie toda la región. NVDA y JAWS nos leen la zona completa de noticias, es decir, las cinco noticias. Si lo hubiéramos puesto a "false" solo nos leería la nueva noticia (el nodo completo: título, fecha y descripción)
• aria-relevant="additions", indica que queremos que nos lea solo los elementos que se insertan en el DOM, por ello nos lee solo la noticia que insertamos pero no la que eliminamos de la lista.

Al no incluir aria-busy, su valor por defecto es "false".

El rol aplicado es role="log", que identifica una región donde nueva información es añadida en un orden significativo y la información vieja puede desaparecer. Este rol implica que hay una relación entre la llegada de nuevos elementos y el orden de lectura, la información se añade solo al final y no en puntos arbitrarios. Los elementos con este rol tienen implícito un aria-live="polite"

Comprobar las diferencias según los valores definidos en los atributos

Para facilitar que podáis comprobar cómo cambia la forma de anunciarse la actualización de las noticias en función del valor de cada atributo, hay un formulario para que podáis modificar estos valores.

Los nuevos valores de los atributos se aplican a la live region sin necesidad de recargar la página.

En el caso de aria-busy, podéis modificar el valor para comprobar cómo anuncia o no los cambios según esté a "true" o a "false", pero hay que tener en cuenta que esto habría que programarlo dinámicamente, para que, mientras se llevan a cabo múltiples actualizaciones de una región dejará de anunciar sus cambios hasta que se completaran todas.

¿Cómo puedo comprobar el resultado?

Si tienes instalado un lector de pantalla solo tienes que abrir la página de ejemplo "Ejemplo ARIA: Live Región" y escuchar. Cada vez que se actualice una noticia te leerá la zona de noticias independientemente de dónde tengas el foco.

Si eres un desarrollador y no tienes instalado un lector de pantalla, puedes instalarte uno gratuito como NVDA o con versión de prueba como JAWS. Pero también puedes instalarte la extensión de Chrome ChromeVox que es muy útil para probar desarrollos con WAI-ARIA.

Una vez instalada la activas en "Herramientas > Extensiones" y abres la página del ejemplo: "Ejemplo ARIA: Live Región", podrás comprobar cómo te anuncia cada actualización de la zona de "Últimas noticias" según los valores definidos para los atributos de la región.

También es muy útil la extensión Accessibility Developer Tools, te permitirá evaluar si tu código ARIA es correcto. Para ello, una vez instalada, accedes a "Herramientas > Herramientas para desarrolladores > Audits" y haces la auditoría con la opción de "Accessibility" seleccionada. Te indicará por ejemplo si falla alguna propiedad ARIA o su valor no es adecuado.

Compatibilidad y diferencias entre diferentes lectores de pantalla

Funciona bastante bien con JAW15 corriendo en Firefox 25 y Explorer 10, sin embargo no funciona con JAW15+Chrome.

También funciona con VoiceOver en Chrome y Safari.

Con NVDA 2013 solo va cuando corre bajo Firefox 25, y además solo con aria-atomic="false", si el valor es "true" no lee nada. No funciona corriendo en Chrome y Explorer.

Hay una diferencia en cómo anuncia ChromeVox y JAWS los cambios de la región cuando aria-atomic="true". JAWS lee toda la región, es decir, todas las noticias. Sin embargo ChromeVox nos anuncia el título de la región, como está asociada al titulo "Últimas noticias" mediante el atributo aria-labelledby nos anuncia que se ha modificado "Últimas noticias".

Por otra parte ChromeVox parace ser el único que anuncia correctamente los nodos eliminados cuando aria-relevant es "removals" o "all", el resto de lectores no anuncian los nodos eliminados.

Si probáis con otros navegadores y/o lectores de pantalla os agradecería que pusierais vuestra experiencia en los comentarios.

Live Regions Roles (alert, log, marquee, status, timer)

¿Qué diferencia hay entre marcar un mensaje de error de estas tres maneras?

<p id="errors3" role="alert" aria-atomic="true"></p>

<p id="errors3" aria-live="assertive" aria-atomic="true"></p>

<p id="errors3" role="alert" aria-live="assertive" aria-atomic="true"></p>

Puedes ver un ejemplo en la página: Simple Form Validation Using Only WAI-ARIA role=alert or aria-live=assertive

role=alert funciona como aria-live con la ventaja de que precede el anuncio de la palabra "alerta".

Se puede usar sin aria-live y se le pueden añadir los atributos aria-atomic, aria-busy y aria-relevant

La ventaja de usarlo con aria-live es que podemos indicar cuándo queremos interrumpir al usuario y aumentamos la compatibilidad con los navegadores. aria-live tiene mejor soporte en JAWS y ChromeVox que en NVDA, donde funciona mejor con Firefox. role=alert está también soportado por IE.

La nueva versión de WAI-ARIA (la 1.1), trae una novedad, define un nuevo tipo de roles, los Live Regions Roles, es decir, aquellos a los que se pueden aplicar los atributos de las live regions:

• role="alert": contiene información relevante y se anuncia con “alerta”. Debería ser aria-live="assertive"
• role="log": donde la información se agrega en orden significativo y la antigua puede desaparecer, debería ser aria-live="polite"
• role="marquee": información no relevante que cambia con frecuencia, debería ser aria-live="off"
• role="status": advertencia no lo suficientemente importante para justificar una alerta, debería ser aria-live="polite"
• role="timer": contador numérico del tiempo transcurrido o restante

Referencia en WAI-ARIA 1.1: 5.3.5 Live Region Roles

WAI-ARIA 1.1 es recomendación desde el 14/12/2017. Puedes consultar todas las novedades en el artículo: Novedades WAI-ARIA 1.1

Enlaces de interés

• Documentos de la especificación WAI-ARIA
• Herramientas de evaluación
• Más ejemplos:
  • Accesible AJAX. Test cases
  • Live Regions, en Mozilla Developer Network
  • Live Regions Examples, en iCITA (Illinois Center for Information Technology and Web Accessibility)

Artículos relacionados

• WAI-ARIA. Introducción, referencias, ejemplos, herramientas
• Novedades WAI-ARIA 1.1
• Ayuda contextual de los formularios más accesible con "aria-describedby" (WAI-ARIA)
• Navegación más accesible y semántica en 2 minutos con Landmark Roles (WAI-ARIA)
• Nuevas técnicas ARIA en las WCAG 2.0. Novedades de la actualización del documento "Techniques for WCAG 2.0" del 11 de marzo de 2014
• PDF accesible. PDF correctamente etiquetado desde inDesign
• Reseña de “Pro HTML5 Accessibility”

Servicios de accesibilidad que ofrezco como consultora freelance

• Consultoría y formación. WCAG 2.x y WAI-ARIA
• PDF accesibles

Un proyecto sobre HTML5 y accesibilidad a los contenidos audiovisuales ha ganado el premio Universia-Vodafone

Hace unos meses os recomendaba en el artículo "HTML 5 y accesibilidad" el trabajo fin de carrera de Alberto Sánchez-Heredero Pérez, tutorizado por Lourdes Moreno López ⁽¹⁾, "Accesibilidad a los contenidos audiovisuales en la Web a través de HTML5" (PDF, 2MB)

Ya entonces me pareció un trabajo muy bueno. Hoy me ha informado Alberto de que su proyecto ha sido el ganador del premio Fundación Universia-Fundación Vodafone España por favorecer la accesibilidad en el ámbito de las Tecnologías de la Información y la Comunicación (TIC).

Enhorabuena!

Se puede ver el visor en HTML 5 support for an accessible user-video-interaction on the Web. ACCESSIBLE HTML5 MEDIA PLAYER

(1) Ver Reseña: "Accesibilidad a los contenidos audiovisuales en la web" .

Cheat Sheet HTML 4.01, HTML 5, XHTML Elements

Descripción: Tabla en formato excel con todas los elementos HTML (incluido HTML 5) y XHTML con información relevante sobre ellos: navegadores que los soportan, anotaciones de accesibilidad, etc. (ver descripción detallada de la tabla)

Versión: [20.01.2011] versión 1.0 en castellano

Autor: Olga Carreras

Descarga: Cheat Sheet HTML 4.01, HTML 5, XHTML Elements (Excel, 189 KB)

Descripción detallada de la tabla

La tabla consta de 14 columnas. Los encabezados de las columnas se han bloqueados para que estén siempre disponibles aunque se escrole la tabla verticalmente.

Columna A: Elemento

Incluye todas los elementos (X)HTML (incluidos los de HTML 5) en orden alfabético con enlace a su descripción en la especificación correspondiente. También se incluyen elementos que no están en ninguna especificación del W3C como marquee, spacer, etc. en cuyo caso enlazan con una web de referencia. Es en estos enlaces donde se puede consultar información sobre los atributos de cada elemento.

No se han incluido los elementos que sólo están presentes en XHTML 2. Como excepción se incluye el elemento h de XHTML 2 para documentar los encabezados en esta especificación. Se pueden consultar todas las etiquetas de XHTML 2 en: XHTMl 2.0. List of elements del W3C.

Está primera columna está bloqueada para tener siempre presente el elemento aunque se escrole la tabla horizontalmente.

Columna B: Descripción

Breve descripción del elemento.

Columna C: Desaprobado/No estándar/Obsoleto

En esta columna se indica si los elementos son:

• Desaprobado (deprecated): son elementos que están en la especificación HTML 4.01 o XHTML pero que el W3C los ha marcado como "deprecated", desaprobando su uso. No están permitidos en documentos STRICT. Se indica el elemento alternativo que debe usarse.


• No estándar: son elementos no estándar, que fueron implementados por algunos navegadores (y que aún las soportan en muchos casos) pero que no pertenecen a ninguna especificación (X)HTML. En cada caso se indica el navegador que las implementó y las alternativas a su uso.


• Obsoleto: son elementos de especificaciones anteriores (se indica de cual).


• HTML 5: elementos que sólo pertenecen a HTML 5.

En cualquier otro caso la celda correspondiente aparece vacía.

Columna D: Web Browser Support

He documentado el soporte de cada elemento (incluidos los de HTML 5) en las diferentes versiones de navegadores.

Referencias sobre soporte en navegadores:

• HTML 4.01 / XHTML 1.0 Reference, about.com


• HTML reference, sitepoint.com


• HTML, XHTML, and WML support in Opera Presto 2.2, soporte en Opera 10


• Web specifications support in Opera Presto 2.7, soporte en Opera 11


• When can I use..., compatibility tables for support of HTML5, CSS3, SVG and more in desktop and mobile browsers


• Comparison of layout engines (Non-standard HTML), wikipedia

En algunos casos se indica el test concreto que se ha realizado para validar un elemento concreto.

Columna E-L: Especificación

Las columnas son:

• HTML 4.01


• XHTML 1.0 Strict


• XHTML 1.0 Transitional


• XHTML 1.0 Frameset


• XHTML 1.1


• XHTML 1.1 Basic


• HTML 5


• XHTML 2

Cuando la celda correspondiente está verde con el texto "SI" indica que el elemento pertenece a esa especificación.

Cuando la celda correspondiente está roja con el texto "NO" indica que el elemento no pertenece a esa especificación.

Algunas celdas pueden aparecer naranjas con una advertencia dentro. Por ejemplo, en el caso de que el elemento pertenezca a HTML 4.01 pero esté desaprobado y no pueda usarse con HTML 4.01 Strict, la celda correspondiente a la columna E (HTML 4.01) estará coloreada en naraja con la advertencia en su interior.

Columna M: Notas de accesibilidad

En este apartado se incluyen notas relevantes como el soporte en lectores de pantalla, ejemplos cuando se trata de elementos poco habituales, mención a puntos de verificación de las WCAG relacionadas con el elemento en cuestión, etc.

Columna N: ¿Semántico?

En esta columna se indica si es una elemento semántico o si por el contrario es un elemento de presentación. En algunos casos, como se indica, puede depender del uso que se haga de ella.

Referencias:

• Semantic (X)HTML, microformats.org


• Presentational (X)HTML, microformats.org

Otros enlaces de interés:

• Keryx (X)HTML Elements Best Practice Sheet

Podeis dejar en los comentarios cualquier propuesta o anotación para incluir en versiones posteriores.