Como você pode programar se é cego?

A visão é um dos sentidos que a maioria dos programadores não reconhece. A maioria dos programadores passava horas olhando para um monitor de computador (especialmente nos períodos em que estão na zona ), mas eu sei que existem programadores cegos (como o TV Raman, que atualmente trabalha no Google).

Se você fosse cego (ou lentamente se tornando cego), como você configuraria seu ambiente de desenvolvimento para ajudá-lo na programação?

(Uma sugestão por resposta, por favor. O objetivo desta pergunta é trazer as boas idéias para o topo. Além disso, os leitores de tela podem ler as boas idéias mais cedo.)

Eu sou um estudante universitário totalmente cego que teve vários estágios de programação, então minha resposta será baseada neles. Eu uso o Windows XP como meu sistema operacional e o Jaws para ler o que aparece na tela para mim em fala sintética. Para programação java, uso o eclipse, pois é um IDE completo que é acessível.

Na minha experiência como regra geral, os programas java que usam SWT como o kit de ferramentas da GUI são mais acessíveis que os programas que usam o Swing, e é por isso que fico longe do netbeans. Para qualquer programação .net, uso o visual studio 2005, pois era a versão padrão usada no meu estágio e é muito acessível usando o Jaws e um conjunto de scripts que foram desenvolvidos para tornar mais acessíveis coisas como o designer de formulários.

Para programação em C e C ++, uso o cygwin com o gcc como meu compilador e o emacs ou vim como meu editor, dependendo do que eu preciso fazer. Grande parte do meu estágio envolveu programação para Z / OS. Usei uma sessão de rlogin através do Cygwin para acessar o subsistema USS no mainframe e o C3270 como meu emulador 3270 para acessar a parte ISPF do mainframe.

Eu costumo confiar na fala sintética, mas tenho uma tela em Braille. Acho que geralmente trabalho mais rápido com a fala, mas uso o visor em braille em situações em que a pontuação é importante e complicada. Exemplos disso são as declarações if com muitos parênteses e JCL aninhados em que a pontuação é incrivelmente importante.

Atualizar

Estou jogando com o Emacspeak no cygwin http://emacspeak.sourceforge.net Não tenho certeza se isso será útil como editor de programação, pois parece não responder, mas não olhei para nenhuma das opções de configuração ainda.

Sou cego e programa há cerca de 13 anos em Windows, Mac, Linux e DOS, em linguagens C / C ++, Python, Java, C # e várias linguagens menores ao longo do caminho. Embora a pergunta original estivesse relacionada à configuração do ambiente, acho melhor responder como uma pessoa cega usaria um computador.

Algumas pessoas usam um ambiente de conversação, como o TV Raman e o ambiente Emacspeak mencionado em outras respostas. A solução mais comum é, de longe, ter um leitor de tela que monitore a atividade do SO em segundo plano e avise o usuário por meio de fala sintética ou uma tela física em braille (geralmente mostrando de 20 a 80 caracteres por vez). Isso significa que uma pessoa cega pode usar qualquer aplicativo acessível.

Então, eu pessoalmente uso o Visual Studio 2008 hoje em dia e o executo com poucas modificações. Desativo alguns recursos, como exibir erros enquanto digito, pois acho isso perturbador. Antes de ingressar na Microsoft, todo o meu desenvolvimento foi feito em um editor de texto padrão como o Bloco de Notas, portanto, mais uma vez, sem personalizações.

É possível configurar um leitor de tela para anunciar o recuo. Pessoalmente, não uso isso, pois o Visual Studio cuida disso e o C # usa chaves. Mas isso seria muito importante em uma linguagem como Python, onde o espaço em branco é importante. Finalmente, o Emacspeak faz uso de diferentes vozes / sons para indicar diferentes partes da sintaxe (palavras-chave, comentários, identificadores, etc.).

Sou cego e sou programador há 12 anos. Atualmente sou arquiteto sênior e trabalho com a Sapient Corporation (uma empresa de consultoria baseada em Cambridge que cria soluções corporativas baseadas na Web e em clientes espessos). Eu uso vários leitores de tela, mas principalmente uso o Jaws para Windows e NVDA.

Tenho trabalhado principalmente na plataforma Microsoft e no visual studio como meu ambiente. Também uso ferramentas como o MS Sql enterprise studio e outras para acesso ao banco de dados, monitoramento de rede etc. Tentei passar algum tempo com o emacspeak, mas como meu trabalho era principalmente baseado na plataforma MS, nunca passei muito tempo lá. Também passei alguns anos trabalhando em C ++ no linux - principalmente o bloco de notas ou o visual studio no windows para toda a codificação e depois o samba para compartilhar arquivos com o ambiente linux. Também usei o borland C para algumas coisas experimentais. Recentemente, brincamos com o python, que, como outras pessoas observaram acima, é particularmente hostil para um usuário cego, porque ele é escrito usando o recuo como o mecanismo de aninhamento. Dito isto, o NVDA, o leitor de tela de código-fonte aberto mais popular é escrito completamente usando python e alguns dos responsáveis ​​pelo projeto são cegos. Uma pergunta particularmente interessante que me fazem frequentemente como arquiteto é como lido com diagramas - UML e visio e rose racional etc. O Visio é provavelmente a ferramenta de diagramação mais acessível existente no mercado. Consegui escrever scripts de mandíbulas para ler diagramas racionais de rosas para mim. Usei uma ferramenta chamada T-dub (entendimento técnico do diagrama para cegos), desenvolvida por alguma universidade alemã para acessar os diagramas UML 2.0. Usaram uma ferramenta feia baseada em java, chamada magic draw, para desenvolver o desenvolvimento orientado a modelos, e foi um colaborador do projeto androMDA e ajudou a desenvolver o gerador de código .Net a partir de um modelo UML. Uma pergunta particularmente interessante que me fazem frequentemente como arquiteto é como lido com diagramas - UML e visio e rose racional etc. O Visio é provavelmente a ferramenta de diagramação mais acessível existente no mercado. Consegui escrever scripts de mandíbulas para ler diagramas racionais de rosas para mim. Usei uma ferramenta chamada T-dub (entendimento técnico do diagrama para cegos), desenvolvida por alguma universidade alemã para acessar os diagramas UML 2.0. Usaram uma ferramenta feia baseada em java, chamada magic draw, para desenvolver o desenvolvimento orientado a modelos, e foi um colaborador do projeto androMDA e ajudou a desenvolver o gerador de código .Net a partir de um modelo UML. Uma pergunta particularmente interessante que me fazem frequentemente como arquiteto é como lido com diagramas - UML e visio e rose racional etc. O Visio é provavelmente a ferramenta de diagramação mais acessível existente no mercado. Consegui escrever scripts de mandíbulas para ler diagramas racionais de rosas para mim. Usei uma ferramenta chamada T-dub (entendimento técnico do diagrama para cegos), desenvolvida por alguma universidade alemã para acessar diagramas UML 2.0. Usaram uma ferramenta feia baseada em java, chamada magic draw, para desenvolver o desenvolvimento orientado a modelos, e foi um colaborador do projeto androMDA e ajudou a desenvolver o gerador de código .Net a partir de um modelo UML. Consegui escrever scripts de mandíbulas para ler diagramas racionais de rosas para mim. Usei uma ferramenta chamada T-dub (entendimento técnico do diagrama para cegos), desenvolvida por alguma universidade alemã para acessar os diagramas UML 2.0. Usaram uma ferramenta feia baseada em java, chamada magic draw, para desenvolver o desenvolvimento orientado a modelos, e foi um colaborador do projeto androMDA e ajudou a desenvolver o gerador de código .Net a partir de um modelo UML. Consegui escrever scripts de mandíbulas para ler diagramas racionais de rosas para mim. Usei uma ferramenta chamada T-dub (entendimento técnico do diagrama para cegos), desenvolvida por alguma universidade alemã para acessar os diagramas UML 2.0. Usaram uma ferramenta feia baseada em java, chamada magic draw, para desenvolver o desenvolvimento orientado a modelos, e foi um colaborador do projeto androMDA e ajudou a desenvolver o gerador de código .Net a partir de um modelo UML.

Em geral, acho que sou mais favorável em um ambiente de equipe em que posso trabalhar com meus pontos fortes. Por exemplo, enquanto um diagrama é extremamente útil para comunicar / documentar um design, o processo de design real envolve muito pensamento e brainstorming e, quando o design foi pensado, um de seus colegas de equipe pode ajudá-lo a montar rapidamente um desenho bem desenhado imagem fora disso. As pessoas interpretam incorretamente o exposto acima como falta de independência ou capacidade, enquanto eu vejo isso como pura interdependência - como em eu tenho certeza que o companheiro de equipe sozinho nunca poderia ter elaborado esse projeto por conta própria e , se eu depender dele para documentar o design, que assim seja. A maioria dos obstáculos que enfrento são inacessíveis com base em ferramentas.

Sou desenvolvedor cego e trabalho no Windows, GNU Linux e MacOS X. Cada plataforma possui fluxos de trabalho diferentes para usuários cegos. Isso depende do leitor de tela que o desenvolvedor cego usa. As ferramentas de desenvolvimento não são completamente acessíveis para desenvolvedores cegos. Posso digitar código e usar funções de compilação em todos os IDEs, mas há muitos problemas se precisar criar uma interface usando ferramentas de design como o Interface Builder, o XGlade ou outro. Quando desenvolvi o Borland Delphi, pude adicionar um controle, um Button por exemplo, e modificar cada atributo visual do controle usando a janela do inspetor de objetos. Muitos IDEs usam janelas do inspetor de objetos para modificar atributos visuais e não visuais, mas o problema para um desenvolvedor cego é adicionar novos controles porque o método para adicionar um novo controle consiste em arrastar e soltar um controle da paleta para a tela. O Visual studio 200x usa métodos alternativos para fazer isso, mas a interface do IDE é alterada a cada nova versão e isso é um grande problema, porque os leitores de tela do Windows precisam de suporte especial, usando scripts, para identificar cada área de alguns aplicativos não padrão. Um desenvolvedor cego pode usar o Visual studio 2008 com seu leitor de tela, mas quando uma nova versão desse IDE aparece, ele precisa aguardar uma nova versão dos scripts para esta versão do IDE. O construtor Xcode with Interface ainda não tem alternativa para arrastar e soltar tarefas. Pedi à Apple muitas vezes, mas elas estão trabalhando em outras coisas. Publiquei 3 aplicativos na App Store (caça-minas acessível, máquina de frutas acessível e RSS da Programar a ciegas) e tive que projetar toda a interface por código. É um trabalho árduo, mas posso gerenciar todos os recursos de cada controle. O Eclipse possui um editor de código acessível, mas outras ferramentas de desenvolvimento como console de depuração, plug-ins para área de design ou documentação apresentam problemas para ferramentas assistenciais para usuários cegos.

A documentação também é um problema para desenvolvedores cegos. Muitas amostras e demonstrações usam imagens para mostrar a explicação (defina as configurações do ambiente como você pode na figura)

Eu acho que a questão não está sendo cega. A questão é que as empresas e os grupos de desenvolvimento acham que a acessibilidade afeta o software final, mas não afeta o software de desenvolvimento. Eles acham que um usuário cego deve ser um cliente, mas um usuário cego não pode ser um parceiro de desenvolvimento.

Associações cegas pedem acessibilidade para produtos e serviços, mas esquecem de desenvolvedores cegos. Pessoas cegas podem trabalhar como advogados, jornalistas, professores, mas um desenvolvedor cego é um conceito estranho, mesmo para cegos. Muitas vezes me sinto sozinho porque alguns amigos meus cegos não conseguem entender meu trabalho.

Você pode ler minha opinião sobre esse assunto neste artigo, em espanhol, no meu blog http://www.programaraciegas.net/2010/11/05/la-accesibilidad-en-crisis-para-los-desarrolladores-ciegos/ existe uma ferramenta de tradução na página da web. Desculpe, mas não o traduzi.

O Emacs possui várias extensões para permitir que usuários cegos manipulem arquivos de texto. Você precisaria consultar um especialista sobre o assunto, mas o emacs possui recursos de conversão de texto em fala. E provavelmente mais.

Além disso, há o BLinux:

http://leb.net/blinux/

Linux para cegos. Já existe há muito tempo. Mais de dez anos, eu acho, e muito maduro.

Lembre-se de que "cego" é uma variedade de condições - há quem seja legalmente cego que possa ler um monitor realmente grande ou com a ajuda de ampliação e, em seguida, há quem não tenha visão. Lembro-me de uma colega na faculdade que tinha um dispositivo especial para ampliar livros e um software especial que ela poderia usar para ampliar uma parte da tela. Ela estava trabalhando duro para terminar a faculdade, porque sua visão estava piorando e ia desaparecer completamente.

A programação também tem um espectro de necessidades - algumas pessoas são boas em criar lotes e lotes de código, e outras são melhores em olhar para o cenário geral e a arquitetura. Imagino que, dada a dificuldade imposta pela interface da tela, a cegueira possa melhorar sua capacidade de obter uma visão geral ...

Hanselman teve um podcast realmente interessante com um desenvolvedor cego recentemente .

Trabalhei para a Greater Detroit Society for the Blind por três anos executando um BBS sob medida para acesso às cegas e trabalhei com vários usuários cegos sobre como atender melhor às suas necessidades e com novos usuários cegos para adaptá-los ao hardware disponível e ofertas de software disponíveis na época. Pelo menos aprendi a ler o Braille como uma proteção contra o caso em que acabei na mesma situação!

A maioria dos usuários e programadores de computadores cegos usa algum tipo de leitor de tela. mandíbulas em particular é popular. Felizmente, a maioria das principais aplicações atualmente oferece algum tipo de acesso para deficientes. Pode ser necessário ajustar um pouco o ambiente para reduzir a conversa, por exemplo, considere desativar o Intellisense no Visual Studio.

Uma tela Braille é menos comum e é comparativamente muito mais cara e pode mostrar 40 ou 80 colunas de texto e pode ser usada quando o posicionamento exato / pontuação é importante. Embora um leitor de tela possa ser configurado para classificar a pontuação, muitas pessoas acham que é perturbador e, em muitos casos, é mais fácil sentir o caminho. As garras podem ser configuradas para conduzir a exibição, para que você não esteja manipulando aplicativos de acessibilidade.

Além disso, muitos usuários legalmente cegos ainda têm um pouco de visão para eles. O uso de fundos de alto contraste e a funcionalidade de ampliação podem ajudar muitos desses usuários.

O uso das teclas de alternância no Windows permitirá que você escute acidentalmente quando você toca acidentalmente em uma das teclas modais 'caps lock', 'num lock', 'scroll lock' etc.

Conheço pelo menos um programador Haskell que usa um leitor de tela e que programa explicitamente sem usar as regras de layout de Haskell e, em vez disso, opta por usar o bastante não-idiomático, mas com suporte {;} , porque é mais fácil / menos perturbador para ele obter seu leitor de tela lê a pontuação do que para ele descobrir o recuo exato que cumpre as regras de layout de Haskell. Na mesma nota, eu ouvi algumas queixas de alguns programadores cegos sobre quando eles precisam escrever em Python.

Por fim, você aprende a jogar com seus pontos fortes.

Não me lembro da fonte, mas ouvi / li sobre uma forma de sintaxe audível "colorindo" - de modo que, em vez de uma atribuição de string ser lida como

foo é igual a citação, esta é uma citação de string

a parte da corda seria lida com um tom ou voz diferente para tornar a separação dos elementos mais clara.

Um ponto de partida é o projeto Blinux:

http://leb.net/blinux/

Esse projeto descreve como obter o Emacspeak (editor com conversão de texto em fala) e possui muitos outros recursos.

Eu trabalhei com uma pessoa que quase não os impedia de usar um monitor - eles se saíram bem com o software leitor de tela e passaram muito tempo usando aplicativos baseados em texto e o shell.

A lista de pacotes de leitores de tela da Wikipedia é outro ponto de partida: http://en.wikipedia.org/wiki/List_of_screen_readers

Sou estudante de pós-graduação em Pequim, China. Sou formado em ciência da computação e muito do meu trabalho é programação. Eu nasci com pouca visão, preciso usar ferramentas de ampliação para ver claramente as fontes na tela. Eu uso as ferramentas mgnify da microsoft no windows e uso o plug-in de ampliação do compiz se estiver no linux. Geralmente, defino a ferramenta para ampliar três vezes o tamanho da fonte original. Para mim, as ferramentas maginify estão ok, o principal problema é a velocidade, tenho que mover o mouse para manter os cursores seguirem o texto que estou vendo, o microsoft magnify fornece uma opção de "seguir automaticamente os pontos de edição de texto", que me impedem de movimento contínuo do mouse ao editar ou codificar. Mas nem sempre funciona por causa do software de edição ou o IDE pode não suportar isso. Ferramentas de aumento no linux são difíceis de usar. O KMag, fornecido com o KDE, tem uma terrível taxa de atualização, que deixa meus olhos desconfortáveis, as tomadas de ampliação do compiz que estou usando agora estão OK, mas não têm a função de foco automático (foco automático a seguir). O iOS fornece uma solução perfeita para a ampliação da tela inteira, especialmente na tela de 9,7 polegadas do ipad. o foco automático não é necessário porque eu quase não os uso para codificar ou fazer outras coisas de edição. O Android fornece muito poucas funções de acessibilidade, apenas como feedback de vibração, que é inútil para mim. não há nenhum tipo de boas ferramentas de ampliação no android, para não mencionar a função avançada, como a ampliação de tela cheia no iOS. Eu estudava Qt, queria criar ferramentas úteis de ampliação no linux, mesmo no android. Mas dificilmente temos algum progresso. mas não tem função de foco automático (foco automático a seguir). O iOS fornece uma solução perfeita para a ampliação da tela inteira, especialmente na tela de 9,7 polegadas do ipad. o foco automático não é necessário porque eu quase não os uso para codificar ou fazer outras coisas de edição. O Android fornece muito poucas funções de acessibilidade, apenas como feedback de vibração, que é inútil para mim. não há nenhum tipo de boas ferramentas de ampliação no android, para não mencionar a função avançada, como a ampliação de tela cheia no iOS. Eu estudava Qt, queria criar ferramentas úteis de ampliação no linux, mesmo no android. Mas dificilmente temos algum progresso. mas não tem função de foco automático (foco automático a seguir). O iOS fornece uma solução perfeita para a ampliação da tela inteira, especialmente na tela de 9,7 polegadas do ipad. o foco automático não é necessário porque eu quase não os uso para codificar ou fazer outras coisas de edição. O Android fornece muito poucas funções de acessibilidade, apenas como feedback de vibração, que é inútil para mim. não há nenhum tipo de boas ferramentas de ampliação no android, para não mencionar a função avançada, como a ampliação de tela cheia no iOS. Eu estudava Qt, queria criar ferramentas úteis de ampliação no linux, mesmo no android. Mas dificilmente temos algum progresso. O Android fornece muito poucas funções de acessibilidade, apenas como feedback de vibração, que é inútil para mim. não há nenhum tipo de boas ferramentas de ampliação no android, para não mencionar a função avançada, como a ampliação de tela cheia no iOS. Eu estudava Qt, queria criar ferramentas úteis de ampliação no linux, mesmo no android. Mas dificilmente temos algum progresso. O Android fornece muito poucas funções de acessibilidade, apenas como feedback de vibração, que é inútil para mim. não há nenhum tipo de boas ferramentas de ampliação no android, para não mencionar a função avançada, como a ampliação de tela cheia no iOS. Eu estudava Qt, queria criar ferramentas úteis de ampliação no linux, mesmo no android. Mas dificilmente temos algum progresso.

Quando eu estava na faculdade, tínhamos um membro da nossa equipe de pesquisa cego. Ele era um pouco mais velho, talvez com uns 40 anos. Ele nos contou como ele programou seu primeiro computador (que era muito antes da conversão de texto em fala) para produzir o conteúdo da tela em Código Morse. Para superar o óbvio problema do ovo e da galinha, ele teve que reescrever completamente o código do zero até que funcionasse bem o suficiente para que ele lesse de volta para ele.

Agora ele usa conversão de texto em fala, embora planeje o código muito bem antes de realmente escrever qualquer um deles, para minimizar o loop de depuração.

Ele também era muito bom em fazer apresentações em PowerPoint que, apesar de sua falta de visão, eram tão bem formatadas quanto qualquer apresentador com visão.

Esta postagem do blog tem algumas informações sobre como a equipe do Visual Studio está tornando seu produto acessível:

Atividade do tour de laboratório de acessibilidade da equipe principal do Visual Studio

Muitos programadores usam o Emacspeak:

Emacspeak - o ambiente de trabalho completo em áudio

De volta à Nova Zelândia, eu conhecia alguém que tinha degeneração macular , por isso estava parcialmente avistado. Ele é um programador muito talentoso e acabou usando o Delphi porque podia trabalhar reconhecendo formas de palavras. Isso era mais fácil com uma sintaxe do tipo Pascal do que com um suporte C-ish. Ele tem um site, mas parece não mencionar a degeneração macular, de modo que não vou chamá-lo.

Sou cego e, há alguns meses, estou usando o VINUX (uma distribuição Linux baseada no Ubuntu) com o SODBEANS (uma versão do netbeans com um plug-in chamado SAPPY que adiciona suporte a TTS). Esta solução funciona muito bem, mas às vezes eu prefiro iniciar o Win XP e o NVDA para lançar muitas páginas no FireFox, porque o Vinux não funciona muito bem quando você tenta abrir mais de 3 janelas do FireFox ...

Como muitos apontaram, o emacspeak tem sido a solução duradoura entre plataformas para muitos dos hackers mais antigos do mercado. Como ele suporta Linux e Mac imediatamente, tornou-se o meu meio preferido de desenvolver projetos de diagnósticos do Windows.

Para a questão de realmente descer a sintaxe através de uma auditiva em vez de visual, descobri que existe uma variedade de técnicas para aproximar uma, se não no mesmo campo de jogo.

Os ícones auditivos podem substituir descritores verbais por um exemplo. Você pode colocar tons para a distância que uma linha é recuada. Quanto mais longo o tom, maior o recuo. Como os tons podem tocar em paralelo com o texto em fala, as informações são transmitidas no mesmo período e não serializam a comunicação de algo tão básico.

O Braille pode decodificar rápida e precisamente para o usuário a sintaxe exata de uma linha. Isso é algo mais útil para pessoas que usam braille na vida cotidiana; a maior vantagem é o acesso aleatório ao conteúdo da tela. As unidades atualizáveis ​​normalmente possuem chaves do roteador acima de cada célula de caractere, que podem colocar o cursor nessa célula. Sem mexer nas teclas de seta O (n) op vs O (1) de acesso.

A dimensionalidade auditiva (tom, frequência, volume, inflexão, riqueza, estresse, etc.) pode transmitir um conceito (palavra-chave, classe, variável, erro, etc.). Por exemplo, os comentários podem ser lidos em uma inflexão monótona ... adequada, se assim posso dizer :).

O Emacs e outros editores em menor extensão (Visual Studio) permitem que um codificador examine um programa de forma símtica (próximo bloco, dobra, desintegração, pule para def, suba na árvore de análise, etc.). Você pode obter rapidamente a imagem "grande" da estrutura de um projeto inteiro fazendo isso; com extensões como o Cedet, você pode obter o benefício da plataforma cruzada VS / Eclipse / etc e em um editor de texto.

Provavelmente poderia continuar, mas em poucas palavras, é a base do motivo de alguns de nós estarmos lá fora, na indústria, na adacdemia ou em nossos porões :).

Um grupo de estudantes da Southern Illinois University Edwardsville e da Washington State University está trabalhando em uma linguagem de programação para cegos:

http://www.youtube.com/watch?v=lC1mOSdmzFc

harald van Breederode é um conhecido especialista, instrutor e apresentador holandês do Oracle DBA, cego. Seu blog contém algumas dicas úteis para pessoas com deficiência visual.

O que no mundo seria um teclado braille?

Existem escritores em braille, mas você nunca usaria um como dispositivo de entrada para um computador.

Se você está simplesmente falando de um teclado com os símbolos em braille, isso também seria uma péssima idéia. Você terá muito mais teclas para alcançar durante a digitação e ainda assim será mais lento.

A digitação por toque NÃO é uma habilidade visual, uma pessoa cega pode fazê-lo tão bem quanto uma pessoa que enxerga.

Eu acho que isso funcionaria bem em programação extrema usando o princípio de programação em pares. Se você está criando software para pessoas cegas, quem é melhor fazê-lo, então alguém que literalmente entraria em contato com os requisitos de negócios, então eu não acho que isso seja muito buscado.

Quanto à escrita de código, bem, a menos que haja algum tipo de feedback, acho que uma pessoa pode ter dificuldades com a sintaxe. O feedback de áudio pode ajudar até certo ponto.

O NVDA é um bom leitor de tela de código aberto para ganhar.

Que tal inventar algum tipo de dispositivo que você conecte em uma porta USB e que seja basicamente uma "folha de borracha" que se modifique para mostrar brail do seu código, permitindo que pessoas cegas o leiam em vez de o ouvir?

Há uma variedade de ferramentas para ajudar pessoas cegas ou com visão parcial, incluindo feedback de fala e teclados braillie. http://www.rnib.org.uk/Pages/Home.aspx é um bom site para obter ajuda e aconselhamento sobre esses problemas.

Depois que conheci Sam Hartman, ele é um famoso desenvolvedor do Debian desde 2000 e cego. Sobre isso entrevista, ele fala sobre a acessibilidade para um usuário Linux. Ele usa o Debian e o gnome-orca como leitor de tela, funciona com o Gnome e "faz um trabalho relativamente bom em falar do Iceweasel / Firefox e Libreoffice".

Especificamente falando sobre programação, ele diz:

Enquanto o [gnome-orca] fala o gnome-terminal, não é realmente bom o suficiente em programas de terminal para falar que eu estou confortável em usá-lo. Então, eu executo o Emacs com o pacote Emacspeak. Dentro disso, eu executo o emulador de terminal Emacs, e dentro disso, eu tendem a executar Screen. Para maior diversão, geralmente executo instâncias adicionais do Emacs nas telas internas.