Manos a la Obra Con ARIA: Elementos de Página de Inicio y de Sistemas de Navegación Estándar

¿Quieres que tu sitio web sea más accesible? ¿Quieres ser el primero conforme surgen en el mercado nuevas interfaces online? No busques más, lo que necesitas es ARIA.

Este conjunto de estándares, mantenido por W3C (World Wide Web Consortium) te proporciona lo mejor de ambos mundos al añadir ciertos atributos que te permitirán ampliar el código HTML en formas semánticas. Aquí, hablaremos de lo que es ARIA, veremos cómo puede beneficiar a un sitio internacional, y también veremos casos de uso paso a paso y con ejemplos de código. ¡Empecemos!

Fundamentos de ARIA

ARIA (llamado en ocasiones WAI-ARIA) es el acrónimo de un conjunto de estándares de accesibilidad, denominado Web Accessibility Initiative–Accessible Rich Internet Applications. Puedes consultar más sobre los fundamentos de ARIA en mi anterior artículo, pero repasemos ahora algunos de sus pilares.

• HTML
  Accesibilidad Web: Primeros Pasos Con ARIA
  Kyle Speaker

Definir Relaciones No-Tradicionales

Una gran mayoría de sitios web están creados con HTML, el cual relaciona unos elementos con otros principalmente de un modo jerarquizado a través de relaciones padre-hijo. Este tipo de estructura es fantástico para definir contenido, pero falla a la hora de definir las interfaces de usuario. Por ejemplo, en muchos sitios y aplicaciones web, un área de contenido está controlada por botones dentro de un elemento hermano—los hermanos tienen el mismo elemento padre, pero en HTML no tienen una relación directa entre sí. Debido a esto, es complicado definir qué elementos de Interfaz de Usuario (UI) controlan cada pieza de contenido cuando se usan tecnologías de asistencia.

Esto también nos lleva a nuevas interfaces. Por ejemplo, si estás intentando navegar en un sitio web a través de un dispositivo móvil, la tarea será complicada si los cambios de los elementos no son visibles.

ARIA te permite relacionar elementos HTML usando atributos adicionales para representar este tipo de controles.

Una Clasificación de Elemento No-Rígida

Otro defecto del HTML es su incapacidad para separar la estructura de la intención.

Por ejemplo, podrías querer convertir un elemento imagen en un botón clicable. Sin embargo, HTML todavía define esa imagen únicamente como imagen, y cualquier cosa más allá de esto sucede en cualquier otro sitio.

Con ARIA, podemos asignar la intención de un elemento de forma independiente, permitiéndonos marcar las imágenes como botones o definir un enlace como tooltip. Esto proporciona mayor control al desarrollador sobre la interfaz de usuario, creando un conjunto de relaciones más claras.

Crear de Áreas de Puntos de Referencia (Landmarks)

Más allá de marcar elementos dentro de la UI, ARIA también nos dá acceso a un atributo de rol—empleado para definir áreas en una página. Por ejemplo, podrías marcar tu menú principal como navegación y el área de contenido de tu artículo como contenido principal. Esto hace que sea más fácil para los usuarios moverse entre las áreas importantes de tu sitio web, y puede evitar confusiones en las páginas con maquetaciones complejas o poco comunes.

Caso de Estudio: Página de Inicio de Pequeño Negocio

Como ejemplo práctico de cómo añadir ARIA a un sitio, vamos a coger una estructura básica de un sitio que podría valer para un pequeño negocio e implementaremos en ella paso a paso nuestros atributos.

Para mayor claridad, hemos fragmentado el código, y eliminado las clases CSS y cualquier funcionalidad procedente del CMS.

Lo primero que queremos hacer es dividir nuestra página en partes para simplificar la adición de ARIA. En la imagen inferior, verás que hemos dividido el sitio en cinco partes principales:

• Navegación
• Contenido
• Sidebar
• Formularios de contacto
• Elementos UI especializados

En nuestro caso, esto toma la siguiente forma:

Cuando dividimos tu sitio en partes de esta forma, perseguimos dos cosas. La primera es para los elementos que pueden ser definidos por un punto de referencia o landmark de ARIA: banner, navigation, main, complementary, content, info, search, y form. Estos puntos representan las partes necesarias de nuestro sitio, y todo lo que no sea necesario para su uso, no será marcado como landmark (por ej. los anuncios).

Lo segundo en lo que nos debemos fijar son los elementos concretos que deban ser aclarados mediante ARIA. En la mayoría de los casos esto es bastante sencillo (por ejemplo, marcar una imagen como imagen), pero con algunos elementos de interfaz, puede resultar un poco engañoso.

Una vez sepamos en qué áreas debemos implementar ARIA, podremos empezar a repasarlas sistemáticamente. Vamos a comenzar con la navegación del sitio.

Navegación

En nuestro ejemplo, habrás notado que tenemos unos cuantos tipos de navegación. El primero es un menú como el de la mayoría de los sitios, en el que se listan algunas páginas del sitio. Directamente debajo tenemos un menú más pequeño que contiene opciones para los usuarios.

Queremos marcarlos con el atributo role="navigation" de manera que puedan ser detectados fácilmente como menús del sitio. Esto nos lleva a la siguiente pregunta: ¿deberían estar agrupados juntos en un landmark de navegación único, o deberían marcarse por separado?

Para responder a esta pregunta en tus propios proyectos puedes plantearte estas dos preguntas:

1. ¿Es distinta la intención de cada uno de los menús? En nuestro ejemplo, el menú superior sirve para navegar hacia las páginas principales del sitio, mientras que el menú más pequeño se centra en cosas que puedan necesitar los usuarios que hayan iniciado sesión. Estos objetivos son distintos, y por tanto tendría sentido separarlos.

2. ¿Están los menús dentro del mismo elemento padre? Se que esto parece contradictorio, ya que ARIA está diseñado para ayudarnos a superar estos tipos de restricciones en las relaciones entre elementos, pero en este caso no se trata tanto de lo que es posible y sino sobre lo que es correcto para el usuario. Tener definido un único menú, pero ubicar la mitad de este en un sitio y la mitad en otro, hace que la navegación sea más complicada.

En nuestro caso, vamos a tratar nuestras navegaciones como landmarks independientes. Así que vamos a hacer algunos cambios en el código. Y vamos a empezar con el HTML.

<!-- Example code before ARIA -->

<div id=’menus’>
    <ul>
  	<li>Home</li>
		<li>About</li>
		<li>Services</li>
		<li>Location</li>
		<li>Contact Us</li>
	</ul>
    <ul>
		<li>Login</li>
		<li>Account</li>
		<li>Settings</li>
	</ul>
</div>

Ahora lo notaremos con algunas marcas de referencia.

<!-- Example code after adding landmarks -->

<div id=’navigation-menu’ role=’navigation’>
    <ul>
        ...
	</ul>
</div>
<div id=’user-menu’ role=’navigation’>
    <ul>
        ...
	</ul>
</div>

El siguiente paso para definir estas landmarks consiste en dar al usuario una pista sobre cuál es el objetivo de cada uno de los menús. Si dejamos ambos como navegación sin más, dificultaremos la interpretación de las cosas. Así que vamos a añadirles etiquetas significativas usando el atributo aria-label:

<!-- Example code after adding labels -->

<div id=’navigation-menu’ role=’navigation’ aria-label=’Main Navigation’>
    <ul>
        ...
	</ul>
</div>
<div id=’user-menu’ role=’navigation’ aria-label=’User Menu’>
    <ul>
        ...
	</ul>
</div>

Más allá de esto, queremos añadir código de rol adicional a nuestro menú que permita a los usuarios saber que esto es un menú, y marcar cada enlace que contenga como elemento de menú.

<!-- Code after ARIA implementation -->

<div id=’navigation-menu’ role=’navigation’ aria-label=’Main Navigation’>
    <ul role=’menu’>
		<li role=’menuitem’>Home</li>
		<li role=’menuitem’>About</li>
		<li role=’menuitem’>Services</li>
		<li role=’menuitem’>Location</li>
		<li role=’menuitem’>Contact Us</li>
	</ul>
</div>
<div id=’user-menu’ role=’navigation’ aria-label=’User Menu’>
    <ul role=’menu’>
		<li role=’menuitem’>Login</li>
		<li role=’menuitem’>Account</li>
		<li role=’menuitem’>Settings</li>
	</ul>
</div>

Área de Contenido

Ahora vamos con el área de contenido. Aquí vamos a marcar el elemento que contiene todo nuestro contenido principal con role="main". De nuevo, para comparar, aquí tienes el código inicial.

<!-- Our code before ARIA -->

<div>
    <img src=”#” onclick=”#” />

	<p> Lorem …
		<a href=”#” onclick=”#”>scelerisque</a>
	…</p>

	<form action="#">
      		<input type="text" placeholder="Enter Your Search Text" name="search">
     		 <button type="submit">Find It</button>
    	</form>
</div>

Y aquí tienes el aspecto que tendrá después de añadir la marca "main".

<!-- Adding in the 'main' landmark -->

<div role=”main”>
    <img src=”#” onclick=”#” />

	<p> Lorem …
		<a href=”#” onhover=”#”>scelerisque</a>
	…</p>

	<form action="#">
      		<input type="text" placeholder="Enter Your Search Text">
     		 <button type="submit">Find It</button>
    	</form>
</div>

Dentro del contenido, tenemos que encontrar cualquier elemento cuyo propósito no coincida con su definición HTML.

Primero, nos ocuparemos de la imagen que funciona como botón añadiéndole el rol "button". 

<img src=”#” onclick=”#” role=”button” />

Este enlace que activa un modal es un poco confuso ya que depende de lo que vaya a ser el modal en sí. En nuestro caso, vamos a indicar que es un tooltip.

<a href=”#” onhover=”#” role:’tooltip’>scelerisque</a>

Dentro de nuestro contenido, también tenemos un formulario de búsqueda. Esto le añade una capa extra de complejidad, en el sentido de que es un formulario de búsqueda que usa elementos HTML, y también cuenta con un landmark de campo de búsqueda. Lo marcaríamos de la siguiente manera:

<div role=’search’>
<form action="#">
          	<input type="text" placeholder="Enter Your Search Text" role=’textbox’>
     		 <button type="submit" role=’button’>Find It</button>
    	</form>
</div>

Más allá de esto, puedes definir cualquier elemento con su propia etiqueta ARIA. En la mayoría de los sitios, esto puede suponer bastante tiempo del proceso de desarrollo, aunque en la mayoría de CMSs puede automatizarse. En los casos en los que sea posible, si la definición de un elemento HTML coincide con su objetivo, podemos considerarlo como de baja prioridad al implementar ARIA. Aquí tienes el aspecto que tendrá el área de contenido principal tras todos estos cambios:

<!-- The completed content area -->

<div role=”main”>
    <img src=”#” onclick=”#” role=”button” />

	<p> Lorem …
		<a href=”#” onhover=”#” role:’tooltip’>scelerisque</a>
	…</p>

<div role=’search’>
<form action="#">
      		<input type="text" placeholder="Enter Your Search Text" role=’textbox’>
     		 <button type="submit" role=’button’>Find It</button>
    	</form>
</div>
</div>

Sidebar

La columna lateral o sidebar de un sitio puede tomar muchas formas. En nuestro caso, proporciona contenido adicional relacionado con el sitio, con una lista de entradas relacionadas al final.

Aquí tienes el código de inicio para un sidebar:

<aside id=’sidebar’>
    <div>
    	<h2>More About Us</h2>
    	<p>Lorem...</p>
    </div>
	<div>
    	<h2>Related Posts</h2>
    	<ul>
    		<li>Post</li>
    		<li>Post</li>
    		<li>Blog Post</li>
    	</ul>
    </div>
</aside>

Parta definir el contenido, querremos asignarle el rol "complementary", permitiendo que los usuarios sepan que la información que contiene el sidebar está relacionada con el contenido principal de la página. Esto tendrá el siguiente aspecto:

<div role=’complementary’>
    <h2>More About Us</h2>
	<p>Lorem...</p>
</div>

Las entradas relacionadas de abajo podrían considerarse como una forma de navegación, permitiendo a los usuarios explorar más entradas del sitio. Queremos marcarlas con el rol "navigation", y asignarle una etiqueta apropiada, de la siguiente manera:

<div role=’navigation’ aria-labelledby=’posts-heading’>
    <h2 id=’posts-heading’>Related Posts</h2>
	<ul role=’menu’>
		<li role=’menuitem’>Post</li>
		<li role=’menuitem’>Post</li>
		<li role=’menuitem’>Blog Post</li>
	</ul>
</div>

El sidebar de cada sitio es distinto y podría requerir una combinación de roles y landmarks distintos. Si tu sidebar contiene publicidad, entonces es mejor no marcar este elemento. Si existe un formulario de búsqueda dentro del sidebar, entonces márcalo también con el rol apropiado. Cualquier menú que aparezca en un sidebar debería seguir el patrón que hemos visto en la sección de la navegación:

• una marca "navigation"
• un rol "menu" para el elemento que contiene los elementos de menú
• roles de "menuitem" para cada uno de los elementos anidados

Aquí tienes el aspecto que tendrá nuestro sidebar:

<aside id=’sidebar’>
    <div role=’complementary’>
    	<h2>More About Us</h2>
    	<p>Lorem...</p>
    </div>
	<div role=’navigation’ aria-labelledby=’posts-heading’>
    	<h2 id=’posts-heading’>Related Posts</h2>
    	<ul role=’menu’>
    		<li role=’menuitem’>Post</li>
    		<li role=’menuitem’>Post</li>
    		<li role=’menuitem’>Blog Post</li>
    	</ul>
    </div>
</aside>

Manejar los Formularios de Contacto

Por último, al final de nuestra página encontramos un formulario de llamada a la acción, que solicita al usuario su nombre y su email, con un botón de envío estándar bajo él. En lo que respecta a los formularios, existen tres partes a tener en cuenta:

1. Asígnale al formulario el rol "form": como el formulario es una parte importante del sitio, tenemos que facilitarle a los usuarios acceder a él. Y esto lo hacemos asignándole un landmark de rol.

2. Asignar roles correspondientes a los elementos. Los formularios son áreas de intención y de definiciones HTML que muy habitualmente se confunden. Añade roles ARIA cuando sea necesario, especialmente cuando trabajes con casillas de verificación, sliders, tooltips y otros elementos que puedan ser implementados de distintas formas. 

3. Asigna etiquetas a los elementos adecuados. HTML gestiona esto de forma muy básica, permitiéndote usar el elemento <label> para asociar una etiqueta con un input. Los formularios pueden tener fácilmente estructuras más complejas que les impida funcionar de forma apropiada; Afortunadamente podemos corregirlo con el atributo aria-labelledby.

Echemos un vistazo a nuestro código actual:

<!-- Contact form after ARIA -->

<form action="#" role=’form’>

    <label for="textbox" id=’textbox-label’>Text box</label>
  	<input type="text" id="textbox" role=’textbox’ aria-labelledby=’textbox-label’>

    <select name="combobox" role=’combobox’ aria-label=’Descriptive Name Dropdown’>
		<option value="choice1" aria-label=’Choice #1’>Choice #1</option>
  		<option value="choice2" aria-label=’Choice #2’>Choice #2</option>
	</select>

	<input type=”checkbox” checked  role=’checkbox’ aria-label=’Get a Newsletter Checkbox’ aria-check=’true’’>Checkbox
	
  	<input type="submit" value="Submit" role=’button’>
      
</form>

Comprobar Tu Implementación

Tras realizar todas nuestras implementaciones, ahora tenemos que comprobar que funcionan correctamente. Para ello, el método más sencillo consiste en usar una herramienta de accesibilidad como las Herramientas de Accesibilidad para Desarrolladores de Google o el Plugin Dynamic Assistant de IBM.

Ambas herramientas se integran con las herramientas para desarrolladores de Chrome que te permitirán inspeccionar en tiempo real la accesibilidad de tu sitio web. En W3C también puedes encontrar una amplia lista de herramientas para la accesibilidad.

Hacer la Web más Accesible

¡Ahora la estructura de nuestro sitio web tiene ARIA! Aunque todavía queda mucho por explorar sobre ARIA, ahora tienes suficientes conocimientos para hacer que gran parte de lo sitios en los que trabajas sean más accesibles. Más allá de esto, tu sitio también está ahora mejor preparado para gestionar cualquiera de las nuevas tecnologías trasversales de internet que puedan surgir.

¿Existe algún otro aspecto de ARIA que quieras explorar? ¿Tienes preguntas relacionadas con este artículo? ¡Plantéalas con total libertad a través de un comentario aquí abajo!