Linguagem programação para cegos - parece possível?

[Célio Ishikawa]

Olá gente do Polignu!

Tenho me envolvido com tecnologia assistiva (tecnologia para deficientes), na parte de desenvolver concepções, ponderar as dificuldades, desafios e tal.

Uma das questões recentes que surgiu é a seguinte: se for possível adaptar fluxos de informações para cegos, será possível adaptar informações longas e complexas para cegos trabalharem? (informações com variáveis, bifurcações, e tal)

E se for possível fazer tal adaptação, quais tarefas os cegos poderiam passar a fazer? E daí que surgiu a questão de que talvez linguagens de programação se encaixe nessa linha a ser desenvolvida.

O que acham? Linguagem de programação para cegos parece possível como premissa? Sim? Não? O que acham?

Queria que vocês levassem em consideração alguns pontos:

- uma linha de código pode ser virar uma linha de corda para o cego, no entanto, uma página teria ramificações (um pouco como uma árvore). A princípio, seria uma árvore complexa demais para acompanhar por meios táteis? (seguindo a corda e acompanhando desdobramentos e tal)

- Há partes de códigos que remetem à bibliotecas, a partes fora do código (me corrijam se essa noção de "fora do código" estiver errada). No trabalho de programação, a biblioteca é algo muito consultada ou pode-se trabalhar com ela apenas de cabeça, lidando com ela mentalmente após se acostumar a trabalhar com ela (eu pergunto isso pois se basta a informação ser mental, não é necessário adaptar uma informação visual para tátil).

- Pondero que a transformação de informação visual para tátil se bem feita não ocuparia tanto espaço (uma das estratégias que pretendo usar é ao invés de usar Braille, que é linha, e portanto unidimensional, usar superfícies bidimensionais ou tridimensionais). Mas ainda assim, provavelmente informação visual leva vantagem em quantidade de informação que chega instantaneamente pelo olho (mais f´ácil ver quantas contas uma novena tem visualmente do que contando com os dedos, no escuro). Sendo assim, na rotina de trabalho de um programador é necessário checar várias páginas de código? (digo, tem de rolar muito a tela para ver o código todo na maioria dos trabalhos?) À primeira vista isso parece inviabilizar a conversão de informação visual em tátil ou não?

- Na maioria das vezes se programa para ver o resultado em tela, um aplicativo que funciona em telas de computadores, tablets ou celulares, mas enfim, telas. Há programação para arduino e hardwares, mas que também muitas vezes é algo para ver com os olhos, sendo raro que a saída seja por exemplo algo que se mexa na mão do cego que perceberá o que se passa de forma tátil. Claro, nessas questões não se enquadram os softwares e hardwares que mexem com som, que por ser informação audível o cego pode perceber.

- Essa parte da maioria das saídas serem coisas a enxergar (mesmo que movimento), demandaria repensar as saídas, por exemplo, se um cego quiser explicar um movimento, porque só pode prodozir uma animação que fica atrás das telas? Porque não pode ser uma animação tridimensional sensorial? Daria para questionar muita coisa.

- Como questionar tanta coisa da saída daria muito trabalho pois é praticamente abrir um universo novo, vamos ficar só na entrada mesmo, na questão de cegos não precisarem ver a saída, vamos imaginar que são programadores com tarefa de arrumar o código por exemplo de um software gráfico, que eles não verão o resultado mas ficarão satisfeitos em arrumar as incongruências do código (parece meio cruel, mas lembre-se que matemáticos lidam com dados abstratos e ficam satisfeitos em produzir produtos abstratos).

- Nisso gostaria de saber se mesmo o programador que enxerga trabalha com a sensação mais ou menos tipo "o resultado visual que se dane, eu quero é resolver esse código e ganhar meu dia" (bem, eu imagino que quem cuida das minúcias da parte visual de videogames acaba pensando isso...).

Se tiver mais tópicos a serem levantados podem colocar!

Como se vê, é tudo ainda na etapa de trabalhar com premissas. Não sei se já tem iniciativas já sendo desenvolvidas nesse sentido, mas mesmo se houver, estou inclinado a não desistir de desenvolver pelo menos algumas considerações por conta (não é cabeça-durice de gastar esforço com fork desnecessário, mas de esperar que uma outra abordagem independente reforce os pontos positivos de outra iniciativa, se existir).

Podem responder sem receio de me desanimar, pois também outro aspecto da minha cabeça-durice é mesmo se a maioria dizer ser impossível eu continuar até eu me convencer!

Célio

[Andres MRM]

Oi, Célio! Muito bacana você tocar nesse ponto.
Algumas vezes já me peguei pensando como eu faria para programar caso
ficasse cego...

Tenho muita pouca noção de como é ser cego, então tenho dificuldade de
responder à essa questão, mas a princípio, me parece que um leitor de
texto resolveria minimamente, não? Provavelmente haveria uma perda de
produtividade no início, mas não sei como seria a longo prazo...

Porque, basicamente o que um programador vidente faz é ler texto e
escrever. E, mesmo um vidente, não consegue ver o texto todo de uma só
vez, ele tem que ir linha por linha, pensando no que cada uma faz.

O que eu acho que seria necessário é um leitor de texto que marcasse
pontos importantes no código. Quando se entra em um bloco código, quando
se sai dele, etc. Mas como códigos seguem sempre um padrão, já que são
interpretados por máquinas, imagino que não seria difícil para o leitor
perceber essas marcas.

Acho que seria importante uma forma boa de se navegar pelo texto também,
a partir dos nomes das funções talvez, mas isso há editores que já
fazem...

Agora estou com a dúvida, estamos pensando em um(a) ceg@ que usa um
teclado "comum" (QWERTY, por exemplo)? Muitas pessoas digitam sem
olhar, então imagino que um(a) não vidente conseguiria usar um teclado
comum.

Posso estar sendo tendencioso, mas me parece que os programas com
interface de terminal, CLI, seriam mais adequados para esse tipo de uso,
uma vez que permitem fazer tudo pelo teclado, e possuem uma interface
puramente textual. Digo que posso estar sendo tendencioso porque eu
gosto mais desse tipo de interface. Ex.: Vim, Mutt, Wyrd, Ranger, etc.

E discordo que um(a) não vidente não conseguiria ver os resultados de
seu código... Talvez não de todos, mas há programas que retornam texto
ou números, que poderiam ser lidos para @ noss@ aspirante em
programação. =)
Esses 4 que citei no fim do parágrafo anterior possuem interfaces
textuais, logo tudo poderia ler lido.
E penso que a pessoa poder ver o resultado é fundamental. Fica muito
difícil você motivar alguém sem isso...

Sobre consultas à documentação, não vejo muitas mudanças também...
Eu pelo menos costumo buscar pelo nome da função que quero, ou ir lendo
os nomes das funções que um objeto possui para ver qual me interessa.
Acho que um(a) não vidente faria algo equivalente. E iria pulando de
nome em nome até gostar de algum deles e ler mais detalhes sobre a
função.


De uma forma geral, acho que programação é uma área que depende bastante
de você pensar nas coisas, nem tanto de ver "fisicamente". Então não
acho que seja perda de tempo seu, de maneira nenhuma. =)

>--
>--
>PoliGNU - Grupo de Estudos de Software Livre da Poli/USP
>http://polignu.org
>Mais informações sobre o e-group: http://groups.google.com/group/polignu?hl=pt-BR
>
>---
>Você está recebendo esta mensagem porque se inscreveu no grupo "PoliGNU - Grupo de Estudos de Software Livre da Poli/USP" dos Grupos do Google.
>Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para polignu+u...@googlegroups.com.
>Para obter mais opções, acesse https://groups.google.com/d/optout.

[Diego Rabatone]

Pessoal,
estou colocando em cópia na conversa o Lucas, que é deficiente visual e trabalha comigo.

Lucas, estou copiando abaixo os dois emails que foram enviados nesta thread, em ordem de envio.

Ah, só não esqueçam que na hora de responder tem que colocar o lucas em cópia pois ele não está na nossa lista de emails.

** email 1 **

** email 2 **

[Célio Ishikawa]

Olá pessoal, obrigado pelo interesse!

Andres, suas considerações são bem importantes, vou dar uma repensada ness parte de leitor de tela, a prinípio eu não ia usar, pois tinha pensado numa superfície que fosse ao mesmo tempo entrada da "digitação" (ou seja, não trabalhar com teclado QWERTY para inserção) e também a "tela", a saída.

Eu pensei em juntar a saída e a entrada pois é uma das tendências que estão sendo exploradas, por exemplo se antes o console de videogame era só entrada (só se apertava) e a única saída era a tela, agora o console também vibra (em jogos de corrida, por exemplo) e a vibração é uma saída. Os tablets são outro exemplo de entrada+saída pois se vê a informação na tela, mas a tela é apertável.

Agora mais especificamente para esse projeto, uma referência boa que encontrei é o PocoPoco http://youtu.be/u8MnsB0h3OU que junta som e relevo que salta para fora.

Mas estou na fase de agregar sem descartar, então estou reparando que teclado QWERTY não pode ser totalmente descartado!

Bem, uma nova leva de perguntas:

Como é para um programador aprender uma nova linguagem? É tranquilo? Como é a adaptação?

E se um programador experiente começasse a perder visão ele trabalharia apenas com a linguagem que conhece? Ou melhor, a pergunta é mais ou menos: uma pessoa cega se motivaria a entender como funciona programação?

(Bethoven continuava compondo mesmo depois de surdo, mas provavelmente ele não se motivaria a aprender música se estivesse surdo desde o começo).

Célio

--

--
PoliGNU - Grupo de Estudos de Software Livre da Poli/USP
http://polignu.org
Mais informações sobre o e-group: http://groups.google.com/group/polignu?hl=pt-BR

---

Você recebeu essa mensagem porque está inscrito no grupo quot;PoliGNU - Grupo de Estudos de Software Livre da Poli/USP" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para polignu+u...@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

[Andres MRM]

Boa, Diego! Vamos ver o que o Lucas acha da questão. =)

Então Célio, talvez seja até melhor uma interface inovadora mesmo...
Esse PocoPoco parece bem legal.
Talvez assim você consiga explorar melhor o potencial de um(a) não
vidente. As preocupações que eu tenho é de não deixar o hardware caro ou
"raro", assim como não excluir os conteúdos já existentes.
Se desse para usar o hardware já existente e se apropriar das
documentações já existentes também, me parece que haveria uma maior
liberdade.

Mas acho que para tomar essas decisões você precisaria
justamente conversar com a comunidade, até mesmo para ver quais são as
necessidades dela.

Pensando agora, um computador sem monitor é até mais portátil.
Um RasperberyPi, um teclado e um par de fones de ouvido seria tudo que
você precisaria...
Se não usar teclado, poderia colocar um Pasperbery dentro do hardware
táctil inovador que você criasse...

>Como é para um programador aprender uma nova linguagem? É tranquilo? Como é
>a adaptação?
>E se um programador experiente começasse a perder visão ele trabalharia
>apenas com a linguagem que conhece? Ou melhor, a pergunta é mais ou menos:
>uma pessoa cega se motivaria a entender como funciona programação?
>(Bethoven continuava compondo mesmo depois de surdo, mas provavelmente ele
>não se motivaria a aprender música se estivesse surdo desde o começo).

Acho que se a pessoa não vidente consegue aprender uma linguagem,
consegue aprender qualquer uma. Me parece ser algo mais de raciocínio e
menos visual. A não ser aquelas linguagens "de ligar bloquinhos" (que
mesmo assim talvez desse para dar uma adaptada).

E sobre motivação, como eu falei antes, a pessoa ainda conseguiria
sentir as saídas dos programas (seja por leitor, seja por algum
dispositivo que permita ela tatear a tela), então acho que ainda
conseguiria se motivar quase como qualquer vidente.


[]s!

[Lucas de Abreu Maia]

Caros,

Existem alguns erros conceituais nas mensagens de vocês. Não vejo
qualquer dificuldade para que um cego programe. Conheço vários cegos
programadores. A UFRJ, inclusive, tem um núcleo de programação para
cegos. Concordo que, de início, pode haver uma perda de eficiência.
ouvir um código sem dúvidas demora mais do que lê-lo. Mas há,
acredito, um ganho de precisão. Um cego não pode "passar o olho" por
nada. Somos oubrigados a ouvir tudo. Assim, fica mais fácil
identificar um erro no código.

Quanto à linguagem de programação, novamente conheço vários cegos que
programam nas mais diversas linguagens.

Sobre o output, nós, cegos, já estamos acostumadíssimos a fazer coisas
cujos resultados nos são desconhecidos. É assim até com coisa básica,
como formatação de texto. Escrevo em LaTeX e obviamente não consigo
ver o resultado. também programo gráficos em R e não vejo o resultado
final. Não chega a ser desestimulante; é simplesmente parte da nossa
vida.

--

.Lucas de Abreu Maia | Estadão Dados<http://blog.estadaodados.com/> |
O Estado de S. Paulo

Av. Eng. Caetano Álvares, 55 - Limão - São Paulo - SP - 02598-900

+ 55 11 3856-2076 | +55 11 97412-6132

[Flavio Steffen]

Lucas:

Caros,
Existem alguns erros conceituais nas mensagens de vocês. Não vejo qualquer dificuldade para que um cego programe. Conheço vários cegos programadores. A UFRJ, inclusive, tem um núcleo de programação para cegos. Concordo que, de início, pode haver uma perda de eficiência. ouvir um código sem dúvidas demora mais do que lê-lo. Mas há, acredito, um ganho de precisão. Um cego não pode "passar o olho" por nada. Somos oubrigados a ouvir tudo. Assim, fica mais fácil identificar um erro no código.
Quanto à linguagem de programação, novamente conheço vários cegos que programam nas mais diversas linguagens.
Sobre o output, nós, cegos, já estamos acostumadíssimos a fazer coisas cujos resultados nos são desconhecidos. É assim até com coisa básica, como formatação de texto. Escrevo em LaTeX e obviamente não consigo ver o resultado. também programo gráficos em R e não vejo o resultado final. Não chega a ser desestimulante; é simplesmente parte da nossa vida.

Concordo com você.
Eu trabalho com computadores há mais de 45 anos e no começo da década de 1970, no Banco Itaú havia dois programadores COBOL cegos, considerados pela gerência como estando entre os melhores cinco.
O teclado do terminal tinha caracteres em braile e uma fileira adicional apos as teclas que era um 'display' braile para as mensagens mais imediatas; ao lado deles havia uma impressora braile para que eles pudessem ver os resultados de compilação e linkedição.

Mas algo que realmente me surpreendeu foi a sensibilidade táctil, auditiva e olfativa de um deles; saímos pela Rua Boa Vista e ele com uma das mãos apoiadas em um ombro meu, identificou corretamente todos os edifícios pelos pelos odores e pelas diferenças de velocidade e odores das brisas que saiam dos saguões de cada um deles.

-- 

--

Flavio Deny Steffen
Bacharel em economia e administração de empresas
Especialista em Segurança de informações e tradutor
Economic Sciences and Business Administration Bachelor
Information Security Expert and Translator
Fones/Phones: 55 19 3312-0144 / 99701-1055
Skype: fdsteffen
Website: http://flaviosteffen.com/

---

Este email está limpo de vírus e malwares porque a proteção do avast! Antivírus está ativa.

[Andres MRM]

Oi, Lucas! Obrigado pela contribuição!
Vou te encher mais um pouco com algumas perguntas básicas...

Só para ter certeza, então vocês costumam usar o teclado comum mesmo?
Simplesmente decoram a posição das teclas como muita gente faz?
E para "ver" a interface é tudo na base do leitor mesmo?

Por exemplo, como você sabe se o documento LaTeX que você gerou está
"acessível para videntes"?

Que programa você usa para editar texto? Ele lê conforme você escreve,
letra a letra? É um editor próprio ou um qualquer que você "pluga"
nele um leitor? E em que programa você está lendo esse e-mail?

E há algo especial que você gostaria de mudar nas interfaces dos
computadores? Em matéria de hardware e de software.
Alguma sugestão do que focar, caso alguém quisesse desenvolver na área?


Abraços!

[Lucas de Abreu Maia]

Andres,

Vamos lá:
1. A imensa maioria dos cegos usa um teclado qwerty. Existem as
chamadas linhas braille, em que o teclado pode ter o formato de uma
máquina perkins, e até teclados qwerty em braile, mas nunca sequer os
ve, de maneira que você pode fazer ideia de quão raros são. Não existe
nenhuma dificuldade em decorar o teclado qwerty.
2. A maioria dos cegos atualmente usa um leitor de telas perfeitamente
integrado ao sistema operacional. Usamos os mesmos navegadores,
editores de texto etc que as pessoas enxergantes. O esforço, portanto,
deve ser na direção de fazer programas e páginas acessíveis a todos.
3. Os leitores de tela atualmente estão muito bons. Conseguem navegar
e ler bem praticamente qualquer programa ou página. As exceções são,
obviamente, imagens. Mesmo quando as imagens contêm texto, o leitor de
telas não consegue lê-las, pois seria lento demais ter um OCR que
funcionasse acoplado ao leitor de telas. Há, felizmente, vários
esforços no sentido de criar banco de dados para identificação e
descrição automatizada de imagens. Acho que essa é a próxima fronteira
e onde a maioria dos esforços de acessibilidade deveriam se
concentrar.
4. Quando programo em LaTeX ou R, sempre peço para que algum
enxergante confira o resultado para garantir que a formatação não está
zoada e que os gráficos têm as informações que desejo.

Abs,

[Andres MRM]

Obrigado pelas respostas, Lucas.
Recomenta algum leitor para Linux? Gostaria de fazer alguns teste...
Outra coisa, uma vez que você "lê" a tela, como sabe onde "clicar"? O
leitor cuida disso?

É, Flavio, imagino que em algumas situações, o fato de não se "distrair"
com a visão te permita usar melhor os outros sentidos...

>--
>--
>PoliGNU - Grupo de Estudos de Software Livre da Poli/USP
>http://polignu.org
>Mais informações sobre o e-group: http://groups.google.com/group/polignu?hl=pt-BR
>
>---

>Você está recebendo esta mensagem porque se inscreveu no grupo "PoliGNU - Grupo de Estudos de Software Livre da Poli/USP" dos Grupos do Google.

>Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para polignu+u...@googlegroups.com.

>Para obter mais opções, acesse https://groups.google.com/d/optout.

[Célio Ishikawa]

Tô vendo que vou precisar me exercitar a mudar meu raciocíno pois penso de maneira muito visual! Essa história do cego que sabia identificar prédios pela brisa e odores... fantástico! A brisa é uma coisa que nem tinha me tocado que existe na cidade pois penso em cidade e só lembro do que pode ser visto!
E reparei também que a brisa é algo em movimento, enquanto que as imagens visuais que tenho na minha cabeça são paradas!
Fazendo uma analogia, quando assisto um filme encaro como uma série de imagens paradas e para tentar prever a próxima fala do filme, acabaria vendo ou as legendas ou a leitura labial. Percebi que esse é um caminho mais longo do que ouvir os sons e prever a próxima fala.
Programação também tava encarando como algo parado, mas pensando bem tem a parte do movimento, a compilação. Eu lia o código e encarava como fotos de lábios parados para tentar imaginar a fala. Mas, bem, encarar como algo em movimento, como uma redação sendo lida tem sentido. E realmente, como na redação temos de ser expectadores e esperar o orador terminar sua fala, de fato o programador cego tem a vantagem de não deixar passar desapercebido coisas que videntes deixariam passar ao passar o olho... Interessante!
Vou refletir: o que é visual-parado parece mais manipulável, enquanto o que é oral-movimento obriga a ouvir e parece menos manipulável (ao colocar o ouvinte como passivo), mas tem a vantagem de fazer com que menos erros passem batido...
Puxa, o programador tem um compilador mental dentro de sua cabeça, mas talvez haja diferença (ou não) na forma de mentalmente colocar blocos do código para rodar!
Celio

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para polignu+unsubscribe@googlegroups.com.

Para obter mais opções, acesse https://groups.google.com/d/optout.

--
--
PoliGNU - Grupo de Estudos de Software Livre da Poli/USP
http://polignu.org
Mais informações sobre o e-group: http://groups.google.com/group/polignu?hl=pt-BR

--- Você está recebendo esta mensagem porque se inscreveu no grupo "PoliGNU - Grupo de Estudos de Software Livre da Poli/USP" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para polignu+unsubscribe@googlegroups.com.

[Célio Ishikawa]

Pessoal, se o cego se orienta pelo código que é falado para ele, isso quer dizer que quanto menos elementos é melhor para ele? Me refiro ao que, por exemplo, nesse blog sobre a história do Python se diz:

(http://python-history-pt-br.blogspot.com.br/2009/04/introducao-e-visao-geral_23.html)

... em vez de escrever comandos em C como

if (a < b) {
    max = b;
} else {
    max = a;
}

Python simplesmente dispensa as chaves (além de ponto-e-vírgula ao fim dos comandos) e usa a seguinte estrutura

if a < b:
    max = b
else:
    max = a

Imagino que essa parte de correções para o que o que se escreve em Python se torne compatível com C é relativamente fácil.

Com a história que Flávio contou sobre os 2 programadores cegos Cobol que estavam entre os melhores 5 do Itaú, fiquei curioso e ao pegar um livro aleatório sobre Cobol, acabei por distração pegando um tão antigo que era do tempo dos cartões perfurados (é, às vezes sou comédia hehehe)!

Nessas horas penso "o que Steve Jobs faria nessa situação", e como imagino que ele leria o livro mesmo assim, li e refleti que talvez a história dos programadores cegos se passasse justamente nessa época dos cartões. Foi proveitoso. Me fez perceber como estamos acostumados a imaginar o programador sentado e olhando uma tela, sendo que naquela época o programador, fazia as coisas em formulários, que depois era passado para a pessoa que perfurava, e depois os cartões perfurados eram passados ao computador. Cada linha do formula´rio preenchido tinha 80 quadrados, de forma que cada linha virava 1 cartão perfurado com 80 espaços.

Extraí disso 2 lições:

- sendo o modo de trabalho de antes muito diferente, isso me inspira a quebrar o paradigma a que estamos acostumados

- o objetivo não precisa necessariamente ser de fazer o cego fazer tudo, se antes o programador preenchia formulários, e precisava de outra pessoa que perfurava os cartões, posso fazer com que o cego seja a pessoa que pensa, planeja e programa, e o resultado ser como os formulários preenchidos. Aí depois colocar outra etapa intermediária para adequar ao computador. No caso, obviamente não seria perfurar cartões, mas adequar as pontuações para C ou Python como no exemplo lá em cima. É claro que se essa etapa de adequação não precisar de ser humano, melhor ainda pois dá mais autonomia ao trabalho do programador cego.

Célio