96% das 200 homepages mais populares do mundo têm problemas em relação à acessibilidade

Recentemente li um relatório sobre Acessibilidade de sites encomendado pela Organização das Nações Unidas à Nomensa.

O estudo feito pela Nomensa em 2006 envolveu 100 sites de 20 países. O objetivo do relatório era obter uma visão geral da Acessibilidade Web no mundo e o resultado não foi nada surpreendente: 97% dos sites líderes selecionados pela Nomensa não alcançavam sequer o nível A do WCAG 1.0. Vale mencionar que entre os sites então analisados pela Nomensa estavam cinco brasileiros, são eles: www.tam.com.br, www.bb.com.br, www.folha.uol.com.br, www.presidencia.gov.br e www.americanas.com.br. Nenhum deles alcançou o nível A do WCAG 1.0.

Então veio minha pergunta, será que desde 2006 ninguém mais fez um estudo desse tipo? Seria interessante obter um dado atual desses considerando o WCAG 2.0, certo?

Bom, primeiro procurei bastante em relatórios, blogs e afins, mas não achei nada. Sendo assim decidi rodar um teste inspirado pelo relatório feito pela Nomensa para verificar como seria esse snapshot da Acessibilidade Web hoje envolvendo os 200 sites mais visitados do mundo.

Como foi feito

Para selecionar 200 sites com maior visitação no mundo recorri ao Alexa, site que conta com um link atualizado diariamente com os 1000 sites mais populares do mundo.

Uma vez selecionadas as 200 homepages, parti para escolher a ferramenta semiautomática de verificação das diretrizes de conteúdo do W3C, o WCAG 2.0. Para isso usei ATRC Checker, ferramenta estável que uso há alguns anos e que conta com uma gama interessante de diretrizes.

Por último faltava rodar a avaliação para todas as 200 homepages selecionadas e para isso usei um script do Selenium, ferramenta que discuti em outro post, para passar cada um dos links pela verificação default do ATRC Checker, isto é, Nível AA do WCAG 2.0, e verificar a existência de problemas conhecidos, ou seja, pontos identificáveis computacionalmente e, consequentemente, fáceis de resolver. Vale comentar que no Nível A as diretrizes são menos “exigentes”, já no nível AAA as diretrizes são bem mais estritas.

Como "bônus" aproveitei para rodar o Unicorn da WC3 para verificar se ao menos os códigos HTML e CSS 2.1 dessas homepages estavam válidos.

Resultados

Em suma, os dados que obtive foram os seguintes: 96% das 200 homepages mais populares do mundo contam com problemas conhecidos das diretrizes do WCAG 2.0 (Nível AA). Inicialmente achei que os resultados seriam desanimadores, mas não tanto assim, pois estamos considerando os sites mais populares e, consequentemente, os que, teoricamente, possuem maior receita.

No entanto, parece que os cuidados com Acessibilidade continuam ficando para segundo plano.
Em relação à codificação HTML e CSS 2.1, mais resultados desanimadores: 97% dos homepages avaliadas contavam com HTML inválido ou usando funcionalidades experimentais; em relação ao CSS 2.1 os resultados foram melhores, pois 93,5% tinham código CSS inválido.

Conclusões

Mesmo depois de 5 anos do relatório da Nomensa que indicou que a situação em relação à Acessibilidade Web era crítica, não tivemos grandes mudanças. Os testes que fiz estão longe de compor um estudo aprofundado sobre como a Web está em relação à Acessibilidade, mas é ao menos um indicativo de que grandes mudanças que esperamos e desejamos ainda não ocorreram.

Por fim, os problemas encontrados em relação à codificação também nos dão pista de que em muitos desses sites líderes não há validação frequente do código.

Voltarei a discutir sobre este assunto assim que me aprofundar nesses estudos e obtiver mais resultados interessantes.

Explorando a ferramenta de testes Selenium

Recentemente conheci a ferramenta de testes, ou melhor, o conjunto de ferramentas chamado Selenium. Explorei a ferramenta, fiz alguns testes e agora compartilho algumas impressões que tive e que acho que podem ajudar quem está procurando uma ferramenta de testes ou está pensando em incluir algo no ciclo de desenvolvimento que garanta que boa parte das features presentes no seu website possam ser verificadas automaticamente a cada modificação no código, garantindo assim um nível razoável de qualidade ao longo do processo de desenvolvimento. Sendo assim, seguem algumas considerações:

  1. O conjunto de ferramentas tem como objetivo testar aplicações e não considera, por default, dados de utilização ou tem a função de data-logger. Se você procura um data-logger ou algo relacionado, esta não é a ferramenta. Entretanto ...
  2. É possível inserir a ferramenta no ciclo de desenvolvimento, uma vez que é relativamente fácil verificar se o sistema responde da maneira esperada para todas (ou quase todas) tarefas, a cada mudança feita no código;
  3. Também é possível usar o Selenium para executar testes de estresse considerando entrada de dados normalmente usados para injeção de código malicioso ou testar disputa de recursos usando o componente grid, do Selenium;
  4. Outro possibilidade interessante é usar o Selenium para fazer a verificação de features considerando diferentes navegadores, obtendo assim um nível de compatibilidade cross-browser razoável;
  5. Por fim, considerando avaliação semiautomática, é possível usar o Selenium para rodar validadores de (X)HTML ou CSS em todas as páginas de website ou até mesmo passar todas as páginas de um website por uma ferramenta semiautomatica de avaliação de avaliação de acessibilidade (e.g., AChecker) e capturar a tela de resultados ou contabilizar o número de resultados conhecidos, prováveis, etc.

Algumas ferramentas semiautomáticas verificam se muitas requisições estão sendo feitas a partir de uma mesma máquina. Portanto, é sempre bom inserir um intervalo entre as requisições para que seu IP não seja bloqueado.

Display pneumático: Botões físicos na tela

Abordagem muito interessante para incorporar botões físicos em telas. Possibilita que diversas aplicações sejam mais acessíveis a partir da inclusão de informações táteis em aplicações que usam touch screen.


Mais informações: http://www.chrisharrison.net/projects/pneumaticdisplays/

Texto de link é uma resposta à pergunta: pra onde ele vai?

Há certo tempo fiz um desabafo sobre o uso do "clique aqui" na Web, mas o desabafo ficou incompleto, pois não sugeri como colocar um texto significativo no lugar do criticado "clique aqui". Nos próximos parágrafos tentarei justificar o uso de outras formas. Outros exemplos de rótulos de link que sofrem do mesmo problema são "Mais informações" e "Leia mais".

O primeiro problema ao usar "clique aqui" como texto de link é que ao fazê-lo é necessário completar com o conteúdo que indique "pra quê?" o usuário deve clicar no link, por exemplo (ou contra-exemplo como vou explicarei), "Clique aqui para ver alguma coisa" ou "Clique aqui para ir para algum lugar".

Neste ponto um redator Web pode argumentar "se eu colocar o 'pra quê?' em todos os links eles vão ficar muito grandes". Certo? Mais ou menos. Explico: se não colocar o "pra quê?" e o link for utilizado fora de contexto, ele não fará muito sentido. Mas você pode estar pensado "como assim fora de contexto?". Vamos lá. Usuários de leitores de tela, por exemplo, navegam usando a tecla tab, então pense como seria navegar e a cada tab você ouvisse apenas sequências de "clique aqui", "mais informações" ou "leia mais". Aposto que nesse momento você pensaria "clique aqui pra quê?", "mais informações sobre o quê?" ou "leia mais sobre o quê?". Esta é uma das justificativas por esta verificação fazer parte da Diretriz 2.4 do WCAG 2.0, que diz que deve-se "fornecer meios para auxiliar usuários a navegarem, encontrarem conteúdo e determinarem onde eles estão".

Qual seria a forma de encurtar esse texto de link e manter o significado? Bom, se você usar "clique aqui", "mais informações" ou "leia mais" no início de todos os links, eliminá-los poderia facilmente reduzir o tamanho dos links. Note que neste ponto estamos partindo do pressuposto de que a solução de design diferencia conteúdo textual de links.

Acho que o princípio do uso de "clique aqui" está exatamente aí, pois o "clique aqui" normalmente é usado em links que não têm cara de link, ou seja, eles não são sublinhados, não contam com características que o diferenciam de maneira consistente e padronizada de conteúdo textual, etc. Uma forma interessante de ver contra-exemplos é buscar pelo termo "clique aqui" em qualquer ferramenta de busca.

Por fim, se eliminarmos as partes com pouco significado e que não auxiliam na navegação e tampouco ajudam usuários a determinar onde eles estão quando usados fora de contexto, qual parte sobra? O destino do link, que é a parte que realmente nos interessa durante a navegação. Sendo assim, o texto de link deve responder a uma pergunta geral muito simples: pra onde ele vai?

Experimentando o Headmouse

Recentemente uma parceria entre os Correios e a empresa espanhola Indra possibilitou que algumas tecnologias assistivas fossem disponibilizadas gratuitamente para evitar a utilização de mouse e teclado físicos, tendo como foco apoiar pessoas com algum tipo de deficiência motora. Os sistemas disponibilizados são: Headmouse e o teclado virtual. No entanto, vou comentar apenas sobre o Headmouse.

Download

As matérias que li divulgando a parceria não divulgaram o link para download do Headmouse. Fica a dica pra quem quiser prestar serviço. O instalador tem cerca de 500 KB, muito leve.

Requisitos do computador

O programa requer uma webcam, que, virada para a pessoa que está usando o computador, identifica para onde o rosto está apontando.

Como funciona

A partir da identificação de onde estão os olhos, sobrancelhas e para onde o rosto está apontando, é possível mover o ponteiro, clicar e arrastar através de ações como piscar de olhos e abrir a boca.

Utilização

Achei difícil executar alguns movimentos finos e interagir com alguns elementos de interface pequenos como botões de minimizar, maximizar e fechar. Fechei meu navegador algumas vezes sem querer quando a ideia era minimizá-lo. Mas, com cerca de uma hora de utilização a coisa ficou um pouco mais fácil. Essa exploração resultou em um pouco de cansaço no pescoço, mas nada comparado ao uso de piscadas para disparar cliques.

Depois de configurar a ação de abrir a boca para executar o clique, a utilização do Headmouse ficou bem menos cansativa. Outra dica é configurar a ferramenta de forma que o piscar seja interpretado como ação somente se o olho ficar fechado por 1,5 segundo. Talvez esse pudesse ser a configuração padrão da instalação. Fica a sugestão de trabalho de conclusão de curso para quem quiser trabalhar com acessibilidade e testar tecnologias de assistivas.

Para o duplo clique foi mais complicado. Nem reduzindo a velocidade do duplo clique ao máximo consegui abrir arquivos. Talvez aí pudesse ser executado o enter via teclado virtual.

Por fim, acho que o Headmouse pode ajudar significativamente pessoas com deficiência motora a usarem o computador de maneira mais eficiente, mesmo com uma curva de aprendizado razoável.

YouTube amplia serviço de geração automática de legendas e facilita inserção de transcrições

O Google está dando um passo importante em relação à acessibilidade no YouTube com o projeto de legendas automáticas. A conversão é feita a partir do áudio contido no vídeo, ou seja, usa-se a fala para obter-se o texto.

Apesar de não estar aberto para todos os vídeos e funcionar apenas com inglês é uma coisa muito interessante no que diz respeito à acessibilidade. No caso do YouTube, o alcance desse tipo feature é incrível e tende a derrubar barreiras de acessibilidade para um grupo significativo de pessoas.

Além de disponibilizar o serviço que gera as legendas automaticamente, a feature em questão possibilita que o usuário visualize a tradução da legenda em outros idiomas, provavelmente via uso da ferramenta de idiomas que vem sendo melhorada por usuários e está cada vez produzindo traduções mais interessantes.

Destaque também merece ser dado à funcionalidade de sincronizar automaticamente textos puros. Assim, se desejar incluir legendas em um vídeo seu que estiver em inglês, basta enviar o arquivo texto com a transcrição da fala. Infelizmente, isto também só está disponível para o inglês e, como ainda está em beta, não está produzindo resultados tão interessantes.

Fiz uma teste com um vídeo em que estou apresentando um short-paper sobre ferramentas de avaliação e estou falando muito rápido. Primeiro tentei utilizar a transcrição automática, mas o YouTube retornou erro. Depois transcrevi e inseri o texto, mas o resultado também não foi dos melhores. De qualquer forma, a iniciativa vale o elogio, mas ainda precisa ser bastante trabalhada.

Mais informações em: http://googleblog.blogspot.com/2009/11/automatic-captions-in-youtube.htm...

Pinacoteca de SP exclui vidente para incluir pessoas com deficiência

Há algumas semanas, num sábado, resolvi dar um passeio no centro de SP. Aproveito para recomendar uma visita ao Museu da Língua Portuguesa e à Pinacoteca, ambos com entrada gratuita aos sábados e um em frente ao outro. Mas o assunto é a visita que fiz à Pinacoteca, vamos lá.

A Pinacoteca conta com um acervo excepcional de telas e esculturas. Enquanto estava apreciando as esculturas em determinado salão, notei que algumas delas continham as suas fichas escritas em Braille. Logo em seguida notei que havia um piso tátil formando uma espécie de circuito e, como bom entusiasta de acessibilidade, achei sensacional! Uma Galeria Tátil! Mas aí vieram os problemas. Como aprendiz de Braille, tateei uma ficha e ameacei tocar em uma escultura, parte da Galeria Tátil, e tive uma surpresa. O segurança que estava próximo à Galeria Tátil me disse que as obras não podiam ser tocadas. Tentei entender um pouco melhor as políticas da Pinacoteca e perguntei: "Por quê eu não posso tocas as obras da Galeria Tátil?". A resposta: "Porque não. Você não é cego!".

Pela primeira vez me senti excluído por ser vidente. Lembrei da frase da professora M. Tereza E. Mantoan,
"Só se pode excluir quando for para incluir"
. Então, a Pinacoteca está à frente ao contar com uma Galeria Tátil, mas acho que tanto as instruções dadas aos seguranças quanto as políticas de funcionamento da Galeria Tátil poderiam ser melhoradas. Algumas questões que julgo pertinentes e que, até o momento, não consegui obter resposta são as seguintes:

- A Pinacoteca conta com uma Galeria Tátil, mas o piso tátil só existe no espaço reservado à galeria. Assim, como alguém que é cego pode ter autonomia na Pinacoteca se a chegada até a Galeria Tátil não considera diferenças?

- Uma pessoa com baixa acuidade visual pode utilizar a Galeria Tátil? Se sim, considerando que essa pessoa tem autonomia, como um segurança saberia distinguir uma pessoa com visão subnormal de uma pessoa com visão plena?

- É possível que alguém que não é cego "experimente" a Galeria Tátil? Por quê? Há alguma questão logística ou de preservação das obras?

Enviei estas questões via website da Pinacoteca do Estado de SP, mas até o momento nada. Por fim, videntes não podem interagir de maneira tátil com as obras da Galeria Tátil. No entanto, notei que algumas esculturas em mármore branco, fora da Galeria Tátil, continham várias marcas de mãos, especialmente as obras representando mulheres nuas. Neste ponto, acho a falta de educação de parte dos visitantes tem um peso significativo, assim como o despreparo do segurança com quem tive contato.

Mais informações sobre a Galeria Tátil da Pinacoteca do Estado de SP: http://internet.comunicacao.sp.gov.br/spnoticias/lenoticia.php?id=204177...

Acessibilidade no Call of Duty: Erros e acertos

Recentemente li uma matéria na Folha Online sobre uma barreira de acessibilidade do jogo Call of Duty: Modern Warfare 2. O erro principal foi a combinação de cores usada nos elementos gráficos do radar, uma vez que soldados aliados são identificados pela cor verde e os inimigos são identificados pela cor vermelha. Isto impossibilita que pessoas daltônicas que não conseguem diferenciar verde de vermelho saibam quem é aliado ou quem é inimigo.

A satisfação dos jogadores foi comprometida por um detalhe relativamente simples que prejudica um projeto do porte do Call of Duty. Para quem não conhece o jogo que e quiser verificar a importância do radar, basta ver um dos vídeos disponíveis no YouTube que mostra jogos on-line.

Os jogadores incomodados com a barreira estão organizando uma petição para que a empresa Infinity Ward, desenvolvedora do Call of Duty, produza um patch que corrija o problema. É interessante notar também que o texto da petição aponta que outra versão do jogo tinha a opção de trocar cores verde/vermelho por laranja/azul. Mas, ainda assim, se contarmos apenas com as cores para diferenciação, o problema pode permanecer em outros contextos de uso.

No desenvolvimento Web contamos com diretrizes para evitar problemas como este. A primeira que me lembro é uma do W3C que diz: "Don’t rely on color alone", que poderia ser traduzida como "Não dependa apenas da cor". Dessa forma, bastaria utilizar elementos gráficos de formas diferentes para representar aliados e inimigos, sem depender apenas da cor.

No entanto, cabe mencionar outro ponto que achei muito interessante na configuração de controle disponível nos jogos da série Call of Duty para o Nintendo DS, console portátil da Nintendo que conta com duas telas, uma delas touch screen. O controle do Nintendo DS possui um botão direcional à direita da tela inferior e quatro botões à esquerda (A, B, X e Y), normalmente usados com os dedos polegares esquerdo e direito, respectivamente. Possui também dois botões que podem ser utilizados com os dedos indicadores, L e R.

Nos jogos da série Call of Duty, o movimento do personagem no cenário pode ser feito via direcional com o polegar da mão esquerda, a mira/visão via caneta stylus com a mão direita e o tiro via L com o polegar da mão esquerda. Agora a parte legal. A configuração padrão permite que os botões A, B, X e Y sejam usados como direcional com o polegar da mão direita e que o R sirva para atirar com o dedo indicador da mão direita. Assim, pessoas destras, canhotas ou ambidestras têm possibilidades iguais de interagir com o controle, na configuração padrão. Exemplo interessante de solução acessível e de smart default, uma vez que, normalmente, um canhoto precisaria configurar os botões ou se adequar ao controle configurado para destros, o que teria, fatalmente, impactos na satisfação e eficiência. Por fim, se você é destro e acha que isto não é importante, tente usar um abridor de latas para destros com sua mão esquerda...

Javascript e manipulação de eventos: Armadilha no uso de onload e foco automático

Manipulação de eventos usando Javascript é um assunto delicado e merece atenção especial quando se trata de desenvolvimento Web client-side. Ao automatizar uma provável ação do usuário devemos considerar diversos contextos de uso. Lembremo-nos que contexto de uso é a combinação envolvendo usuários, tarefas, equipamentos (hardware, software e materiais), ambiente físico e social em que algo é usado. Vide: http://warau.nied.unicamp.br/?id=t601

É muito comum encontrarmos páginas que tentam prever o clique do usuário em determinado campo atribuindo foco automático ao primeiro campo vazio. Um exemplo corriqueiro é o de telas de autenticação em que o primeiro campo vazio ganha foco automaticamente, seja o campo de nome de usuário ou de senha, caso o nome de usuário possa ser recuperado de alguma forma (e.g., cookie).

Isto é legal e realmente deixa a interação mais eficiente. Pode aumentar a satisfação do usuário, pode evitar a mudança de um dispositivo para outro (e.g., do teclado para o mouse), pode envolver questões de acessibilidade na movimentação do ponteiro até o campo ou barreiras que um usuário cego poderia enfrentar até que o foco chegasse ao campo vazio, só para citar alguns.

No entanto, a antecipação às ações de usuário sem considerar se o usuário já está interagindo com a interface pode ser um "tiro no pé".

Imagine que o usuário está preenchendo o nome de usuário em uma página de autenticação. Então, o evento load é disparado e em seguida o foco é alterado automaticamente para o campo da senha, uma vez que o conteúdo do nome de usuário era diferente de vazio, mas antes do usuário terminar de escrever o nome. O que isto pode causar? Algo que deveria economizar um clique custará um clique e eventuais backspaces. Este cenário pode ocorrer, por exemplo, se a máquina estiver sobrecarregada ou se houver uma lentidão momentânea na rede.

Identifiquei um problema deste tipo e resolvi verificar em dois webmails famosos.

Gmail – No Gmail o foco é atribuído automaticamente para o primeiro campo vazio. Se, antes do navegador disparar o evento load, você clicar no campo nome de usuário e começar a digitar, assim que o evento load for disparado, o campo senha ganha foco automaticamente enquanto está preenchendo o usuário. Isto acontece porque a verificação é baseada no campo nome de usuário estar ou não vazio. Assim, se você não tiver terminado de escrever o nome, terá que retornar ao campo nome de usuário para terminar de preenchê-lo. Em suma, o que deveria economizar ações, poode custar uma quantidade igual ou maior de ações caso o foco automático não fosse usado.

Yahoo – No e-mail do Yahoo o foco é atribuído automaticamente para o campo ID Yahoo, mas se o usuário começar a digitá-lo antes do evento load da página ser disparado, a mudança não é feita automaticamente. Assim, a utilização feita no Yahoo é mais conservadora e não chega a custar mais ações para o usuário.

Note que a armadilha é atribuir foco automático em um campo após o usuário começar a disparar eventos. O evento load das páginas é disparado pelo navegador. Uma possível solução é "desligar" o foco automático caso o usuário atribua foco a qualquer elemento.

Por fim, alguém pode pensar se isso é, de fato, tão crítico. Faltariam dedos para contar problemas mais comuns e muito mais críticos, mas acho que comentar e discutir detalhes de desenvolvimento Web client-side como este são produtivos para quem deseja melhorar acessibilidade e usabilidade de websites via smart defaults.

Conteúdo sindicalizado