Acessibilidade: Muito além do Acid3
Fabião 16 anos atrás
Se você perguntar para qualquer pessoa: “Você acha correto que o governo tome medidas para inclusão plena do portador de necessidades especiais à sociedade?”, todos, sem exceção, dirão que sim. Porém, poucos são os desenvolvedores de websites e aplicações que realmente se preocupam com o acesso dos seus produtos ao público que possui deficiências motoras, auditivas e visuais, tornando a internet e o desktop uma espécie de “calçada sem guia rebaixada cibernética” e dificultando ao máximo a tarefa de navegação não convencional. No caso da web, pior ainda: Sites cheios de técnicas não ortodoxas de visualização, uso excessivo de AJAX, “captchas” imagens no lugar de texto em prol do visual e certas “gambiarras” que viram armadilhas pro coitado que tentar navegar na página usando um software leitor de tela, por exemplo.
A W3C, além de regular os padrões da web quando dizem respeito a renderização do conteúdo que aparece em nossos browsers, também mantém seus “padrões” para acessibilidade, na Web Accessibility Initiative (WAI), que sugere aos webdesigners algumas boas práticas no desenvolvimento e montagem de suas páginas. A maioria destas regras são de fácil execução e implementação, tais como sempre usar o atributo “alt” em suas imagens, para descrever textualmente a imagem que está no layout e permitir que um browser de texto (ou um daemon que leia páginas e envie para algum hipotético cara que não toma banho) exibir uma referência e possibilitar aos leitores de tela “dizerem” ao usuário o que aquela imagem é, entre outras.
Notem que não se trata de uma caridade, mas sim de respeito ao usuário e visão de mercado: Se seu site ou programa for acessível a todos, é um diferencial que pesará muito na escolha do mesmo por um portador de necessidades especiais, que também paga pelo seu programa ou conta nas visitas de seu site. Não se trata de um opcional, um “plus”, ou algo que você deva deixar por último (mesmo porque se fizer isso, vai sofrer bastante): É uma obrigação do desenvolvedor que se preze preocupar-se com a acessibilidade de seu produto, tanto quando um cozinheiro deve lavar as mãos antes de preparar o jantar.
Todavia, infelizmente, o assunto “acessibilidade” é muito pouco comentado nas discussões sobre desenvolvimento web (área da qual faço parte). Discussões sobre qual browser suporta SVG ou quantos pontos o mesmo fez a mais do que o do concorrente no teste do momento em tecnologias que não serão adotadas tão cedo, certamente são muito mais abundantes e emotivas do que recursos e técnicas de acessibilidade que podem (e DEVEM) ser adotadas já, e que os browsers já possuem suporte faz tempo.
Diferente da validação mecânica do XHTML e do CSS que usamos nos sites, a validação do conteúdo de acordo com as WCAG (Web Content Acsessibility Guidelines), embora possa ser realizada de modo automático por validadores como o brasileiro daSilva, depende, acima de tudo, do bom senso e de testes.
A maneira mais segura de saber se seu site ou programa é razoavelmente acessível é tentando usá-lo como um portador de necessidades especiais usaria; este post, aliás, é motivado pela experiência desastrosa de uso de um site meu em um leitor de tela.
Se você, desenvolvedor que leu este texto, achar que é prudente “acessibilizar” seu site (programas também, porque não?), pode usar algumas técnicas simples de teste:
- Exibir o conteúdo com as imagens bloqueadas.
- Exibir o site sem nenhuma folha de estilos.
- Verificar se a leitura do site não fica prejudicada para os daltônicos. Você pode testar facilmente isto usando o Visicheck.
- Testar seu site em browsers de texto, como o Lynx.
- Desligar o monitor e tentar usar um leitor de tela. Este é o maior soco na cara que um desenvolvedor web pode tomar, no que diz respeito a acessibilidade: Aquele ditado de “Pimenta nos olhos dos outros é refresco” vale bastante neste caso. Pelo menos pra mim, valeu.
O desenvolvedor interessado nesta brincadeira pode usar o Dosvox ou o NVDA no Windows, o Orca ou o LSR no Linux e, ponto pra Apple, se você usa o OsX depois do Tiger você já possui o VoiceOver por padrão. Aliás, neste ponto, a Apple é disparada a melhor opção para um usuário deficiente visual: Até a instalação do OSx tem suporte a braile.
Pode-se também obter mais informações no site do SERPRO, do Governo federal, ou ainda no site do Marco Antonio de Queiroz, o Bengala Legal: Marco é cego, aliás.
Pra esclarecer: A imagem do acid3 é só pra encher o saco. Eu não verifiquei, porém, PRESUMO (e espero sinceramente estar certo), que algumas dos padrões validados por ele sejam sobre acessibilidade.E o título é uma licença poética, porque, definitivamente, não é um artigo questionando os browsers, mas sim os desenvolvedores.
E também vale lembrar que a deficiência que o potencial usuário do seu programa enfrenta não se resume a problemas visuais, eu resumo bastante a abrangência aqui. E que qualquer referência a pessoas reais neste post é mera coincidência.
