Índice do artigo


Introdução

As Directrizes de Acessibilidade para o Conteúdo da Web Versão 1.0 (WCAG 1.0) estão principalmente preocupadas com a defesa da utilização das Tecnologias W3C, tais como o HTML e as CSS, para criar sítios web acessíveis. A Versão 2.0 das Directrizes é neutra quanto à tecnologia. Isto é, as WCAG 2.0 não referem explicitamente a utilização do HTML mas sim em melhorar a acessibilidade dos sítios web independentemente das tecnologias utilizadas.

Como parte desta nova aproximação, as WCAG 2.0 incorporam a noção de "tecnologias que suportam acessibilidade" definida como:

"Uma tecnologia que suporta acessibilidade é uma tecnologia (HTML, CSS, etc.) que funcionará com tecnologias de apoio (TA) e as características de acessibilidade dos navegadores e outros agentes de utilizador. Apenas tecnologias (incluindo características das tecnologias), que são "suportadas pela acessibilidade" podem ser utilizadas em conformidade com o Critério de Sucesso das WCAG 2.0."

Apesar de não existir lista reconhecida de "tecnologias que suportam acessibilidade", é expectável que todas as tecnologias W3C e as mais comuns que não são tecnologias W3C (por exemplo JavaScript e Flash) quando utilizadas apropriadamente suportem acessibilidade.

As WCAG 2.0 estão construídas sob 4 princípios básicos. No seio destes princípios, existem 12 Directrizes que contêm um total de 61 Critérios de Sucesso testáveis. A cada Critério de Sucesso é atribuído um dos três níveis de conformidade definidos: A (mais baixo), AA, AAA (mais alto).

A Web Accessibility Initiative (WAI) disponibilizou os seguintes documentos primários:

  • Recomendação das WCAG 2.0 (30 de Abril de 2008)
  • Como Conhecer as WCAG 2.0 documento referência (30 de Abril de 2008), que contem sugestões de técnicas para cada Critério de Sucesso
  • Compreender as WCAG 2.0 (30 de Abril de 2008)

Os diversos formulários apresentados neste documento foram testados com os seguintes leitores de ecrã: JAWS 7.1, JAWS 9 e Window-Eyes 6.1.

Formulários: acessibilidade e tecnologias de apoio

Os formulários podem apresentar problemas aos utilizadores da Web portadores de deficiência visual e/ou motora e às pessoas com incapacidades cognitivas ou de aprendizagem. Uma pessoa com deficiência visual que dependa de uma tecnologia de apoio como o leitor de ecrã com áudio e/ou linha Braille pode facilmente perder-se num formulário mal feito. Para estes dispositivos funcionarem correctamente, a tecnologia precisa de ser capaz de associar uma etiqueta de formulário (pedido ou imediato) com o controlo correcto do formulário, tal como um campo de texto ou uma checkbox.

Muitas pessoas com deficiência visual ou motora interagem com a web (e com formulários) usando primeiramente um teclado em vez do rato. Como resultado as suas interacções tendem a ser sequenciais pela ordem amplamente controlada pela forma como a página fora desenhada.

Os leitores de ecrã permitem que os utilizadores interajam com uma página web de variadas formas. Por defeito, os leitores de ecrã lerão sequencialmente o conteúdo da página; com o JAWS é chamado o modo "Cursor Virtual do PC" e com o Window-Eyes é chamado "Modo Navegação". Por conveniência, este documento referirá a este modo por defeito de acesso como o modo de "Leitura". Utilizando o modo de Leitura, os utilizadores podem rapidamente localizar um formulário numa página e fazer o varrimento do seu conteúdo.

Quando o utilizador necessita de introduzir texto no formulário, tem de usar o teclado para desligar o Cursor Virtual e na linguagem do JAWS ligar ao "Formulário" em modo de entrada. Com o Window-Eyes o utilizador tem que ligar o modo "Navegar desligado". A isto será chamado modo "Formulário" neste documento.

No modo Formulário, o utilizador está basicamente restrito a movimentar-se entre os elementos na página que podem aceitar foco (por exemplo entradas de formulário e links) e isto significa que se precisarem de ler o material circundante tal como parágrafos ou cabeçalhos têm que sair do modo Formulário.

Etiquetas de entrada de formulário

Dois Pontos de Verificação das WCAG 1.0 referem-se directamente à utilização das etiquetas para formulários:

"Até que os agentes do utilizador suportem associações explicitas entre as etiquetas e os controlos de formulário, para todos os controlos com etiquetas implicitamente associados, certifique-se que as etiquetas se encontram apropriadamente posicionadas." [Prioridade 2]

WCAG 1.0 Ponto de Verificação 10.2

"Associe explicitamente as etiquetas aos respectivos controlos. Em HTML essa associação faz-se geralmente através do elemento LABEL." [Prioridade 2]

WCAG 1.0 Ponto de Verificação 12.4

Combinando estes dois pontos de verificação, quando lidos em conjunção com a especificação do HTML 4.01, parecem exigir todas as entradas de formulário para haver uma etiqueta que esteja correctamente posicionada e explicitamente associada ao controlo (entrada).

Nenhum dos Critérios de Sucesso das WCAG 2.0 mencionam directamente o HTML ou formulários. Contudo, os dois seguintes Critérios de Sucesso concernem, em parte, em identificar os controlos do formulário.

"Informações e Relações: As informações, a estrutura e as relações transmitidas através de apresentação podem ser determinadas de forma programática ou estão disponíveis no texto." (Nível A)

WCAG 2.0 Critério de Sucesso 1.3.1

"Etiquetas ou Instruções: As etiquetas ou instruções são fornecidas quando o conteúdo exigir a entrada de dados por parte do utilizador." (Nível A)

WCAG 2.0 Critério de Sucesso 3.3.2

Os Critérios de Sucesso 1.3.1 e 3.3.2 contêm ambos as seguintes Técnicas do tipo Suficiente (HTML):

H44: Utilizar elementos de etiqueta para associar os textos de etiquetas com os controlos de formulários (HTML)

H65: Utilizar o atributo TITLE para identificar os controlos do formulário quando o elemento LABEL não possa ser usado (HTML)

Associação explícita

A Técnica do tipo Suficiente H44 é muito semelhante ao Ponto de Verificação 12.4 das WCAG 1.0 em que requer que as etiquetas do formulário sejam associadas explicitamente aos seus controlos.

A associação explícita significa que o elemento HTML label com o atributo for, e o atributo de entrada id devem ser utilizados para associar texto ou uma etiqueta de gráfico com um controlo específico de formulário. Os atributos podem ser utilizados com quase todos os elementos de entrada, incluindo caixas de texto, checkboxes e radio buttons, área de texto e seleccionar. Contudo, o atributo id para cada elemento (radio button, texto etc.) num documento tem que ser único.

Formulário simples demonstrando a posição apropriada das etiquetas:

Formulário 1

Formulário 1: Posição correcta e associação explícita das etiquetas

O seguinte excerto de código para o formulário em cima utiliza label for e id para associar explicitamente a entrada de texto e os radio buttons com as suas etiquetas.

HTML

<form action="#" method="post">
  <div>
    <label for="nm">Name: </label> 
    <input id="nm" type="text" name="name" value="">
  </div>
  <div>
    <input id="yes" name="request" value="yes" type="radio">
    <label for="yes">Yes</label> &nbsp; 
    <input id="no" name="request" value="no" type="radio">
    <label for="no">No</label> 
  </div>
</form>

No modo Leitura, o leitor de ecrã JAWS apresentará o formulário simples de cima da seguinte forma:

Nome dois pontos, nome dois pontos editar. Radio button não activado, sim. Radio button não activado, não.

Quando accionar para o modo Formulário o formulário é apresentado assim:

Nome dois pontos editar, preencha o campo. Sim radio button não activado. Um de dois, para seleccionar a selecção pressione as teclas de seta para cima ou para baixo.

Outro beneficio em associar explícitamente uma etiqueta ao seu controlo (entrada) é o aumento de tamanho da área que pode ser clicada para aceder à entrada. Isto ajuda particularmente pessoas com baixa visão ou com incapacidade para executar movimentos finos com controlo e destreza (motricidade fina), mas que ainda consigam utilizar um rato. Com a entrada de texto (tal como o exemplo acima do nome) clicando em qualquer lugar na etiqueta ou na caixa de texto posicionará o cursor no inicio da área de entrada de texto. Semelhantemente, um radio button ou checkbox podem ser activados clicando quer na etiqueta ou botão (ou caixa).

Nota: O elemento etiqueta não é utilizado para o que se segue, porque as etiquetas para estes elementos são fornecidos através do valor do atributo (para botões de Submissão ou Reset), o atributo alt (para botões de imagem), ou os próprios elementos de conteúdo (botão).

  • Botões de Submissão ou Reset (entrada tipo="submeter" ou entrada tipo="reset")
  • Botões de imagem (entrada tipo="imagem")
  • Campos escondidos de entrada (entrada tipo="escondido")
  • Botões Script (elementos de botões ou (entrada tipo="botão"))

Fonte: Técnica H44 das WCAG 2.0:

O atributo title

Quando se procede à identificação dos controlos de formulário, um dos mais significativos avanços com as WCAG 2.0 é a Técnica do tipo Suficiente H65 que permite o controlo do formulário, o atributo title ser utiliizado com este propósito, "quando o desenho visual não possa acomodar a etiqueta ou onde possa ser confuso mostrar a etiqueta".

Por questões de desenho a entrada do campo de pesquisa em alguns sítios web, posicionada no topo das páginas, é apresentada sem etiqueta. De modo a cumprir completamente com as WCAG 1.0, alguns criadores forneceram uma etiqueta não-visivel para essas entradas de pesquisa utilizando a técnica CSS off left, técnica para remover a etiqueta da área visivel enquanto continua a permitir ser acedido pelos leitores de ecrã. Com as WCAG 2.0, o uso do atributo title do controlo do formulário é considerado uma Técnica do tipo Suficiente.

Formulário 2

Formulário 2: Formulário com campo de pesquisa do sítio Web sem etiqueta

Quando nenhuma etiqueta é fornecida para um controlo de formulário, como no exemplo em cima, alguns leitores de ecrã automaticamente associarão o texto imediatamente precedente ao controlo. Com o exemplo em cima, isto pode levar a alguns utilizadores de leitor de ecrã a acreditar que essa entrada se relaciona com a procura de informação sobre as questões de emprego (Employment).

Contudo, quando nenhuma etiqueta é apresentada e o atributo title, para o controlo de formulário (campo de entrada de texto), é utilizado, as versões recentes do JAWS e do Window-Eyes apresentarão o atributo title quando o controlo do formulário receber o foco.

HTML

<div id="global">
  <ul>
    <li><a href="#">About us</a></li>
    <li><a href="#">Services</a></li>
    <li><a href="#">Employment</a></li>
  </ul>
  <form method=get id="searchform" action="/search.php">
    <div>
      <input type="text" title="site search" name="query" id="q" value="">
      <input type="submit" value="search">
    </div>
  </form>
</div>

Por vezes, os formulários necessitam de fornecer informação que se relaciona com a seguinte questão. Quando esta informação é apresentada como um cabeçalho, ou frase/parágrafo como apresentado no Formulário 3 em baixo, não será apresentado pelo leitor de ecrã quando está em modo de Formulário. Uma forma de assegurar que esta informação é apresentada em modo Formulário é utilizar a informação como legend dentro de um fieldset. (Ver a secção mais adiante Agrupar elementos de formulário.)

Uma vez que a utilização do atributo title para identificar um controlo de formulário é uma Técnica do tipo Suficiente perante as WCAG 2.0 isto fornece uma outra potencial forma de marcar esta questão.

Formulário 3

Formulário 3: Formulário com radio buttons que utilizam atributos title

HTML

<form action="#" method="post">
  <div>
    <label for="name">Name: </label> 
    <input id="name" type="text" name="name" value="">
  </div>
  <div>
    <label for="email">Email: </label> 
    <input id="email" type="text" name="email" value="">
  </div>
  <p>
    Choose a subscription option from below:
  </p>
  <div>
    <input id="Weekly" title="weekly subscription" 
    name="subscribe" value="Weekly" type="radio">
    <label>Weekly</label>
    <input id="Monthly" title="monthly subscription" 
    name="subscribe" value="Monthly" type="radio">
    <label>Monthly</label> 
    <input id="Quarterly" title="quarterly subscription" 
    name="subscribe" value="Quarterly" type="radio">
    <label>Quarterly</label> 
  </div>
</form>

Quando o formulário em cima é apresentado pelo JAWS em modo de Leitura, a instrução, "Escolha uma opção de subscrição abaixo indicada" seguida pelos radio buttons é apresentada da seguinte forma:

"Escolha uma opção de subscrição abaixo indicada dois pontos."
"Radio button não activado subscrição semanal. Semanal"
"Radio button não activado subscrição mensal. Mensal"
"Radio button não activado subscrição trimestral. Trimestral"

No modo Formulário a instrução do parágrafo não é lida. Contudo, o objectivo dos radio buttons é claramente comunicado pelo leitor de ecrã apresentando o atributo title para cada um dos radio buttons da seguinte forma:

"Subscrição semanal radio button não activado; Uma de três. Para alterar a selecção pressione a tecla seta para cima ou para baixo. [Pressione a seta para baixo]"
Subscrição mensal radio button não activado; duas de três. Para alterar a selecção pressione a tecla seta para cima ou para baixo. [Pressione a seta para baixo]"
Subscrição trimestral radio button não activado; três de três. Para alterar a selecção pressione a tecla seta para cima ou para baixo."

O Window-Eyes também apresenta efectivamente o atributo title em ambos modos de Leitura e de Formulário, apesar do Window-Eyes tender geralmente a usar menos palavras.

Vale a pena mencionar que ambos os leitores JAWS e Window-Eyes não necessitam ligar o modo Formulário (isto é desligar o Cursor virtual ou Modo Navegador) de forma a fazer a selecção de radio button ou checkbox.

VIDEO 1: Relato do leitor de Ecrã sobre a associação explícita e o atributo title.

Controlos de formulário em tabelas de dados

Algumas tabelas de dados contêm entradas de formulário que podem ser utilizados para introduzir informação. Por exemplo um formulário para encomendar quantidades de diferentes produtos ou um formulário para depositar dinheiro em diferentes contas é mostrado no exemplo simplificado em baixo.

Formulário 4

Formulário 4: Tabela de dados contendo campos de formulário de entrada de texto

A inclusão de uma etiqueta para cada uma das entradas do formulário, que podem ser utilizadas para introduzir informação como na tabela em cima, é tanto desnecessária como redundante. Segundo as WCAG 2.0, o uso do atributo title, como demonstrado no excerto de código em baixo, seria uma Técnica do tipo Suficiente e provavelmente seria a aproximação mais fazível em situações como esta.

HTML

<form action="#" method="post">
  <table summary="form for allocating deposits to different accounts">
    <caption><strong>Deposit form</strong></caption>
    <thead>
      <tr>
        <th>Account name</th>
        <th>Account balance</th>
        <th>Deposit amount</th>
      </tr>
    </thead>
    <tbody>
      <tr>
        <th>Personal savings</th>
        <td align="center">$1,200.00</td>
        <td align="center"><input type="text" 
        title="deposit amount for personal savings" 
        value=""></td>
      </tr>
      <tr>
        <th>Investment account</th>
        <td align="center">$2,200.00</td>
        <td align="center"><input type="text" 
        title="deposit amount for investment account" 
        value=""></td>
      </tr>
      <tr>
        <th>Holidays</th>
        <td align="center">$3,200.00</td>
        <td align="center"><input type="text" 
        title="deposit amount for holidays" 
        value=""></td>
      </tr>
    </tbody>
  </table>
</form>

Quando o "Formulário de depósito" acima é lido pelo JAWS em modo Leitura, o leitor de ecrã identifica uma célula contendo a entrada de formulário e apresenta o controlo do atributo title como se segue:

Montante do depósito para poupanças pessoais, editar.

Se o utilizador deseja entrar num campo específico do formulário, então precisa de ligar o modo Formulário. O leitor de ecrã JAWS apresentará o atributo title para cada entrada conforme o utilizador pressionar a tecla tab através do formulário:

Montante do depósito para poupanças pessoais editar, preencha o campo. [tab]
Montante do depósito para contas de investimento editar, preencha o campo. [tab]
Montante do depósito para férias editar, preencha o campo.

Quando se tem acesso ao "Formulário de depósito" com o Window-Eyes acontece algo similar:

Video 2: Demonstração da forma como os leitores de ecrã transmitem o formulário de depósito (tabela de dados) do formulário acima indicado.

Agrupar elementos de formulário

Um formulário onde diferentes elementos estão bem organizados com os seus similares e agrupados torna a sua utilização mais fácil para todos. Agrupar os elementos de formulário pode ser particularmente útil para pessoas que dependem de leitores de ecrã e para aqueles com incapacidades cognitivas ou de aprendizagem.

Segundo as WCAG 1.0, o Ponto de Verificação 12.3 defende a utilização de elementos HTML fieldset e legend para este propósito.

Dividir grandes blocos de informação em mais grupos manuseáveis onde seja natural e apropriado. Por exemplo, em HTML, use OPTGROUP para agrupar elementos OPTION dentro de uma SELECT; agrupar controlos de formulário com FIELDSET e LEGEND; usar listas encaixadas onde seja apropriado; usar cabeçalhos para estruturar documentos, etc." [Prioridade 2].

WCAG 1.0 Ponto de Verificação 12.3

Nas WCAG 2.0 o Critério de Sucesso 1.3.1 contém as seguintes três Técnicas de tipo Suficiente que fundamentalmente remetem para a mesma questão:

H71: Fornecer uma descrição para grupos de controlos de formulário utilizando elementos fieldset e legend (HTML)

H82: Agrupar os controlos de formulário com FIELDSET e LEGEND (HTML)

H85: Utilizar OPTGROUP para agrupar elementos OPTION dentro duma SELECT (HTML)

Fieldset e legend

Os elementos HTML fieldset e legend permitem os formulários com diferentes áreas de interesse serem organizados de forma lógica. Por defeito, o elemento fieldset criará uma caixa à volta da secção selecionada e a legend ficará em negrito. Desta forma, os elementos de formulário podem ser agrupados em categorias identificadas. Por exemplo:

Formulário 5

Formulário 5: Fieldset e legend

HTML

<fieldset>
  <legend> Personal Details</legend>
  <div>
    <label for="name">Name:</label> 
    <input id="name" type="text" name="name" size="30">
  </div>
  <div>
    <label for="idnum">ID Number:</label> 
    <input id="idnum" type="text" name="id number" size="20">
  </div> 
</fieldset>

Os diferentes navegadores podem mostrar por defeito a margem fieldset de diferentes formas. As Folhas de Estilo em Cascata podem ser utilizadas para remover a borda ou modificar a sua aparência.

A maioria dos leitores de ecrã irá identificar os diferentes itens dentro de um fieldset. No modo 'Formulário' o JAWS transmite o valor da legend antes da etiqueta para cada controlo contidos dentro do fieldset. Os Dados Pessoais do formulário, na imagem acima, são apresentados pelo JAWS em modo 'Formulário' da seguinte forma:

Dados pessoais, nome dois pontos editar, preencha o campo

Dados pessoais, ID número dois pontos editar, preencha o campo

O Window-Eyes identifica quando um fieldset começa e termina e transmite a legend no inicio do fieldset.

Fieldset encaixado

Um fieldset pode ser encaixado dentro de outro fieldset. Por exemplo:

Formulário 6

Formulário 6: Fieldsets Encaixados

Ao encaixar os fieldsets é preciso ter cuidado para evitar fazer um formulário demasiado complicado e assegurar que o objectivo do encaixe seja correctamente apresentado pelos leitores de ecrã. Por exemplo, quando um controlo de formulário extra é apresentado depois de um fieldset encaixado, como se mostra em cima, alguns leitores de ecrã associarão o precedente legend com o controlo de formulário extra ao invés da legend da origem fieldset.

O JAWS 7.1 em modo Formulário por exemplo, transmite da seguinte forma o formulário com um fieldset encaixado como mostrado no exemplo de cima:

Participante, nome dois pontos editar, preencha o campo [tab]
Áreas de interesse, checkbox escrever não activada. Para activar pressione a barra de espaços [tab]
Áreas de interesse, checkbox desenhar não activada. Para activar pressione a barra de espaços [tab]
Áreas de interesse, checkbox pintar não activada. Para activar pressione a barra de espaços [tab]
Áreas de interesse, checkbox cerâmica não activada. Para activar pressione a barra de espaços [tab]
Áreas de interesse, cônjuge dois pontos editar, preencha o campo

NOTA: A etiqueta de formulário "Cônjuge" (Companion) é apresentado com a legend "Áreas de Interesse".

Vídeo 3: Transmissão do leitor de ecrã para fieldset e legend

JavaScript

De um modo geral, as WCAG 1.0 não consideravam o JavaScript universalmente acessível e requeriam que as páginas web funcionassem sem o suporte do JavaScript.

"Certifique-se que as páginas são usáveis quando scripts, applets, ou outros objectos programáveis se encontram desactivados ou não são suportados. Se isto não for possível, forneça informação equivalente numa página alternativa acessível." [Prioridade 1]

WCAG 1.0 Ponto de Verificação 6.3

Quando era utilizado JavaScript, o mesmo tinha que ser directamente compatível com as tecnologias de apoio e não fazer uso de manipuladores de eventos dispositivo-dependentes.

"Faça com que os elementos programáveis tais como scripts e applets sejam directamente acessíveis ou compatíveis com tecnologias de apoio." [Prioridade 1 se for funcionalmente importante e não apresentada em qualquer outro local, caso contrário será de Prioridade 2]

WCAG 1.0 Ponto de Verificação 8.1

"No caso dos scripts, especifique manipuladores de eventos por software em vez de manipuladores de eventos dependentes de dispositivos."

WCAG 1.0 Ponto de Verificação 9.3

Contudo, um número significativo de formulários online usam JavaScript. Uma vez que a maioria das tecnologias de apoio actualmente suportam JavaScript quando é utilizado apropriadamente, e a maioria dos utilizadores destas tecnologias acedem à internet com navegadores e dispositivos que permitem JavaScript, a utilização de JavaScript per-se já não é susceptível de causar problemas significativos de acessibilidade.

Visto que as WCAG 2.0 são desenhadas para serem neutras quanto à tecnologia nenhum dos Critérios de Sucesso relata especificamente a utilização de JavaScript. Porém, há 5 Requisitos de Conformidade que devem ser ordenados pelo conteúdo para ser classificado como "conforme" com as WCAG 2.0.

Requisitos de Conformidade, 4 estados:

"Apenas Tecnologias que Suportam Acessibilidade: Apenas as tecnologias que suportam acessibilidade podem ser tidas em conta para satisfazer os critérios de sucesso. As informações ou funcionalidades que são implementadas em tecnologias que não suportam acessibilidade estão também disponíveis através das tecnologias que suportam acessibilidade."

Noções sobre Conformidade (WCAG 2.0)

Quando se trata de utilizar JavaScript com formulários, as seguintes Técnicas, que são suportadas pelos modernos navegadores e leitores de ecrã, o seguinte pode ser útil:

"Fornecer validação e alerta do lado do cliente: Para validar a entrada de dados por parte do utilizador à medida que os valores são introduzidos em cada campo, através de scripting do lado do cliente. Se forem encontrados erros, uma caixa de diálogo de alerta descreve a natureza do erro no texto."

Descrição do W3C da Técnica SCR18

"SCR19: Utilizar um evento onchange num elemento select sem provocar uma alteração de contexto: O objectivo desta técnica é demonstrar como utilizar correctamente um evento onchange com um elemento select para actualizar outros elementos na página Web. Esta técnica não provoca uma alteração de contexto."

Descrição do W3C da Técnica SCR19

"SCR21: Utilizar funções do Modelo de Objecto de Documento (DOM) para adicionar conteúdo a uma página: O objectivo desta técnica é demonstrar como utilizar as funções do Modelo de Objecto de Documento (DOM) para adicionar conteúdos a uma página, em vez de utilizar document.write ou object.innerHTML. Esta técnica é útil para inserir mensagens de erro no topo de um formulário."

Descrição do W3C da Técnica SRC21

Para mais informação e técnicas veja a Lista completa das Técnicas de Scripting do lado do Cliente para as WCAG 2.0 do W3C

Deteção de erro e mensagens

As WCAG 1.0 não continham nenhuma directriz que fosse directamente relacionada com a prevenção e correcção de erros. Endereçar esta questão com a seguinte Directriz especifica é um dos avanços significativos das WCAG 2.0:

"Directriz 3.3 Assistência de Entrada: Ajudar os utilizadores a evitar e corrigir erros."

Esta Directriz contém os seis seguintes Critérios de Sucesso que se referem directamente à prevenção, deteção e correcção de erro:

"Identificação do Erro: Se um erro de entrada for automaticamente detectado, o item que apresenta erro é identificado e o erro é descrito ao utilizador por texto."

Critério de Sucesso 3.3.1 (Nível A) das WCAG 2.0

"Etiquetas ou Instruções: As etiquetas ou instruções são fornecidas quando o conteúdo exigir a entrada de dados por parte do utilizador."

Critério de Sucesso 3.3.2 (Nível A) das WCAG 2.0

"Sugestão de Erro: Se um erro de entrada for automaticamente detectado e forem conhecidas sugestões de correcção, então as sugestões são fornecidas ao utilizador, a menos que ponham em perigo a segurança da finalidade do conteúdo."

Critério de Sucesso 3.3.3 (Nível AA) das WCAG 2.0

"Prevenção de Erros (Legal, Financeiro, Dados): Para páginas Web que façam com que ocorram responsabilidades jurídicas ou transacções financeiras para o utilizador, que modificam ou eliminam dados controláveis pelo utilizador em sistemas de armazenamento de dados, ou que submetam respostas de teste do utilizador, no mínimo, uma das seguintes afirmações é verdadeira:

  • Reversível: As submissões são reversíveis.
  • Verificado: Os dados introduzidos pelo utilizador são verificados relativamente à existência de erros de entrada e é facultada uma oportunidade ao utilizador de os corrigir.
  • Confirmado: Está disponível um mecanismo para rever, confirmar e corrigir as informações antes de finalizar a submissão."

Critério de Sucesso 3.3.4 (Nível AA) das WCAG 2.0

"Ajuda: Está disponível ajuda contextualizada."

Critério de Sucesso 3.3.5 (Nível AAA) das WCAG 2.0

"Prevenção de Erros (Todos): Para páginas Web que exijam que o utilizador submeta informações, no mínimo, uma das seguintes afirmações é verdadeira:" (Igual ao 3.3.4)

Critério de Sucesso 3.3.6 (Nível AAA) das WCAG 2.0

O W3C fornece muitas "Técnicas do Tipo Suficiente" e "Técnicas do Tipo Aconselhada" para ajudar os desenhadores a preparar formulários que obedeçam ao Critério de Sucesso 3.3: Assistência de Entrada.

Técnicas para Directriz 3.3 para Ajudar os Utilizadores a Evitar e Corrigir os Erros

Os desenhadores podem considerar útil as seguintes Técnicas do Tipo Suficiente, que são suportadas por modernos navegadores e leitores de ecrã:

G83: Fornecer descrições em texto para identificar os campos obrigatórios.

SCR18: Fornecer validação e alerta do lado do cliente.

G85: Fornecer uma descrição em texto quando a entrada de dados por parte do utilizador não se enquadre no formato ou valores obrigatórios.

G139: Criar um mecanismo que permita aos utilizadores passarem directamente para os erros

SCR21: Utilizar funções do Modelo de Objecto de Documento (DOM) para adicionar conteúdo a uma página.

Em geral, quando a validação detecta erros num formulário, existe um processo com 4 passos para assegurar uma recuperação de erros utilizável e acessivel.

  1. Alertar o utilizador para a presença de um erro de uma maneira acessível.
  2. Fornecer conselho sobre como o erro pode ser corrigido.
  3. Permitir ao utilizador aceder facilmente aos elementos do formulário que necessitem de ser rectificados.
  4. Permitir a re-submissão e re-validação do formulário.

Evitar utilizar jargão ou código organizacional para mensagens de erro.

O seguinte formulário fornece uma sugestão como as mensagens de erro podem ser apresentadas de uma forma útil e acessível:

Formulário 7

Formulário 7: Identificar erros e fornecer assistência

 

Formulário 7a

Formulário 7a: Identificar erros e fornecer assistência

O formulário "Deteção de Erros e Mensagens" utiliza JavaScript do lado do cliente para identificar um erro (por exemplo falha em preencher o primeiro número) e fornece a descrição do erro no topo da página. A descrição do erro é um link, que quando activado move o cursor (foco) para o controlo do formulário correspondente de forma que o utilizador possa facilmente proceder à correcção necessária.

O código fonte para o Formulário 7 Deteção de Erros e Mensagens contém o requerido CSS, JavaScript e HTML para o formulário.

Este formulário funciona com as versões recentes do JAWS e Window-Eyes. Contudo, uma vez que poucas pessoas acedem à web com dispositivos que não suportam JavaScript, os desenhadores devem assegurar que a deteção de erro do lado do cliente falha graciosamente onde o JavaScript não está disponível ou se tornou inactivo. Isto inclui a provisão de apoio da verificação do lado do servidor, que é equivalente ao serviço do lado do cliente, para utilizadores que não têm JavaScript.

Video 4: Formulário de deteção de erro e mensagem

Auto-preenchimento da selecção de opções

Alguns formulários contêm diversos menus do tipo combo drop-down que usam elementos seleccionados, e a escolha feita num menu determina o que é apresentado no menu seguinte. Esta questão é abordada na Directriz 3.2 das WCAG 2.0:

Alteração a Pedido: As alterações de contexto são iniciadas apenas a pedido do utilizador, ou está disponível um mecanismo para desactivar essas alterações.

Critério de Sucesso 3.2.5 (Nível AAA) das WCAG 2.0

O Critério de Sucesso 3.2.5 abrange um número de questões, com Técnicas do Tipo Suficiente para cada uma. Em relação à utilização dos menus de selecção que ditam o conteúdo dos outros menus é fornecida a seguinte Técnica do Tipo Suficiente:

SCR19: Utilizar um evento onchange num elemento select sem provocar uma alteração de contexto.

O seguinte exemplo contém dois elementos Select, "Região" e "País". Quando a Região é seleccionada, por exemplo Ásia-Pacífico, as escolhas de País para essa Região ficam disponiveis. Se outra Região for seleccionada (e.g. Europa) então as escolhas de País são automaticamente actualizadas para as opções correspondentes da nova Região.

Formulário 8

Formulário 8: Formulário com actualização do elemento Select

 

Formulário 8a

Formulário 8a: Formulário apresentando as opções do segundo elemento Select

O JavaScript é utilizado para permitir que as opções disponiveis no segundo elemento Select sejam dinamicamente determinadas pela primeira opção Select.

Este formulário funciona com as versões recentes do JAWS e do Window-Eyes. O código fonte para o Formulário 8 JavaScript e Menus Select contém o requerido CSS, JavaScript e HTML para o formulário.

NB: Tendo em conta que algumas pessoas acedem à web sem suporte JavaScript, é aconselhável fornecer uma forma alternativa acessível de obter a informação que está disponível neste tipo de formulário.

Vídeo 5: Formulário com a actualização dinâmica de Select

Mostrar/esconder as secções do formulário

Com os formulários multi-facetados por vezes é útil mostrar apenas as áreas relevantes do formulário. Os bancos e outras instituições financeiras muitas vezes têm formulários que contêm um número de variáveis e a informação que o utilizador é solicitado a fornecer depende da variável que o utilizador seleccionar: Por exemplo, deseja um empréstimo à habitação ou um empréstimo pessoal? Ou, deseja fazer um seguro do seu carro ou barco?

Existem consideráveis benefícios de usabilidade e acessibilidade em fornecer ao utilizador apenas os campos do formulário que são relevantes para o seu pedido. Isto pode ser particularmente útil para pessoas com incapacidades cognitivas e com dificuldades de aprendizagem.

Uma combinação de CSS e JavaScript pode ser utilizada para mostrar e esconder diferentes secções de um formulário. Contudo deve-se ter cuidado para assegurar que se mostram novamente as secções que estão disponiveis para os utilizadores de leitor de ecrã, ao mesmo tempo parar o leitor de ecrã de voltar ao topo da página quando uma nova secção é apresentada. Por defeito, quando é feito a reinicialização a uma página o ecrã começará a ser lido do topo da página.

Esta questão está relacionada com a seguinte Técnica do Tipo Suficiente que refere três Critérios de Sucesso:

SCR26: Introduzir conteúdo dinâmico no Modelo de Objecto de Documento imediatamente a seguir ao elemento accionador

O W3C fornece a seguinte descrição desta técnica:

"Esta técnica insere novo conteúdo no Modelo de Objecto de Documento (DOM) imediatamente seguido do elemento que foi activado para accionar o script. O elemento accionador tem de ser um link ou um botão, e o script tem de ser invocado a partir do seu evento onclick. Estes elementos podem receber o foco de forma nativa e o seu evento onclick é independente do dispositivo. O foco permanece no elemento activado e o novo conteúdo, introduzido após o mesmo, surge imediatamente a seguir na ordem de tabulação e na ordem de leitura do leitor de ecrã.

Note que esta técnica funciona para actualizações síncronas. Para actualizações assíncronas (por vezes chamadas AJAX), é necessária uma técnica adicional para informar a tecnologia de apoio que o conteúdo assíncrono foi introduzido."

SCR26: Inserindo conteúdo dinâmico no DOM

O formulário seguinte contém uma secção mostrar/esconder que é determinada pela selecção do radio button. Se for seleccionado "Cone" a escolha do tamanho do cone é apresentado. Porém, se for seleccionado "Copo" a secção do tamanho do cone não é apresentada.

Formulário 9

Formulário 9: Formulário Mostrar/esconder, secção Mostrar exibida

Este formulário funciona com as versões recentes do JAWS e do Window-Eyes. O código fonte do Formulário 9 Mostrar-esconder contém o requerido CSS, JavaScript e HTML para o formulário.

Vídeo 6: Formulário com uma secção mostrar-esconder

Respostas cronometradas

Alguns formulários têm tempo limite associado. Por exemplo, as transacções online muitas vezes utilizam formulários onde um cookie ou a variável do lado do servidor é regulada para expirar depois de um determinado tempo ou como resultado de um periodo de inactividade.

Completar um formulário muitas vezes requer do utilizador do sítio web realizar um número de separadas tarefas que envolvem a leitura e a compreensão de intruções, fazer escolhas e depois proceder à acção apropriada.

A fixação do tempo limite para formulários provavelmente exclui alguns utilizadores com certas incapacidades de completar o formulário no tempo requerido. Onde a imposição de um periodo de tempo limite não for essencial deve ser evitado.

É provavél que pessoas com incapacidades cognitivas e dificuldades de aprendizagem demorem mais tempo a ler e a compreender informação escrita. De igual modo, é normal que as pessoas que dependem das tecnologias de apoio tais como leitores de ecrã e manípulos de entrada para aceder à informação numa página web e interagir com formulários, também demorem mais tempo.

Estas necessidades devem ser tidas em consideração quando são fixados os tempos limite e está especificamente mencionado nas WCAG 2.0:

"Ajustável por Temporização: Para cada limite de tempo definido pelo conteúdo, no mínimo, uma das seguintes afirmações é verdadeira:

Desligar: O utilizador pode desligar o limite de tempo antes de o atingir; ou

  • Ajustar: O utilizador pode ajustar o limite de tempo antes de o atingir, acima de um grande intervalo que dure, no mínimo, dez vezes mais do que a predefinição; ou
  • Prolongar: O utilizador é avisado antes de o tempo expirar e tem, no mínimo, 20 segundos para prolongar o limite de tempo com uma simples acção (por exemplo, "pressionar a barra de espaços"), e o utilizador pode prolongar o limite de tempo, no mínimo, dez vezes; ou
  • Excepção em Tempo Real: O limite de tempo é uma parte necessária de um evento em tempo real (por exemplo, um leilão), e não é possível nenhuma alternativa ao limite de tempo; ou
  • Excepção Essencial: O limite de tempo é essencial e prolongá-lo iria invalidar a actividade; ou
  • Excepção de 20 Horas: O limite de tempo é superior a 20 horas."

Critério de Sucesso 2.2.1 (Nível A) das WCAG 2.0

O Critério de Sucesso 2.2.1 contém as seguintes "Técnicas do Tipo Suficiente" que os desenhadores podem considerar útil:

SCR16: Fornecer um script que avise o utilizador que um limite de tempo está prestes a expirar: O objectivo desta técnica é notificar os utilizadores de que está prestes a terminar o tempo para completar uma interacção e fornecer um mecanismo para solicitar mais tempo.

Técnica SCR16

SCR1: Permitir ao utilizador prolongar o limite de tempo predefinido: O objectivo desta técnica é permitir que os utilizadores prolonguem o limite de tempo predefinido.

Técnica SCR1

G133: Fornecer uma caixa de verificação na primeira página de um formulário de várias partes, que permite aos utilizadores solicitar um limite de tempo de sessão maior ou nenhum limite de tempo de sessão. O objectivo desta técnica é minimizar o risco de os utilizadores perderem o seu trabalho fornecendo uma caixa de verificação para solicitar mais tempo.

Técnica G133

O W3C aconselha, o Critério de Sucesso 2.2.1 "deve ser considerado em combinação com o Critério de Sucesso 3.2.1 que estabelece limites nas alterações de contéudo ou contexto como resultado da acção do utilizador."

Campos obrigatórios

Muitos formulários contêm campos de entrada que o utilizador terá que completar. Todos os utilizadores, incluindo aqueles com incapacidades, deveriam ser capazes de facilmente determinar quais os campos obrigatórios, ou solicitados.

A cor utilizada sozinha não deve ser utilizada para indicar os campos obrigatórios. Esta questão está abordada no Critério de Sucesso 1.4.1 (Uso da Cor) com as seguintes Técnicas do Tipo Suficiente:

G122: Incluir um sinal de aviso de texto sempre que forem utilizados sinais de aviso a cores

G14: Garantir que as informações transmitidas através de cores diferentes estão também disponíveis em texto

Muitas vezes é utilizado um símbolo ou a palavra "obrigatório" para indicar a obrigatoriedade do campo. O símbolo ou palavra deve ser apresentado com a etiqueta do controlo do formulário, e dentro do elemento label. Não deve ser apresentado depois do controlo do formulário (entrada).

Quando um símbolo é utilizado, a chave para o símbolo deve ser apresentada antes do formulário e não no rodapé do formulário.

Cores e fontes

Algumas pessoas com incapacidade visual são incapazes de distinguir certas cores ou podem não ser capazes de distinguir texto do plano de fundo se houver contraste insuficiente entre os dois. Em geral, utilize a cor com moderação nos formulários, e se utilizada deve haver uma diferença considerável entre o texto e o plano de fundo.

Nas WCAG 2.0 o requisito mínimo de assegurar contraste suficiente está mencionado no Critério de Sucesso 1.4.3:

Contraste (Mínimo): A apresentação visual de texto e imagens de texto tem uma relação de contraste de, no mínimo, 5:1, excepto para o seguinte:

  • Texto Ampliado: Texto ampliado e as imagens compostas por texto ampliado têm uma relação de contraste de, no mínimo, 3:1;
  • Texto em plano Secundário: O texto ou imagens de texto que fazem parte de um componente de interface de utilizador inactivo, que são meramente decorativos, que não estão visíveis para ninguém, ou que são parte de uma imagem que inclui outro conteúdo visual significativo, não têm requisito de contraste."

Critério de Sucesso 1.4.3 (Nível AA) das WCAG 2.0

As seguintes Técnicas do Tipo Suficiente são fornecidas para este requisito:

Situação A: texto com tamanho inferior a 18 (se não estiver a negrito) e inferior a 14 (se estiver a negrito)

G18: Garantir que existe uma relação de contraste de pelo menos 5:1 entre o texto (e imagens compostas por texto) e o plano de fundo

G148: Não especificar cor no plano de fundo, não especificar cor no texto, e não usar características da tecnologia que alterem estes padrões

Situação B: o tamanho do texto tem pelo menos 18 (se não estiver a negrito) e pelo menos 14 (se estiver a negrito)

G145: Garantir que existe uma relação de contraste de pelo menos 3:1 entre o texto (e imagens compostas por texto) e o plano de fundo

G148: Não especificar cor no plano de fundo, não especificar cor no texto, e não usar características da tecnologia que alterem estes padrões

NB: As WCAG 2.0 utilizam um algoritmo diferente do utilizado nas WCAG 1.0 para determinar as diferenças das cores entre o primeiro plano e o plano de fundo.

De igual modo, alguns utilizadores consideram o tamanho padrão das fontes nos sítios web na maioria muito pequena para uma leitura confortável. Isto pode-se tornar um maior problema no caso do utilizador não ser capaz de aumentar o tamanho da fonte através do seu navegador, por isso deve ser sempre usado tamanho de fonte com valores relativos. Com os formulários, é necessário garantir que quando o tamanho da fonte é aumentado desta forma que o texto e os diferentes elementos não se sobreponham.

Esta questão é abordada na Técnica do Tipo Suficiente para o Critério de Sucesso 1.4.4:

Redimensionar texto: Excepto para legendas e imagens de texto, o texto pode ser redimensionado sem tecnologia de apoio até 200 porcento sem perder conteúdo ou funcionalidade.

Critério de Sucesso 1.4.4 (Nível AA) das WCAG 2.0

Referências e mais informação


Tutorial Original de Roger Hudson com o título: Accessible Forms using WCAG 2.0
Tradução portuguesa: Cláudia Cardoso
Revisão Técnica: Jorge Fernandes