Eyes-free y Android 4, una buena combinación

La aparición de Android 4, por parte de Google ha traído mejoras en la accesibilidad para los dispositivos Android. Muchas de estas mejoras vienen orientadas para dar solución a las necesidades de las personas con discapacidad visual. Muchas de estas mejoras se originan en el proyecto Eyes-free encargados del primer lector de pantallas para Android, más conocido como Talkback.

Eyes-free Talkback, el lector de pantallas de este proyecto, nos permite utilizar una de las nuevas mejoras de la capa de accesibilidad de Android 4. Una persona ciega puede arrastrar el dedo por la pantalla táctil de su dispositivo para explorar los controles que allí aparecen.

Talkback suele venir instalado en la mayoría de distribuciones Android que existen en el mercado ya que los principales fabricantes incluyen en sus teléfonos el paquete básico de accesibilidad para Android 4.

Aunque Talkback nos permita arrastrar el dedo para explorar la pantalla realizar ciertas operaciones básicas se vuelve una actividad compleja para el usuario ciego. Una de esas operaciones es la de introducir texto a través del teclado virtual en pantalla. Por esa razón los miembros del proyecto Eyes-free han desarrollado su propio teclado virtual conocido en el market de Android, la tienda de aplicaciones para esta plataforma, como Eyes-free keyboard.

Eyes-free keyboard ofrece, entre otras cosas, un teclado virtual en pantalla compatible con Talkback. Además permite un modo de navegación parecido al que se usa en VoiceOver para iOS, el lector de pantallas para iPhone e iPad, consistente en movimientos de arrastre corto (flicks) en vertical y horizontal para mover el foco de Talkback y explorar de forma más ordenada la pantalla.

Mejoras sustanciales pero trabajo por hacer

Las mejoras en la capa de accesibilidad para esta versión de Android son notables pero aún faltan características básicas para garantizar una accesibilidad suficiente para esta plataforma. Por ejemplo, para que los controles del interfaz de una aplicación sean reconocidos por la capa de accesibilidad y sus productos de apoyo es necesario que el desarrollador incluya una línea de código por cada control en su proyecto. Esto ha mejorado notablemente ya que sólo es necesario una línea de código por cada control pero el usuario con discapacidad sigue dependiendo de la generosidad y la concienciación de los desarrolladores para que incluyan esas pocas líneas de código.

Otro problema importante es la ejecución errática de los diferentes servicios del proyecto Eyes-free en según qué modelos. Se sabe que el Samsung Galaxy nexus funciona correctamente con el software vinculado al proyecto Eyes-free pero otros dispositivos de este y otros fabricantes no funcionan de la forma esperada. Errores en el reconocimiento de flicks, arrastres y otros gestos son comunes en otros dispositivos; problemas en la síntesis a la hora de pausar la verbalización o retomar la misma y problemas con las teclas de navegación Android (Back, Home, search, etc) en los dispositivos sin teclas físicas son problemas presentes en varios dispositivos que utilizan esta versión de Android.

Pero los problemas más preocupantes son: un usuario con discapacidad visual no tiene un método seguro para activar y desactivar el lector de pantallas o el magnificador ya que el control de gestos incluido por eyes-free no funciona del todo bien y la potencial pérdida de información de un usuario con discapacidad visual a la hora de explorar un interfaz. El usuario está obligado a arrastrar el dedo por toda la pantalla sin garantía de que todo lo que encuentre sea reconocible por el lector de pantallas. El sistema de navegación por gestos ofrecido por Eyes-free keyboard no funciona del todo bien y, en algunas aplicaciones, salta controles y etiquetas de contenido. Un resumen de este problema se puede resumir en la siguiente frase: Una plataforma que obliga a un usuario ciego a arrastrar el dedo por la pantalla durante más de 20 segundos para encontrar el botón aceptar es un sistema que necesita muchas mejoras.

Eyes-free incluye un pequeño tutorial básico de uso pero se limita a las funciones básicas de Talkback. Además aún no se ha incluido soporte para castellano.

Con todo esto podemos decir que Android 4 puede ser utilizado por personas con discapacidad visual con mucha experiencia en el manejo de dispositivos móviles y sus productos de apoyo y para aquellos usuarios con discapacidad con mucha paciencia. Esperemos que estos productos de apoyo y la capa de accesibilidad de Android sigan mejorando para garantizar una experiencia de usuario completamente satisfactoria para los usuarios con y sin discapacidad.

Ventajas y peligros de la accesibilidad

La Web se ha convertido en el medio donde el conocimiento de la humanidad se comparte de forma más global, accesible y efectiva. Muchos defendemos la neutralidad de Internet pero hay otros peligros que rodean a la Web.

La accesibilidad en la Web

En el principio la Web era principalmente texto y enlaces. Esto limitaba los problemas de accesibilidad a ciertos perfiles de discapacidad fácilmente superables con un equipo informático adaptado que permitiese el acceso al texto. Con el tiempo aparecieron imágenes, formularios y otros elementos visuales para proporcionar mayor vistosidad al contenido. Posteriormente aparecieron vídeos, sonido, contenidos dinámicos y tecnologías externas al propio HTML como Javascript, Flash y Applets Java. Todas estas mejoras beneficiaron a la mayoría de usuarios de Internet pero provocó la aparición de multitud de barreras de accesibilidad.

El W3C observó que existía un total desconocimiento de las necesidades de las personas con discapacidad en la Web y que no existían criterios que permitiesen a los creadores de contenidos satisfacer estas necesidades. De todo esto surge la WAI (Web Accessibility Initiative) que busca proporcionar criterios y técnicas para que la Web sea accesible y evitar la tendencia de que por cada nueva tecnología o característica que aparezca en la Web se creen nuevas barreras de accesibilidad.

Aunque esta tendencia de nuevas barreras por cada nueva tecnología aún persiste en nuestros días hay que reconocer que gracias a la WAI, los usuarios y la progresiva concienciación global de los usuarios de Internet hoy podemos disfrutar de una Web más inclusiva, aunque aún no es suficiente.

Las pautas y técnicas ofrecidas por la WAI permitió a los desarrolladores de productos de apoyo definir un modelo más claro sobre cómo acceder a los contenidos de una página web y cómo acceder a los servicios y funciones ofrecidos en ella. También permitió avanzar en formatos y estándares y definir marcos legales para comprender el concepto de una página web accesible para que legisladores, diseñadores y fabricantes de tecnología tuviesen un mismo punto de partida.

La realidad de la accesibilidad legal

Muchos gobiernos han definido y están definiendo hoy día sus marcos legales para la Web a partir de los criterios indicados por la WAI. Aunque esto sea satisfactorio en muchos casos es cierto que el utilizar los criterios definidos por la WAI no garantizan una página web accesible ya que, como todo en la vida, cualquier elemento tiene un uso correcto y muchos incorrectos. Además, aunque la WAI ha ido actualizando sus criterios y técnicas las leyes suelen ir siempre por detrás por lo que encontramos que muchas leyes definen requisitos de accesibilidad para la Web con criterios concebidos hace más de 14 años. Pero lo importante de estas leyes es que apoyan los estándares por encima de soluciones específicas y describen las necesidades de diversos perfiles de discapacidad para acceder a los distintos contenidos definiendo el concepto de web accesible para todos.

Todo esto hace pensar que la ley es insuficiente para garantizar la accesibilidad real en la Web. Pero debemos entender que las leyes son necesarias como incentivo para los creadores de contenidos que hacen bien su trabajo y como herramienta para obligar a empresas y organismos para crear páginas de forma responsable.

Guetos digitales

Las empresas, los organismos, los diseñadores y los responsables de muchos sitios web al conocer el hecho de que sus páginas web no son accesibles optan por crear un sitio web alternativo al que llaman versión accesible. Un sitio web con pocas o ninguna imagen, con pocas o ninguna función de la llamada Web 2.0 y que suele ser actualizada más tarde que la versión oficial o, en algunos casos, olvidada por los propios creadores. Esta versión accesible, creada por aquellos que confunden la accesibilidad de la Web por algo visualmente feo, dedicado a aquellos que la sociedad ha olvidado por sus necesidades especiales y que, por tanto, es algo que también se puede olvidar. La versión accesible de un sitio web es un lugar virtual donde confinar a aquellos que no cumplen esos requisitos físicos, sensoriales o cognitivos necesarios para acceder al sitio oficial. Aquellos que deben ser ovlidados en un patio trasero para que no molesten a los que visitan al sitio oficial y, además, deben estar agradecidos por ofrecerles este gueto donde acceder a las migajas de contenidos y servicios de esa página web.

Esta versión accesible es confundida por estos creadores con el concepto de alternativa. En lugar de ofrecer una alternativa a las imágenes, sonidos y tecnologías no compatibles con la accesibilidad se opta por dar un camino alternativo al contenido, un camino más oscuro, más feo, más limitado y más discriminatorio.

Soluciones específicas

Algunos fabricantes y desarrolladores relacionados con la accesibilidad han creado productos de apoyo y servicios específicos para satisfacer las necesidades de unos pocos perfiles de discapacidad para proporcionar un método de comunicación entre el usuario y el dispositivo compatible con las necesidades del usuario.

En el caso de barreras de accesibilidad al hardware o al software, como pueden ser lectores de pantalla, magnificadores, teclados adaptados o virtuales, reconocedores del habla o apuntadores; su objetivo es dar un acceso general a los contenidos y funciones de un dispositivo informático. Estas soluciones, en muchos casos, son tan específicas para el perfil de discapacidad que su uso provoca la aparición de barreras de accesibilidad para aquellas personas que no posean dicho perfil de discapacidad. Por ejemplo existen lectores de pantalla que desactivan el funcionamiento habitual del teclado o ratón, muchas personas sin discapacidad visual se sienten incapaces de utilizar un equipo informático cuya pantalla muestra una porción mínima de la pantalla de forma aumentada.

La Web se ha entendido como un nuevo medio de actividad virtual. Esto ha provocado que algunos fabricantes hayan decidido ignorar la presencia de estos productos de apoyo para el hardware y el software y, en su lugar, crear aplicaciones web o navegadores web que satisfagan las necesidades de algunos perfiles de discapacidad. Ejemplos como navegadores web para niños autistas, como ZacBrowser, o personas ciegas como el IBM home page reader han demostrado ser soluciones que dan un acceso parcial a los contenidos y funciones que ofrece una web completa.

Otras soluciones como Web anywhere, ReadSpeak o Inclusite consisten en una aplicación Java, Flash u otra tecnología similar que proporcionan un método de acceso alternativo a los contenidos y funcionalidades de una web.

En el caso de Readspeak se confunde accesibilidad con mejor experiencia del usuario ya que el servicio consiste en una función para que el navegador nos lea la página web que estamos visitando por si no nos apetece hacerlo ya que una persona ciega que haya accedido a esa página de forma autónoma no necesita dicho servicio ya que disfruta de la voz ofrecida por su lector de pantallas.

Pero en el caso de Web anywhere e Inclusite su función va más allá ya que intentan sustituir al producto de apoyo habitual del usuario ya que, en muchos casos, estos servicios son incompatibles con algunos lectores de pantalla o sistemas de reconocimiento del habla dejando al usuario con discapacidad en un limbo de indefensión en el momento de pasar al uso de su producto de apoyo al de estos servicios ya que, aunque estos servicios satisfagan las necesidades de algunos usuarios no contemplan una serie de problemas básicos:

  • Si el usuario desactiva su producto de apoyo para acceder al servicio de WebAnywhere o Inclusite aparece el problema de que el usuario está utilizando un equipo informático sin adaptación y necesita abrir un navegador web y acceder a la página de WebAnywhere o Inclusite. Estas operaciones pueden ser realizadas de forma autónoma por aquellos usuarios que conozcan y hayan personalizado su sistema, como puede suceder en el caso de personas ciegas. Pero es totalmente imposible para aquellos usuarios incapaces de acceder al teclado y al ratón. Es como si a una persona en silla de ruedas se le proporciona una rampa de acceso a un edificio pero, a cambio, se la obliga a acceder al edificio avandonando por unos instantes su silla de ruedas para sentarse en otra nueva y específica para recorrer dicho edificio. Una persona con movilidad en sus brazos puede intentar realizar la operación pero otras personas con menor movilidad serán incapaces de hacerlo de forma autónoma.
  • Estos servicios, como es el caso de Inclusite, suelen dar acceso sólo a un número muy concreto de sitios web y funciones de dichos sitios. Esto provoca que los usuarios de estos servicios no puedan salir de las páginas web compatibles creando un nuevo concepto de gueto digital. Ahora los discapacitados no se quedan en el patio trasero de algunos edificios sino que se les invita a quedarse en edificios diseñados específicamente para ellos.
  • Estos servicios, como sucede en WebAnywhere, no dan acceso completo a las funciones de un sitio web sino que se limitan a ofrecer algunos de ellos que si resultan compatibles con el modelo de uso definido por ellos. Es como si al usuario se le ofreciese una mesa llena de multitud de alimentos pero se le atasen las manos con cuerdas de una determinada medida para que sólo tuviese acceso a algunos de dichos platos.
  • Estos servicios se diseñan para satisfacer, como es el caso de Inclusite, las necesidades de unos perfiles de discapacidad concretos provocando la aparición de barreras de accesibilidad para otros perfiles. Por ejemplo, Inclusite da sólo soporte a personas ciegas que utilicen síntesis de voz pero olvida a aquellas que utilicen dispositivos de lectura braille dejando fuera a personas sordociegas.
  • Estos servicios utilizan tecnologías que no están disponibles para todas las plataformas y usuarios. Por ejemplo, Inclusite actualmente utiliza tecnología Flash por lo que el usuario debe instalar dicho soporte. Si el usuario utiliza un smartphone o un tablet esta operación es imposible pero si utiliza OSX, Linux o Windows se puede encontrar con un instalador poco o nada accesible.

Estos servicios proporcionan un método de acceso más que suficiente para algunas personas ya que satisfacen sus necesidades por completo pero no solucionan las necesidades de todos los usuarios.

Todos estos servicios, actualmente, deben aceptarse como una alternativa opcional para algunas personas con discapacidad. En ningún caso deben presentarse como soluciones completas y reales para conseguir una web accesible.

Un sitio web accesible

Una web accesible es aquella que presenta sus contenidos y funciones utilizando los estándares y siguiendo las pautas de accesibilidad de forma apropiada proporcionando alternativas accesibles para aquellos contenidos y funciones que presenten barreras de acceso para algunos perfiles de discapacidad. Pueden incorporar alguno de los servicios anteriores como valor añadido pero nunca y bajo ningún concepto deben utilizarse como garantía de que el sitio web es accesible tan sólo por incorporar dichos servicios.

Una accesibilidad a la web mal entendida puede crear muchas más barreras de acceso. Debemos apostar por el diseño para todos en lugar del diseño para algunos, lgunos que puedan ver, algunos que puedan usar el teclado, algunos que puedan usar una tecnología o algunos que tengan una determinada discapacidad.

Un sitio web accesible debe ser aquel que presente sus contenidos de forma comprensible proporcionando mecanismos para acceder al significado de dichos contenidos a través del canal más apropiado para cada persona, textos para ciegos, imágenes para sordos, pictogramas y aclaraciones dinámicas para personas mayores y personas con discapacidad cognitiva, uso de teclado o ratón a voluntad del usuario y respeto de los estándares tecnológicos. Pero también debe ofrecer una estructura de navegación que permita una experiencia de usuario satisfactoria.

Esto se puede conseguir incorporando el concepto de accesibilidad al principio del proyecto. No debemos conformarnos con parches, sean estos versiones alternativas, feas y limitadas de un sitio oficial o servicios específicos para acceder a sitios concretos y que son incompatibles con otras soluciones de la accesibilidad.

Las personas con o sin discapacidad no queremos estar en guetos digitales o depender de otras personas para superar barreras de accesibilidad. Internet debe ser de todos, por todos y para todos.

Manifiesto de petición de mejora de accesibilidad para los productos Apple

Los usuarios con y sin discapacidad que utilizamos productos Apple manifestamos lo siguiente:

reconocemos la gran labor realizada por Apple al incluir productos de apoyo para varios perfiles de discapacidad en sus productos. Gracias a esto muchas personas podemos acceder a multitud de servicios y contenidos en la misma fecha, de la misma forma y pagando lo mismo que personas sin discapacidad. Sin embargo, el gran potencial de este esfuerzo hecho por Apple podría crecer más. es necesario un mayor compromiso por parte de la compañía para alcanzar una accesibilidad plena en sus productos y servicios, ya que las personas con discapacidad aún encuentran problemas para acceder libremente a ellos. Por todo esto solicitamos:

  • Apple debe dar más importancia a la accesibilidad de las aplicaciones de la App store y la Mac app store ,ya que existen muchos desarrolladores que desconocen o no prestan atención a las necesidades de las personas con discapacidad. Es muy importante dar mayor relevancia a los temas de diseño accesible y herramientas para la mejora de accesibilidad dentro de la documentación, guías de diseño y herramientas de desarrollo proporcionadas por Apple para sus desarrolladores, pues, actualmente, la documentación y herramientas para la accesibilidad ocupan espacios de menor importancia y muchos desarrolladores desconocen la existencia de estos elementos.
  • Apple debe premiar el esfuerzo de los desarrolladores que hagan sus aplicaciones accesibles dándoles mayor visibilidad en las tiendas de aplicaciones. Para ello vemos necesario la creación de una distinción o nueva categoría de aplicaciones para la App store y la Mac app store en que se agruparán las aplicaciones donde la accesibilidad esté garantizada. Para conseguir esto, además de crear el distintivo o la correspondiente categoría en las tiendas de aplicaciones, Apple debe definir procedimientos para evaluar la accesibilidad de las aplicaciones durante el proceso de revisión previo a la publicación de cada aplicación.
  • Apple debe integrar la accesibilidad en su plantilla de trabajadores. Es necesario una mayor formación y concienciación acerca de la accesibilidad y la discapacidad para los empleados de Apple, a fin de que puedan ayudar de forma más efectiva a este grupo de usuarios a sacar más provecho de sus productos y servicios.
  • En virtud de que el español es un idioma cuyo número de hablantes es muy alto a nivel global, y que cada vez más personas de países hispanohablantes adquieren y usan productos de Apple, vemos vital la extensión del soporte de accessibility@apple.com al español, a fin de ampliar la retroalimentación entre Apple y sus usuarios, pues dicha retroalimentación ha resultado ser de gran importancia para la compañía.

Si deseas añadirte a este manifiesto, te invitamos a descargarlo de aquí, publicar el mismo en tu blog o cualquier medio que consideres oportuno, y también unirte a la petición de firmas que lanzaremos para dirigir esta carta a Apple.

Users with and without disabilities who use Apple products declare the following:

We recognize the great work done by Apple in order to include support for multiple disability profiles for their products. With this, many people can access a big variety of services and content on the same date, in the same way and paying the same as people without disabilities. However, the great potential of this effort made by Apple could grow more. A major commitment by the company is required to achieve full accessibility in their products and services, as people with disabilities still face problems accessing them freely. For all this we request:

  • Apple should give more importance to the accessibility of applications from the App store and the Mac app store, since there are many developers who ignore or do not pay attention to the needs of people with disabilities. It is very important to raise the presence of accessible design issues and tools for improving accessibility within the documentation, design guidelines and development tools provided by Apple to its developers, for at this time, , documentation and accessibility tools fill in positions of minor importance, and many developers are unaware of these elements.
  • Apple should reward the efforts of developers who create accessible applications by giving them a greater visibility within the application stores. for this a new category or distinction for applications should be created in the Mac App store and app store, where applications in which accessibility is assured are classified. To achieve this, besides creating the distinctive character or the corresponding category in the App Store, Apple should define procedures for evaluating the applications accessibility during the review process prior to the publishing of each application.
  • Apple should integrate accessibility within their staff. Employees at Apple should have more training and awareness about accessibility and disabilities , so they can more effectively help this group of users to take more advantage of Apple’s products and services.
  • According to the fact that Spanish is a language whose speakers number is high worldwide, and more people from spanish speaking countries acquire and use Apple products, we find necessary that the support of accesibility@apple.com extends into Spanish in order to improve the feedback between Apple and its users, for this feedback has proved to be very important for the company.

If you want to join to this declaration, we encourage you to download it from here, publish it in your blog or any other place which you find relevant, as well as add your sign to the petition we have launched in order to address this letter to Apple.

Sigue Programar a ciegas desde tu iPhone

Los dispositivos móviles son, cada vez más, el dispositivo principal para acceder a webs y portales de conocimiento.

Tyflos Accessible Software, el sello de desarrollo de software que está detrás de este portal, ha desarrollado una aplicación para iPhone y iPod touch para poder acceder a los artículos publicados en este blog. De esta forma podrás seguir las noticias y artículos de forma más cómoda.

Puedes descargar, de forma gratuita, la aplicación Programar a ciegas RSS desde la App store utilizando este enlace: Programar a ciegas RSS en la App store

Personalización de teclado en OSX

El sistema operativo de Apple para sus equipos de sobremesa, más conocido como OSX, incluye una serie de funciones para personalizar el comportamiento de nuestro equipo. Entre dichas funciones destaca la de poder asignar atajos de teclado para controlar ciertos comportamientos o ejecutar ciertas aplicaciones.

Para poder acceder a esta función debemos ir a las preferencias de sistema y buscar el elemento teclado. Lo podréis encontrar en la categoría de hardware.

Al acceder a este elemento del panel de preferencias de sistema encontraremos dos pestañas: teclado y funciones rápidas de teclado. Es en esta última pestaña donde encontraremos esta funcionalidad para personalizar atajos de teclado.

Solucionando problemas del teclado español

OSX por defecto, y aunque seleccionemos un idioma distinto, define los atajos de teclado para el mapa de teclas del uso norteamericano. Funciones como buscar (Comando+f) o cerrar una ventana (Comando+w) hacen referencia a los nombres en inglés de estas funciones.

No es recomendable personalizar todas las funciones que se nos ocurra ya que esto provocará confusión si utilizamos otro equipo con OSX o alguien utiliza nuestro equipo.

Pero si es recomendable cambiar ciertas combinaciones de teclado que son conflictivas para el mapa de teclado español. Un ejemplo de ello es la combinación para cambiar de ventana (Comando+`) esta combinación, al tratarse de una tecla de acento, `(acento circunflejo), puede no funcionar si el foco de teclado se encuentra en un área de texto o similar.

Vamos a cambiar dicha combinación a una más cómoda para el teclado español, por ejemplo, Comando+< (Comando + menor que).

En el cuadro de funciones rápidas de teclado encontraremos una tabla de categorías y una tabla de asociaciones de teclas. En la tabla de categorías debemos seleccionar la categoría teclado y texto. A continuación debemos buscar en la tabla de combinaciones una llamada Centrar en la siguiente ventana cuya combinación estará asignada a comando+`.

Los usuarios de VoiceOver encontrarán que estas tablas tienen varias columnas. La columna más a la izquierda permite activar o desactivar el servicio o el atajo de teclado, dependiendo en la categoría en la que nos encontremos, la columna a continuación indica el nombre del atajo o combinación y la siguiente columna contiene las teclas que han de pulsarse para activar el atajo de teclado.

Una vez hayamos encontrado la combinación que queremos modificar podemos cambiarla simplemente haciendo click sobre ella. Los usuarios de VoiceOver deben pulsar la tecla enter para poder editar el campo y desactivar el modo de navegación rápida pulsando las teclas de flecha izquierda y flecha derecha a la vez.

Añadiendo nuestras propias funciones

Podemos añadir nuevas funciones y atajos de teclado para nuestro sistema desde este mismo panel de preferencias. El proceso es muy sencillo.

En el panel de funciones rápidas de teclado debemos ir a la categoría aplicaciones. Una vez seleccionada esta categoría buscaremos un botón llamado Añadir una función rápida para una aplicación.

Una vez pulsado dicho botón nos aparecerá un cuadro de diálogo para definir nuestra nueva función.

En este cuadro de diálogo deberemos seleccionar en qué aplicación funcionará nuestro atajo de teclado, en caso de querer hacer un atajo general deberemos seleccionar el valor todas las aplicaciones para que nuestro atajo de teclado funcione en todas las aplicaciones.

Otro campo de este cuadro de diálogo es título de menú. Esto representa el nombre del servicio o función del sistema que queremos ejecutar.

Por último deberemos definir la combinación de teclas.

Script para identificar nivel de indentación con VoiceOver

A la hora de escribir textos para desarrollar aplicaciones en un lenguaje de programación se utilizan una serie de caracteres para indentar el texto separándolo una distancia determinada con respecto al margen izquierdo del documento. Esto se utiliza para estructurar el código del proyecto software y obtener una mejor visualización de las diversas estructuras y áreas del archivo de código. Algunos lenguajes de programación, como Python, utilizan estos caracteres de indentación para definir bucles o subrutinas por lo que la indentación pasa a tomar mayor importancia.

Para indentar un texto se suele utilizar el caracter de espacio o el caracter de tabulación. De esta forma se pueden definir distintos niveles de indentación de forma homogénea.

Los desarrolladores con discapacidad visual que utilizan un lector de pantallas no pueden acceder a esta información de forma habitual. Aunque algunos lectores de pantallas, como las últimas versiones de Jaws, incorporan funciones para identificar cambios en la indentación del texto la mayoría de estos productos de apoyo carecen de herramientas para gestionar este atributo del texto. VoiceOver para OSX carece de esta funcionalidad pero podemos incorporar algo que nos permita consultar el nivel de indentación de una línea de texto gracias a la ampliación de funcionalidad de VoiceOver mediante Apple script.

Script para verificar el nivel de indentación de una línea de texto

Tyflos Accessible Software ha desarrollado un script para VoiceOver el cual devuelve el número de indentación del último texto verbalizado por VoiceOver.

Esta primera versión del script sólo soporta caracteres de tabulación. En futuras versiones se aportará mayor soporte para otros caracteres de indentación.

Puedes descargar el archivo comprimido del script de verificación del nivel de indentación e instalarlo en tu sistema OSX.

Para utilizarlo es necesario activar el soporte de scripts de VoiceOver y añadir un comando para VoiceOver asociado a este script.