Accesibilidad en la web

¿Alguna vez te has preguntado cómo pueden las personas con discapacidad visual hacer uso de una página web o de un computador en general? ¿O cómo lo pueden hacer personas con movilidad reducida? Por difícil que parezca, en ambos casos es perfectamente posible. Pero no sin la ayuda de diseñadores y desarrolladores. En este artículo vamos a hacer una breve exploración del concepto de accesibilidad de interfaces de usuario y entraremos un poco más en detalles técnicos de cómo desarrollar para la web, teniendo la accesibilidad en mente.

¿Qué es la accesibilidad?

La accesibilidad se refiere -de manera general- a la cualidad de objetos o servicios de poder ser usados por personas con diferentes grados de discapacidad. Está visible, por ejemplo, en el diseño de accesos a edificios y lugares públicos, donde usualmente -en especial en construcciones más modernas- hay no sólo escaleras a la entrada, sino también rampas de baja inclinación para que puedan entrar personas en sillas de ruedas, padres y madres con sus hijos en coche, o personas con dificultad para caminar o subir y bajar escaleras.

Al hacer uso de computadoras, y en particular de páginas y aplicaciones web, también podemos tener interfaces accesibles o no, dependiendo del cuidado que pongamos los diseñadores y desarrolladores al construirlas. Existen páginas y aplicaciones que sólo ofrecen el equivalente a la escalera del mundo real y páginas que, además, ofrecen las rampas. Este artículo te ayudará a iniciar el camino para que los sitios web en los que trabajes no excluyan a quienes necesitan las rampas.

Accesibilidad en la Web

La plataforma web es normalmente accesible sin nosotros tener que hacer mucho trabajo. El problema surge cuando, por razones estéticas y visuales, no queremos usar los componentes nativos de la plataforma. Esta no es la única causa, pero es la más común.

Enlaces vs. botones

Por ejemplo, en ocasiones necesitamos un botón que no parezca un botón sino un enlace (o viceversa). Puede parece trivial, pero hay una diferencia semántica entre ambos, más allá de su apariencia visual: el enlace (léase un elemento <a href="...">) representa una acción de navegación hacia otros sitios, otras páginas web u otras partes de la página actual; el botón representa otro tipo de acciones, como enviar un formulario, abrir un menú desplegable o un modal, etc.

Y aquí podrían decirme ¿pero qué diferencia hace si la acción es abrir un modal o navegar a otra página? Una acción es una acción.

El problema está en que más allá de la apariencia visual, ambos elementos tienen distinta interpretación por parte el navegador y se comportan de maneras sutilmente distintas, pero cuyas diferencias son importantes para usuarios de navegación asistida (más adelante hablaremos sobre qué es la navegación asistida).

Y pasa que, en aras de lograr un botón que no parezca botón, muchas veces usamos algunas de las siguientes variantes:

<a onClick={…}>Click me</a>
<a href=”#” onClick={…}>Click me</a>

O peor aún:

<span onClick={...}>Click me</a>

Los problemas que introducen estas prácticas no son aparentes cuando siempre usamos el mouse para interactuar con los elementos en la web. Por el contrario, se hacen evidentes cuando usamos el teclado. Y aunque no lo parezca, la usabilidad de páginas web vía teclado es importante. Es el medio principal que usan las personas débiles visuales (con ayuda de tecnologías de navegación asistida, de las que hablaremos en breve) y también personas con movilidad reducida o problemas de movilidad en general. Y no sólo estos casos, sino personas sin discapacidad alguna, que encuentran más rápido y eficiente el uso del teclado para muchas tareas.

Sin entrar en muchos detalles técnicos, en aras de la brevedad prometida, les comento que algunos de los ejemplos alternativos de botones mencionados más arriba, o no reciben el foco del teclado cuando presionamos la tecla Tabpara iterar por los elementos interactivos de una página, o si lo reciben (como es el caso del segundo tag <a>) no pueden ser activados de la misma manera que son activados los botones normales. Tampoco todos obedecen a las mismas reglas que un botón cuando éste es deshabilitado con el atributo disabled. Para más información sobre los detalles en qué difieren estos elementos con los botones, y sus implicaciones, les sugiero este artículo (en inglés), y otros muchos que pueden encontrar sobre el tema.

Este ejemplo de botones vs. enlaces es sólo uno de muchos otros ejemplos similares, cuyo factor común está en que nosotros los desarrolladores y diseñadores descuidamos el uso de tecnología nativa de la plataforma, sólo para lograr un resultado visual estético. Resulta que hoy podemos hacer que los botones <button> parezcan visualmente un enlace, via CSS, sin necesidad de ir en contra de la accesibilidad nativa de la plataforma.

¿Qué es la navegación asistida?

Ya mencionamos más arriba que el teclado es la vía principal mediante la cual las personas con visibilidad reducida pueden hacer uso de las páginas web. Piénsalo, si no puedes ver muy bien, o no ves nada, ¿para qué te sirve el cursor del mouse en la pantalla?

Por el contrario, mediante el teclado, estas personas pueden ir moviendo el foco entre los distintos elementos interactivos que tiene la página. Pero esto por sí solo no es suficiente. Porque igual si no puedes ver muy bien, o no ves nada, ¿para qué te sirve ir moviendo el foco con el teclado?

Screen readers

Resulta que estos usuarios también hacen uso de lo que se conoce como screen readers, o lectores de pantallas. Es un sistema que, en conjunto con la navegación via teclado, pueden hablarle a la persona que está haciendo uso de una página web y contarle lo que está pasando en ella, en qué elemento está posicionado en cada momento, y cuál es el rol o función de este elemento (veremos más sobre estos roles más adelante). Estos screen readers son muchas veces parte integral de los sistemas operativos modernos, aunque también existen software de terceros que pueden ser instalados. Apple por ejemplo incorpora VoiceOver en todos sus sistemas operativos, y Microsoft Windows por su parte viene con Narrator. También existen por supuesto opciones para Linux.

Sin embargo, para que estas tecnologías sean efectivas, nosotros los desarrolladores y diseñadores tenemos que hacer un uso adecuado de la plataforma. El primer paso es tratar de usar los elementos nativos semánticos de HTML lo más posible. El caso de botones vs. enlaces que vimos anteriormente es uno de muchos ejemplos en este sentido.

Sin embargo, no siempre es posible limitarse a los componentes nativos de HTML. En ocasiones las interfaces de usuario modernas exigen componentes y controles un tanto más complejos, o visualmente diferentes, por razones tanto estéticas como funcionales. Y ahí es donde muchas veces, mayormente por desconocimiento, nos lanzamos a hacer UIs interactivas muy intuitivas para quienes, como la mayoría de nosotros, podemos usarlas visualmente y con el mouse, pero que dejan de tener sentido cuando las trata de interpretar un screen reader.

El screen reader hace el papel de los ojos de las personas débiles visuales, pero lo hace interpretando la semántica de los elementos en la página (el código HTML) y no la apariencia visual. Por ende, si creamos un menú desplegable tipo dropdown para usar en lugar de un <select>nativo, por ejemplo, este screen reader no puede inferir del HTML y CSS solamente, que este <div>aquí y este <button>allá, de conjunto hacen el papel de lo que comúnmente se conoce como un dropdown menu o dropdown select.

Entonces ¿qué hacemos? Aquí es donde viene a nuestro rescate lo que se conoce como ARIA roles.

ARIA roles y WAI-ARIA

No se asusten con todas estas siglas. WAI significa Web Accessibility Initiative. Es una iniciativa de los organismos que rigen los estándares web por mejorar la capacidad de las tecnologías web para ser accesibles. Y WAI-ARIA, que significa Accessible Rich Internet Applications, es una especificación técnica que surgió a partir de la mencionada iniciativa, para darle forma concreta a las mejoras que la web necesitaba en su momento para ser más accesible.

En concreto, esta especificación técnica nos provee con herramientas (en forma mayormente de nuevos atributos HTML) que, al aplicarlas a los elementos de una página web de manera correcta, le añaden al HTML mucha de la semántica que no tienen originalmente. La ventaja es que esta suerte de marcadores semánticos no nos atan a tener que usar determinados controles nativos, que muchas veces dejan algo que desear, ya sea por su apariencia visual, inconsistencia de funcionalidad entre distintos navegadores, o incluso por deficiencias funcionales que resultarían en experiencias no óptimas.

Ok, pero, y en concreto, ¿cómo se usa todo esto?

¿Recuerdan que hablé más arriba de cómo un screen reader va narrando los distintos elementos que van tomando el foco del teclado, y en particular diciendo el rol de cada elemento? Pues resulta que ARIA introduce un nuevo atributo role que puede tomar uno de muchos valores posibles, que cubren de manera general la mayoría de los tipos de components que usualmente son necesarios en las aplicaciones modernas.

Este nuevo atributo no es el único aspecto que introduce ARIA. También alrededor de estos roles hay toda una serie de atributos cuyos nombres todos comienzan con aria- que cuando se utilizan de conjunto con los distintos roles, hacen que todo tome vida para que las tecnologías de navegación asistidas sean efectivas. Algunos ejemplos de estos atributos son aria-expanded, aria-disabled, aria-labelledby, aria-selected, y muchos otros.

¿Qué sigue?

Toda esta información puede parecer abrumadora, y de hecho lo es. Sobre todo para quienes, como nosotros en Get on Board hasta hace poco, parten de cero, sin haber estado al tanto de nada de esto. Mi recomendación es tomarlo con calma, pero sin dejar de informarse ni descuidar el tema, y poco a poco hacer mejoras. Acá incluyo algunos otros tips concretos:

• Usar librerías open source de componentes en lugar de desarrollar una propia. La mayoría de las librerías open source más populares de componentes web vienen con soporte para accesibilidad out-of-the-box, incluyendo el uso apropiado de todo los que mencionamos más arriba, sin tú tener que hacer nada. Y muchas son muy adaptables a cambiarles la apariencia visual para que encaje con tu branding.
• Hacer una suerte de smoke test con tus aplicaciones web usándolas sólo con el teclado. En particular puedes enfocarte en acciones claves de la plataforma. Si hay algo clave de tu plataforma que no puedes hacer si no es con el mouse, enfócate en eso primero.
• Investiga si ya tienes usuarios con discapacidad interesados y ofréceles beneficios de uso (costos reducidos o uso gratis por un tiempo) a cambio de que te den feedback sobre los pain points al usar tu app. O estar al tanto si feedback al respecto te llega por los canales de soporte.
• Infórmate sobre otras aristas de la accesibilidad no relacionadas con lo que hemos visto en este artículo. Por ejemplo temas de contraste y uso apropiado de colores para personas con daltonismo. También puedes ofrecer guiones en modo texto de cualquier contenido auditivo que tengas, para que las personas con problemas auditivos también puedan consumir dicho contenido.

En este artículo no vamos a entrar en más detalles técnicos pues no tendríamos para cuando acabar. Nuestro principal objetivo aquí es, sobre todo, crear conciencia sobre estos temas, llamar la atención sobre su importancia, apuntar hacia las tecnologías clave que dan vida a la accesibilidad en la Web, y que -a partir de aquí- puedan buscar más información. Hay muchos artículos y documentación técnica al respecto.

Lamentablemente la mayoría de la información está en inglés. Parte de la motivación de escribir este artículo fue para aportar a la conversación sobre estos temas en las comunidades de desarrollo y diseño de habla hispana. En Get on Board estamos hoy día poniendo la accesibilidad en primer plano, en nuestro esfuerzo por mejorar la plataforma, y siendo el mundo TI de Latinoamérica nuestra principal audiencia, no podíamos dejar de compartir la experiencia. De seguro vendrán más artículos en este blog donde, ya habiendo introducido el tema, entraremos en más detalles técnicos.

------

Escrito por: Ernesto García