Blog do Xorna

Neste artigo, também decidi extrair outro capitulo de minha autoria do material do curso de desenvolvimento web acessivel, espero que seja útil, na verdade ele é uma síntese do que o autor original fala, ao contrário de outros blogs que simplesmente traduzem, e cá entre nós, teve um caso que estava meio traduzido. (rs)

Atualmente, muitas entidades estão envolvidas com a criação de padrões e metodologias para desenvolvimento de aplicações acessíveis. Um dos aspec-tos mais críticos é o Ajax (Asyncronous JavaScript and XML). Muitos grupos de desenvolvimento espalhados por aí hoje trabalham afim de criar esses padrões, entre muitas estão a WAI (Web Accessibility Initiative's), WAT-C (Web Accessibility Tools Consortium) entre outras. Mas para podermos ter uma idéia de como deixar uma aplicação com Ajax mais acessível, devemos nos interar sobre o comportamento de alguns leitores de tela.

Comportamento dos Leitores de Tela

Basicamente um leitor de tela consiste em um software que que faz uma varre-dura da página, coloca seu conteúdo no seu buffer virtual, feito isso ele libera o conteúdo que foi gravado em seu buffer para o usuário. Sem esse buffer, o leitor de tela seria limitado a acessar somente parte dos elementos de um site, como âncoras e elementos da interface, ficando praticamente impossibilitado de fornecer ao usuário condições de interagir com os demais elementos e seus nós descendentes no conteúdo, tais como listas, imagens, tabelas entre outros.

Como informar ao leitor de tela que ocorreu uma mudança no conteúdo

Se o conteúdo for alterado via Script, de algum modo isso deve ser informado ao leitor de telas. Como não há ainda um mecanismo que detecte essa umdança no conteúdo, um usuário de leitor de tela nunca ficará sabendo da mudança, ou ainda, será informado, mas precisará ler todo o documento pra descobrir o que foi alterado.

A última linha de leitura é aquela que contém o elemento ativado pelo usuário para produzir o novo conteúdo, dessa maneira, o usuário não terá a mínima idéia de como localizar a mudança de conteúdo. Uma maneira para resolver isso é utilizando o método focus, que é padrão ECMAScript, que pode ser utili-zado para colocar o foco no local da página onde o conteúdo foi alterado, porém, para que isso funcione, o elemento alvo deve ser habilitado a receber o foco. No HTML e XHTML os elementos habilitados a receberem foco são: a, area, button, input, object, select e textarea.

Em XHTML 2 todos os elementos podem receber foco, mas nas atuais especi-ficações para HTML 4.01 e XHTML 1.x somente elementos âncora e elementos de interface podem receber foco. Para tentar contornar isso, a WAI-PF[1], pro-pôs a Dynamic Accessible Web Content Roadmap[2], onde é sugerido que se use -1 para o tabindex, em elementos que não podem receber foco, e formalizou tal proposta em States and Adaptable Properties Module[3]. A necessidade de que todos elementos possam receber foco foi reconhecida pela Web Applications 1.0[4].

O atributo tabindex aceita valores entre 0 e 32767. Um valor positivo determina a ordem em que um elemento deve ser acessado quando a navegação se dá pelo teclado. Um valor igual a 0 siginifica que esse elemento deve ser acessado de acordo com sua ordem dentro do arquivo HTML. Atribuir o valor 0 para o tabindex em um elemento que não seja âncora ou que não seja da interface, significa que ele está sendo habilitado a receber foco, e atribuir o valor -1 para o mesmo, significa habilita-lo a receber foco via ECMAScript, contudo, isso pode causar certa confusão para usuários que navegam por meio do teclado, pois ao atribuir -1 para o tabindex desse elemento, ele estará habilitado para receber foco via ECMAScript, mas não será colocado na ordem de tabulação dos elementos do site.

Estruturando conteúdo para aplicações AJAX

Existem várias maneiras de estruturar conteúdos para que uma aplicação Ajax funcione corretamente em um leitor de tela. A mais simples e talvez a melhor é a de se fazer com que as partes da aplicação que exigem ativação pelo usuá-rio, estejam em elementos para formulários. Esta solução permite informar ao usuário sobre mudanças, focando na parte do documento que foi alterada. Isto requer que o usuário desabilite/habilite o mode buffer virtual, mas é isso exatamente que o usuário espera quando interage com formulários.Se a parte alterada do documento está no formulário, então surge um problema; Tomemos como exemplo para ilustrar esta situação uma tabela de dados incorporada em um formulário (uma estruturação destas poderia ser melhorada, mas vamos considerar para efeito de exemplo que seja uma solução plausível). Se um dado em uma célula da tabela for atualizado em resposta ao evento onreadystatechange o foco pode ser dado a célula e o leitor anunciará a atualização. O problema é que a tabela contento o texto atualizado não será mais reconhecida como uma tabela e o usuário será incapaz de localizar os headers da tabela e navegar o restante da tabela. Para reverter esta situação o usuário terá que voltar ao mo-do buffer virtual. Como os leitores de tela sempre anunciam o atributo title, este poderia ser usado para os controles de formulário que possam receber foco (inclusive elementos que não sejam de interface com um específico valor para o atributo tabindex) e que não estejam associados a um label. A seguir um exemplo de como atualizar o conteudo de uma célula de tabela em resposta ao evento onreadystatechange.

var objCurrent = document.getElementById('update');
var objReplacement = document.createElement('td');

// Set the title attribute to prompt the user to change mode
// This should use simpler language than used here, as the user
// isn't likely to understand the concept of a virtual buffer
objReplacement.setAttribute('title', 'Switch to virtual buffer');
// When the element loses focus, remove the attribute for other
// user agents
objReplacement.onblur = function(){this.removeAttribute('title');};

// Set a negative tabindex attribute value so the element
// can receive focus
objReplacement.tabIndex = -1;

objReplacement.setAttribute('id', 'update');
objReplacement.appendChild(document.createTextNode(strResult));

// Replace the existing node with the new node
objCurrent.parentNode.replaceChild(objReplacement, objCurrent);
// Set focus to the element
objReplacement.focus();

Se a interação com a aplicação não for por formulário, o mais importante é avi-sar ao usuário para que ele desabilite o modo modo buffer virtual (tal como ele faria para interagir com um formulário). Isto não é tão simples como parece, pois será necessário usar instruções muito claras ao usuário do leitor de tela que na sua maioria desconhece os detalhes técnicos do software que estão utilizando ? da mesma forma que usuários de navegadores visuais não ne-cessariamente conhecem como redimensionar os textos no navegador. Uma solução simplista é a de disponibilizar uma página de ajuda, facilmente locali-zável na aplicação, explicando buffer virtual e contendo uma tabela mostrando os atalhos para habilitá-lo e desabilitá-lo nos leitores de tela mais populares. A tabela a seguir mostra os atalhos de teclado para habilitar e desabilitar o buffer virtual dos leitores de tela que nós usamos para testes.

Links:

[1] – http://www.w3.org/WAI/PF/
[2] – http://www.w3.org/WAI/PF/roadmap/
[3] – http://www.w3.org/WAI/PF/roadmap/DHTMLRoadmap040506.html#focus
[4] – http://whatwg.org/specs/web-apps/current-work/#tabindex0

Referência:

http://juicystudio.com/article/making-ajax-work-with-screen-readers.php

Outras Referências Traduzidas:

http://www.maujor.com/tutorial/ajax-screen-readers.php