Acessibilidade em aplicativos da web modernos
Atualmente, faço parte de uma equipe que desenvolve um aplicativo Web complexo para um cliente alemão (desculpe, não posso dizer nada sobre o projeto). Gostaríamos de "ser um bom cidadão" e desenvolver o aplicativo com a acessibilidade em mente. Agora estamos diante dos seguintes problemas:
- Se seguirmos as regras em http://www.w3.org/WAI/WCAG20/quickref/ , às vezes elas contradizem a especificação que o cliente escreveu. Como devemos lidar com isso?
- Usando as "novas tecnologias" (como AJAX e substituindo parte do DOM), não é fácil verificar se seguimos as regras. Por exemplo, quando clico em uma das guias, parte do conteúdo será substituída.Quando olho para a fonte (Firefox 3.6.10), não há nenhuma alteração.Como verificar se você segue as regras corretamente?
Espero que a pergunta seja apropriada para este site ...
Ao projetar sites acessíveis, evito usar AJAX e modificar o DOM demais, pois isso torna as coisas, como você disse, muito mais difíceis. Então, sempre que possível, tente usar HTML padrão documentos com interatividade mínima - facilitará muito seu trabalho e facilitará a vida de quem usa leitores de tela etc.
Outra coisa que você pode fazer é fazer com que seu aplicativo funcione totalmente sem javascript e, depois, enriquecer as coisas em locais onde agrega utilidade. As guias são um bom exemplo: primeiro, crie cada guia para que o conteúdo da guia seja carregado em uma nova página quando a guia for clicada. Em seguida, use javascript discreto para "enriquecer" o evento onclick da guia para que ele busque o conteúdo da página referenciada e carregue-o usando AJAX, por exemplo. Agora você terá guias acessíveis que ainda se comportam da maneira que você deseja. Você também pode criar configurações de acessibilidade no aplicativo que controlam como essas guias se comportam.
Ah, e lembre-se de não quebrar o botão voltar!
Se as especificações contradizem as especificações do cliente, eu o abordaria - explique por que a acessibilidade é importante, mostre a tendência no mundo, mencione que, para sites governamentais nos EUA, ela é imposta por lei e o mais importante - encontre uma solução alternativa que faça o trabalho.
Esta é uma pergunta antiga, mas apareceu no topo, então aqui está uma resposta. Bem, nem tanto uma resposta, mas alguns pontos-chave que não parecem inteiramente abordados nas outras respostas:
- As diretrizes de acessibilidade são exatamente isso - diretrizes. Cuidado com eles ficando desatualizados, sem um contexto específico e recomendando coisas que não funcionam bem com o software de acessibilidade
- Parte da acessibilidade precisa recair no navegador e nos fabricantes de dispositivos/software de assistência. Sei que isso não é totalmente justo para o usuário final, mas, para que os padrões e as melhores práticas funcionem, os fabricantes de dispositivos e software precisam segui-los da mesma forma que os desenvolvedores da Web (sempre detestei o JAWS por falta de segurança. atualizado a esse respeito)
- O JavaScript faz parte da web agora. É perfeitamente aceitável exigir isso. O software e dispositivos de assistência atualizados devem poder lidar com isso (concedido, eles podem não). Até o W3C está ciente disso e é aqui que os atributos da ARIA são algo a se analisar: http://www.w3.org/WAI/intro/aria
- sempre teste suas soluções em humanos. Seguir as especificações, padrões e diretrizes é bom, mas não o levará até lá. No final, cada produto deve ser analisado por si próprio.
Você escreveu:
1.Se seguirmos as regras em http://www.w3.org/WAI/WCAG20/quickref/ , elas contradizem às vezes a especificação que o cliente escreveu. Como devemos lidar com isso?
Como alguém já disse, a melhor coisa é: informe ao seu cliente que existem alguns contratados e que é melhor seguir o padrão. e você escreveu também:
2. Usando as "novas tecnologias" (como AJAX e substituindo parte do DOM), não é fácil verificar se seguimos as regras. Por exemplo, quando clico em um dos guias, parte do conteúdo será substituída.Quando eu olho para a fonte (Firefox 3.6.10), não há nenhuma alteração.Como verificar se você segue as regras corretamente?
Se para você é muito importante, sugiro que peça a algumas persianas que experimentem seu site. Algumas vezes as ferramentas que verificam a acessibilidade não são a melhor escolha!
Durante as etapas de design, você pode considerar os problemas de acessibilidade em seu site, independentemente do tipo de informação que ele terá. Ao seguir as regras de acessibilidade, você não está apenas considerando as pessoas com deficiência ... está levando em consideração todo o universo de usuários que podem encontrar informações úteis em seu novo site.
A abordagem mais fácil é criar seu aplicativo no ajax, como você disse, e ao mesmo tempo garantir que seu site funcione sem javascript. Por exemplo, o uso das tags xhtml (links) pode ajudá-lo a disponibilizar todo o seu site sem javascript e também os leitores de tela ou o navegador de voz funcionarão no seu site.
Uma ilustração para essas tags pode ser:
< a id=\"item_menu_15\" href="?module=rapido&mitem=15"
onclick="cargar_modulo('publi_cont',
'comp=articulos&tipo=2&id=18&modv=',
'Loading...',15,this,0);return false;" >
Onde:
id=dom_id (um objeto dom)
href= deve conter o link direto para o conteúdo atual que você deseja exibir
onclick= deve conter a função que você usa para criar a interação ajax e fornecer os parâmetros necessários, como publi_cont (dom_id - para o contêiner) e url/parameters (comp=articulos&tipo=2&id=18&modv=) que você deseja visualizar dentro do contêiner etc.
Lembre-se de que as informações a serem exibidas usando ajax ou não (link direto) devem ser as mesmas. Todos os usuários, independentemente do material de acessibilidade, podem ver o site da mesma maneira. Portanto, você não precisa criar versões diferentes do seu site depende de pessoas com deficiência. Você deve considerar as regras de acessibilidade para o seu site desde o início dos procedimentos de design e, em seguida, a usabilidade também pode ser aumentada porque os usuários-alvo não precisam mais considerar as regras de acessibilidade. Obviamente, depende das funcionalidades que o cliente precisa, mas você pode explicar que pode ser uma boa ideia aumentar seu grupo-alvo considerando os problemas de acessibilidade, porque a usabilidade também pode aumentar.