Topo da página.

Acessibilidade Legal

Barra horizontal superior.

  • Acessibilidade
  • Padrões Web
  • Tecnologias Assistivas
  • Perguntas Frequentes

Coluna vertical direita.

Busca Interna.
  • Links
  • Contatos
  • Mapa do site
  • Feeds

Destaques.

  • Vídeo: Acessibilidade Web: Custo ou benefício?Site Externo.
    Esse vídeo com 12 minutos mostra os principais obstáculos e soluções de acessibilidade e usabilidade na web.
  • Lista Acesso DigitalSite Externo. A Acesso Digital criou uma lista de discussão para tratar de acessibilidade na web. Quer participar? É só se inscrever.
  • Recomendações para a Acessibilidade do Conteúdo da Web 1.0 Site Externo.
    Versão do WCAG 1.0 em português de Portugal. Os itens de acessibilidade web preconizados pelo W3C através do WCAG 1.0, apesar de serem os mais discutidos internacionalmente, ainda servem, em sua maioria, como padrão para desenvolvimento de páginas web acessíveis em todo o mundo.
  • Diretrizes para a Acessibilidade dos Conteúdos da Web 2.0 Site Externo.
    Versão do WCAG 2.0 em português do Brasil. A versão WCAG 2.0 vem substituir as Diretrizes de Acessibilidade para o Conteúdo da Web 1.0 [WCAG1.0], que foram publicadas como uma Recomendação W3C em Maio de 1999. Embora seja possível seguir tanto as WCAG 1.0 como as WCAG 2.0 (ou ambas), o W3C recomenda que os conteúdos novos e atualizados utilizem a versão WCAG 2.0. O W3C recomenda também que as políticas de acessibilidade da Web façam referência às WCAG 2.0.
  • WCAG Samurai em Português. Site Externo.
    Esta é uma errata às WCAG 1.0. A WCAG Samurai é uma alternativa à WCAG 2.0. Você pode seguir a WCAG 2.0 ou esta errata, ou mesmo não seguir nenhuma delas, mas não é possível seguir ambas.

Esquerda - Conteúdo.

Como fazer links que funcionem com e sem JavaScript.

O Básico da Web. Site Externo.
Bruno Torres.

Podemos fazer maravilhas com JavaScript e, com a popularização das chamadas HTTP via JavaScript (mais conhecidas como AJAX ) e posteriormente do que chamam de web 2.0, essa linguagem de scripts, tão mal falada e quase esquecida em um passado não muito distante, voltou à tona e é usada, hoje, por 9,9 entre 10 desenvolvedores web.

O problema é que, na maioria dos casos, os desenvolvedores não se limitam a usar o JavaScript onde ele é realmente necessário, e traz realmente algum ganho de produtividade e usabilidade para o usuário. Acabam abusando da linguagem e, pior ainda, fazendo com que funcionalidades e conteúdo estejam acessíveis apenas quando houver suporte a JavaScript.

A idéia desse texto não é falar mal do JavaScript e sim mostrar a vocês como fazer com que ele não fique no caminho do usuário, ou seja, fazer com que o que funciona com JavaScript também funcione sem JavaScript.

Na verdade, é o contrário, a idéia é usar sempre o conceito de progressive enhancement, que é, basicamente, o uso racional e correto do desenvolvimento em camadas. Algo tão simples quanto começar do começo e dar um passo de cada vez para chegar a um resultado satisfatório.

Tenha em mente que, por mais que existam poucos usuários que navegam sem JavaScript, um desses usuários pode ser um grande cliente em potencial navegando de um PDA ou o Google .

Enfim, vamos ao que interessa. Comecemos pelo exemplo mais simples..

Não existe protocolo Javascript, portanto não é certo usar Javascript:

Isso mesmo. Atire a primeira pedra aquele que nunca fez isso:

<a href="javascript:fazAlgumaCoisa();">Clique aqui para fazer alguma coisa</a>

O atributo HREF do elemento A (o popular anchor, ou link para os íntimos) foi feito especificamente para definir uma URI. Uma URI é composta por algumas partes e a primeira delas é o protocolo (na verdade, um esquema, mas vamos chamar de protocolo porque é o nome mais comum, que deve ser algo como http:, ftp:, mailto:, etc e tal. javascript: não faz parte dessa lista. Não é um esquema, não é um protocolo. Não use sob hipótese alguma.

Outra coisa importante é: só use links se realmente tiver algum lugar para apontar usando HREF. Se o propósito é totalmente outro, use outro elemento. Veremos isso mais a frente no texto.

Tá bom, eu não uso, mas como eu faço então, tio?

Há varias maneiras. Algumas melhores, outras piores. Vejamos:

<a href=http://meusite.com/teste.html onclick="fazAlgumaCoisa();return false;">Link de teste</a>

O que estamos fazendo na linha acima é um link para uma URL que existe e, caso haja suporte a JavaScript, ao ser clicado, esse link vai executar a função fazAlgumaCoisa(), definida em algum outro lugar. Notem o return false depois da chamada da função. Ele serve para que o clique seja cancelado após executar a função. Se esquecer dele, o usuário será levado à URL em questão depois de executar a tal função e, em geral, não é isso que você quer, não é?

Mas esse modo tem alguns problemas:

  1. Não separa o comportamento do conteúdo . Ou seja, você está misturando as camadas, o que não é bom por diversos motivos.
  2. Só funciona para o evento de clique do mouse. Usuários que sigam o link via teclado não vão ter a funcionalidade do script, o que pode ser o efeito desejado, mas, em geral, não é.

Como resolver isso então?

Separando o JavaScript do HTML. Para isso, você precisa definir algo para identificar esse link em específico e poder acessá-lo pelo JavaScript. Vamos usar um ID para o nosso exemplo:

<a href=http://meusite.com/teste.html id="linkteste">Link de teste</a>

Um link simples. Vamos agora adicionar a funcionalidade em um JavaScript externo:

function powerLinks(){
var link = document.getElementById(’linkteste’);
link.onclick = function(){
fazAlgumaCoisa();
return false;
}
}

window.onload = powerLinks;

Ou seja, redefinimos o evento onclick do link e adicionamos o nosso código nele. Simples, não? A última linha faz com que a função seja executada ao carregar a página (existem formas melhores de fazer isso, mais uma promessa para um outro post. Me cobrem, por favor).

Mas ainda temos o problema do mouse. Precisamos fazer com que o script funcione também para quem está navegando via teclado.

Fazemos isso usando o evento onkeypress, que é ativado quando o usuário aperta alguma tecla e checando se a tecla pressionada, que foi o ENTER. Veja como:

function powerLinks(){
//aqui entra o codigo anterior do script
link.onkeypress = function(e){
var keynum;
if(window.event) // para o IE
keynum = window.event.keyCode;
else if(e.keyCode) // Netscape/Firefox/Opera
keynum = e.keyCode;
if (keynum == 13) {
fazAlgumaCoisa();
return false;
}
}
}

Como vocês podem perceber, o IE trata o evento onkeypress um pouquinho diferente dos outros browsers, mas nada ultra complicado. 13 é o número de tecla correspondente ao ENTER. Ou seja, quando o usuário pressionar ENTER, o script será executado.

Para não deixar o post ainda mais longo, vou abordar outros tipos de abusos de JavaScript em outro post. E, como já disse, me cobrem, por favor.

Disponibilizado em: 04/04/2008.

Barra horizontal inferior.

  • Padrões Web
  • Principal
  • Topo

Acessibilidade Legal - www.acessibilidadelegal.com

Rodapé da página.

Bengala Legal -  Acessibilidade, Inclusão Social e Direitos Humanos - Site externo.

Topo.

eXTReMe Tracker

238