Construindo formulários HTML/XHTML acessíveis - 3a. Parte

Publicado em: 18/04/2006

Autor: Ian Lloyd
URL do original: http://www.webstandards.org/...accessible-forms.html
Título original: Accessible HTML/XHTML forms
Este artigo é uma tradução do original em inglês publicado no site da WaSP e está dividido em três partes.
Nível Iniciante | Intermediário | Avançado

Vimos nas seções anteriores os princípios básicos para formulários, e também o uso de algumas tags pouco conhecidas a nossa disposição para projetar formulários. Seus formulários são acessíveis e você, acredite, é o máximo. Bem, na verdade, sempre existe um detalhe a mais e mesmo que você esteja atento para detalhes, alguma coisa pode escapar e acabar criando um problema. Nesta seção trataremos destes aspectos da maneira mais adequada possível.

Onde estou agora?

Usando um mouse é muito fácil saber onde você está em uma página web. E, isto torna-se muito mais fácil se você aumentar visualmente o tamanho do cursor e habilitar o "mouse trails" (se esta facilidade estiver disponível no seu Sistema Operacional). Se você não tiver restrições visuais mas não for capaz de usar um mouse, por um motivo qualquer, terá que valer-se de um teclado para navegar e neste caso não terá qualquer tipo de aviso sonoro, como os de leitores de tela, para informá-lo onde você está na página Web. Em alguns casos será difícil distinguir visualmente onde se encontra o foco na tela. Os browsers devem renderizar uma linha pontilhada ao redor do elemento de formulário que recebe o foco, mas você poderá tornar este destaque para o foco bem mais fácil de ser visualizado...

Em Cascading Style Sheets Level 2 (CSS2), existe a pseudo propriedade focus que pode ser aplicada a qualquer elemento HTML, mas é particularmente eficaz quando empregada em formulários. Não é amplamente suportada por todos os browsers, mas funciona nos brownsers Mozilla. A regra CSS a seguir:

input:focus, select:focus, textarea:focus {
  background:red;
  color:white; 
  }

... resulta em um excelente indicador visual do local onde você está a medida que se desloca pelos do formulário, tornando-o muito mais fácil de usar e interagir com qualquer um que tenha restrições motoras:

Field in focus is clearly visible

Accesskeys nos campos Inputs e os Labels

Uma accesskey (NT: atalho de teclado ) é teoricamente uma eficaz ferramenta de acessibilidade a ser usada em web sites. Lamentavelmente, neste caso, na prática a teoria não funciona. A teoria é simples - você escolhe um atalho de teclado para cada um dos elementos do formulário, possibilitando assim, um acesso rápido ao elemento. Por exemplo, para um campo de busca localizado no topo da página decidimos escolher a letra 's' como accesskey.

<input type="text" name="txtsearch" accesskey="s" />

Na prática, os diversos browsers e dispositivos especiais de usuários, se utilizam de accesskey para navegação. Consequentemente, se você deseja usar accesskey="f" para um campo de formulário a ser preenchido com o primeiro nome do usuário, o accesskey simplesmente não vai funcionar como você espera. Por que? Porque ao pressionar alt + f (alt normalmente é usado em conjunto com a letra para ativar o accesskey) você trará para a tela o menu file (arquivo) do seu browser.

Você pode aplicar o accesskey tanto ao elemento <label> como ao elemento <input>. O problema é que não há como o usuário saber que estamos usando um accesskey (somente o browser iCab fornece uma dica da existência do accesskey). Uma maneira sugerida para prover uma informação visual da existência do acesskey é adotar a técnica usada em aplicações Windows (conhecida como 'chave aceleradora'), que consiste em sublinhar a letra que representa o acesskey:

<label for="txtsearch" accesskey="S"><span class="accelerator">S</span>earch:</label> <input type="text" name="txtsearch" id="txtsearch" />

E, estabeleça uma regra para a classe accelerator que coloque um efeito sublinhado (não se limite a usar simplesmente a tag <u> para destacar o acesskey!).

.accelerator {text-decoration:underline;}

Mensagens de erros

Várias são as maneiras de se tratar os erros cometidos pelo usuário ao preencher um formulário.

  1. Pode-se usar um script no lado do cliente (JavaScript), que reporta erros de preenchimento incorreto do formulário. Contudo, para garantir que sua página seja acessível, você deve evitar esta prática, pois caso JavaScript esteja desabilitado ou não disponível na aplicação do usuário, este método não vai funcionar. Em consequência...
  2. Use outro método no lado do servidor como backup para reportar erros de preenchimento.

mensagens de erros no lado do cliente

Vamos supor que o browser está com Javascript habilitado (caso contrário vá para o título seguinte: MENSAGENS DE ERROS NO LADO DO SERVIDOR). Neste caso existem vários scripts que detectam e tratam erros de preenchimento, mas o detalhamento e estudo de scripts está fora do escopo deste artigo. Alguns caminhos criados pelos scripts são mais acessíveis que outros e isto veremos a seguir.

Frequentemente usa-se JavaScript para validar formulários de modo a que todos os erros cometidos sejam coletados e apresentados ao usuário em um grande alerta único, como mostrado abaixo:

Big alert box containing lots of information.

Agora, considere receber de uma só vez está quantidade de erros ou talvez até uma lista maior ainda quer visualmente na tela, quer sendo lida por um leitor de tela. Irritante não é mesmo? Mas, então o que fazer?

Um método melhor seria alertar o usuário a medida que o erro for detectado e encaminhá-lo de volta ao campo preenchido incorretamente para ser corrigido e assim por diante um a um para todos os campos validados. Com JavaScript habilitado, você pode valer-se dele para fazer voltar o foco ao campo preenchido incorretamente e talvez até adicionar algum texto default ao campo bem como selecioná-lo:

A smaller alert that is easier to take in, react to.\

document.forms['"personaldetails"].fullname.value="Please enter your full name";
document.forms['"personaldetails"].fullname.select();

Você poderá ainda usar JavaScript para destacar o campo, incrementando a acessibilidade para pessoas não completamente privadas de visão, mas com alguma necessidade visual. Quem sabe uma borda em negrito ao redor do campo? Ou, talvez um cor contrastante para fundo do campo?

Alguns dirão que este método é repetitivo e enfadonho, quando um número considerável de erros é cometido. Na verdade, para alguns usuários, este método pode tornar-se uma grande dor de cabeça, mas você deverá fazer uma análise e julgamento de quanto a acessibilidade está trabalhando contra a usabilidade, considerando principalmente seu público.

mensagens de erros no lado do SERVIDOR

Uma vez processado um formulário e encontrado erros de preenchimento, o método usual é o de apresentar-se no topo de uma página, um sumário dos erros encontrados destacando-se os locais onde encontrados os erros. Este método parece OK, contudo se pensarmos em um leitor de tela a informação dos erros não será tão óbvia. ("O que houve? Eu enviei o formulário e recebi de volta a mesma página? O que está acontecendo?...".

Um "truque" bem simples - Coloque um alerta no campo <title> da página (normalmente o primeiro texto que um leitor de tela lê ao entrar numa página), e repita o alerta no primeiro nível de cabeçalho da página.

<title>Alguns dados estão incorretos ou faltando no formulário que você acabou de preencher : Detalhes adicionais </title>

No sumário dos erros encontrados forneça um link encaminhando para o campo do formulário a ser corrigido. Isto evita que o usuário tenha que percorrer todo o formulário a procura dos campos incorretos.

"Aha,"diria você , "e se existirem cinco erros ? Ao clicar no link para correção este levaria ao primeiro campo a ser corrigido e os outros campos?"

O último recurso a se pensar é o de obrigar o usuário a ir e vir de um local a outro na sua página e para isto eu não sugiro a você implementar um link tipo "voltar ao topo da página" para as correções. Contudo, como o ir e vir torna-se necessário, você poderá tornar a tarefa menos enfadonha, informando ao usuário quantos são os erros a serem corrigidos:

5 errors listed for the user

Mas, talvez exista algo mais radical a se fazer? Em lugar de retornar ao usuário sempre a mesma página com campos corrigidos e campos a corrigir ou completar você poderá fazer o seguinte:

  • capturar os dados preenchidos corretamente e armazená-los
  • retornar ao usuário somente os campos com erros para correção

Em lugar de retornar o formulário completo para que o usuário vá aos campos a corrigir, você retorna simplesmente o conjunto dos campos com erros a corrigir.

Sumário

Existem muitos pequenos "truques" - e outros não tão pequenos - a serem usados com CSS e Script para incrementar a acessibilidade a formulários que este artigo poderia estender-se por mais e mais páginas. Assim, caro leitor, encerro, deixando por conta de sua imaginação e criatividade seguir adiante com demais inovações.

Nível Iniciante | Intermediário | Avançado