Update no endereço… Avenida Presidente Wilson 164 – 12º andar
A Synapsis DI está com uma parceria bem legal de desenvolvimento com a 288 Design. Eles estão começando agora com algumas atividades e eu sugeri para eles alguns temas legais para fazer algumas palestras curtinhas, recheadas de exemplos práticos. Eu vou dar a primeira delas sobre acessibilidade:
288 atividades: Planejando interfaces Web acessíveis
A acessibilidade numa interface Web começa antes da fase codificação. Ela toma forma no briefing com o cliente. É ali que se define o público-alvo e que tipo de interação será exercida. Planejar interfaces acessíveis desde a fase zero do projeto é o melhor caminho para a experiência do usuário, seja ele qual for.
Data e hora:
Terça-feira, 9 de outubro de 2007, das 9 às 12 horas
Local: Avenida Presidente Wilson, 164 – 12o. andar – Centro – Rio de Janeiro
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:
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:
As recomendações para o Modelo de Acessibilidade de Governo Eletrônico e para a Cartilha Técnica estão disponíveis para download e abertas para consulta pública até 24 de fevereiro. Estes documentos são essenciais para quem quiser trabalhar em qualquer site nas três esferas governamentais, autarquias, empresas públicas e adjacências. Fale agora ou cale-se para sempre!
Simone Villas Boas é pós-graduada em marketing digital. Faz parte da equipe de criação do site do jornal O Globo. É evangelista de padrões Web, apaixonada por experiência do usuário.
