Acessibilidade

Acessibilidade

O "leitor de tela básico em braille" foi adicionado recentemente ao kernel do Linux e, com ele, um subdiretório drivers/accessibility e a opção CONFIG_ACCESSIBILITY correspondente. Vale destacar que as primeiras reações foram do tipo "que raios é essa tal de acessibilidade?". Isso mostra como a idéia é pouco conhecida entre os desenvolvedores.
E olha que a acessibilidade no GNU/Linux, ou seja, a usabilidade do GNU/Linux por portadores de deficiência (como cegos, por exemplo), obviamente não é nova. Já há trabalho nessa área faz tempo: a versão 0.07 do leitor de tela speakup foi lançada para o kernel 2.2.7 em 1999, e o leitor de tela em braille brltty foi iniciado em 1995. O leitor de tela básico em braille que acaba de ser adicionado ao kernel do Linux é apenas a parte visível desse trabalho que já está em andamento há anos.



Com a popularização do GNU/Linux entre o público não-técnico, tem havido um interesse renovado por um suporte mais mainstream à acessibilidade: o desktop GNOME, o OpenOffice.org e o Firefox 3 agora podem ser renderizados por sintetizadores de voz e braille graças ao framework AT-SPI e ao leitor de tela Orca. Assim que essas tecnologias forem adaptadas ao D-BUS, o KDE também vai aderir. Além disso, começaram a aparecer menus de acessibilidade nas distribuições.
Uma das maiores preocupações dos portadores de deficiência costumava ser a falta de suporte ao Javascript nos navegadores em modo texto e a falta de suporte das suítes de escritório. Conforme mais e mais empresas e governos migram para o Linux, especialmente devido à exigência de alguns estados por acessibilidade nas ferramentas usadas pelo governo, um esforço renovado no desenvolvimento foi se tornando cada vez mais uma necessidade. Em Massachusetts, o povo chegou a fazer um abaixo-assinado contra a migração para o software livre porque, na época, ele não oferecia as ferramentas de acessibilidade necessárias!

O que é acessibilidade?

Acessibilidade, também abreviada como a11y, é fazer com que um software possa ser utilizado por pessoas portadoras de deficiência. Isso inclui os cegos, é claro, mas também pessoas com pouca visão, surdos, daltônicos, pessoas que só têm uma das mãos ou que só podem mover alguns dedos ou apenas os olhos. Pessoas com problemas cognitivos (ainda que leves) ou não familiarizadas com a linguagem também estão incluídas. Por último, mas não menos importantes, os idosos, que têm um pouco de todas essas deficiências. Sim, isso quer dizer que, um dia, todo mundo vai estar incluído nesse grupo. Isso implica em suporte a dispositivos especiais, mas também em precaução no desenvolvimento, evitando presumir que um alarme sonoro será ouvido, ou que uma breve mensagem será lida.
Talvez uma das técnicas de acessibilidade mais óbvias sejam os sintetizadores de voz, que transformam texto em áudio que pode ser enviado aos alto-falantes e fones de ouvido. Já houve sintetizadores de voz baseados em hardware (suportados pelos drivers do speakup), mas a maioria deles vem sendo substituída pelos sintetizadores de voz baseados em software. Embora a qualidade do software comercial para sintetizar voz seja muito boa hoje em dia, a qualidade das alternativas livres varia bastante. Existem sintetizadores de voz livres muito bons para a língua inglesa, mas o suporte a outros idiomas varia. Por exemplo, os engines Festival e eSpeak suportam vários idiomas, mas o som é robótico demais. Há bibliotecas de fonemas melhores, como o mbrola, mas elas geralmente não são 100% livres. Para lidar de maneira mais eficiente com esses backends de sintetização de voz, o daemon de voz precisa escolher automaticamente a sintetização apropriada, de acordo com o idioma e o estilo desejados.
Outro tipo de dispositivo muito popular é o terminal braille. Ele "exibe" o texto levantando e abaixando pequenos pinos que formam os padrões do braille. O terminal braile custa caro, e geralmente tem espaço para apenas 40 caracteres, ou mesmo por volta de 12 ou 20. Ele tem teclas para navegação pela tela, e com isso o usuário vai lendo em partes. Comparado aos sintetizadores de voz, o terminal braille é muito mais preciso, mas nem todo mundo pode ler em braille, e o preço é muito alto (em torno de 5.000 dólares). O suporte aos vários dispositivos existentes é muito bom: dentre os leitores de tela, tanto o brltty quanto o suseblinux suportam uma ampla variedade de dispositivos.
Os cegos provavelmente usarão dispositivos em braille e sintetizadores de voz em conjunto. Os dispositivos para os outro tipos de deficiência variam bastante. Eles vão de joysticks (suportados nativamente pelo X.org) a sistemas que acompanham o movimento dos olhos (gerenciados pelo dasher), fazendo uso do apertar de botões (suportado pelo GOK, o teclado de tela do GNOME) ou da mera ampliação da tela (implementada pelo gnome-mag).

Uso Diário

A eterna guerra entre a linha de comando e a interface gráfica também se encena entre os usuários de terminais braille e sintetizadores de voz. O contraste entre as duas interfaces talvez seja ainda mais exacerbado pelas dificuldades inerentes à realização de tarefas no computador por pessoas portadoras de deficiências.
A velha maneira tradicional de se usar um sistema GNU/Linux, o console de texto, funciona bem com os dispositivos em braille e com os sintetizadores de voz há tempos. O princípio é bem simples: são 25 linhas de 80 caracteres, e o texto é apresentado seqüencialmente. Com isso, os leitores de tela para terminais braille exibem automaticamente apenas o que foi escrito mais recentemente, permitindo ao usuário navegar entre as 25 linhas. Os leitores de tela com sintetizador de voz, como o speakup e o yasr, falam o texto conforme ele se apresenta na tela, além de oferecer alguns recursos de análise semelhantes ao dos leitores de tela em braille. Isso funciona muito bem, porque os aplicativos estão limitados à interface TTY e não possuem recursos mirabolantes e inacessíveis como botões gráficos. Alguns aplicativos podem não ser lidos com tanta facilidade, como por exemplo, os que usam desenhos em ASCII ou os que usam cores para indicar os botões ativos, mas esses aplicativos costumam ter opções para maior acessibilidade. Uma coleção de dicas pode ser encontrada neste wiki.
Já a acessibilidade nos desktops gráficos é um assunto bem mais recente, em parte porque o problema técnico é bem mais complicado: enquanto os aplicativos em modo texto são limitados à produção de texto, os aplicativos gráficos modernos muitas vezes renderizam o texto como bitmaps, fazendo com que as informações do texto não estejam disponíveis para os leitores de tela. Já houve tentativas de se adaptar aplicativos no passado (como o ultrasonix), mas a iniciativa nunca se popularizou. O projeto GNOME vem desenvolvendo a AT-SPI (Assistive Technology Service Provider Interface, ou interface provedora de serviços para tecnologia assistiva) desde a década passada, e com o advento do leitor de tela Orca ela se tornou uma promessa e tanto. A AT-SPI pode ser entendida como um protocolo entre os leitores de tela como o Orca e os aplicativos. Para ser "acessível", um aplicativo precisa implementar a AT-SPI ou usar um toolkit que a implemente, como o GTK ou (em breve) o Qt, para que os leitores de tela possam obter o conteúdo lógico e textual do aplicativo. O Orca ainda não é maduro o suficiente para fazer tudo o que os leitores de tela proprietários do Windows fazem, mas já é suficientemente útil para o trabalho diário. Ele está avançando rapidamente, graças ao apoio da Sun e ao envolvimento do Accessibility Free Software Group, o grupo de acessibilidade do software livre. No momento em que este artigo foi escrito, apenas o Gtk+ 2 (e conseqüentemente o desktop GNOME e os aplicativos Gtk+ 2), o Java/Swing, a suíte Mozilla, o OpenOffice.org e o Acrobat Reader implementam a AT-SPI e são acessíveis. O suporte do Qt (e do desktop KDE) deve se concretizar assim que a tecnologia for adaptada ao D-BUS. Para melhores resultados, recomenda-se o uso das versões mais recentes dos aplicativos; o Firefox, por exemplo, só é realmente acessível a partir da versão 3.
Outra abordagem é utilizar aplicativos que implementem a leitura por conta própria. O Firevox é uma versão do Firefox que vem com um leitor de tela dedicado integrado. Isso permite uma maior integração entre o leitor e o aplicativo, mas seu uso é limitado ao aplicativo específico. Outro exemplo é o emacspeak, uma versão "vocalizada" do emacs. Algumas pessoas usam apenas o emacspeak e mais nada, pois o emacs já faz tudo o que elas precisam.
No fim das contas, cada pessoa tem um grau de satisfação. Algumas vão gostar muito do maduro e eficiente leitor de tela do console de texto; outras vão considerar isso um retrocesso (como um retorno ao DOS) e vão preferir ambientes intuitivos como o GNOME, embora o leitor de tela Orca ainda seja muito recente. É bem comum o uso de ambos: o console de texto para o trabalho habitual e o ambiente gráfico para tarefas que o exijam, como a navegação por sites com Javascript ou a manipulação de documentos do OpenOffice.

Integração ao upstream

E como instalar isso tudo? A maioria das distribuições já oferece boa parte dos pacotes úteis, mas não a documentação sobre quais ferramentas são úteis para cada deficiência. O site de recursos de acessibilidade no Linux é uma fonte bastante completa de informações sobre as várias ferramentas que podem ser usadas. Também há um wiki para que os administradores dêem os primeiros passos no assunto.
Vale notar que algumas distribuições têm componentes de acessibilidade integrados aos CDs de instalação. Por exemplo, o instalador do Debian (a partir do Etch, também conhecido como Debian GNU/Linux 4.0) detecta terminais braille automaticamente e, caso os encontre, muda para o modo texto, roda o brltty e se assegura de que o brltty seja instalado e configurado no sistema alvo. É comum o caso de distribuições que são adaptadas extra-oficialmente, com imagens de instalação "braillificadas". O mais importante é que isso permite que pessoas portadoras de deficiência visual sejam absolutamente independentes da ajuda de pessoas que enxerguem. Nesse aspecto, o Windows está bem atrás das conquistas do GNU/Linux.

Desafios futuros

Resumindo, o GNU/Linux "acessível" também está se democratizando, só que esse processo está acontecendo um pouco depois da democratização do Linux tradicional. Claro que há muito a ser melhorado. Ainda que geralmente as distribuições contenham software de acessibilidade, é difícil para os portadores de deficiência recém-chegados saberem quais softwares podem ser úteis para cada tipo de deficiência; as distribuições vão ter que desenvolver assistentes para orientá-los. Enquanto isso, sites como o site de recursos de acessibilidade no Linux podem ser usados como fontes de informações. De qualquer maneira, é essencial que haja um debate com os usuários portadores de deficiência para que se estabeleça uma solução adequada (não adianta ter saída em braille se o usuário não sabe ler em braille).
Além da instalação e do uso comum do GNU/Linux, os estágios iniciais do boot ainda não são muito acessíveis. Com o desenvolvimento do leitor de tela básico em braille, o kernel do Linux um dia deve ser capaz de oferecer um feedback básico ao usuário antes mesmo que os daemons dos leitores de tela em espaço de usuário possam ser iniciados no disco rígido. Os gerenciadores de boot como o Lilo e o Grub podem emitir bips básicos, mas seria necessária alguma ajuda para editar com precisão a linha de comando do kernel, por exemplo. Por último, mas não menos importante, os portadores de deficiência já podem alterar as configurações da BIOS em máquinas avançadas com consoles seriais. A democratização da plataforma EFI pode ser uma boa oportunidade para embutirmos funcionalidades básicas de leitura de tela.