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.
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.:
WCAG 2.0 - rascunho da introdução às novas diretrizes para acessibilidade ao conteúdo da Web Acessibilidade na Web – pesquisa da doutoranda de Amanda Meincke Melo
Diversos textos sobre a iniciativa de acessibilidade do W3C traduzidos para o português pelo incansável Mauricio Samy Silva Noções de acessibilidade – acessibilidade.net
Mitos x Intormação
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.
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.
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*.
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: 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.
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" />
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)
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.
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.
Hera (em português) Cynthia Lift
DaSilva (em português) Valet
Ocawa Lista avaliadores de acessibilidade indicada pela WAI 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:
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.
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." WCAG 1.0 Checklist (em português traduzido pelo Maurício Samy Silva)
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.
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.
aplicação do tag LABEL no formulário de busca para torna-lo acessível aos leitores de tela.
função para enviar o formulário também via de teclado (onKeypress).
aplicação de atalhos na navegação principal do site e seu sistema de busca utilizando a propriedade TABINDEX. Exemplo do código como está do formulário de busca:
<td class="busca">
Busca: <input name="Query" size="16"
class="FormBusca" type="text">
<a href="#" onclick="Enviar()">
<img src="/geral/imagens/figuras/bullet_busca.gif"
<label for="bus">Busca:</label>
<input name="Query" size="16"
tabindex="10" accesskey="1">
<a href="#" onclick="Enviar()" onKeypress="Enviar()">
tabindex="15">
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.
É 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."
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.