Como testar a acessibilidade em websites? – Parte 01

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, em seu livro Building Accessible Websites, a acessibilidade deve
ser testada:

…da mesma forma que testamos os Websites, com pessoas de verdade…

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 Informaçã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 discutirmos o assunto acessibilidade na Web com os profissionais
da área, percebemos que alguns ainda não têm a menor idéia do que é
acessibilidade e que uma grande parte deles 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 traz 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
de 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 softwares, 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:

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 WCAG 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 à imagem:

    <img src="casa.gif" />

Exemplo da foto da casa com texto alternativo aplicado à 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:

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 phrases 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õe a página com a descrição da guideline do aviso selecionado e que também pode ser acessada pelo link: create link phrases that make sense when read out of context

Para entender o problema desse aviso, imaginemos que um determinado Website utilize a técnica de criar links com o texto: “clique aqui“, “saiba mais“, etc., repetidamente dentro de suas páginas HTML.

Quando deficientes visuais acessarem esse site, não serão capazes de
diferenciar um link do outro. A navegação direta pelos links através
da 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 esse aviso não se aplica ao site do MTE.

O número de avisos em relatórios de acessibilidade normalmente
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. Existe 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 os softwares utilizam
a versão 1.0 do WCAG como base para suas avaliações.

Um pouco antes de terminar esse artigo, recebi uma fantástica dica do especialista em acessibilidade, o português Jorge Fernandes através da lista de acessibilidade de que fazemos parte, de uma nova ferramenta para avaliar acessibilidade de sites. Se chama eXaminator
e, a princípio, se parece bastante com os outros avaliadores de
acessibilidade, porém tem foco um pouco diferente e, 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á uma 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:

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 para 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.

Seguindo a mesma idéia, resolvi testar a nova ferramenta em alguns
sites de administração pública brasileira e obtive os seguintes
resultados:

Portal do governo brasileiro: nota 4,7
Receita Federal: nota 3,6
Ministério da Saúde: nota 3,3
Governo Eletrônico (versão original): nota 2,9
Governo Eletrônico (versão acessível): nota 6,4
Agência Nacional de Energia Elêtrica: nota 4,3
Portal da Justiça Federal: nota 5,2

Com o último teste, resolvi colocar a cara a tapa e apliquei o eXaminator nesse artigo que ficou com nota 7,2. Pois é, acho que preciso consertar algumas coisas e ser um pouco mais cuidadoso.

Parabéns ao Jorge Fernandes e à competente equipa da ACESSO/UMIC pelo belíssimo trabalho e iniciativa.

Segundo: passar o checklist do WCAG 1.0

O objetivo desse segundo teste é utilizar os pontos de verificação para acessibilidade ao conteúdo Web, o Checklist do WCAG 1.0 da W3C, para apurar se realmente o site está contemplando todos os itens de acessibilidade.

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íses, o que as tornam menos
confiáveis.

Apesar de os avaliadores automáticos teoricamente contemplarem o
checklist, sugiro que ele seja incluído na lista de testes,
principalmente nas 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 seu
objetivo é simular a experiência de deficientes visuais e motores:

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

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

Teste 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 as propriedades TABINDEX e ACCESSKEY no capítulo 8 do livro do Joe Clark.

Apliquei um pequeno teste de navegação via teclado na homepage do MTE.
O objetivo era avaliar o grau de dificuldade para acessar o sistema de
busca e verificar seu nível de acessibilidade. Infelizmente, além de o
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 para 31 passos.

Algumas conclusões do teste:

por estar posicionado no canto inferior esquerdo da página em uma
área com pouca evidência, o sistema de busca é difícil de achar e
acessar.
torna-se quase inacessível via teclado acessar o sistema de busca. É só imaginar um deficiente motor ter que teclar 25 vezes na tecla TAB,
para acessar o formulário de busca.
o formulário não está acessível para deficientes visuais.

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

reposicionamento do sistema para a parte superior do site.
mudança na ordem da navegação via teclado utilizando a propriedade “tabindex”.
aplicação do tag LABEL no formulário de busca para torná-lo acessível aos leitores de tela.
uso da função para enviar o formulário também via teclado (onKeypress).
aplicação de alternativo em texto para a imagem da seta que envia o formulário (propriedade ALT na imagem).
colocação de atalhos diretos para o menu de navegação principal do
site e de seu sistema de busca utilizando a propriedade TABINDEX.

Exemplo do código como está no 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">	  

  <input type="image" onclick="Enviar()" onKeypress="Enviar()"
  src="/geral/imagens/figuras/bullet_busca.gif" 
  border="0" alt="pesquisar"   

  tabindex="15">	   

</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üentemente, a 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, por conseguinte, os 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 utilizá-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.

De 0 a 10, o quanto você recomendaria este artigo para um amigo?

Powered by: