Javascript e Acessibilidade

StackOverflow https://stackoverflow.com/questions/266777

Pergunta

Como um desenvolvedor web, uma série de projetos que trabalham em queda sob guarda-chuvas do governo e, portanto, estão sujeitas a Acessibilidade 508 leis, e às vezes W3C acessibilidade diretrizes. Até que ponto pode JavaScript ser utilizado apesar de se cumprir esses requisitos?

Ao longo destas linhas, até que ponto é JavaScript, especificamente AJAX e usando pacotes como jQuery para fazer coisas como exibir diálogos modais, pop-ups, etc. suportadas pelo software de acessibilidade moderna, como JAWS, Orca, etc? No passado, a regra foi algo como "Se ele não funcionará no Lynx, não vai funcionar para um leitor de tela." Isso ainda é verdade, ou que tenha havido mais progresso nessas áreas?

EDIT: O consenso parece ser que javascript é muito bem contanto que há fallbacks não-javascript, no entanto, ainda parece incerto sobre o suporte para AJAX no software leitor de tela. Se alguém tem experiência específica com isso, que seria mais útil.

Foi útil?

Solução

Se a acessibilidade é a sua principal preocupação, sempre começar um site usando compatível com os padrões (escolher uma definição Tipo de Documento e cumpri-lo) HTML. Se for uma aplicação web (envios de formulários, etc), certifique-se as formas irá funcionar usando apenas HTTP GET e POST. Uma vez que você tem um site / aplicação completa você pode adicionar pedaços de CSS e JavaScript, desde que o site ainda funciona, com um ou ambos off.

O conceito mais importante aqui é Progressive Enhancement . Você está adicionando sinos e assobios usando CSS / JavaScript adicionais, mas seu web site / aplicativo irá funcionar perfeitamente sem qualquer um.

A grande ferramenta para testar 508 , WAI , CSS off, JavaScript off tente usar o web Developer plugin para o Firefox.

Outras dicas

Eu acho que a resposta é realmente em como você as coisas arquiteto. JQuery tem a capacidade de ser discreto e, portanto, acessível. O truque é ter redundância em torno de suas chamadas AJAX para que navegadores sem JavaScript ainda pode utilizar o seu serviço. Em outras palavras, onde quer que você tem respostas JavaScript, diálogos, etc você precisa ter um equivalente degradado.

Se você tem acessibilidade em mente e você está adequadamente testando para ambos os casos de uso (JavaScript vs. não-JavaScript) que você deve ser capaz de aplicações de gravação que atendem a ambos os públicos.

Exemplo ($ (document) .ready chamada omitido para clareza e concisão: 

<script>
  $("#hello").click(function(){
    alert("Hi");
  });
</script>
<a href="/say_hello.htm" id="hello">Say Hello</a>

Um exemplo trivial, mas basicamente isso só irá avaliar o clique evento JavaScript se o JavaScript é suportado. Caso contrário, ele irá executar como um link normal e ir para say_hello.htm -. Seu trabalho como o desenvolvedor é certificar-se de que ambos os resultados são manipulados para apropriadamente

Espero que ajude!

melhora progressiva é certamente uma rota, mas unobtrusiveness não é o princípio eo fim de todas acessibilidade JavaScript como leitores de tela tendem a usar navegadores como base para o seu trabalho. Atendendo a que os navegadores suportam JavaScript, scripts em sua página ainda será executado. Este é um problema particular com AJAX como clicar em uma parte da página pode mudar outra parte da página que o leitor de tela não tem conhecimento de.

Como AJAX amadurece, porém, os métodos de torná-lo acessível estão surgindo. Olhada na WAI-ARIA para métodos modernos de fazer AJAX acessível, e AxsJAX do Google para uma boa maneira de implementá-lo.

Veja

Você também pode dar uma olhada em FlashAid, embora esteja longe de uma solução perfeita. (Mas, se você usou melhoria progressiva e utilizado AJAX quando o Flash estava presente e o usuário não estava usando a API de acessibilidade, você pode ter uma solução razoável ... para Windows.)

No longo prazo, WAI-ARIA é a solução. É um pouco apoiado em JAWS 10 (beta) e FireVox, mas certamente não é suficiente para todos os usuários de hoje.

JQuery tem a capacidade de ser discreto e, portanto, acessível. O truque é ter redundância em torno de suas chamadas AJAX para que navegadores sem JavaScript ainda pode utilizar o seu serviço. Em outras palavras, onde quer que você tem respostas JavaScript, diálogos, etc você precisa ter um equivalente degradado.

Uma maneira de fazer isso para reutilizar o seu código, é ter sua página "simples" chamar uma "função" (ou o que você usa para a lógica do lado do servidor) que pode ser chamado por si só, retornando JSON ou XML.

Por exemplo: /static/myform.asp (no lado do servidor, 'inclui' a mesma lógica que /ajax/myform.asp) Dessa forma, você estaria usando asp como modelos do Django.

Claro que, com um quadro sino featured e assobios completa, você pode fazer isso muito mais fácil (pensar em ter um html e um xml 'modelo' para o mesmo ponto de vista no Django), mas a mesma idéia applyes.

Depois de ter feito isso, a iteração sobre todas as âncoras no documento pronto usando jQuery e adicionando onclick eventos usando próprio link da âncora, remplacing / static / ajax / pode tornar sua vida mais fácil.

Alguém pode pensar em razões para que isso seja demasiado de um fardo? Gostaria de saber se há alguma falha grave neste 'idéia do projeto'.

Não afiliado a StackOverflow
scroll top