No hagamos sitios accesibles, hagamos que los browsers brinden accesibilidad.
Published: 2018-08-13 00:03:38

---
title: No hagamos sitios accesibles, hagamos que los browsers brinden accesibilidad.
published: true
description: Idea para lograr accesibilidad en Internet para usuarios que no pueden utilizar *mouse* y teclado.
tags:  
---
La accesibilidad es la oportunidad que tienen las personas de poder utilizar un objeto, visitar un lugar o acceder a un servicio, independientemente de sus capacidades técnicas, cognitivas o físicas.

![Accesibilidad-teclado-motivación](https://thepracticaldev.s3.amazonaws.com/i/gm3q59fmaaw0v3ilhh3n.jpg)

Este concepto también es aplicable en los sitios de Internet. Cuando un sitio que visitamos se acoge de ciertos estándares, brinda contenido HTML rico a sus diferentes etiquetas, proporciona métodos alternativos para el contenido no textual, entre otros; encontramos indicios de accesibilidad en él. 
Tristemente, muchos de los sitios en Internet no poseen una característica tan importante como la accesibilidad.

Este *post* busca validar una idea para brindar accesibilidad a un sector en particular que presenta esta problemática: los usuarios que poseen discapacidades en sus extremidades superiores y no pueden utilizar las herramientas clásicas para la navegación en Internet: un teclado y un *mouse*.
 
Es necesario brindar accesibilidad tomando en cuenta que existen millones de sitios en la web que no fueron construídos pensando en serlo, y que además no se van a cambiar para que empiecen a serlo ahora. Además, hay muchos más que están en camino y tampoco serán accesibles. ¡No podemos cambiar todos los sitios viejos y no podemos influír en el desarrollo de todos los nuevos!

Ahora, si consideramos que todos los sitios que visitamos en Internet son alcanzables gracias a herramientas que permiten llegar a ellos; los *browsers*, entonces, ¿no se debería centralizar esfuerzos en los *browsers* para alcanzar la accesibilidad a los sitios?

¡Hagamos Internet accesible tal y como está ahora mismo! Sin enfocarnos en alcanzar accesibilidad en sitios **individuales**, sino más bien que sea la forma **general** en la que los navegamos la que se convierta en accesible!

##Idea general

La idea para brindar accesibilidad está basada en la creación de **áreas de concentración en la pantalla (SCA)** que permitan que las instrucciones brindadas al *browser* sean más precisas. Esto, aunado a una navegación a través de la voz; hará que el público meta de este sistema pueda olvidarse de teclado y *mouse* cuando naveguen en Internet.

Las SCAs son delimitaciones de la pantalla del monitor del usuario. Estas se formarán a través de líneas que al juntarse generen regiones debidamente identificadas para que el usuario elija la región con la que necesita interactuar. Veamos un ejemplo:

![Accesibilidad-youtube-Introduciendo]
(https://thepracticaldev.s3.amazonaws.com/i/xr3emuy0cmssz0s2ibk5.PNG)

A su vez, si el usuario requiere que la región elegida sea aún más granulada; podrá hacerlo tantas veces como sea posible en el monitor en uso. 

![Accesibilidad-youtube-Granularidad]
(https://thepracticaldev.s3.amazonaws.com/i/4cre62tku2k3dt0extwx.PNG)

Note que este sistema evitará ambigüedad en comparación a métodos que solo permitan dirigir instrucciones de voz sin ningún otro apoyo visual al usuario. Por ejemplo: en la caja de comentarios de YouTube, imagine que su instrucción es dar *like* a un comentario en específico. En la siguiente imagen, si la instrucción con la que se debe realizar la tarea es "*like* the comment", ¿cuál usuario recibiría ese *like*?.

![Accesibilidad-youtube-ejemplo]
(https://thepracticaldev.s3.amazonaws.com/i/tte2llwjjcbx57ntxy2p.PNG)

A falta de un procesamiento de lenguaje natural lo suficientemente sólido para dar una instrucción precisa sobre cuál comentario debe recibir el *like*, la instrucción puede tornarse en ambigua, o inclusive desgastante, al entrar un proceso iterativo sobre los comentarios hasta dar con el deseado.

Los comandos de voz para la navegación pueden ser tan extensos como se pueda imaginar. Pero los comandos para trabajar directamente con las SCAs serán como los siguientes:

- Init SCA: para iniciar el sistema de navegación accesible.
- Stop SCA: para salir del sistema de navegación accesible.
- Go to {id}: es el comando mediante el cuál el usuario se podrá movilizar hacia cualquier SCA de la pantalla.
- Do SCA: creará nuevas áreas de concentración dentro del área de concentración actual.
- Undo SCA: borrará las áreas de concentración actuales. Será como devolverse al área de concentración anterior.
- Click: emulará un click del *mouse* en el elemento en donde esté el cursor.
- Find {nombre del elemento}: ubicará dentro del SCA el elemento que tenga relación con el comando dicho por el usuario. Si hay más de una posibilidad: el sistema resaltará los elementos uno a uno hasta que el usuario use la instrucción de voz Click, o bien; se acaben los candidatos.
- Stop dictation: para que un *input* de tipo texto deje de recibir lo que el usuario le está dictando.

##Caso de uso para los SCAs
A continuación se presenta un ejemplo del uso de SCA en un sitio que la mayoría usamos: el correo electrónico. Veremos cómo sería para un usuario meta el realizar acciones básicas como redactar un nuevo correo y enviarlo a uno de sus contactos.

1- Primero; el usuario activará el sistema de navegación.
   *Instrucción*: Init SCA

![Accesibilidad-Init-CasoUsoUno]
(https://thepracticaldev.s3.amazonaws.com/i/bt0gxt1cpcuo9l65go7b.PNG)

2- El usuario irá al SCA en donde está la opción de redactar un correo.
   *Instrucción*: Go to One

![Accesibilidad-Init-CasoUsoDos]
(https://thepracticaldev.s3.amazonaws.com/i/4rx2750kijv7p0u5g0w2.PNG)

3- El usuario dirá el elemento con el que quiere interactuar. Como el objetivo aquí es redactar un correo, dirá "redactar".
    *Instrucción*: Find Redactar

![Accesibilidad-Init-CasoUsoCuatro]
(https://thepracticaldev.s3.amazonaws.com/i/2d1ppol9un4mjohrbbg2.PNG)

   Como no hay ambigüedad; el sistema hará click inmediatemente en redactar.

4- El usuario ahora debe posicionarse en el SCA adecuado para redactar el correo.
    *Instrucción*: Go to Two

![Accesibilidad-Init-CasoUsoCuatro]
(https://thepracticaldev.s3.amazonaws.com/i/2p2g3lc4pyy7sbut7l2h.PNG)

5- El usuario llenará el encabezado del correo. Primero llenará los destinatarios.
    *Instrucción*: Find Destinatarios

6- Como no hay ambigüedad, el sistema encontrará el *input* de destinatarios y hará click sobre él. Entonces; como es un *input* de texto: el sistema se preparará para anotar los destinatarios del correo. Cuando el usuario haya dado sus destinatarios, dará la *Instrucción*: Stop dictation para dejar de dictar al sistema.

7- Para llenar el asunto del correo se hacen pasos análogos a 5 y 6.

8- Ahora, lo siguiente a llenar es el cuerpo del correo. Notemos que para hacer esto el usuario no está posicionado en el SCA indicado. Entonces, el usuario debe ir al SCA que le permitirá empezar a redactar ese correo.

![Accesibilidad-Init-CasoUsoCuatro]
(https://thepracticaldev.s3.amazonaws.com/i/q522h5l9sp6uecaqhcl4.PNG)

9- Para llenar el cuerpo del correo se hacen pasos análogos a 5 y 6.

10- Finalmente; el usuario enviará el correo. Para hacer esto usará la *Instrucción*: Find Enviar. Como solo hay un *input* de enviar: se hará click de una vez al botón y se enviará el correo que redactamos.

Casos de uso como este son los que permiten observar que aplicaciones que combinen tanto comandos de voz, como apoyo visual en pantalla; puedan ser una aproximación a que los *browsers* logren que los sitios web sean accesibles. Los comandos para SCA son amigables y con pocas palabras en ellos, esto permitirá que los usuarios no tengan que esforzarse de más para poder navegar. Además; los SCA son flexibles de acuerdo al tamaño de las pantallas; lo que hace que se pueda extender su función a muchos dispositivos.

##¿Qué sigue?

- Mejora continua de los comandos de voz: los comandos pueden seguir creciendo con nuevos *releases*. Una primera fase puede dejar muchos vacíos sobre lo que el público meta aún necesita, así que futuras mejoras vendrían a cubrir esos vacíos.
- Áreas de concentración inteligentes: las SCA pueden hacer un pre-análisis de cada sitio para construirse solo en las zonas donde se presenten interacciones con el usuario. Veamos un ejemplo de este aprovechamiento de áreas:

![Accesibilidad-Init-MejoraUno]
(https://thepracticaldev.s3.amazonaws.com/i/z45k8q9w80n7u42hs81v.PNG)

- También, si vemos el caso de uso analizado; el usuario pudo haber dado una instrucción que lo enfocara solamente en la pantalla de Redactar. Así, no hubiera sido necesario el paso 8, dado que las *Instrucciones* Find posicionarían al usuario en el cuerpo del correo sin necesidad de cambiarse de SCA.

![Accesibilidad-Init-MejoraDos]
(https://thepracticaldev.s3.amazonaws.com/i/5r2ntd7zw9dtqc3cw5yo.PNG)

- Mapas de calor: SCA se puede integrar con Google Analitics para brindar reportes sobre las zonas más frecuentadas por los usuarios en los sitios web. Así; se puede sugerir al usuario las siguientes acciones a realizar a través de predicciones sobre el flujo que está llevando a cabo.


##¿Cómo me puedes ayudar?
Si tienes dudas, oportunidades de mejora, comentarios, o si conoces personas a quienes le podría ser útil esta idea, por favor contactarme al correo jeanczm@gmail.com