Sitios web más accesibles

Aunque no es la primera vez que hablo del HTML semántico he decidido darle un repaso a todo lo que ARIA implica en el desarrollo de un sitio web. WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications) son unas mejoras del HTML para mejorar la accesibilidad de los sitios web. Como ya dije en su momento, básicamente le da algo más de inteligencia semántica a los sitios.

Pero no hemos de olvidar que el propio HTML5 a diferencia de sus versiones anteriores ha incorporado que prácticamente todas sus etiquetas ya llevan incorporados ciertos elementos semánticos. Por poner un ejemplo, la etiqueta H1 ya implica un header. La cuestión es… ¿cuándo y cómo hay que usar ARIA en HTML?

La primera de las normas es bastante sencilla. Si un elemento HTML ya incluye semántica ARIA integrada, no hace falta indicarla, a menos que la queramos cambiar.

La segunda de las normas también es sencilla, aunque a mi personalmente no me gusta mucho. Es recomendable no sobre escribir las reglas ARIA de los elementos. Por poner un ejemplo:

No se debe hacer así:

<h1 role="button">botón en la cabecera</h1>

Sería mejor hacerlo así:

<h1><span role="button">botón en la cabecera</span></h1>

Aunque si lo queremos hacer óptimo, podemos usar:

<h1><button>botón en la cabecera</button></h1>

¿Qué significa esto? Pues que si por ejemplo hacemos algo de este estilo:

<h1 role=button>texto</h1>

Realmente lo que tendríamos a nivel significado es esto:

<button>texto</button>

Otro ejemplo sería el siguiente:

<button role="heading" aria-level="1">texto</button>

Que nos dejaría con algo tan simple como esto:

<h1>texto</h1>

Vale, hasta aquí nos queda claro que es importante usar el significado que viene por defecto en los diferentes elementos o la oportunidad de sobre escribir el significado de los mismos, pero… ¿qué ocurre con todo ese código “de mierda” que metemos en las páginas que en principio llevan significado de por sí, pero que realmente sólo usamos para “dar formato” a lo que queremos? Pues para este tipo de código podemos utilizar un sistema que elimina cualquier significado: el role="presentation".

Un detalle de este parámetro es que se come el significado también de cualquier etiqueta hija que incluya. Para poner un ejemplo algo “complejo” os dejo este:

<table role="presentation">
  <tr>
    <td>
      <table>
        <tr>
          <td><abbr title="Application Programming Interface">API</abbr></td>
        <tr>
      </table>
    </td>
  </tr>
</table>

Realmente, su significado “real” quedaría mucho más reducido, a esto:

<>
  <>
    <>
      <table>
        <tr>
          <td><abbr title="Application Programming Interface">API</abbr></td>
        <tr>
      </table>
    </>
  </>
</>

Personalmente, desde el punto de vista SEO este último elemento debería tener todo el sentido del mundo ya que implicaría quitarle significado a toda la basura de código que muchas veces se genera en determinados sitios web. Aún así, Bing y Google tratan ARIA de formas muy distintas y dispersas y no queda claro su funcionamiento. Después de esto, mi pensamiento es que si se hace bien y se pone el código como se debe, mal no debe hacer.

¿Cómo se oculta información? Habitualmente usamos a través de CSS el display:none o el visibility:hidden, pero esto simplemente lo que hace es no mostrarlo, pero sigue siendo “visible” desde el punto de vista de la accesibilidad. ¿Cómo eliminarlo? Pues añadiendo el aria-hidden. Hay que tener tener en cuenta que una de las novedades en HTML5 es que todos los elementos del DOM incluyen el nuevo atributo hidden, lo que significa que otra forma de ocultar contenidos se puede aplicar con un pequeño JavaScript tal que así:

<script>
  function ocultar() {
    document.getElementById('prueba').hidden = true;
  }
</script>

Existen muchos roles en el sistema, y como ya he comentado al principio la mayoría de etiquetas del HTML ya incluyen su significado semántico… pero no todos los elementos disponen de sus propios roles.

  • Cualquier elemento: como ya he comentado antes, cualquier elemento podría usar el role="presentation".
  • address: podría incorporar en caso necesario el role="contentinfo" que amplia la información del documento actual.
  • article: los navegadores aún no indican su rol por defecto, así que habría que indicarlo expresamente con role="article".
  • details: como el anterior, aún no va de serie, así que hay que indicarle el role="group".
  • dialog: otro que debería y no lo lleva de serie, con el role="dialog".
  • div, p, pre y blockquote: no tienen un rol definido por defecto, así que les podemos asignar el que nos venga en gana según necesitemos.
  • footer: es curioso que este elemento no lleve un significado implícito, por lo que si en la página hay un pie “general”, a ese en concreto se le puede asignar el role="contentinfo".
  • header: al igual que el pie, este tampoco lleva implícito nada, por lo que podríamos utilizar por ejemplo el role="banner" si es la cabecera principal.
  • main: este elemento que se está planteando par el HTML5.1 debería ir acompañado siempre del role="main".
  • nav: indica una navegación por lo que debería ir acompañado del role="navigation".
  • span: el “tag inútil” tiene una gran ventaja… al igual que el div se le puede incorporar cualquier rol.
  • table: aunque no incopora ningún significado por defecto hay dos opciones que sí que se podrían utilizar; la primera es cuando se le da uso de “diseño”, por lo que es inútil y se debería eliminar cualquier significado con el role="presentation"; en el caso de que se le de un uso de tabla pura, se le podría dar el role="grid".

A parte de estos elementos que son principalmente contenedores tenemos otros como em, strong, small, s, cite, q, dfn, abbr, time, code, var, samp, kbd, sub, sup, i, b, u, mark, ruby, rt, rp, bdi, bdo, br, wbr… que como son utilizables para dar formato no incorporan ningún tipo de significado semántico. Se les puede dar el rol que se quiera, pero personalmente no creo que sea recomendable.

Hasta ahora he comentado varios de los posibles roles que se pueden utilizar, pero la lista de roles es bastante grande…

  • alert: Un mensaje importante y con una duración en el tiempo limitada.
  • alertdialog: Un bloque que incluye un mensaje de alerta.
  • application: Todo lo contrario a un “documento”. O sea, que no es una web.
  • article: Parte de un documento que se puede tratar como un elemento independiente.
  • banner: Bloque que suele contener contenido para todo el sitio.
  • button: Sistema que reacciona tras un clic o presión.
  • checkbox: Entrada que tiene 3 posibles estados: verdadero, falso o mixto.
  • columnheader: Celda que contiene la información de una columna.
  • combobox: Un listado en el que además se pueden añadir opciones.
  • complementary: Contenido complementario al contenido principal pero que a su vez tiene significado propio.
  • contentinfo: Información relacionada al contenido principal.
  • definition: Definición de un concepto.
  • dialog: Ventana que detiene el proceso actual a la espera de que el usuario introduzca información para continuar.
  • directory: Referencia a un grupo de elementos (como si fuera un índice).
  • document: Todo el contenido de una página web.
  • form: Un formulario (y todo lo que lo acompaña).
  • grid: Como una tabla, tiene filas y columnas con celdas.
  • gridcell: Una celda.
  • group: Una lista de objetos pero que no es un directorio.
  • heading: La cabecera del contenido de una página.
  • img: Colección de elementos que forma una imagen.
  • link: Referencia que, cuando se pulsa, hace que el navegador vaya a ese recurso.
  • list: Lista de elementos no interactivos.
  • listbox: Lista de elementos interactivos con el usuario.
  • listitem: Elemento de una lista o directorio.
  • log: Zona en la que se va añadiendo información nueva dejando paso de la anterior.
  • main: Contenido principal del documento.
  • marquee: Zona en la que la información (no esencial) va cambiando.
  • math: Expresión matemática.
  • menu: Lista de opciones para un usuario.
  • menubar: Menú habitualmente siempre visible y en horizontal.
  • menuitem: Opción dentro de un menú.
  • menuitemcheckbox: Opción de un menú que tiene 3 posibles estados: verdadero, falso o mixto.
  • menuitemradio: Opción de menú que sólo permite una posibilidad a la vez.
  • navigation: Elementos que permiten la navegación por páginas externas o internas.
  • note: Bloque que añade información puntual al documento principal.
  • option: Elemento seleccionable de una lista.
  • presentation: Elemento que no debe ser accesible.
  • progressbar: Barra de progreso.
  • radio: Elementos que sólo pueden ser seleccionables una vez.
  • radiogroup: Grupo de elementos que sólo pueden ser seleccionables una vez.
  • region: Agrupación de contenidos que podrían estar en un directorio.
  • row: Fila de celdas.
  • rowgroup: Grupo de filas de celdas.
  • rowheader: Celda que contiene la información de una fila de celdas.
  • scrollbar: Barra de navegación que controla el scroll de una zona.
  • search: Bloque que agrupa elementos que permiten realizar búsquedas.
  • separator: Separador de secciones en un contenido o grupos de menús.
  • slider: Lugar de selección entre valores de un determinado rango.
  • spinbutton: Rango de opciones en los que el usuario ha de elegir.
  • status: Bloque de información para el usuario no tan importante como una alerta.
  • tab: Etiquetas que permiten al usuario una ayuda sobre el contenido.
  • tablist: Lista de “tabs”.
  • tabpanel: Contenedor de “tablist”.
  • textbox: Texto libre.
  • timer: Contador de tiempo.
  • toolbar: Colección de botones.
  • tooltip: Contenido contextual de información de un elemento.
  • tree: Lista que permite extender o contraer sus elementos.
  • treegrid: Listas por filas que permiten expandir o contraer sus elementos.
  • treeitem: Elemento de un árbol.

Ahora que tenemos todo esto sobre la mesa… Cuando hablan de la Web 3.0 ¿se refieren a esto?

2 comentarios en “Sitios web más accesibles”

Deja un comentario