<
Menu

Tableless


colors

As cores da minha web

Architecture project

CSS3 – Módulo Template Layout

acess

Boas práticas de Acessibilidade

720

Seu lugar ao sol


Javascript e acessibilidade

Dando continuidade a nossa série sobre acessibilidade, confira algumas dicas para desenvolver sites dinâmicos tendo um mínimo de cuidado com screen readers e navegadores com JavaScript desabilitado.

É muito comum o desenvolvedor ficar empolgado ao descobrir recursos, plugins, animações e efeitos JavaScript e acabar exagerando no produto final. Também é muito comum, como disse a Thaiana, que acessiblidade esteja ligado exclusivamente a sites governamentais. Aos poucos este cenário está mudando.

Além de tornar o seu site acessível à pessoas com necessidades especiais, as técnicas abaixo serão úteis também quando o navegador do usuário estiver com JavaScript desabilitado. E se mesmo assim você ainda não estiver convencido, pense que, quanto menos JavaScript, mais otimizado e estável será o seu site/sistema.

O problema

Acessibilidade, basicamente, significa tornar o seu site/sistema compatível com dispositivos leitores de tela. O que este dispositivo faz é tentar converter todo o conteúdo presente em uma página para uma saída especial, seja ela voz (text-to-speech) ou braille. Por isso a importância da semântica no HTML e, por isso também, a importância do JavaScript não acabar atrapalhando o funcionamento do seu site.

Dependendo da forma como você utilizou JavaScript, parte do conteúdo pode passar batida no screen reader. Isso acontece muito com animações (conteúdos escondidos) e eventos que não são nativos do elemento, como tentar utilizar onClick em um parágrafo.

<noscript>

A prioridade número 1 nas regras para acessibilidade é tornar todo o conteúdo disponível quando o navegador não estiver com JavaScript habilitado. Procure implementar alternativas HTML parecidas com o conteúdo estabelecido por seus scripts.

No entanto, é importante ressaltar que o noscript só vai funcionar quando o javascript estiver dasabilitado no navegador (ele não vai funcionar se o JavaScript estiver com erro, por exemplo). Alguns screen readers tentam interpretar JS, portanto, utilizar JavaScript NÃO significa tornar seu site pouco acessível. Depende da forma como você implementa seus scripts.

Muita gente é a favor da extinção da tag <noscript>. O que eles defendem é que basta você desenvolver seus scripts de forma não-obstrutiva. Seu script pode ser executado ou não – independente disso ele não afetará a funcionalidade básica da página.

Preciso mesmo usar JavaScript?

Sempre que for utilizar algum efeito ou interação em JavaScript você deve se perguntar se ele é mesmo necessário. Ou ainda, não daria pra fazer a mesma coisa utilizando apenas HTML e CSS?

Pense duas vezes antes de implementar qualquer tipo de script. Analise não só a questão da acessibilidade, mas também performance e manutenção.

Não invente eventos e não fique preso ao mouse

Procure utilizar eventos JavaScript apenas em elementos que estão aptos a recebê-los. Por exemplo, não utilize onClick em um <li>. Geralmente, os eventos de interação devem estar associados a links e botões.

Lembre-se também que nem sempre vai ser utilizado o mouse, logo, eventos como onMouseOver e onMouseOut seriam inválidos. Ofereça alternativas globais, como onFocus, onBlur, onClick (que, no teclado, seria executado com a tecla Enter) – visando usuários que utilizam outros dispositivos.

Um problema grave são menus ativados no mouseover. Nesse caso o usuário não teria como acessar todas as páginas – ele não poderia navegar por toda a estrutura do site.

Essas regras estão também diretamente ligadas a conteúdos carregados via AJAX. Dependendo da forma como você ativa o evento, o screenreader vai ler ou não o conteúdo recém adicionado.

WAI-ARIA

Procurando estabelecer um padrão para acessibilidade e conteúdos dinâmicos foi criada a especificação WAI-ARIA (Accessible Rich Internet Applications). O que ela faz é adicionar novas formas de identificar e habilitar funcionalidades dinâmicas através de propriedades nas tags HTML. Recentemente o jQuery UI adicionou suporte total ao framework ARIA tornando assim seus widgets e elementos de interface acessíveis a usuários com alguma necessidade especial.

O ARIA, por exemplo, pode definir regiões em um site e habilitar o movimento via tab entre essas regiões, ao invés de elemento por elemento. O WAI-ARIA também possibilita definir papéis (roles) para elementos como menu, menuitem, banner, application etc.

Este é um assunto muito rico e ainda pouco explorado. Para mais informações visite a especificação do WAI-ARIA no site do W3C e também este tutorial sobre os papéis disponíveis no ARIA.

Por Davi Ferreira

Programador apaixonado pelo que faz. Responsável pelo desenvolvimento de sistemas e interfaces para Globo.com, Confederação Brasileira de Vôlei, Ricoh Brasil, Embratel entre outros.

http://www.daviferreira.com/blog

Mais posts do autor

Comentários (8)

  • Pingback: Tweets that mention Javascript e acessibilidade | Boas práticas de Desenvolvimento com Padrões Web -- Topsy.com

  • http://tutorial-city.net/ Eduardo Matos

    Dizer que acessabilidade é tornar o site acessível aos leitores de tela é pensar pequeno demais. Existem vários outros problemas que usuários podem enfrentar, e que exigem soluções diferentes. Existem pessoas que tem dificuldade de dintinguir cores por exemplo, então é bom ter um certo contraste entre os elementos. Existem pessoas que tem deficiência auditiva, então é interessante adicionar legendas nos vídeos. A lista de possíveis problemas é razoavelmente grande, então não dá pra ficar preso aos leitores de tela.

    No caso dos menus dropdown, realmente não dá pra contar que o usuário passe o mouse em cima, e esse é um problema que os dispositivos touchscreen já enfrentam. Pra solucionar não precisa descartar o evento mouseover, basta linkar também os itens superiores, não só os que aparecem quando o mouse está em cima do menu.

    Eu não sou fã da tag noscript, simplesmente pelo fato de achar que o HTML NÃO deve ser criado já se pensando em javascript. Existem alguns casos onde essa tag pode ser útil, mas em geral ela é dispensável.

    Construir um site com HTML limpo e acessível é bem complicado, e acaba passando despercebido nos projetos. Em grandes projetos o ideal é que se tenha um especialista no assunto, assim como se tem um especialista em interfaces, um especialista em usabilidade etc. Em pequenos projetos só depende da consciência do desenvolvedor, aí o buraco é mais em baixo. Já é difícil convencer uma pessoa que ela precisa adaptar um site pro internet explorer, o que dirá adaptar pra pessoas com deficiências.

  • Acelio

    WAI-ARIA
    ?
    Muito boa esta dica! Continuem assim! Parabéns.

    Sei que o peixe é mais caro que a vara de pescar, mas fala aí…
    ” …Dependendo da forma como você ativa o evento, o screenreader vai ler ou não o conteúdo recém adicionado …”

    Que forma é esta? Como se faz isto?

    Opinando…

    O event correto para o link/botão/input é onkeypress = quando se pressiona a tecla enter. eu uso xhtml
    Falando em javascript, o href do link geralmente vai estar ocupado, sendo uma #âncora ou só # – e a ação do link esteja efetivamente no onclick.

  • http://www.twitter.com/lvps Lucas Sandoval

    Davi, legal o artigo(apesar de ser breve). O desenvolvedor deve adotar o método de desenvolvimento em camadas: Primeiro o HTML mais semântico possível, deixando assim o conteúdo totalmente acessível. A codificação HTML é a base de tudo! Se a marcação for confusa, o css e o javascript serão confusos. Sobre o javascript é aquela história: “Javascript não destrói sites, pessoas usando Javascript destroem sites. Um grande problema é que a maioria dos desenvolvedores aprenderam a usar Javascript do jeito errado e, pior, não se preocupam com isso. Infelizmente é assim :(

  • http://rodrigofante.com Rodrigo Fante

    Ei, comentei no artigo desenvolvendo para IE6 e apareceu aqui.. estranho, muito estranho.

  • http://rodrigofante.com Rodrigo Fante

    Estou no artigo Navegabilidade em dispositivos móveis, Windows 7 – Firefox 3.6.12 -teste

  • http://www.minicriativo.com.br Allan

    KB já não é mais a barreira, hoje os mobile sites são produzidos com o foco em determinado público. Claro, que não significa que o poder da 3G chegue aos pés de uma banda larga, mas é um mercado a ser explorado e ainda temos muitos paradigmas a quebrar, já que relativamente é algo que as empresas estão se adequando idéia de ter um site funcional e não mais app’s apenas para promoção que muitas vezes pode ser um tiro no pé,