Introdução
Formulários coletam informações e dados a serem processados.É difícil o
entendimento dos aspectos de acessibilidade relacionados aos
formulários.
Conteúdos estáticos do site serão facilmente visualizados e
entendidos por usuários de leitores de tela ou até mesmo, talvez, por um
computador Braille se cosiderarmos que você usou uma marcação semântica
e bem estruturada (tal como h1 -
h6 para cabeçalhos). Ler ou deixar de ler um conteúdo
estático no site é uma atitute passiva do visitante, mas ao encontrar um
formulário o usuário quer interagir com ele e de repente
muda-se um campo - é uma via de duplo sentido. Para formulários, a
marcação torna-se crucial para a correta captura de informações do
usuário.Elementos HTML usados
Os elementos HTML usados para marcação de formulários são:- O elemento
- podem ser de variados tipos como: texts, submit, button, radio button e checkbox;
button
Não se aplica (usar atributo)
Mas , e a acessibilidade?
O quê? Oh sim, nada se disse sobre as "tags de acessibilidade". Acredite em nós, seguindo as diretrizes acima e construindo seus formulários de acordo com os princípios CHI, eles serão mais acessíveis ecumprirão melhor sua finalidade. Até aqui mostramos as boas práticas e como manter as coisas simples e sem complicações (aprofundaremos neste fundamento mais adiante). E, com o propósito de manter as coisas simples, devemos considerar como usar (ou não usar) scripts para construir formulários mais acessíveis.Scripts
Considere que scripts estão desabilitados no lado do usuário
Um formulário deve cumprir sua finalidade independentemente de scripts estarem ou não habilitados no browser (ainda que eles suportem scripts - lembre-se que alguns dispositivos adaptados não suportam scripts). Validação e manipulação de dados no lado do servidor possibilita o funcionamento de formulários independentemente de scripts no lado do usuário. Muitos desenvolvedores ainda se utilizam largamente de scripts no lado do cliente para validação, ou mesmo disparadores de eventos (observe a seguir um formulário, cujo funcionamento é totalmente dependente de scripts estarem habilitados no lado do usuário:Evite usar JavaScript para navegação
Por outro lado quais as implicações de se usar JavaScript que desencadeia no formulário uma ação fora do controle do usuário? O exemplo clássico ocorre com um elemento de formulário do tipo "drop-down-list" usado como ferramenta para navegação. Muitos sites utilizam este recurso que consiste em ao usuário selecionar um item do menu, automaticamente abre-se a página selecionada. Para usuários impossibilitados de usar mouse (pessoas cegas navegando com leitores de tela, pessoas com restrições motoras e outros casos mais) o uso do menu torna-se muito difícil (ou mesmo impossível).
Usar o teclado para tentar selecionar as opções da lista não terá efeito, pois resultará sempre em seleção e ativação do primeiro item da lista. A tentativa de encontrar uma solução inteligente resultou em uma armadilha para a acessibilidade. Mantenha as coisas simples - use uma lista "drop-down-list" sempre que assim desejar, mas forneça um botão "Go" (Ir) para o usuário ativar sua seleção, conforme mostrado abaixo:
Uma observação sobre tabelas
Uma outra questão envolvendo a acessibilidade em formulários, diz respeito ao uso de tabelas para se conseguir um layout alinhado e certinho. Esta prática não implica necessariamente em um problema de acessibilidade, mas poderá vir a causar problemas - um layout de formulário baseado em tabela é irrelevante para um leitor de tela, o conteúdo é lido na ordem em que foi escrito no código fonte. Se você dispor seu layout de formulário, agrupando os rótulos descritivos e os controles do formulário você "quebrará" o relacionamento entre eles. Isto pelo fato de que leitores de tela ' linearizam' as tabelas e interpretarão erroneamente o formulário, conforme exemplo mostrado na imagem a seguir:
Para que serve a tag label?
O elementoLABEL funciona como uma espécie de indicador
de caminho a seguir. Ele diz ao agente de usuário: "Hey,
você está vendo aquele campo ali? Aquele de nome 'firstname'? Bem,
aquele campo é meu, e, por favor não não faça confusão com ele nem
comigo. Ou, em código XHTML seria assim:
Isto cria um inconfundível relacionamento entre o texto (rótulo descritivo) e o campo, relacionamento este que só será quebrado se você introduzir erro na marcação do código (notadamente quando aplicada a técnica de copiar-colar um código pronto e depois esquecer-se de mudar alguma id - lembre-se ids devem ser únicas, você não pode ter mais de um elemento em uma página com a mesma id).
Se for de sua conveniência, agora você pode alterar a ordem entre texto e campo sem causar confusão para os dispositivos adaptados, pois eles continuarão a entender qual texto refere-se a que campo:
O uso do elemento
LABEL acrescenta um benefício adicional não tão óbvio a primeira vista - muitos browsers renderizam o conteúdo da tag 
Onde posso usar Label?
A tag| Form element looks like | Coded like: |
|---|---|
|
|
First
Name: |
id="txtFirstName" value="">
Age:
Age:
id="radAge4_0"value="Under30"> Under 30
id="radAge4_1" value="Over30"> Over 30
What colours do you like:
What colors do you like:
id="chk0_0"value="red"> red
id="chk1_1" value="green"> green
id="chk2_2" value="blue"> blue
id="chk3_3" value="purple"> purple
Your
life story:Favorite
Town:>
Agrupando elementos do formulário
Você já tinha ouvido falar de
e O elemento Fieldset
Imagine uma lista de 50 checkboxes com opções de variados assuntos no qual você tenha que examinar todos, para escolher o(s) que interessa(am). Eu não ficaria aborrecido - e você?Tem um ditado que diz: "Dividir para vencer'', e temos um amigo no XHTML, o elemento
FIELDSET.
Usando
FIELDSET você divide seus 50 itens, em digamos, 5
grupos de tópicos claramente identificáveis, cada um deles com 10
propriedades/atributos comuns. Você incrementa a
usabilidade/acessibilidade fazendo sua página mais clara para usuários
com deficiências visuais, ou usuários com restrições cognitivas. Leitores de tela, quando oferecem suporte para este elemento, o fazem ainda de maneira precária, tornando questionável sua utilidade para usuários cegos. Contudo, o fato de ainda não haver total suporte para este elemento em dispositivos adaptados, não é justificativa para não empregá-los. Ao contrário, as boas práticas aconselham seu emprego desde já e com vistas ao futuro quando houver pleno suporte.
Abaixo um exemplo do emprego de
FIELDSET (em conjunto com LEGEND
- que vem a ser o texto 'My Radio Buttons' descritivo do conteúdo da caixa (ou seja, do fieldset):
O código de marcação do exemplo acima é:
Como acontece com a maioria dos elementos HTML, você pode usar CSS para estilizar
FIELDSET de acordo com suas preferências, como o exemplo mostrado na figura abaixo:
FIELDSET pode ser usado para agrupar qualquer variedade de elementos input
de formulários - e não um agrupamento único como mostrado acima. É
perfeitamente legal usar fieldsets aninhados sempre que necessário, como
mostrado na figura (um formulário bem simples) abaixo:
O elemento Optgroup
Da mesma forma como você pode agrupar inputs de um formulário, pode também agrupar as opções de uma tag Você percebeu como foi escrito o código acima?
A lista do tipo "drop-down list" foi agrupada por tipos de alimentos. Alguns browsers renderizam corretamente o elemento optgroup e outros simplesmente o ignoram. Mas, assim como ocorre com fieldset, a falta de suporte por alguns browsers e dispositivos adaptados, não é justificativa para não usá-lo.
Obs: não confunda a tag
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;
}
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.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
E, estabeleça uma regra para a classe accelerator que coloque um efeito sublinhado (não se limite a usar simplesmente a tag
.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.- 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...
- 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:
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:
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
</code>
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.</p>
<p>
<code><title>Alguns dados estão incorretos ou faltando no
formulário que você acabou de preencher : Detalhes adicionais
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:
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
Referência:
http://maujor.com/tutorial/formac-a.php
Nenhum comentário:
Postar um comentário