workflow - ¿Cómo puedes programar si eres ciego?
development-environment accessibility (24)
La vista es uno de los sentidos que la mayoría de los programadores dan por sentado. La mayoría de los programadores pasan horas mirando un monitor de computadora (especialmente durante los momentos en que están en la zona ), pero sé que hay programadores ciegos (como TV Raman, que actualmente trabaja para Google).
Si fuera una persona ciega (o poco a poco se ciega), ¿cómo configuraría su entorno de desarrollo para ayudarlo en la programación?
(Una sugerencia por respuesta, por favor. El propósito de esta pregunta es llevar las buenas ideas a la parte superior. Además, los lectores de pantalla pueden leer las buenas ideas antes).
¿Qué diablos sería un teclado braille?
Hay cosas tales como escritores en braille, pero nunca usarías uno como dispositivo de entrada para una computadora.
Si simplemente estás hablando de un teclado con los símbolos en braille, esto también sería una muy mala idea. Vas a tener muchas más teclas que alcanzar mientras escribes y aún será más lento.
La escritura táctil NO es una habilidad visual, una persona ciega puede hacerlo tan bien como una persona vidente.
¿Qué tal si inventas algún tipo de dispositivo que conectas en un puerto USB y eso sería básicamente una "hoja de goma" que se modificaría para mostrar el código de tu código, permitiendo que las personas ciegas lo lean en lugar de escucharlo?
Como muchos han señalado, emacspeak ha sido la plataforma multiplataforma de soluciones duraderas para muchos de los piratas informáticos más antiguos que existen. Dado que es compatible con Linux y Mac, se ha convertido en mi medio preferido para desarrollar proyectos electrónicos de Windows.
Para el tema de bajar realmente la sintaxis a través de uno auditivo en lugar de uno visual, he encontrado que existe una variedad de técnicas para acercarse, si no en el mismo campo de juego.
Los íconos auditivos pueden colocarse en lugar de descriptores verbales para un ejemplo. Puede, poner tonos para la sangría de una línea. Cuanto más largo sea el tono, mayor será la sangría. Dado que los tonos pueden reproducirse en paralelo con el texto a voz, la información llega en el mismo período de tiempo y no serializa la comunicación de algo tan básico.
Braille puede descodificar de forma rápida y precisa al usuario la sintaxis exacta de una línea. Esto es algo más útil para las personas que usan braille en la vida diaria; La mayor ventaja es el acceso aleatorio a los contenidos de la pantalla. Las unidades actualizables suelen tener claves de enrutador sobre cada celda de caracteres que pueden colocar el cursor en esa celda. No juegue con las teclas de flecha O (n) op vs O (1) acceso.
La dimensionalidad auditiva (tono, velocidad, volumen, inflexión, riqueza, estrés, etc.) puede transmitir un concepto (palabra clave, clase, variable, error, etc.). Por ejemplo, los comentarios se pueden leer en una inflexión monótona ... satisfaciendo, si puedo decirlo :).
Emacs y otros editores en extensiones menores (Visual Studio) permiten que un programador examine un programa de manera simétrica (bloque siguiente, bloque doble, defun, defun, salto hacia la definición, suba el árbol de análisis, etc.). Puede obtener muy rápidamente la imagen "grande" de la estructura de un proyecto completo haciendo esto; con extensiones como Cedet, puede obtener la bondad de VS / Eclipse / etc multiplataforma y en un editor de texto.
Probablemente podría seguir y seguir, pero en pocas palabras, es la base de por qué algunos de nosotros estamos trabajando en la industria, la adacdemia o en nuestros sótanos :).
Creo que esto funcionaría bien en la programación extrema utilizando el principio de programación en pares. Si está creando software para personas ciegas, quién es el mejor para hacerlo, entonces alguien que literalmente estaría en contacto con los requisitos comerciales, por lo que no creo que sea muy descabellado.
En cuanto a escribir código, bueno, a menos que haya algún tipo de retroalimentación, creo que una persona puede tener problemas con la sintaxis. La retroalimentación de audio puede ayudar a un punto sin embargo.
Cuando estaba en la escuela de posgrado, teníamos un miembro de nuestro equipo de investigación que era ciego. Era un poco mayor, tal vez a mediados de los 40. Nos contó cómo programó su primera computadora (que era mucho antes de que fuera común la conversión de texto a voz) para mostrar el contenido de la pantalla en código Morse. Para superar el obvio problema del huevo y la gallina, tuvo que reescribir completamente el código cada vez desde cero hasta que funcionara lo suficientemente bien como para que se lo volviera a leer.
Ahora usa el texto a voz, aunque planea el código muy a fondo antes de escribir cualquiera de ellos, para minimizar el bucle de depuración.
También era bastante bueno para dar presentaciones de PowerPoint que, a pesar de su falta de visión, estaban tan bien formateadas como cualquier presentador vidente.
De vuelta en Nueva Zelanda, conocí a alguien que tenía degeneración macular , por lo que fue parcialmente vista. Es un programador muy talentoso y terminó usando Delphi porque podía trabajar reconociendo formas de palabras. Esto era más fácil de hacer con una sintaxis parecida a Pascal que con un soporte ondulado de tipo C-ish. Tiene un sitio web, pero no parece mencionar en absoluto la degeneración macular, por lo que no le pondré un nombre.
Emacs tiene varias extensiones para permitir que los usuarios ciegos manipulen archivos de texto. Tendría que consultar a un experto en el tema, pero emacs tiene capacidades de texto a voz. Y probablemente más.
Además, hay BLinux:
Linux para los ciegos. Ha estado alrededor por mucho tiempo. Más de diez años pienso, y muy maduros.
Esta publicación de blog contiene información sobre cómo el equipo de Visual Studio está haciendo accesible su producto:
Actividad del tour de laboratorio de accesibilidad del equipo de Visual Studio Core
Muchos programadores usan Emacspeak:
Estoy ciego y desde hace algunos meses estoy usando VINUX (una distribución de Linux basada en Ubuntu) con SODBEANS (una versión de netbeans con un complemento llamado SAPPY que agrega un soporte de TTS). Esta solución funciona bastante bien, pero a veces prefiero lanzar Win XP y NVDA para lanzar muchas páginas en FireFox porque Vinux no funciona muy bien cuando intentas abrir más de 3 ventanas de FireFox ...
Estoy ciego, y he estado programando durante aproximadamente 13 años en Windows, Mac, Linux y DOS, en lenguajes de C / C ++, Python, Java, C # y varios lenguajes más pequeños en el camino. Aunque la pregunta original era acerca de la configuración del entorno, creo que es mejor responderla observando cómo una persona ciega usaría una computadora.
Algunas personas utilizan un entorno de conversación, como TV Raman y el entorno de Emacspeak mencionados en otras respuestas. La solución más común con diferencia es tener un lector de pantalla que se ejecute en segundo plano, monitoreando la actividad del sistema operativo y alertando al usuario mediante un discurso sintético o una pantalla física en braille (que generalmente muestra entre 20 y 80 caracteres a la vez). Esto significa que una persona ciega puede usar cualquier aplicación accesible.
Por lo tanto, personalmente uso Visual Studio 2008 en estos días y lo ejecuto con muy pocas modificaciones. Desactivo ciertas funciones, como mostrar errores mientras escribo, ya que esto me distrae. Antes de unirme a Microsoft, todo mi desarrollo se realizó en un editor de texto estándar como el Bloc de notas, así que una vez más no hay personalizaciones.
Es posible configurar un lector de pantalla para anunciar la sangría. Yo personalmente no uso esto, ya que Visual Studio se encarga de esto, y C # usa llaves. Pero esto sería muy importante en un lenguaje como Python, donde el espacio en blanco importa. Finalmente, Emacspeak hace uso de diferentes voces / tonos para indicar diferentes partes de la sintaxis (palabras clave, comentarios, identificadores, etc.).
Hay una variedad de herramientas para ayudar a las personas ciegas o deficientes visuales, incluidos los comentarios del habla y los teclados en braille. http://www.rnib.org.uk/Pages/Home.aspx es un buen sitio para obtener ayuda y asesoramiento sobre estos temas.
NVDA es un buen lector de pantalla de código abierto para ganar.
No puedo recordar la fuente, pero he oído / leído acerca de una forma de sintaxis audible "coloreado", por lo que en lugar de una asignación de cadena se lee como
Foo es igual a esta cita es una cadena
la parte de la cuerda se leería con un tono o voz diferente para que la separación de los elementos sea más clara.
Soy ciego y he sido programador durante los últimos 12 años aproximadamente. Actualmente soy un arquitecto senior y trabajo con Sapient Corporation (una empresa de consultoría basada en cambridge que crea soluciones empresariales basadas tanto en la web como en el cliente pesado). Utilizo varios lectores de pantalla, pero en su mayoría me quedo con Jaws para Windows y NVDA.
He trabajado principalmente en la plataforma de Microsoft y en el estudio visual como mi entorno. También utilizo herramientas como MS Sql Enterprise Studio y otras para el acceso a bases de datos, monitoreo de redes, etc. Traté de pasar un tiempo con Emacspeak, pero como mi trabajo se basaba principalmente en la plataforma MS, nunca pasé mucho tiempo allí. También pasé un par de años trabajando en C ++ en linux, en su mayoría usé bloc de notas o estudio visual en Windows para toda la codificación y luego samba para compartir archivos con el entorno de linux. También usé borland C para algunas cosas experimentales. Recientemente he estado jugando con python, lo que, como otras personas han señalado anteriormente, es particularmente hostil para un usuario ciego porque está escrito utilizando sangría como el mecanismo de anidación. Dicho esto, NVDA, el lector de pantalla de código abierto más popular, se escribe completamente usando python y algunos de los comprometidos en ese proyecto son ciegos. Una pregunta particularmente interesante que me hacen con frecuencia como arquitecto es cómo lidiar con los diagramas: UML, visio y rational rose, etc. Visio es probablemente la herramienta de diagramación más accesible que existe. Pude escribir guiones de mandíbulas para leer diagramas de rosas racionales para mí. He utilizado una herramienta llamada T-dub (comprensión de diagramas técnicos para ciegos) desarrollada por alguna universidad alemana para acceder a diagramas UML 2.0. He utilizado una herramienta fea basada en java llamada magic draw para realizar el desarrollo guiado por modelos y fue un comitante en el proyecto androMDA y ayudó a desarrollar el generador de código .Net a partir de un modelo UML.
En general, encuentro que prospero más en un ambiente de equipo donde puedo trabajar en mis fortalezas. Por ejemplo, si bien un diagrama es extremadamente útil para comunicar / documentar un diseño, el proceso de diseño real implica mucha reflexión y lluvia de ideas, y cuando el diseño ha sido pensado, uno de sus compañeros de equipo puede ayudarlo a armar rápidamente una imagen fuera de ella. La gente interpreta incorrectamente lo anterior como falta de independencia o capacidad mientras veo esto como pura interdependencia, ya que estoy seguro de que el compañero de equipo por sí solo nunca podría haber ideado ese diseño por sí solo y en general. -tornear, si dependo de él para documentar el diseño, que así sea. La mayoría de los obstáculos que enfrento son la inaccesibilidad basada en herramientas. Por ejemplo, todos los productos de Oracle han ido disminuyendo progresivamente la accesibilidad a lo largo de los años (vergüenza de ellos) y un entorno de equipo básicamente me permite una capa adicional de defensa contra estos más allá de mis lectores de pantalla y scripts personalizados.
Soy un desarrollador ciego y trabajo bajo Windows, GNU Linux y MacOS X. Cada plataforma tiene diferentes flujos de trabajo para usuarios ciegos. Esto depende del lector de pantalla que usa el desarrollador ciego. Las herramientas de desarrollo no son completamente accesibles para los desarrolladores ciegos. Puedo escribir código y usar funciones de compilación en todos los IDE, pero hay muchos problemas si tengo que diseñar una interfaz usando herramientas de diseño como Interface Builder, XGlade u otra. Cuando estaba desarrollando con Borland Delphi, podía agregar un control, un Botón, por ejemplo, y podía modificar cada atributo visual del control usando la ventana del inspector de objetos. Muchos IDE usan ventanas de inspector de objetos para modificar atributos visuales y no visuales, pero el problema para un desarrollador ciego es agregar nuevos controles porque el método para agregar un nuevo control consiste en arrastrar y soltar un control desde la paleta hasta el lienzo. Visual Studio 200x usa métodos alternativos para hacer esto, pero la interfaz del IDE cambia en cada nueva versión y esto es un gran problema porque los lectores de pantalla para Windows necesitan soporte especial, usando scripts, para identificar cada área de algunas aplicaciones no estándar. Un desarrollador ciego puede usar Visual Studio 2008 con su lector de pantalla, pero cuando aparece una nueva versión de este IDE, tiene que esperar una nueva versión de scripts para esta versión del IDE. Xcode with Interface builder no tiene aún una alternativa para arrastrar y soltar tareas. Se lo pedí a Apple muchas veces, pero están trabajando en otras cosas. Publiqué 3 aplicaciones en la tienda de aplicaciones (limpiador de minas accesible, fruitmachine accesible y Programar a ciegas RSS) y tuve que diseñar toda la interfaz por código. Es un trabajo duro pero puedo administrar todas las características de cada control. Eclipse tiene un editor de código accesible, pero otras herramientas de desarrollo como la consola de depuración, los complementos para el diseño o el área de documentación presentan problemas para las herramientas de asistencia para usuarios ciegos.
La documentación también es un problema para los desarrolladores ciegos. Muchas muestras y demostraciones usan imágenes para mostrar la explicación (establezca la configuración del entorno como pueda en la imagen)
Creo que la pregunta no es ser ciego. La pregunta es: las compañías y los grupos de desarrollo piensan que la accesibilidad afecta al software final, pero no afecta al software de desarrollo. Piensan que un usuario ciego debería ser un cliente, pero un usuario ciego no puede ser un compañero de desarrollo.
Las asociaciones de ciegos piden accesibilidad para productos y servicios, pero se olvidaron de los desarrolladores ciegos. Las personas ciegas pueden trabajar como abogados, periodistas, maestros, pero un desarrollador ciego es un concepto extraño incluso para los ciegos. Muchas veces me siento solo porque algunos de mis amigos ciegos no pueden entender mi trabajo.
Puedes leer mi opinión sobre este tema en este artículo, en español, en mi blog http://www.programaraciegas.net/2010/11/05/la-accesibilidad-en-crisis-para-los-desarrolladores-ciegos/ Hay una herramienta de traducción en la página web. Lo siento pero no lo traduje.
Soy un estudiante de postgrado en Beijing, China. Me especialicé en informática y gran parte de mi trabajo es programación. Nací con poca visión, necesito usar herramientas de aumento para ver las fuentes en la pantalla con claridad. Yo uso las herramientas de Microsoft en Windows y uso el complemento Magnify de Compiz si está en Linux. Usualmente configuro la herramienta para que se amplíe tres veces más que el tamaño de fuente original. Para mí, las herramientas maginify están bien, el problema principal es la velocidad, tengo que mover el mouse para mantener los cursores siguiendo el texto que estoy viendo, la función magnify de microsoft ofrece una opción de "seguir automáticamente los puntos de edición de texto", que me han dado Movimiento continuo del ratón al editar o codificar. Pero no siempre funciona debido a que el software de edición o IDE no lo admiten. Las herramientas de aumento en linux son difíciles de usar. El KMag con KDE tiene una frecuencia de actualización terrible que hace que mis ojos se sientan incómodos, los enchufes de aumento de Compiz que estoy usando ahora están bien, pero no tienen ninguna función de enfoque automático (seguimiento automático). iOS me ofrece una solución bastante perfecta con la ampliación de pantalla completa, especialmente en la pantalla de 9.7 pulgadas del iPad. no es necesario el enfoque automático porque difícilmente los uso para codificar o hacer otras tareas de edición. Android proporciona muy pocas funciones de accesibilidad, solo como comentarios de shake, lo cual no sirve para mí. no hay ningún tipo de buenas herramientas de aumento en Android, por no mencionar la función avanzada, como el aumento de pantalla completa en iOS. Solía estudiar Qt, quiero construir herramientas de aumento útiles en Linux, incluso en Android. Pero apenas tienen algunos progresos.
Soy un estudiante universitario totalmente ciego que ha tenido varias pasantías de programación, por lo que mi respuesta se basará en estas. Utilizo Windows XP como mi sistema operativo y Jaws para leer lo que aparece en la pantalla en voz sintética. Para la programación en java, uso eclipse, ya que es un IDE con todas las funciones que es accesible.
En mi experiencia como regla general, los programas java que usan SWT como el kit de herramientas GUI son más accesibles que los programas que usan Swing, por lo que me mantengo alejado de netbeans. Para cualquier programación .net, utilizo Visual Studio 2005, ya que fue la versión estándar utilizada en mi pasantía y es muy accesible utilizando Jaws y un conjunto de scripts que se desarrollaron para hacer que las cosas como el diseñador de formularios sean más accesibles.
Para la programación en C y C ++, uso cygwin con gcc como compilador y emacs o vim como editor, dependiendo de lo que necesito hacer. Gran parte de mi pasantía involucró programación para Z / OS. Utilicé una sesión de rlogin a través de Cygwin para acceder al subsistema USS en el mainframe y C3270 como mi emulador 3270 para acceder a la parte ISPF del mainframe.
Por lo general confío en el lenguaje sintético, pero tengo una pantalla Braille. Creo que generalmente trabajo más rápido con el habla pero uso la pantalla Braille en situaciones donde la puntuación importa y se complica. Ejemplos de esto son las afirmaciones con muchos paréntesis anidados y JCL donde la puntuación es increíblemente importante.
Actualizar
Estoy jugando con Emacspeak en cygwin http://emacspeak.sourceforge.net No estoy seguro de que esto pueda usarse como un editor de programación ya que parece no responder, pero no he visto ninguna de las opciones de configuración todavía.
Tenga en cuenta que "ciego" es un rango de condiciones: hay algunos que son legalmente ciegos que podrían leer un monitor realmente grande o con ayuda de aumento, y luego están los que no tienen ninguna visión. Recuerdo a un compañero de clase en la universidad que tenía un dispositivo especial para ampliar libros y un software especial que podía usar para ampliar una parte de la pantalla. Ella estaba trabajando duro para terminar la universidad, porque su vista estaba empeorando y se iba a ir completamente.
La programación también tiene un espectro de necesidades: algunas personas son buenas para desarrollar una gran cantidad de códigos, y algunas personas son mejores para ver el panorama general y la arquitectura. Me imagino que, dada la dificultad impuesta por la interfaz de la pantalla, la ceguera puede mejorar su capacidad para obtener una visión general ...
Trabajé para la Greater Detroit Society for the Blind durante tres años con una BBS adaptada para el acceso a ciegos y trabajé con varios usuarios ciegos para satisfacer mejor sus necesidades, y con usuarios recientemente ciegos para que se aclimataran al hardware disponible. Ofertas de software que estaban disponibles en ese momento. Si nada más, ¡al menos aprendí a leer Braille como una cobertura contra el caso en el que alguna vez terminé en la misma situación!
La mayoría de los usuarios y programadores ciegos de computadoras usan algún tipo de lector de pantalla. Jaws en particular son populares. Afortunadamente, la mayoría de las aplicaciones importantes en estos días ofrecen algún tipo de acceso para discapacitados. Es posible que deba ajustar un poco el entorno para reducir la charla, por ejemplo, considere la posibilidad de desactivar Intellisense en Visual Studio.
Una pantalla Braille es menos común y, comparativamente, es mucho más costosa y puede mostrar 40 u 80 columnas de texto, y puede usarse cuando la posición / puntuación exacta es importante. Si bien un lector de pantalla se puede configurar para eliminar la puntuación, muchas personas lo encuentran como una distracción, y en muchos casos es más fácil moverse a través de él. Las mordazas pueden configurarse para controlar la pantalla, por lo que no está haciendo malabares con las aplicaciones de accesibilidad.
Además, muchos de los usuarios legalmente ciegos todavía tienen algo de visión que les queda. El uso de fondos de alto contraste y la funcionalidad de ampliación pueden ayudar a muchos de estos usuarios.
El uso de ToggleKeys en Windows le permitirá escuchar cuándo toca accidentalmente una de las teclas modales ''bloqueo de mayúsculas'', ''bloqueo numérico'', ''bloqueo de desplazamiento'', etc. también.
Conozco al menos un programador de Haskell que usa un lector de pantalla y que programa explícitamente sin usar las reglas de diseño de Haskell, y en su lugar opta por usar el lenguaje no idiomático, sino el de {;}
en su lugar, porque es más fácil / menos distractor que consiga que su lector de pantalla lea la puntuación que para que descubra la sangría exacta que cumple con las reglas de diseño de Haskell. En esa misma nota, escuché algunas quejas de un par de programadores ciegos sobre cuándo tienen que escribir Python.
En última instancia, aprendes a jugar con tus fortalezas.
Un grupo de estudiantes de Southern Illinois University Edwardsville y Washington State University están trabajando en un lenguaje de programación para ciegos:
Un lugar para comenzar es el proyecto Blinux:
Ese proyecto describe cómo obtener Emacspeak (editor con texto a voz) y tiene muchos otros recursos.
Trabajé con una persona que, a simple vista, evitó que usaran un monitor: les fue bien con el software de lector de pantalla y pasaron mucho tiempo utilizando aplicaciones basadas en texto y el shell.
La lista de Wikipedia de paquetes de lectores de pantalla es otro lugar para comenzar: http://en.wikipedia.org/wiki/List_of_screen_readers
Una vez que conocí a Sam Hartman, él es un famoso desarrollador de Debian desde 2000 y es ciego. En this entrevista habla de accesibilidad para un usuario de Linux. Utiliza Debian, y gnome-orca como lector de pantalla, funciona con Gnome, y "hace un trabajo relativamente bueno hablando Iceweasel / Firefox y Libreoffice".
Específicamente hablando de programación dice:
Mientras que [gnome-orca] habla gnome-terminal, no es realmente lo suficientemente bueno para hablar en programas de terminal, por lo que me siento cómodo usándolo. Entonces, ejecuto Emacs con el paquete Emacspeak. Dentro de eso, ejecuto el emulador de terminal Emacs, y dentro de eso, tiendo a ejecutar Screen. Para mayor diversión, a menudo ejecuto instancias adicionales de Emacs dentro de las pantallas internas.
harald van Breederode es un conocido experto en DBA de Oracle, entrenador y presentador que es ciego. Su blog contiene algunos consejos útiles para personas con discapacidad visual.