Barreras de accesibilidad - Drag and drop

Cada vez es más frecuente la funcionalidad de “drag and drop” (arrastrar y soltar) en todo tipo de páginas. En ocasiones sí que es una forma muy útil de solucionar acciones complicadas en páginas complicadas, pero otras veces se utiliza por moda, parece que la página queda más actual aplicando esta función.

Esta función puede provocar tanto problemas de usabilidad como de accesiblidad. Hay usuarios que no están acostumbrados a su uso, y el diseñador se ve a menudo tras pruebas de usuario, a añadir muchas explicaciones en la página para que se entienda lo que hay que hacer.

En cuanto a accesibilidad, el problema viene con los usuarios que no utilizan ratón por diferentes motivos, o no pueden, o usan dispositivos que no lo tienen como puede ser un dispositivo móvil. También hay usuarios con movilidad reducida que pueden encontrar muy difíciles determinadas tareas.

Se trataría de tener una forma alternativa de realizar esta misma función. En el editor de este mismo blog que estoy escribiendo, se utiliza por ejemplo la función drag and drop para cambiar el orden de los elementos de página de sitio. Quizás sería tan sencillo como añadir unos links a cada elemento con el enlace “subir” o “bajar elemento”. Las soluciones pueden ser muy diversas.

En el siguiente artículo de quirksmode.org, se describe cómo aplicar un drag and drop que se puede utilizar tanto con ratón como con teclado.

Por otro lado, la Web Accessibility Initiative (WAI) que desarrolla directrices de accesibilidad Web, ha creado las WAI-ARIA (Accessible Rich Internet Applications), unas guías de desarrollo que pretenden hacer más accesibles el contenido de la Web y las aplicaciones Web, especialmente, con contenidos dinámicos y avanzados controles de interfaz de usuario desarrollados con AJAX, HTML, JavaScript y otras tecnologías (eventos y APIs de accesibilidad, por ejemplo).

WAI-ARIA propone nuevas buenas prácticas sobre la función drag and drop. Tal como explican, introducen 2 nuevas propiedades, “grab” y “dropeffect” que permiten a los desarrolladores facilitar el proceso de drag and drop. La propiedad “grab” se aplica a la ruta del objeto que está siendo arrastrado, mientras que “dropeffect” es aplicado al target de destino.

El uso de estas propiedades combinadas con buenas prácticas para dejar que el usuario seleccione la operación de drag adecuada y para asignar la apropiada operación de teclado para realizar la acción, mejora mucho la accesibilidad. Para conocer el uso concreto de estas propiedades os remito directamente al texto original de ARIA, en inglés.

Barreras de accesibilidad - Captcha

Muchos sitios y aplicaciones utilizan en su página de login un captcha (1), a modo de test de seguridad. Se trata de comprobar cuando el usuario que intenta logarse es humano o no. Podría tratarse de un robot haciendo spam, por ejemplo.

Existen diferentes formatos pero habitualmente se necesita “ver” el texto o número que aparece en una imagen distorsionada y teclear a continuación lo que aparece en una caja de texto. Esta verificación es “visual”, con lo que un usuario invidente por ejemplo no lo podría usar. Pero también causaría problemas a alguien con visión baja, a una persona mayor o alguien con problemas con dislexia, o simplemente a alguien con un navegador sólo texto.

En la imagen siguiente aparece una secuencia típica de caracteres “smvm” distorsionados, de forma ondulada.






Lo importante es ofrecer alternativas.

Ficheros de audio
Una manera sería colocar un fichero de audio al lado, para oir el sonido, y siempre que no necesite para ello tener javascript activado. Es decir, se permite elegir entre la validación visual o sonora. Pero este sistema no es muy eficiente y hay robots que tienen éxito con el software de reconocimiento de voz.
Un ejemplo bastante malo al respecto es el que utiliza gmail. Además de necesitar javascript activado, el ruido de fondo es tan intenso que cuesta mucho entender la secuencia de números que dice.

Verificación SMS
Hay quien opta por la verificación mediante SMS, pero presupone que todos tenemos móvil y además los SMS presentan problemas de accesibilidad para invidentes.

Sistema Pregunta-Respuesta
El sistema propone una pregunta que en principio sólo un humano sabe responder. Puede ser tipo matemática, ejemplo ¿2+2?. O puede ser de tipo textual (¿Quién es el presidente de España?). Pero también este sistema genera problemas: deben ser muy fáciles como para que un usuario con problemas cognitivos no tenga problemas, que están relacionados con un idioma y con una cultura a menudo, que generan más de una posible respuesta (escribo una palabra o dos, con artículo o sin…), ortografía.
Otro tipo de preguntas que no suponen conocimiento alguno son del tipo: cuál es la segunda palabra de “Hola, buenos días”. Pero esta frase también tiene que estar muy bien elegida para no generar problemas.

En conclusión, de momento no existe el captcha perfecto, aunque los de tipo pregunta-respuesta son preferibles. Lo ideal sería no tener que usarlos y usar otro tipo de filtros de control de spam.

Enlaces de interés

- Qué dice la Wikipedia
- Qué dice el W3C (en inglés)

(1) Captcha es el acrónimo de Completely Automated Public Turing test to tell Computers and Humans Apart (Prueba de Turing pública y automática para diferenciar a máquinas y humanos).

Accesibilidad en la web 2.0 - Introducción

De forma general, la accesibilidad web supone que todos los usuarios, independientemente de su discapacidad (temporal o no), de su edad, o contexto de uso tecnológico, puedan disponer de los servicios y contenidos de un sitio web.

En referencia a las personas discapacitadas, su acceso a Internet puede ser de forma muy diferente y con distinto nivel de dificultad. Algunos ejemplos serían usuarios con deficiencia visual o ciegos que utilizan lectores de pantalla o magnificadores, usuarios con limitación motriz que utilizan atajos de teclado o dispositivos apuntadores, usuarios con sordera que requieren alternativas textuales a elementos multimedia sonoros, etc.., etc…

Lo cierto es que hay numerosas barreras digitales en todos los sectores, a pesar de que actualmente existen herramientas y técnicas que permiten desarrollar contenidos web accesibles a todos los usuarios, así como mecanismos para detectar los problemas de accesibilidad presentes en un sitio web. Los problemas se derivan de la combinación entre las barreras en la información de los sitios, con las barreras de las aplicaciones de usuario (navegadores, dispositivos multimedia o ayudas técnicas como los lectores de pantalla o reconocedores de voz).

Con la llegada de la Web 2.0 los problemas de accesibilidad de agravan. La publicación en Internet se acelera por multitud de editores particulares que no tienen conocimientos de accesibilidad. Además utilizan herramientas y tecnologías que de entrada no son accesibles, y que generan a su vez aplicaciones (mashups) con contenidos poco accesibles.

Se da la paradoja por tanto, de que aunque la web 2.0 ofrece participación a todos los usuarios en la comunidad virtual, sin embargo añade nuevas barreras a las ya existentes para algunos.

Como complemento, linko una presentación de slideshare.net sobre el tema:

Accesibilidad en la web 2.0

Ver en SlideShare la presentacion. (tags: accesibilidad web)