AJAX indexable y accesible

Escrito por Ramón Saquete

AJAX (Asynchronous Javascript and XML) es una combinación de tecnologías que permite recargar partes de una página, evitando así tener que hacerlo con una página entera. Desde siempre, esta tecnología se puede implementar de forma que sea indexable y con HTML5, además, podemos hacer que sea accesible.

Para ilustrar la explicación, supongamos que disponemos de un menú principal con cabecera, pie y contenidos de página que se cargan por AJAX, sin tener que recargar la cabecera y el pie de página cada vez que se carga un contenido distinto. Al leer estas líneas, muchos recordaréis, que esto se hacía antiguamente (a finales de los 90 y principios del siglo XXI) con los marcos, técnica que quedó obsoleta ya que daba muchos problemas. Veamos si es posible, una década más tarde, aplicar AJAX para resolver este supuesto sin tener problemas de indexabilidad y accesibilidad.

AJAX indexable

Para que un enlace en AJAX sea indexable debemos disponer siempre de dos URLs, una que devolverá sólo la parte de la página que tiene que repintar para los usuarios y otro que devolverá la página entera para los robots rastreadores y para los usuarios que tengan Javascript desactivado.

En el ejemplo propuesto supongamos que en el menú tenemos una opción para ir al Blog, así que tendremos dos enlaces:

https://www.humanlevel.com/blog.html → Esta URL cargará la página entera con las entradas y se indexará.

https://www.humanlevel.com/ajax/blog.php → Esta URL cargará sólo las entradas del blog.

En el menú, el enlace aparecerá de la siguiente forma:
<a href="https://www.humanlevel.com/blog.html" id="menuLinkBlog">Blog</a>

Como el enlace tiene asociado una URL indexable, cuando la araña de Google llegue no tendrá ningún problema en seguir el enlace.
¿Pero qué pasará cuando pinche el usuario? Pues, como buenos desarrolladores, habremos implementado una función de Javascript que estará asociada al evento click del enlace con identificador “menuLinkBlog”. Esta función de Javascript cargará por AJAX, dentro del contenido principal de la página, el resultado de la URL https://www.humanlevel.com/ajax/blog.php con el listado de entradas y evitará que se ejecute la acción por defecto del enlace, por lo que no hará el salto a https://www.humanlevel.com/blog.html.

Añadiendo la siguiente línea al archivo robots.txt, evitamos, por si acaso la araña fuera capaz de ejecutar Javascript, que las URLs de peticiones asíncronas en el directorio /ajax, se indexen:

Disallow: /ajax/

Actualización: esta solución ya no es aplicable, ahora la mejor opción es realizar las llamadas con el método POST para evitar que se indexen.

AJAX accesible

Además de que la URL https://www.humanlevel.com/blog.html sea indexable, queremos que sea accesible de forma que aparezca en la barra del navegador al pinchar en el enlace, permitiendo así que los usuarios puedan compartirlo, guardarlo en favoritos y además navegar por el historial pinchando adelante y atrás.

Solución con Javascript de HTML5 (pushState)

Con el objetivo de conseguir que la URL del navegador pueda cambiar sin ir a otra página, se ha creado el método pushState de Javascript:


history.pushState(null, "Blog de HumanLevel", "https://www.humanlevel.com/blog.html");

El primer parámetro es para pasar datos al cambiar de URL, el segundo para cambiar el título de la página (cosa que ya se podía hacer con document.title) y el último indica la URL nuevo al que vamos a ir.

Además, tendremos que asociar una función al evento popstate. Éste se disparará al movernos por el historial y se encargará de cargar, por AJAX, el contenido correspondiente a la URL amigable en la que estamos, sin recargar la página entera.

Esta es una solución estupenda como técnica de WPO (Web Page Optimization) y además, nos puede ahorrar memoria en el servidor, al poder mantener, en el cliente, el estado de las variables que no afectan a la seguridad. Las únicas desventajas que tiene son el aumento del tiempo de desarrollo y que todavía es pronto para usarla por culpa del odioso Internet Explorer. Esto es debido a que Internet Explorer no implementa pushState hasta la versión 10 y, aunque en unos meses va a salir la versión 11, las versiones 8 y 9 están tan extendidas ahora mismo, que no es viable el uso de esta fantástica técnica, que va a revolucionar el tiempo de carga de la Web.

Solución con fragmentos

¿Qué ocurre si el navegador (Internet Explorer) no soporta pushState? Entonces, podemos detectar esta situación desde nuestro código y, si no nos importan demasiado los inconvenientes de la solución con fragmentos, implementarla.

Cuando se escribe el carácter almohadilla # (hash en inglés), al final de una URL, y a continuación una palabra, le estamos añadiendo un fragmento a esta URL (no confundir con las etiquetas de Twitter llamadas hashtag).

Pues bien, resulta que sin usar el nuevo método pushState, mediante la propiedad location.hash=’blog’, se puede modificar éste en la URL, y además, al igual que con el evento popstate, con el evento hashchange, podemos detectar si nos movemos por el historial.

De esta forma, mediante Javascript, al pinchar en el enlace del ejemplo anterior la URL cambiará a algo así:

https://www.humanlevel.com/#blog.html

El problema de esto es que a la hora de que compartan nuestra URL, no nos estarán generando popularidad hacia la página del blog, si no hacia https://www.humanlevel.com/. Esto se debe a que al hacer la petición al servidor, los URL con fragmento son enviados sin éste. El URL de la página sin fragmento será el que recuperará e indexará la araña de Google cuando encuentre el enlace en otra página.

Sin embargo, los usuarios podrán ver el contenido del blog ya que, mediante AJAX, una vez cargada la página que devuelve el servidor, el contenido debería cambiar por el del blog. De esta manera el tiempo de carga aumentará considerablemente para los usuarios que vengan de enlaces externos con fragmento. Además, en el extraño caso de que el usuario tenga Javascript desactivado no se le cargará la misma página.

La mala solución de Google con hashbang

Hace unos cuantos años Google publicó una especificación llamada AJAX application crawlable para hacer las aplicaciones programadas con AJAX indexables y accesibles al mismo tiempo.

Esta especificación no nos convenció a muchos desarrolladores. La prueba de que no fue una buena idea la tenéis con Twitter, que la implementó para después abandonarla, creo recordar, entre los años 2010 y 2012.

La idea es tener enlaces con URLs como el del siguiente ejemplo:

<a href="https://www.humanlevel.com/#!blog.html">Blog</a>

En este caso, lo que hace la araña de Google es que al encontrar el «hashbang» (#!), en lugar de enviar la petición al servidor con el URL https://www.humanlevel.com/ como dicta el estándar, se salta todos los principios de buena ingeniería y realiza una petición al servidor como esta:

https://www.humanlevel.com/?_escaped_fragment_=blog.html

En el código del servidor tendremos que haber programado que esta petición devuelva la página completa del listado de entradas del blog como si se tratase del URL https://www.humanlevel.com/blog.html de los ejemplos anteriores y, de nuevo con Javascript, controlaremos la carga por AJAX del contenido para los navegadores, para lo que en este caso tendríamos que implementar sólo la lógica del evento hashchange.

Los problemas de esta solución son:

• Aumenta el tiempo de desarrollo.
• Es muy fácil realizar una mala implementación generando contenido duplicado.
• Es una solución válida sólo para Google y Bing. Este último también la ha adoptado pero sólo activándola desde su herramienta para webmasters.
• En lugar de la URL amigable https://www.humanlevel.com/blog.html, en el buscador aparecerá indexada la URL https://www.humanlevel.com/#!blog.html. Aunque Google diga que esta aberración es una URL bonita, para mí es bastante discutible.
• Al igual que en el caso anterior, el tiempo de carga aumenta para usuarios que accedan directamente a la URL «bonita» https://www.humanlevel.com/#!blog.html, puesto que debemos cargar la página y luego por Javascript lanzar otra petición al servidor para cargar la parte que viene por AJAX.
• Hay que lidiar con transformaciones de codificación que se hacen entre el fragmento original y la querystring que se envía en la URL transformada.
• Los usuarios con Javascript desactivado no verán la misma página.

Accesibilidad para discapacitados con WAI-ARIA

No se puede hablar de accesibilidad web y Javascript, sin al menos mencionar el estándar de la WAI (Web Accessibility Initiative), llamado ARIA (Accessible Rich Internet Applications). Este estándar está pensado, principalmente, para hacer accesibles las aplicaciones Web, con un uso intensivo de Javascript, a los usuarios discapacitados que sólo pueden usar el teclado o que tienen que usar un lector de pantalla como Jaws o NVDA.

Este estándar añade una serie de atributos al HTML, que definen información semántica sobre las funcionalidades de cada elemento y los estados de éstos, que deben ir manipulándose con Javascript al mismo tiempo que se usa la aplicación, con el fin de que la API de accesibilidad del sistema operativo los interprete y pase la información al lector de pantalla del usuario.

WAI-ARIA forma parte de la especificación de HTML5 y, según el W3C, debe usarse teniendo en cuenta que las etiquetas semánticas de HTML5 y, dentro de tres años, de HTML5.1, deben emplearse sobre los atributos de WAI-ARIA cuando existan equivalencias, aunque en la práctica a veces se usan ambos, cuando se utiliza alguna etiqueta nueva de HTML5 que todavía no se soporta por los navegadores, como ocurre, por ejemplo, con la nueva etiqueta de HTML5 main que se suele acompañar del atributo role=»main» de WAI-ARIA.

La Web evoluciona para mejor. El método pushState de HTML5 y WAI-ARIA permiten implementar páginas más rápidas y accesibles sin afectar al SEO. No obstante, sólo podremos disfrutar de las nuevas tecnologías cuando desaparezcan las versiones antiguas de Internet Explorer.