Autocompletado accesible para resultados de búsqueda
20 de Diciembre 2008
En mis últimos trasteos con el blog, he incorporado un “autocompletado” para el formulario de búsqueda. (Utilizo el término autocompletado porque es el más común, aunque yo simplemente lo llamaría resultados de búsqueda instantáneos.)
El funcionamiento se basa en hacer una petición AJAX para la consulta que estamos escribiendo en el campo de búsqueda cada vez que se pulse una tecla, a partir de 3 caracteres escritos. El resultado de esto es una lista que se va actualizando mientras escribimos, con las entradas que coinciden con nuestra búsqueda, con lo que, deseáblemente, los resultados se muestran de forma predictiva.
Ventajas de este sistema:
- La obtención de resultados es mucho más rápida que si tuviéramos que cargar la página completa.
- La aparición de la lista de resultados mientras se escribe, puede ahorrar la escritura del literal completo de búsqueda.
Inconvenientes:
- Los usuarios se quedan sin la posibilidad de agregar la página de resultados a sus marcadores, volver mediante el botón del navegador a una consulta anterior, etc.
- La página independiente de resultados de búsqueda nos ha quedado un poco desangelada.
- Las actualizaciones dinámicas de contenido suponen un problema para algunos usuarios como los de lectores de pantalla.
Soluciones a los inconvenientes.
Pérdida de funcionalidad de la interfaz del navegador.
Este problema ha quedado sin resolver, aunque no afirmo que sea insalvable. Yo no conozco la solución.
Un usuario experimentado podría buscar la url de la petición AJAX e introducirla diréctamente en su navegador, o simplemente desactivar Javascript para obtener el comportamiento normal del formulario de búsqueda.
Página independiente de resultados.
Aunque esta página ha quedado bastante triste, se ha procurado que siga teniendo sentido por sí misma al sacarla del contexto para el que está diseñada (la caja de resultados dinámica.)
Para ello se han añadido varios textos ocultos al encabezado visible “Resultados de búsqueda”. Uno contiene los términos de búsqueda y otro el nombre del sitio en el que se ha realizado la búsqueda, de manera que si un usuario llegara a esta página sin haber pasado por el buscador, seguiría teniendo una referencia u orientación general sobre el contenido encontrado.
Por otra parte, se han seguido los principios del Javascript no intrusivo haciendo que los elementos que sólo tienen sentido con Javascript habilitado o que existen solamente para ejecutar una funcionalidad Javascript, no estén en el código HTML, sino que se generen también con Javascript. Para ello se ha reemplazado el enlace que aparece en la página de resultados a la página principal de este sitio, por el botón de cerrar que aparece en la caja de resultados.
Contenidos dinámicos VS lectores de pantalla.
Como comentaba en un post anterior, los usuarios de lectores de pantalla tienen dificultades para enterarse de las actualizaciones dinámicas de contenido mediante Javascript. En primer lugar no pueden apreciar visualmente los cambios, y en segundo lugar, los lectores de pantalla leen el contenido de la página de manera lineal, a partir de una “captura del DOM” (buffer virtual) que guardan al cargar la página.
Esto último supone, que mientras el contenido ha cambiado, el lector de pantalla sigue usando una versión no actualizada del DOM. En las últimas versiones del lector de pantalla JAWS, este problema se ha solucionado parcialmente refrescando el buffer virtual cada cierto tiempo para evitar que se use una versión desactualizada de la página. Aun así, la aparición o modificación de contenidos sigue resultando un problema, ya que, aunque el lector de pantalla actualice el buffer virtual, el usuario no tiene forma de saber automáticamente que el contenido ha cambiado o dónde se ha producido esa actualización de contenido.
Una de las medidas más efectivas para solucionar este problema, o al menos minimizarlo, consiste simplemente en llevar el foco a la capa en la que se generan los resultados de búsqueda, que por otra parte, y por razones de posicionamiento CSS, no aparece inmediátamente después del formulario de búsqueda, sino al final del documento. Para ello simplemente le hemos asignado un valor negativo (-1) al atributo tabindex, para que pueda recibir el foco mediante Javascript (elemento.focus();) pero no aparezca en el orden natural de tabulación de la página.
El atributo tabindex no valida en elementos que no sean campos de formulario o enlaces, por lo que se ha añadido mediante Javascript.
Con esto conseguimos que al desenfocar el campo de búsqueda (evento onblur), la capa con los datos actualizados reciba inmediátamente el foco y pueda ser leída a continuación.
WAI-ARIA para los más avanzados.
La solución de llevar el foco al elemento actualizado, resulta efectiva en Internet Explorer (6 y 7) usando JAWS y NVDA, pero para los navegadores que actualmente soportan WAI-ARIA (Firefox 2 y superiores y Opera), hemos añadido unos cuantos atributos que informan además, sobre la cantidad de contenido que se actualizará en un área dinámica, la prioridad con que el lector de pantalla debe anunciar la actualización o el papel que cumple el área actualizada en el documento (es un contenido independiente, complementario, navegación, etc.)
Para conocer una lista de las posibilidades de WAI-ARIA, recomiendo echarle un vistazo a los ejemplos de ARIA que publican en iCITA.
Después de varias combinaciones y pruebas con JAWS 9, NVDA y el plugin para Firefox, Firevox, he decidio usar las siguientes propiedades y atributos para la capa de los resultados:
'aria-live': 'assertive',
'aria-relevant': 'all',
'aria-atomic': 'true'
También tengo que comentar, que el lector de pantalla con el que he obtenido unos resultados más parecidos a los esperados, ha sido el lector gratuito NVDA.
