Como testar a acessibilidade em Websites? (parte 1)


Existem diferentes maneiras de testar a acessibilidade de um Website: testes automáticos, semi-automáticos, manuais com especialistas, usuários, etc.

Para o especialista em acessibilidade, Joe Clark, a acessibilidade deve ser testada: “...da mesma forma que testamos os Websites, com pessoas de verdade...”.
Capítulo 14 Certification and Testing do seu livro Building Accessible Websites.

Esse artigo tem como objetivo apresentar os diferentes testes, softwares e técnicas de avaliação de acessibilidade de um Website.

Como ainda não existe uma metodologia homologada para testar a acessibilidade de Websites, este trabalho estará sempre sujeito a mudanças, correções e inclusões. Quaisquer troca de experiências entre nossos leitores sobre: novas técnicas, softwares e metodologias de testes, serão devidamente analisadas e, se for o caso, incluídas neste trabalho com indicação da fonte.

Antes de aplicar qualquer teste de acessibilidade é importante não esquecer de incluir nos projetos Web, as técnicas, melhores práticas e diretrizes de acessibilidade para Internet. Essas técnicas devem fazer parte da metodologia de desenvolvimento de sites. Torná-lo acessível, deve ser um processo de aprendizagem contínua, onde somente a prática pode garantir um bom resultado.

Lista com links para cartilhas de acessibilidade, recomendações, dicas, artigos, etc.:


Mitos x Intormação


Apesar de um significativo avanço em 2005, ainda é freqüente a falta de informação sobre acessibilidade, usabilidade, arquitetura da informação e os padrões Web (Web Standards), nas equipes de desenvolvimento de sites.

Ao discutimos o assunto acessibilidade na Web com os profissionais da área, percebemos que alguns ainda não tem a menor idéia do que é acessibilidade e, uma grande parte, não está bem informada sobre o assunto. Muitos Webdesigners acham que a acessibilidade limita a criatividade e torna as páginas pouco atraentes, programadores acreditam que vai atrasar e atrapalhar seus projetos e gerentes que o custo da acessibilidade é alto e que o retorno não compensa.

Esses mitos/paradigmas devem ser derrubados através da informação e capacitação dos profissionais da área sobre o que é acessibilidade e o que devem fazer para tornar um site acessível. Todos os envolvidos no desenvolvimento de projetos Web devem ter ciência dos benefícios que a acessibilidade trás para a empresa, clientes e a sociedade.

Um Website acessível não é sinônimo de um pouco criativo e com limitações visuais. Se a acessibilidade fizer parte do processo de criação e desenvolvimento do projeto, não comprometerá o cronograma, o orçamento, nem o trabalho de ninguém. Se for aplicada corretamente pode evitar perda de clientes, processos judiciais, desperdício de tempo e dinheiro com retrabalho, problemas com a imagem da empresa e outros.


Testes de Acessibilidade


Em alguns testes utilizei a Homepage do MTE - Ministério do Trabalho e Emprego como base para as análises.


Primeiro: testes automáticos e semi-automáticos


O primeiro passo é testar as páginas que compõem o site nos avaliadores de acessibilidade que são softwares que detectam o código HTML de uma página Web e fazem uma análise do seu conteúdo, normalmente baseados na Iniciativa de Acessibilidade na Web do W3C. Dentro de um conjunto de regras, avaliam o nível de acessibilidade das páginas pesquisadas, produzindo automaticamente relatórios detalhados segundo os três níveis de prioridades:

Prioridade 1 - Pontos que os criadores de conteúdo Web devem satisfazer inteiramente. Se não o fizerem, um ou mais grupos de usuários ficarão impossibilitados de acessar as informações contidas no documento*.

Prioridade 2 - Pontos que os criadores de conteúdos na Web deveriam satisfazer. Se não o fizerem, um ou mais grupos de usuários terão dificuldades em acessar as informações contidas no documento*.

Prioridade 3 - Pontos que os criadores de conteúdos na Web podem satisfazer. Se não o fizerem, um ou mais grupos poderão se deparar com algumas dificuldades em acessar informações contidas nos documentos*.

Apesar de testarem apenas um limitado conjunto de regras, os avaliadores são muito úteis durante o processo de desenvolvimento de Web Sites acessíveis, pois ajudam o Webdesign/desenvolvedor, a encontrar erros e esquecimentos, apontando com exemplos, como acertar os itens listados.

A maioria dos avaliadores têm versão online gratuita, mas só podem testar uma página HTML de cada vez. Alguns softwares como o Bobby, têm além da versão gratuita, uma comercial com mais recursos e que pode testar de uma única vez, um Website inteiro.

Para demonstrar como funcionam esses avaliadores de acessibilidade testamos a Homepage do MTE - Ministério do Trabalho e Emprego com o mais popular desses software, o WebXact (Bobby). O teste foi realizado em dezembro de 2005.

Vejamos abaixo a imagem com o relatório da página inicial do MTE:

Relatório emitido pelo avaliador de acessibilidade WebXact sobre a Homepage do MTE - Ministério do Trabalho e Emprego

De acordo com o relatório, a Homepage do MTE não foi aprovada, pois não está contemplando diversos pontos que compõem o WCAG 1.0. Foram listados 2 erros de prioridade 1 com 19 casos verificados, 6 erros de prioridade 2 com 111 casos e 4 de prioridade 3 com 27 casos.

O relatório emitido pelo WebXact indica a quantidade de erros de acessibilidade encontrados no documento classificados de acordo com as prioridades 1, 2 e 3. Para cada uma das prioridades, são identificados os erros que precisam de ajuste e a quantidade de vezes que foram listados com os respectivos números das linhas de código em que se encontram.

Para auxiliar os desenvolvedores no ajuste da acessibilidade, em cada um dos erros listados é associado um link para diretriz do WCGA que não está sendo atendida.

Selecionei um dos erros de prioridade 1 listado no teste para explicar com mais detalhes como funcionam esses relatórios. O erro indica que a guideline (diretriz): “Provide alternative text for all images - WAI checkpoint 1.10” não está sendo atendida. O resultado do teste indica que 17 imagens na Homepage do MTE não estão com texto alternativo.

Esse é um erro comum na maioria dos Websites, porém grave, porque impede que deficientes visuais, sistemas de busca, etc., tenham acesso ao conteúdo das imagens.

Exemplo do código HTML da foto de uma casa sem nenhum texto alternativo aplicado na imagem:

    <img src=”casa.gif” />

Exemplo da foto da casa com texto alternativo aplicado na imagem:

    <img scr=”casa.gif” 
    alt=”foto de uma casa amarela de dois andares” />
	   

Ao clicar no link da guideline, uma nova página é aberta com a descrição da regra de acessibilidade exatamente como é mostrado na imagem abaixo:

Erro de Prioridade 1 - Provide alternative text for all images

Link para a descrição da guideline: 1.1 Provide alternative text for all images.

Além dos erros, os relatórios também listam avisos, que são na verdade, verificações / recomendações que devem ser analisadas manualmente pelo Webdesign / desenvolvedor. Isso acontece porque os programas de avaliação não podem testar automaticamente todas as regras e assegurar a acessibilidade em todos os itens do site. Portanto, é preciso que a equipe responsável pelo desenvolvimento do projeto verifique cada um dos avisos manualmente, com objetivo de eliminar quaisquer barreiras à acessibilidade do site.

No mesmo teste com a Homepage do MTE foram listados 12 avisos de prioridade 1 com 104 casos verificados, 18 avisos de prioridade 2 com 104 casos e 12 avisos de prioridade 3 com 12 casos.

Assim como os erros, cada um dos avisos também é um link para a guideline com a descrição da regra de acessibilidade. Selecionei um aviso de prioridade 2, cujo guideline é: “create link phrares that make sense when read out of context” - WAI checkpoint 13.1, ou seja, crie links que façam sentido mesmo se forem lidos fora do contexto.

A imagem abaixo expõem a página com a descrição da guideline do aviso selecionado e que também pode ser acessada pelo link: create link phrares that make sense when read out of context (LINK)

Aviso de prioridade 2 - Create link phrases trat make sense when read out of context

Para entender o problema desse aviso, vamos imaginar que um determinado Website utilize a técnica de criar links com o texto: “clique aqui”, “saiba mais”, etc., repetidamente dentro das páginas do site.

Quando deficientes visuais acessarem o site através dos softwares leitores de tela utilizando apenas o teclado, não serão capazes de diferenciar um link, do outro. A navegação direta pelos links e campos de formulário utilizando sucessivamente a tecla TAB, é uma experiência muito comum entre os usuários deficientes e, os links do tipo “clique aqui” quando lidos fora do seu contexto original, não fazem o menor sentido.

A Homepage analisada não utiliza essa antiga técnica de links, pois isso, esse aviso não se aplica ao site do MTE.

O número de avisos em relatórios de acessibilidade supera em muito a quantidade de erros listados, isso ocorre em razão da capacidade limitada das regras que podem ser testadas automaticamente por esses softwares.

Existem diferenças relevantes entre as ferramentas de avaliação de acessibilidade principalmente na sua aderência aos Web Standards (padrões Web), portanto, para obter um resultado melhor, teste em mais de um desses softwares. Existem mais de uma dezena de avaliadores disponíveis, listo a seguir alguns deles:

Gosto de utilizar nos testes o WebXact e o Hera, sendo que esse último, disponibilizou recentemente sua versão em português de Portugal e pode ser considerado como um dos avaliadores de acessibilidade mais aderentes aos padrões Web. Ambos softwares utilizam a versão 1.0 do WCAG como base para suas avaliações.

Um pouco antes de terminar a primeira parte desse artigo, recebi uma excelente dica enviada pelo Jorge Fernandes na lista de acessibilidade do Yahoo de uma ferramenta em português de Portugal para avaliar acessibilidade de sites chamada eXaminator. A princípio, se parece bastante com os outros avaliadores de acessibilidade, porém, além das diretrizes do WCAG 1.0, também valida o código HTML e o CSS da página diretamente no W3C. Outra característica interessante do software, é que após o teste, ele dá nota de 0 a 10 para acessibilidade do site analisado baseando-se nos 3 testes realizados.

Fiz um teste com a Homepage do MTE e ela obteve a nota 2.9 como podemos observar na imagem abaixo:

Relatório do Avaliador de acessibilidade eXaminator da Homepage do MTE - Ministério do Trabalho e Emprego.

Outra iniciativa muito bacana da equipe da ACESSO/UMIC foi a criação da página de Benchmarking da Acessibilidade Web da AP Portuguesa que disponibiliza notas de alguns importantes sites portugueses. Essa pode se tornar uma importante iniciativa pressionar e, por que não, motivar essas e outras empresas a buscarem melhores pontuações para a acessibilidade de seus sites. Pelo jeito, já começou a dar resultados, como a inclusão do site do Presidente da República de Portugal no Top 5 da acessibilidade com a nota 9.0.

Parabéns ao Jorge Fernandes e a toda fantástica equipa da ACESSO/UMIC pelo belíssimo trabalho.


Segundo: passar o checklist do WCAG 1.0


O objetivo desse segundo teste é fazer uma checagem para averiguar se realmente todos os itens de acessibilidade estão sendo contemplados pelo site utilizando os pontos de verificação para acessibilidade ao conteúdo Web, o Checklist do WCAG 1.0 da W3C.

Esse Checklist fornece uma listagem com todos os pontos de verificação previstos nas Diretrizes para Acessibilidade ao Conteúdo da Web.

“A listagem pode ser usada para revisões dos itens de acessibilidade em um documento. Para cada ponto de verificação é indicado se a condição foi satisfeita, se não foi ou se ela não se aplica.”

Os softwares avaliadores utilizam como base o WCAG 1.0 para criar seus relatórios de acessibilidade e, a priori, eles deveriam contemplar todos os itens do Checklist. Mas como sabemos, essas ferramentas são proprietárias e normalmente aplicam algumas características próprias de seus paízes, o que torna essas ferramentas menos confiáveis.

Sugiro que apensar dos avaliadores automáticos teoricamente contemplarem o checklist, que ele seja incluído na lista de testes, principalmente na páginas críticas e mais importantes do seu projeto.


Terceiro: teste com especialistas simulando usuários deficientes


Não é tarefa muito fácil simular uma pessoa com deficiência, mas podemos obter um bom resultado se desligarmos alguns periféricos como, por exemplo, o mouse e realizarmos algumas tarefas.

Agora é hora de colocar-se no lugar de usuários com deficiência e testar se a navegação do site e as suas principais funções/tarefas estão verdadeiramente acessíveis.

Esse item foi dividido em três diferentes tipos de testes e seus objetivos são simular deficientes visuais e motores:

3.1 – Sem mouse – com mouse desligado navegue pelo site utilizando teclado e monitor.

Desconecte seu mouse e teste se a navegação está funcionando apenas com o teclado. Verifique se está simples, acessível e fácil de usar, assim como as principais funções do site.

Procure testar algumas tarefas simples e importantes a qualquer Website, como por exemplo, fazer uma busca, enviar uma sugestão pelo Fale Conosco, encontrar um determinado produto/serviço, etc.

Em projetos com grande quantidade de conteúdo e com estruturas complexas, um sistema de pesquisa (busca) e um mapa do site são muitas vezes os únicos caminhos até o conteúdo desejado. Por esta razão devem estar posicionados na parte “acima da dobra do jornal”, ou seja, na parte principal da página que é de acesso rápido e fácil.

Para melhorar a experiência de deficientes visuais e motores é fundamental a disponibilização de saltos (links internos diretos para o conteúdo principal da página), atalhos para links e formulários (aplicação da propriedade ACCESSKEY) e seqüências especiais de navegação via teclado (aplicação da propriedade TABINDEX) para as áreas mais acessadas e importantes do site.

Aprenda como aplicar TABINDEX e ACCESSKEY no capítulo 8 do livro do Joe Clark.

Apliquei um pequeno de navegação via teclado na homepage do MTE. O objetivo do teste era avaliar o grau de dificuldade para acessar o sistema de busca e verificar seu nível de acessibilidade. Infelizmente, além do formulário não estar acessível, foi necessário teclar 25 vezes na tecla TAB, para enfim, chegar ao sistema de busca.

Por curiosidade, refiz este teste em março de 2006 e, por incrível que pareça, eles conseguiram aumentar de 25 vezes para 31.

Algumas conclusões do teste:

Vejamos a seguir, algumas medidas que tornariam o sistema bem mais acessível e fácil de usar:

Exemplo do código como está do formulário de busca:

<td class="busca">
	Busca: <input name="Query" size="16" 
	class="FormBusca" type="text">
</td>

<td valign="top">
   <a href="#" onclick="Enviar()">
	<img src="/geral/imagens/figuras/bullet_busca.gif" 
	border="0">
    </a>
</td>

Exemplo do mesmo código acessível (com aplicação das propriedades e tags label, for, id, tabindex, accesskey, onKeypress e alt):

<td class="busca">
	<label for=”bus”>Busca:</label> 
  <input name="Query" size="16" 
  class="FormBusca" type="text" id=”bus”  
  tabindex=”10” accesskey=”1”>
</td>

<td valign="top">
   <a href="#" onclick="Enviar()" onKeypress=”Enviar()”>
      <img src="/geral/imagens/figuras/bullet_busca.gif" 
      border="0" alt=”pesquisar” 
      tabindex=”15”>
   </a>
</td>

Três tutoriais sobre formulários acessíveis:


3.2 – Sem mouse e com software Leitor de Telas - navegar pelo site com o teclado, um software leitor de telas e com monitor.


Mantenha o mouse desligado e instale o software conhecido como “leitor de telas”. É com ajuda dessas ferramentas que os deficientes visuais acessam a Internet.

O objetivo do teste é verificar se na página analisada, a informação textual enviada pelo software é compatível com a informação visual. Esse batimento é muito importante para manter a integridade entre as informações e, conseqüente, acessibilidade entre os diferentes usuários e sistemas.

Esse tipo de análise pode tornar-se cansativa após algum tempo, portanto, tenha em mente que ele pode ser interrompido quantas vezes forem necessárias até que todas as áreas críticas do site tenham sido verificadas.


3.3 – Sem mouse e monitor - navegar pelo seu site utilizando apenas o teclado com orientação do leitor de telas.


É importante colocar-se no lugar do usuário com deficiência visual e, conhecer um pouco mais de perto, como é a sua experiência na utilização de Websites. Essa é a única maneira de compreender a grande diferença entre a teoria e a prática e também todos problemas criados pela falta de acessibilidade em sites.

"Para a maioria das pessoas a tecnologia torna a vida mais fácil. Para uma pessoa com necessidades especiais, a tecnologia torna as coisas possíveis."
Francisco Godinho em seu livro online: Internet para Necessidades Especiais.

Para vivenciar essa experiência, além do mouse, desconecte também o monitor. Para acessar o Website utilize apenas o teclado e um software leitor de telas. Se nós que conhecemos previamente o site tivermos dificuldades, imagine um visitante deficiente?

Assim como os softwares avaliadores de acessibilidade, os leitores de tela também apresentam diferenças entre seus diversos fabricantes, portanto, procure testar em mais de um software Leitor de Telas.

Como primeira opção pode ser usado o DOS/VOX, que apesar tem uma interface própria e menos recursos que os outros softwares, é gratuito. O projeto é de responsabilidade do NCE (Núcleo de Computação Eletrônica)/UFRJ.

Com recursos mais avançados podemos usar o americano JAWS (software mais utilizado no mundo) e o brasileiro Virtual Vision. Ambos são pagos e não são baratos, mas para grandes e médias empresas o investimento pode ser facilmente adicionado em um projeto sem comprometer seu orçamento.

Podemos ainda utiliza-los em suas versões TRIAL, ou seja, durante um determinado tempo para testes. O JAWS, por exemplo, pode ser usado por 40 minutos consecutivos durante um determinado número de vezes.

Adicionalmente podemos comprar uma versão do JAWS para utilizar durante um determinado período de tempo.

Uma observação importante é que esses softwares só funcionam em ambientes Windows, o SERPRO prometeu lançar em breve um "Leitor de Telas" em ambiente GNU/Linux (fonte:Portal Software Livre), vamos aguardar.

Todos os leitores de tela têm uma configuração padrão própria e, muitas vezes, são necessárias pequenas alterações nas configurações para conseguir uma melhor experiência nessas ferramentas.


No próximo artigo, descreverei testes de compatibilidade com os padrões Web, impressão, dispositivos móveis, outros ambientes e navegadores, contrastes de cores, dependência com tecnologias e finalmente, testes com diferentes usuários.


Para comentar este artigo, clique aqui e utilize o blog do autor

Horácio Soares - Analista de Sistemas e WebdesignerHorácio Soares é professor universitário e trabalha como Analista de Sistemas e Webdesigner de uma multinacional.
horacio.soares@internativa.com.br