pixeladas aleatórias

O discurso politicamente correto da acessibilidade na Web está esgotado e deu poucos resultados. Precisamos de numa nova estratégia? Não, apenas precisamos enxergar bem mais longe do que isso.

Qualquer dicionário de bolso traz uma definição bem clara e precisa sobre acessibilidade:

acessibilidade
do Lat. Accessibilitate. s. f., qualidade de ser acessível; facilidade na aproximação, no trato ou na obtenção.
Priberam Informática – Língua Portuguesa On-Line

Não sei como, mas todos ficaram obcecados com a idéia de que acessibilidade serve apenas para usuários portadores de alguma deficiência visual. Nem mencionam miopia, hipermetropia, daltonismo ou qualquer outro defeito de percepção visual: acessibilidade é para quem possui baixa visão ou cegueira e ponto final. Desta forma, não há cliente ou chefe que seja convencido a pagar a mais pela verificação de acessibilidade de um código, mesmo que a especificação seja criada para impedir qualquer tipo de obstáculo ao acesso a qualquer tipo de usuário.

Somos todos míopes

Esta percepção também é uma herança de nossa arrogância nos primeiros anos do desenvolvimento Web. Focamos o projeto em um público-alvo bem específico e construímos o melhor do mundo para estes usuários.

Anos atrás, durante um curso de usabilidade, participei de um grupo que fazia um teste em um website de uma montadora de veículos. O site era inteiramente em Flash, daqueles altamente “interativos” com efeitos de som para cada botão na interface. Quesítionados se algum portador de deficiência visual poderia ter acesso àquela informação, chegamos à conclusão que cegos não precisam acessar sites de carros e partimos para o ponto seguinte. Qualquer discussão com este foco acaba sempre em um beco sem saída.

Olhando um pouco mais para o futuro onde usaremos mais dispositivos móveis e mais computação ubíqua, será que poderemos usar um site projetado para computadores desktop e obter a mesma experiência em um celular? Talvez esta interface consiga ser acessível de qualquer outro dispositivo que não um computador com teclado e mouse, mas eu não apostaria meu emprego nisso.

Imagine um usuário Web avançado usando seu smartfone num táxi. Ele deseja comprar um carro novo. Neste instante, passa por ele um modelo 2008, incrível, de sua montadora favorita. Imediatamente, ele sente vontade de acessar o website da montadora para verificar as especificações do carro e condições de financiamento. Este usuário pode estar a um passo da decisão de compra do produto, mas se ele não conseguir acessar imediatamente, como ele está acostumado a fazer, o desejo esfria e a memória sobre o modelo vira fumaça.

Robôs: os preteridos

Numa era onde falta apenas enviar flores com dedicatórias amorosas para o GoogleBot para convencê-lo a indexar as páginas com mais atenção e carinho, não acredito que ninguém pense na sua acessibidade. Afinal, ele é um usuário como qualquer outro.

Bem, isso não é inteiramente verdade. O GoogleBot ainda não passou no Teste de Turing, é totalmente cego e surdo, não entende JavaScript, entende muito pouco de Flash, entre outras limitações que o distinguem de um navegador moderno e de um usuário humano. Poucos usuários devem ser tratados com tanto amor e ao mesmo tempo são tão desprezados pela maior parte dos desenvolvedores Web.

WCAG não é tudo na vida

A principal lista de verificação de acessibilidade em uso é WCAG 1.0. É um documento de oito anos numa mídia onde tudo muda de um ano para o outro. Não é exatamente o que podemos chamar de confiável. Há vários parâmetros interessantes, mas outros passam batidos.

Por exemplo: muitos afirmam que para uma interface ser acessível ele não precisa ser construído com marcação semântico e CSS design. E ele de fato consegue passar um site montado com tabelas em um verificador automático e conseguir o selo de conformidade que desejar, mas ele não cumpriu o WCAG 1.0 de verdade e nem conseguiu uma interface realmente acessível. O desenvolvedor foi iludido porque considerou apenas o mundo ideal de acesso usando um computador desktop. Em qualquer outro dispositivo o acesso à informação fica seriamente comprometida. Além disso, há várias citações à marcação semântica na lista, como nas seções 2, 3 e 11.

Há uma nova versão do rascunho do WCAG 2.0. A principal diferença entre este e seu antecessor é que o foco saiu dos usuários com necessidades especiais e o W3C passou ambicionar que a Web atinja realmente todos usuários, “independentemente do seu equipamento, software, infra-estrutura de rede, idioma, cultura, localização geográfica, ou habilidade mental ou física” [W3C in 7 points]. Ainda é um rascunho e não há verificadores automáticos para ele. Por enquanto, segue a regra: não faça do WCAG uma verdade absoluta. O seu julgamento enquanto usuário, desenvolvedor e testador é bem mais importante do que um selinho de conformidade gerado por um robô.

Além disso, o grupo WCAG Samurai fez uma revisão interessante sobre a lista de verificação original do W3C.

O melhor verificador

A solução mais fácil para garantir a acessibilidade de um dispositivo é ser simples. Construa as interfaces do seu website ou seu webapp respeitando os padrões Web e acrescente as camadas de aprimoramento da experiência do usuário aos poucos. Não faça com que este aprimoramento se torne um obstáculo. Se for importante para conseguir o reconhecimento de algum verificador automático para exibir um selo de conformidade, é necessário apenas seguir as especificações tomando um ou outro cuidado especial de acordo com o tipo de elemento utilizado.

O compromisso com a acessibilidade vai além de um selo de conformidade. Leia de novo todas as tags XHTML e seus atributos. Desta vez, preste atenção onde é possível melhorar a acessibilidade. Nos formulários mais complexos das webapps, abuse dos atributos accesskey e tabindex para otimizar a realização da tarefa. Verifique mesmo o conteúdo alternativo de elementos multimídia para melhorar a indexação do documento por um mecanismo de busca.

A verificação de acessibilidade é uma tarefa diária no desenvolvimento Web e é responsabilidade de todos na equipe. Cada um tem uma pespectiva própria de uma interface e deve opinar no código sim. No desenvolvimento de aplicativos, é importante o acompanhamento do usuário realizando a tarefa. Nos testes de usabilidade, leve alguém que entenda de marcação HTML que possa ajudar a criar atalhos para os usuários avançados, identificar quais conteúdos podem ser omitidos ou mostrados de acordo com a mídia utilizada, entre outros fatores.

Palestra sobre planejamento de interfaces acessíveis para Web

Em outubro, fiz uma palestra (na realidade, uma mesa redonda) para discutir o projeto de interfaces Web acessíveis para a maior parte dos usuários. Esta foi a apresentação:

Referências:

• O grupo de pesquisa AcessoDigital.net fez um vídeo sobre acessibilidade na Web.
• Ivo Gomes publicou hoje um artigo sobre softwares leitores de tela com um vídeo muito legal do engenheiro de acessibilidade do Yahoo! Victor Tsaran.
• Acessibilidade web: 7 mitos e um equívoco, por Leda Spelta no Acesso Digital.