A palavra “Deficiente visual” é abrangente demais – podemos falar de daltônicos, míopes (que é meu caso, por exemplo), hipermétropes, fotofóbicos e etc, e não é objetivo falar sobre tudo isso nesse artigo. Logo, acho que usar a palavra “cego” (que não vejo por onde possa ser ofensiva) define muito bem o tipo de usuário com o qual estamos preocupados.

Por que essa preocupação? Veja bem, isso não é “bondade”, diria até que está mais para uma obrigação. Além, é claro, de permitir igual acesso ao máximo de pessoas possível, lembre-se que é mais um recurso que pode aumentar o número de usuários e, por consequência, fideliza-los.

Internet acessível

Há toda uma gama de recursos atualmente que auxiliam pessoas com necessidades especiais a ter acesso à internet. Estes aparatos podem variar de simples varinha para auxiliar pessoas com movimentos restritos até complexos hardwares para cegos-surdos que convertem textos para braile.

No caso específico dos cegos, o recurso mais comum é o Screen Reader – que nada mais é do que um programa que converte palavras para áudio. Infelizmente, segundo um vídeo no Webaim, percebe-se a grande maioria dos websites não é escrito de forma que possa ser facilmente compreendido por estas ferramentas.

Acessibilidade: por onde começar?

Acima de tudo, acessibilidade tem em seu princípio a regra de ouro de qualquer programa ou aplicação web, a regra KISS! (Keep it simple, stupid! – ou em tradução livre “mantenha isso simples, estúpido!”). Quanto mais robusto e simples o seu código, melhor a qualidade do texto “narrado” pelo Screen Reader. Evite usar scripts complexos no corpo da página, gambiarras que sujem o código (em especial POGs de crossbrowser) e atributos desnecessários.

Seu site precisa ser navegável via teclado

Um cego nunca usará o mouse para navegar uma vez que ele não teria como saber onde posicionar o cursor, o que o obriga a navegar basicamente usando o TAB e enter do teclado. Pode parecer estúpido citar isso aqui uma vez que, à primeira vista, parece um pensamento óbvio – mas é fato que são poucos os desenvolvedores e designers param e pensam a respeito das implicações que isso traz para a interface, tanto no design quanto na construção html/css.

Linearidade

Quando construir a página certifique-se que todo o conteúdo está disposto de forma linear, de forma que com o css desabilitado o texto esteja sequencial. Muitas vezes, por questão de facilitar o alinhamento crossbrowser, é comum inverter dois boxes de posição e ajusta-los via css. Isso faz com que o Screen Reader leia boxes de forma invertida também.

O melhor teste para ver se a linearidade está correta é desabilitar o css do Browser e checar como o texto se alinha na página – o ideal é que os boxes fiquem um abaixo do outro.

Vá direto ao ponto

Esta é a coisa mais simples que pessoas poderiam fazer para melhorar a acessibilidade de um site e que infelizmente não é difundida o suficiente: ao montar a página coloque no topo um link “ir direto para o conteúdo” e linka-lo à uma ancora no ponto que o texto começa. Este link não necessariamente precisa ter visual, ele pode ser escondido de forma que só é acessivel pelo screen reader. Dica: eu não tenho certeza se os screen readers mais modernos entendem quando o bloco está com “display:none”, então, por via das dúvidas, uma sugestão de código para esconder este link é o seguinte:

.escondeLink {

position:  absolute;

display:block;

margin-top:  -4000px;

}

Repare que desta forma você não “apagou” o link da página, somente tirou-o da área visual do browser.

O ideal para aplicação desta ancora é que ela esteja logo após a abertura da tag BODY. Um exemplo de como deve ser usado pode ser visto no próprio http://www.webaim.org .

Outra preocupação para não ter problema com os robôs do google, é fazer uma indicação explícita que esses links não devem ser indexados, já que as âncoras podem ser interpretadas como uma nova URL:

<a rel="nofollow" href="http://afronteirafinal.com#conteudo">
A Fronteira Final
</a>

Cuidado com chamadas nos links e comandos JavaScript

Esta regra é similar à aplicada a SEO: evite criar links que não deixem claro seu destino. Evite ao máximo “clicando aqui”, “clique”, etc.

Sempre dê preferência por ser específico, usando coisas como por exemplo “Conheça o site A Fronteira Final” à “Conheça o site a fronteira Final clicando aqui“. Cegos e buscadores agradecerão por este simples cuidado.

Outra coisa a respeito dos links é que eles TEM QUE APONTAR PARA ALGUM LUGAR. Evite chamar funções javascript nos links pois isso tende a confundir os Screen Readers e outros softwares de interpretação. E lembrando: dependendo da forma como o comando JS responde, pode ser que ele iniba a navegação via teclado.

Efeitos OnMouseOver e OnMouseOut

Só para enfatizar o tópico anterior, eventos relacionados a ações do mouse estão entre os grandes vilões da acessibilidade. Tenha sempre em mente que estes dois comandos ou qualquer outro evento relacionado diretamente à captura de mouse devem ser descartados se afetarem a navegação via teclado ou proporcionarem qualquer tipo de informação que só possa ser assimilada de forma visual.

Alt nas imagens

Outra regrinha que também vale para SEO: sempre coloque a descrição correta nas imagens do seu site de forma clara e concisa. Escrever “Circo” ao invés de “Foto do Cirque du Soleil em apresentação no Morumbi” é algo que pode fazer muita diferença quando você não tem a referência visual.

Cor/imagem como informação

Evite ao máximo usar qualquer informação que dependa de cor, imagem ou animação para compreensão plena do texto. Se não houver como escapar, tente criar algum recurso textual (alt, legenda, um parágrafo falando o que é o signo acima) que amenize ao máximo este problema. Tente usar este tipo de recurso apenas no ambito da estética.

Tabelas e formatos especiais

Evite a todo custo tabelas complexas. O Screen Reader vai tentar le-la da esquerda para a direita, ficando difícil de compreender o tipo de conteúdo que ela contém.

Outro cuidado é com formatos diferenciado como os Microformatos. Pode usar sem medo, desde que os Microformatos sejam aplicados de forma correta.

Tabelas, quando necessárias, devem ser escrita de forma semanticamente correta para que o Screen Reader, evitando qualquer confusão para a interpretação de Screen Readers ou qualquer outro recurso. Veja o exemplo abaixo:

<table><caption>texto</caption>
<thead>
<tr>
<th> texto</th>
<th> texto</th>
<th> texto</th>
<th> texto</th>
</tr>
</thead>
<tfoot>
<tr>
<th> texto</th>
<th> texto</th>
<th> texto</th>
<th> texto</th>
</tr>
</tfoot>
<tbody>
<tr>
<th> texto</th>
<td>texto</td>
<td>texto</td>
<td>texto</td>
</tr>
<tr>
<th> texto</th>
<td>texto</td>
<td>texto</td>
<td>texto</td>
</tr>
<tr>
<th> texto</th>
<td>texto</td>
<td>texto</td>
<td>texto</td>
</tr>
</tbody>
</table>

Outro formato que merece cuidado é o formulário, que deve ter todos os campos, labels e teclas de acesso nos lugares corretos.

<form id="form" method="post" action="#">
<fieldset>

<legend>Dados pessoais</legend>
<label for="nome">Nome</label>
<input id="nome" name="nome" type="text" title="Nome" alt="Nome" tabindex="1" accesskey="n" />
<label for="email">E-mail</label>
<input id="email" name="email" type="text" title="E-mail" alt="E-mail" tabindex="2" accesskey="e" />
</fieldset>
<fieldset>

<legend>Destinatário</legend>
<label for="departamento">Selecione o departamento</label>
<select id="departamento" name="departamento" title="Departamento" tabindex="3">
<optgroup label="Departamento 01">
<option value="nomefunc01" title="Nome do funcionário 01">Nome do funcionário 01</option>
<option value="nomefunc02" title="Nome do funcionário 02">Nome do funcionário 02</option>
</optgroup>

<optgroup label="Departamento 02">
<option value="nomefunc01" title="Nome do funcionário 01">Nome do funcionário 01</option>
<option value="nomefunc02" title="Nome do funcionário 02">Nome do funcionário 02</option>
</optgroup>
</select>
</fieldset>
<fieldset>
<legend>Mensagem</legend>

<label for="mensagem">Escreva sua mensagem</label>
<textarea id="mensagem" name="mensagem" cols="100" rows="10" title="Escreva sua mensagem" tabindex="4" accesskey="m"></textarea>
<input id="enviar" name="enviar" type="submit" value="Enviar" title="Enviar" alt="Enviar" tabindex="5" accesskey="s" />
</fieldset>
</form>

Para saber mais

Seguindo essas regras simples a qualidade do seu site aumentará bastante mas, como em tudo que se relaciona com internet, é um assunto “saco sem fundo”, daqueles que quanto mais você estuda mais tem a estudar. Alguns sites para procurar mais informação à respeito:

http://www.webaim.org/ – citado duas vezes no texto, é uma organização focada em acessibilidade e possuí material vastíssimo sobre o assunto.

http://brasilmedia.com/Acessibilidade-na-Web.html – A Brasil Média pegou parte do material do Webaim e verteu para o português.

http://www.acessibilidadelegal.com/ Um bom site em português também, mas este com produção própria de artigos. Vai um pouco mais fundo nos tópicos levantados neste artigo.

http://www.w3c.br/index-3dez-1.htm – Quer entender como um cego navega? A W3C lançou um hotsite que simula esta experiência.

http://imasters.uol.com.br/artigo/12814 – Ótimo artigo de Horácio Soares sobre como realizar os testes de usabilidade, com vários links e referências de programas, validadores e sites com orientações valiosas.

Padronização para elementos comuns em sites

Qual a vantagem real disso? Um desenvolvedor esperto perceberá que, usando ou criando os devidos plugins, a extração e conversão de dados para qualquer formato em uma página é muito mais fácil. Um exemplo interessante disso é o hCard, que permite puxar e exportar dados cadastrais ou eventos em um formato reconhecível por qualquer gerenciador de e-mails  (seja online, seja um outlook da vida).  Num futuro pode-se até pensar em browsers que já venham com funções nativas voltadas que use este tipo de recurso, valendo-se de APIs como o Google Maps ou o Yahoo Maps, por exemplo.

E claro, como toda padronização, ela auxilia na usabilidade,  pois facilita a vida de vários “interpretadores” (screen readers, browsers, aplicativo Air, etc) na forma de usar a informação fornecida.

Melhora na qualidade para indexadores de busca

Não encontramos dados do quanto de relevância os buscadores estão a dar para os microformats, embora tanto o Google quanto Yahoo já tenham anunciado suporte. De qualquer forma, o fato dos algorítimos de busca interpretarem qualquer coisa como texto (mesmo que sejam tags), já indica que os microformatos por si só são “alimentadores de relevância” por natureza.

Um exemplo que pode ser visto é este:  quando realizamos uma esta busca no Google, um dos resultados apresentados (o terceiro, logo abaixo do título) já possui quantidade total de reviews a respeito do estabelecimento procurado.  Isto é possível graças ao hReview que, como o proprio nome sugere, serve para destacar uma opinião sobre um produto, serviço ou quaquer outra coisa.

Humanamente “entendível”

Ao contrário de outros formatos de proposta similar, os microformats tem como conceito ser primeiro compreensível por seres humanos e somente depois por máquinas.  A sintaxe é muito mais intuitiva, mais simples de compreender e memorizar. Acredito que essa é de longe sua principal vantagem sobre o RDFa, por exemplo, que não só é um código mais complexo como ainda por cima possui uma série de padrões diferenciados. Outra vantagem sobre RDFa é que os microformatos permitem ao desenvolvedor a escrever BEM menos código, mantendo uma sintaxe simples, limpa e totalmente intelígivel para qualquer outra pessoa que mexa no código depois – mesmo que não familiarizada com estas definições (no futuro pretendemos entrar novamente no assunto RDFa x microformatos, agora não é o momento).

Aplicável ao HTML 5, XHTML 2

As próximas versões de HTML e XHTML tem, entre outras propostas, aplicar para a web do futuro o conceito de Web Semântica (aquela história de que toda informação deve ser um ‘pacote completo’ de dados e referências, manja?), o que vai suprir parte da necessidades propostas pelos Microformats. Embora muita gente já esteja usando estas definições, a web ainda não está pronta para lidar com eles – Por que não usar os microformatos, que não impactarão em absolutamente nada na codificação e já são aceitos e usados? Ele não conflitará em absolutamente nada com HTML 5 ou XHTML 2 e, de lambuja, ainda ajudará os buscadores a indexar e classificar seu site de forma bastante precisa.

Problemas com microformats

Em 2008 a BBC renunciou ao uso dos microformatos por conta do formato hCalendar. Este formato cria um problema de acessibilidade por usar a tag abbr como marcador e não como uma abreviação propriamente, o que confunde boa parte dos screen readers. Num contexto normal, ela seria usada assim:

<abbr title="Organização Mundial de Saúde">O.M.S</abbr>

Um screen reader habilitado para ler siglas por extenso leria este trecho como “Organização Mundial de Saúde”.

No caso do hCalendar, a tag é usada da seguinte forma:

<abbr title="20070312T1700-06">March 12, 2007 at 5 PM</abbr>

O screen reader não leria como data,  mas sim  “Vinte milhões, sete mil e trezentos e 12 TÊ mil e setecentos traço zero seis”.  Já existe um fix para isso sugerido pela própria Microformats.org (que são os pais da criança), usar span no lugar de abbr.

Até onde testamos e pesquisamos este foi a única problema registrado. Usamos o FANGs para emular a acessibilidade para deficientes visuais.

Mas é só isso?

Por enquanto sim. O assunto é extenso demais para ser tratado num único post – num futuro não muito distante voltaremos a ele e nos aprofundaremos em pontos mais específicos. Enquanto isso não ocorre, a lista abaixo fornece uma bela gama de coisas para brincar. Divirta-se!

Microformatos – Referências

http://microformats.org – site oficial do projeto. Todas referências, exemplos, geradores automáticos, wiki e lista de discussão estão lá.

http://en.wikipedia.org/wiki/Microformat – tópico na wikipédia, a informação técnica resumida.

https://addons.mozilla.org/pt-BR/firefox/addon/4106 – Operator, ADD-on do firefox que detecta e importa dados de microformatos. Tem alguns problemas ainda, mas já dá uma bela visão de usos.

https://addons.mozilla.org/pt-BR/firefox/addon/402 – FANGS: um emulador de screen reader. Infelizmente, após a atualização do Firefox para a versão 3.5 ele perde a compatibilidade. Espero que resolvam logo este problema, estava usando-o para uma pesquisa de acessibilidade.

http://www.semanticfocus.com/blog/entry/title/microformats-vs-rdf-how-microformats-relate-to-the-semantic-web/ – Artigo que aprofunda-se um pouco na discussão a respeito do formato RDFa vs Microformats.

http://googlewebmastercentral.blogspot.com/2009/05/introducing-rich-snippets.html – mostra a implementação feita pelo google para o formato hReview

http://www.google.com/search?q=Drooling+Dog+BarBQ – Link para a busca com o resultado do google.