Técnicas para as WCAG 2.0

Ir para o conteúdo (Pressione a tecla Enter)

Técnicas de Scripting do lado do servidor para as WCAG 2.0

Esta página Web lista as Técnicas de Scripting do lado do servidor de Técnicas para as WCAG 2.0: Técnicas e Falhas para as Directrizes de Acessibilidade para o Conteúdo da Web 2.0. Para informação sobre as técnicas, consulte Introdução às Técnicas para as WCAG 2.0. Para uma lista das técnicas utilizadas em outras tecnologias, consulte o Índice.


Índice



SVR1: Implementar redireccionamentos automáticos no lado do servidor em vez de no lado do cliente

Aplicabilidade

Tecnologias do lado do servidor, incluindo linguagens de scripts do lado do servidor e ficheiros de configuração do servidor com URLs ou padrões de URL para redireccionamentos.

Esta técnica está relacionada com:

Descrição

O objectivo desta técnica é evitar a confusão que possa ser originada quando duas novas páginas são carregadas em rápida sucessão, porque uma página (a pedida pelo utilizador) redirecciona para outra. Alguns agentes de utilizador suportam a utilização do elemento meta HTML para redireccionar o utilizador para outra página após um determinado número de segundos. Isto torna a página inacessível a alguns utilizadores, especialmente utilizadores com leitores de ecrã. As tecnologias do lado do servidor fornecem métodos para implementar redireccionamentos de forma a não confundir os utilizadores. Um ficheiro de configuração ou um script do lado do servidor pode fazer com que o utilizador envie uma resposta HTTP apropriada com um código de estado no intervalo 3xx e um cabeçalho Localização com outro URL. Quando o browser recebe esta resposta, a barra de localização muda e o browser faz um pedido com o novo URL.

Exemplos

Exemplo 1: JSP/Servlets

Em Java Servlets ou Java Server Pages (JSP), os programadores podem utilizar HttpServletResponse.sendRedirect(String url).

Código Exemplo:

…
public void doGet(HttpServletRequest request, HttpServletResponse response)
    throws ServletException, IOException {
…
  response.sendRedirect("/newUserLogin.do");
}

Envia uma resposta com um código de estado 302 ("Encontrado") e um cabeçalho Localização com o novo URL para o agente de utilizador. Também é possível definir outro código de estado com response.sendError(int code, String message) com uma das constantes definida na interface javax.servlet.http.HttpServletResponse como código de estado.

Código Exemplo:

…
public void doGet(HttpServletRequest request, HttpServletResponse response)
    throws ServletException, IOException {
…
  response.sendError(response.SC_MOVED_PERMANENTLY, "/newUserLogin.do");
}

Se uma aplicação utilizar HttpServletResponse.encodeURL(String url) para reescrita de URL, uma vez que a aplicação depende das sessões, deve ser utilizado o método HttpServletResponse.encodeRedirectURL(String url) em vez de HttpServletResponse.sendRedirect(String url). É igualmente possível reescrever um URL com HttpServletResponse.encodeURL(String url) e, em seguida, passar este URL para HttpServletResponse.sendRedirect(String url).

Exemplo 2: ASP

Em Active Server Page (ASP) com VBScript, os programadores podem utilizar Response.Redirect.

Código Exemplo:

              Response.Redirect "newUserLogin.asp"

ou

Código Exemplo:

Response.Redirect("newUserLogin.asp")

O código seguinte é um exemplo mais completo com um código de estado HTTP específico.

Código Exemplo:

Response.Clear
Response.Status = 301
Response.AddHeader "Location", "newUserLogin.asp"
Response.Flush
Response.End

Exemplo 3: PHP

Em PHP, os programadores podem enviar um cabeçalho HTTP básico com o método header . O código seguinte envia um código de estado 301 e uma nova localização. Se o estado não for explicitamente definido, a resposta de redireccionamento envia um código de estado HTTP 302.

Código Exemplo:

             <?php
header("HTTP/1.1 301 Moved Permanently);
header("Location: http://www.example.com/newUserLogin.php");
?>

Exemplo 4: Apache

Os programadores podem configurar o servidor da Web Apache para processar redireccionamentos, tal como no exemplo seguinte.

Código Exemplo:

redirect 301 /oldUserLogin.jsp http://www.example.com/newUserLogin.do

Recursos

(actualmente, não existe nenhuma indicada)

Testes

Procedimento

  1. Localize cada link ou referência programática a outra página ou página Web.

  2. Para cada link ou referência programática a um URI no conjunto de páginas Web que estão a ser avaliadas, verifique se a página Web referenciada contém um código (por ex., script ou elemento meta) que origine um redireccionamento do lado do cliente.

  3. Para cada link ou referência programática a um URI no conjunto de páginas Web que estão a ser avaliadas, verifique se o URI referenciado não origina um redireccionamento OU origina um redireccionamento do lado do servidor sem um tempo limite excedido.

Resultados Esperados

  • O passo 2 é falso e o passo 3 é verdadeiro.


SVR2: Utilizar .htaccess para garantir que a única forma de aceder a conteúdo que não esteja em conformidade é a partir de conteúdo em conformidade

Aplicabilidade

Conteúdo existente num servidor da Web que suporte .htaccess (tipicamente Apache), em que uma versão em conformidade do conteúdo é fornecida como uma alternativa para uma versão que não está em conformidade.

Esta técnica está relacionada com:

Descrição

O objectivo desta técnica é garantir que os utilizadores possam sempre aceder a uma versão acessível do conteúdo quando também estão disponíveis versões que não estão em conformidade. Sempre que o conteúdo é fornecido num formato que não esteja em conformidade com as WCAG, o sítio da Web como um todo ainda pode estar em conformidade se forem fornecidas as versões alternativas do conteúdo inacessível. O Critério de Sucesso 4 requer que as versões alternativas possam derivar do conteúdo que não está em conformidade ou do respectivo URI.

Uma vez que nem sempre é possível fornecer um link acessível a partir do conteúdo que não está em conformidade, esta técnica descreve como os autores podem utilizar o Módulo Apache "mod_access" para garantir que o conteúdo que não está em conformidade só possa ser acedido a partir de URIs que funcionem como versões alternativas do conteúdo que não está em conformidade ou a partir de páginas que incluam links para a versão que não está em conformidade e a versão alternativa.

Exemplos

Exemplo 1

O seguinte ficheiro .htaccess utiliza o módulo Apache mod_redirect para redireccionar pedidos de "inaccessible.html" para "accessible.html", a menos que o pedido provenha de "accessible.html".

Código Exemplo:

# If the request for inaccessible content comes from a file 
# called accessible.html, then set an environment variable that 
# allows the inaccessible version to be displayed.
SetEnvIf Referer .*(accessible.html)$ let_me_in
<FilesMatch ^(inaccessible.html)$>
    Order Deny,Allow
    Deny from all
    Allow from env=let_me_in
</FilesMatch>

# If the request comes from anyplace but accessible.html, then 
# redirect the error condition to a location where the accessible 
# version resides
ErrorDocument 403 /example_directory/accessible.html

Exemplo 2

Este exemplo assume uma estrutura de directórios em que os documentos estão disponíveis em múltiplos formatos. Um dos formatos não cumpre as WCAG ao nível exigido e utiliza a extensão de ficheiro "jna" (Just Not Accessible). Todos estes ficheiros estão armazenados numa pasta denominada "jna" com um ficheiro .htaccess, que garante que qualquer pedido directo de um ficheiro com a extensão .jna a partir de páginas em que as versões inacessíveis ainda não se encontram disponíveis é redireccionado para uma página de índice que indica todos os formatos disponíveis.

Código Exemplo:

# If the request for inaccessible content comes from a file at 
# http://example.com/documents/index.html, then set an environment 
# variable that allows the inaccessible version to be displayed.
SetEnvIf Referer ^http://example.com/documents/index.html$ let_me_in
<FilesMatch ^(.*\.jna)$>
    Order Deny,Allow
    Deny from all
    Allow from env=let_me_in
</FilesMatch>

# If the request comes from anyplace but http://example.com/documents/index.html, then 
# redirect the error condition to a location where a link the accessible 
# version resides
ErrorDocument 403 http://example.com/documents/index.html

Recursos

Testes

Procedimento

  1. Identifique as páginas que não estão em conformidade com as WCAG no nível de conformidade exigido, em que as alternativas acessíveis são tratadas com base na utilização de ficheiros .htaccess.

  2. Visite o URI do conteúdo que não está em conformidade.

  3. Verifique se a página resultante é uma das seguintes:

    1. uma versão alternativa em conformidade para o conteúdo que não está em conformidade

    2. uma página que inclui um link para a versão alternativa em conformidade e para o conteúdo que não está em conformidade

Resultados Esperados

  • O passo 3.1 ou 3.2 é verdadeiro.


SVR3: Utilizar o referenciador HTTP para garantir que a única forma de aceder a conteúdo que não esteja em conformidade é a partir de conteúdo em conformidade

Aplicabilidade

Conteúdo criado utilizando scripting do lado do servidor, em que uma versão em conformidade do conteúdo seja fornecida como uma alternativa para uma versão que não esteja em conformidade baseada no Referenciador HTTP.

Esta técnica está relacionada com:

Notas de Apoio para o Agente de Utilizador e para a Tecnologia de Apoio

Uma vez que alguns agentes de utilizador não suportam o cabeçalho referenciador HTTP, podem ser configurados para não enviarem nenhum, ou encontram-se protegidos por um proxy ou firewall que o remove, é possível que alguns utilizadores não consigam aceder ao conteúdo que não está em conformidade quando esta técnica for implementada.

Descrição

O objectivo desta técnica é garantir que os utilizadores podem obter uma versão acessível do conteúdo, na qual são fornecidas a versão em conformidade e a versão que não está em conformidade.

O Requisito de Conformidade 1 permite que as páginas que não estão em conformidade sejam incluídas no âmbito da conformidade, desde que disponham de uma "versão alternativa em conformidade". Nem sempre é possível para os autores incluírem links suportados por acessibilidade para conteúdo em conformidade a partir de conteúdo que não está em conformidade. Por conseguinte, os autores podem necessitar de se basear na utilização de tecnologias de Scripting do Lado do Servidor (ex. PHP, ASP, JSP) para garantir que a versão que não está em conformidade só possa ser obtida a partir de uma página em conformidade.

Esta técnica descreve como utilizar as informações fornecidas pelo HTTP referer para garantir que o conteúdo que não está em conformidade só possa ser obtido a partir de uma página em conformidade. O cabeçalho HTTP referer é definido pelo agente de utilizador e contém o URI da página (se existir) que remeteu o agente de utilizador para a página que não está em conformidade.

Para implementar esta técnica, um autor identifica o URI para a versão em conformidade do conteúdo, para cada página que não está em conformidade. Quando é recebido um pedido para a versão que não está em conformidade de uma página, o servidor compara o valor do cabeçalho HTTP referer com o URI da versão em conformidade para determinar se o link para a versão que não está em conformidade provém da versão em conformidade. A versão que não está em conformidade só é apresentada se o HTTP referer corresponder ao URI da versão que não está em conformidade. Caso contrário, o utilizador é redireccionado para a versão em conformidade do conteúdo. Tenha em atenção que, ao comparar o URI no cabeçalho referenciador HTTP, as variações não relevantes no URI, tais como na consulta e no destino, devem ser levadas em consideração.

Exemplos

Exemplo 1: Demonstrações interactivas de processos físicos

Um curso de física online utiliza uma linguagem de modelação registada para fornecer demonstrações interactivas de processos físicos. O agente de utilizador para a linguagem de modelação não é compatível com a tecnologia de apoio. O sítio da Web inclui um script que utiliza o referenciador HTTP para garantir que, a menos que os utilizadores tentem aceder à demonstração interactiva a partir de uma página que contenha uma descrição em conformidade do processo e dos modelos, o servidor redirecciona o pedido para uma página em conformidade que contém um link para a versão que não está em conformidade. Os alunos podem escolher aceder à versão interactiva que não está em conformidade, mas os que não o fizerem ainda podem obter informações sobre o processo.

Exemplo 2: Utilizar o referenciador Http em PHP

O exemplo seguinte ilustra como esta técnica pode ser utilizada em PHP. Inclui dois ficheiros, conforming.php e non-conforming.php, que funcionam em conjunto para garantir que a única forma de aceder ao conteúdo que não está em conformidade seja a partir do conteúdo em conformidade.

conforming.php:

Código Exemplo:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
	"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
	<head>
    		<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
    		<title>Conforming Content</title>
    	</head>
	<body>
		<h1>This is a conforming page</h1>
		<p>From here, you can visit the <a href="non-conforming.php">non-conforming 
		page</a>. </p>
	</body>
</html>

non-conforming.php:

Código Exemplo:

<?php 
// if the request comes from a file that contains the string "conforming.php" then render the page
	if(stristr($_SERVER['HTTP_REFERER'], "conforming.php")) {
?>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
	"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
	<head>
		<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
		<title>Non-Conforming Content</title>
	</head>
	<body>
		<h1>This is a non-conforming page</h1>
		<p>Because you came from <?php echo $_SERVER['HTTP_REFERER']; ?>, you are 
			able to view the content on this page. </p>
	</body>
</html>
<?php
}
// if the referring page is not conforming.php, then redirect the user to the conforming version
else  {
header("Location: conforming.php");
}
?>

Testes

Procedimento

Quando forem fornecidas alternativas em conformidade com as WCAG para conteúdo que não esteja em conformidade:

  1. Identifique as páginas que não estão em conformidade com as WCAG no nível de conformidade exigido, em que as alternativas acessíveis são tratadas com base na utilização de ficheiros .htaccess.

  2. Visite o URI do conteúdo que não está em conformidade.

  3. Verifique se a página resultante é uma das seguintes:

    1. uma versão alternativa em conformidade para o conteúdo que não está em conformidade

    2. uma página que inclui um link para a versão alternativa em conformidade e para o conteúdo que não está em conformidade

Resultados Esperados

  • O passo 3.1 ou 3.2 é verdadeiro.


SVR4: Permitir que os utilizadores forneçam preferências para a apresentação de versões alternativas em conformidade

Aplicabilidade

Conteúdo criado utilizando scripting do lado do servidor para armazenar preferências.

Esta técnica está relacionada com:

Descrição

O objectivo desta técnica é fornecer um mecanismo para os utilizadores seleccionarem uma preferência para uma versão alternativa em conformidade de uma página Web.

O fornecimento de preferências para permitir que os utilizadores visualizem versões alternativas em conformidade pode ser efectuado de várias formas. Um método comum é fornecer um link que acciona um processo do lado do servidor que define um cookie de sessão ou persistente que o servidor da Web utiliza para modificar a página ou redireccionar o utilizador para a versão alternativa. Outros métodos incluem o fornecimento de opções específicas do utilizador que são armazenadas como parte das informações de início de sessão do utilizador para um sistema em que os utilizadores iniciam sessão para aceder a uma página Web ou serviço.

Os utilizadores que precisam de uma versão alternativa irão necessitar que o mecanismo fornecido na página que não está em conformidade esteja acessível para poderem encontrá-lo e utilizá-lo. O próprio mecanismo deve estar em conformidade com o nível de acessibilidade exigido.

Exemplos

Exemplo 1: Definir um cookie de sessão ou persistente para armazenar uma preferência de utilizador

Um sítio da Web oferece um link para uma página de "preferências" em páginas existentes no sítio da Web. Nesta página, existe a opção de ver uma versão alternativa do sítio da Web. Podem existir vários aspectos da página afectados, ou o utilizador pode optar por ver uma versão totalmente alternativa do sítio da Web. A preferência pode ser apresentar uma versão do sítio da Web, na qual o vídeo incluído apresenta as legendas, ou pode ser oferecida porque o sítio da Web principal contém problemas de conformidade de acessibilidade que são abordados apenas através da alternativa.

Um autor de páginas Web pode optar por controlar esta preferência através de um cookie, que pode ser controlado através de uma linguagem de scripts do lado do servidor, tal como PHP.

A página de preferências pode ser apresentada da seguinte forma:

Código Exemplo:

             <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
  <html xmlns="http://www.w3.org/1999/xhtml">
      <head>
      <title>Site Preferences</title>
  </head>
  <body>
      <h1>Site Preferences</h1>
      <form id="form1" name="site_prefs" method="post" action="pref.php">
          <fieldset>
              <legend>Which version of the site do you want to view?</legend>
              <input type="radio" name="site_pref" id="site_pref_reg" value="reg" />
              <label for="site_pref_reg">Main version of site</label>
              <input type="radio" name="site_pref" id="site_pref_axx" value="axx" />
              <label for="site_pref_axx">Accessibility-conforming version</label>
          </fieldset> 
      </form>
  </body>
  </html>

O formulário é submetido para o ficheiro pref.php para processamento. É definido um cookie e, neste exemplo simples, o browser do utilizador é direccionado para a página inicial do sítio da Web.

pref.php:

Código Exemplo:

<?php
    if(isset($site_pref)) {
        setcookie("site_pref",$site_pref, time() + (86400 * 30)); //set for 30 days
        header("location: http://www.example.com"); //redirects to home page
    }
?>

A página inicial é iniciada com um código que implementa a preferência do utilizador.

index.php:

Código Exemplo:

<?
if(isset($site_pref)) {
	if($site_pref="axx") {
	header("location: ./accessible/index.php");
}
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
 ...

Para um sistema baseado no início de sessão, a preferência é armazenada no registo da base de dados do utilizador e indicada pelo script do lado do servidor que gera as páginas para visualização por parte do utilizador.

Recursos

Os recursos são indicados apenas a título informativo, não implica que tenham sido aprovados.

Testes

Procedimento

  1. Mude uma preferência relativamente a como as páginas são apresentadas no sítio da Web.

  2. Verifique se a própria preferência, ou um link para a página onde possa ser definida, pode ser alcançada a partir de cada página que não está em conformidade.

  3. Verifique se as páginas Web são apresentadas de acordo com a preferência seleccionada.

  4. Verifique se, quando as preferências são definidas, a página Web está em conformidade consoante o exigido.

  5. Verifique se a página resultante é uma versão alternativa em conformidade da página original.

Resultados Esperados

  • Os passos 2 e 3 são verdadeiros.