Techniques for WCAG 2.0

Skip to Content (Press Enter)

Server-side Scripting Techniques for WCAG 2.0

This Web page lists Server-side Scripting Techniques from Techniques for WCAG 2.0: Techniques and Failures for Web Content Accessibility Guidelines 2.0. For information about the techniques, see Introduction to Techniques for WCAG 2.0. For a list of techniques for other technologies, see the Table of Contents.


Table of Contents



SVR1: Implementing automatic redirects on the server side instead of on the client side

Applicability

Server-side technologies, including server-side scripting languages and server configuration files with URLs or URL patterns for redirects.

This technique relates to:

Description

The objective of this technique is to avoid confusion that may be caused when two new pages are loaded in quick succession because one page (the one requested by the user) redirects to another. Some user agents support the use of the HTML meta element to redirect the user to another page after a specified number of seconds. This makes a page inaccessible to some users, especially users with screen readers. Server-side technologies provide methods to implement redirects in a way that does not confuse users. A server-side script or configuration file can cause the server to send an appropriate HTTP response with a status code in the 3xx range and a Location header with another URL. When the browser receives this response, the location bar changes and the browser makes a request with the new URL.

Examples

Example 1: JSP/Servlets

In Java Servlets or JavaServer Pages (JSP), developers can use HttpServletResponse.sendRedirect(String url).

Example Code:


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

This sends a response with a 302 status code ("Found") and a Location header with the new URL to the user agent. It is also possible to set another status code with response.sendError(int code, String message) with one of the constants defined in the interface javax.servlet.http.HttpServletResponse as status code.

Example Code:


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

If an application uses HttpServletResponse.encodeURL(String url) for URL rewriting because the application depends on sessions, the method HttpServletResponse.encodeRedirectURL(String url) should be used instead of HttpServletResponse.sendRedirect(String url). It is also possible to rewrite a URL with HttpServletResponse.encodeURL(String url) and then pass this URL to HttpServletResponse.sendRedirect(String url).

Example 2: ASP

In Active Server Page (ASP) with VBScript, developers can use Response.Redirect.

Example Code:


  Response.Redirect "newUserLogin.asp"

or

Example Code:


Response.Redirect("newUserLogin.asp")

The code below is a more complete example with a specific HTTP status code.

Example Code:


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

Example 3: PHP

In PHP, developers can send a raw HTTP header with the header method. The code below sends a 301 status code and a new location. If the status is not explicitly set, the redirect response sends an HTTP status code 302.

Example Code:


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

Example 4: Apache

Developers can configure the Apache Web server to handle redirects, as in the following example.

Example Code:


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

Resources

Resources are for information purposes only, no endorsement implied.

(none currently listed)

Tests

Procedure

  1. Find each link or programmatic reference to another page or Web page.

  2. For each link or programmatic reference to a URI in the set of Web pages being evaluated, check if the referenced Web page contains code (e.g., meta element or script) that causes a client-side redirect.

  3. For each link or programmatic reference to a URI in the set of Web pages being evaluated, check if the referenced URI does not cause a redirect OR causes a server-side redirect without a time-out.

Expected Results

  • Step 2 is false AND step 3 is true.


SVR2: Using .htaccess to ensure that the only way to access non-conforming content is from conforming content

Applicability

Content residing on a Web server that supports .htaccess (typically Apache) where a conforming version of content is provided as an alternative to a non-conforming version.

This technique relates to:

Description

The objective of this technique is to ensure that users can always access an accessible version of the content when non-conforming versions are also available. Whenever content is provided in a format that does not conform to WCAG, the site as a whole can still conform if alternate versions of the inaccessible content are provided. Conformance Criterion 4 requires that alternate versions can be derived from the nonconforming content or from its URI.

Since it is not always possible to provide an accessible link from within non-conforming content, this technique describes how authors can use Apache's Module "mod_access" to ensure that non-conforming content can only be accessed from URIs that serve as alternate versions to the non-conforming content or from pages that include links to both the non-conforming version and the alternative version.

Examples

Example 1

The following .htaccess file uses Apache's mod_redirect module to redirect requests for "inaccessible.html" to "accessible.html" unless the request comes from "accessible.html".

Example Code:


# 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

Example 2

This example assumes a directory structure where documents are available in multiple formats. One of the formats does not meet WCAG at the level claimed and uses the file extension "jna" (Just Not Accessible). All of these files are stored in a folder called "jna" with an .htaccess file which ensures that any direct request for a file with the .jna extension from pages where inaccessible versions are not already available is redirected to an index page that lists all of the available formats.

Example Code:


# 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

Resources

Resources are for information purposes only, no endorsement implied.

Tests

Procedure

  1. Identify pages that do not conform to WCAG at the conformance Level claimed where accessible alternatives are served based on the use of .htaccess files.

  2. Visit the URI of the non-conforming content.

  3. Verify that the resulting page is one of the following:

    1. a conforming alternate version for the non-conforming content

    2. a page that includes a link to both the conforming alternate version and the non-conforming content

Expected Results

  • Check #3.1 or #3.2 is true.


SVR3: Using HTTP referer to ensure that the only way to access non-conforming content is from conforming content

Applicability

Content created using server-side scripting where a conforming version of content is provided as an alternative to a non-conforming version based on HTTP Referer.

This technique relates to:

User Agent and Assistive Technology Support Notes

Because some user agents do not support the HTTP referer header, can be configured not to send one, or are behind a proxy or firewall that strips it out, it is possible that some users will be unable to access the non-conforming content when this technique is implemented.

Description

The objective of this technique is to ensure that users can obtain an accessible version of content where both non-conforming and conforming versions are provided.

Conformance Requirement 1 allows non-conforming pages to be included within the scope of conformance as long as they have a "conforming alternate version". It is not always possible for authors to include accessibility supported links to conforming content from within non-conforming content. Therefore, authors may need to rely on the use of Server Side Scripting technologies (ex. PHP, ASP, JSP) to ensure that the non-conforming version can only be reached from a conforming page.

This technique describes how to use information provided by the HTTP referer to ensure that non-conforming content can only be reached from a conforming page. The HTTP referer header is set by the user agent and contains the URI of the page (if any) which referred the user agent to the non-conforming page.

To implement this technique, an author identifies the URI for the conforming version of the content, for each non-conforming page. When a request for the non-conforming version of a page is received, the server compares the value of the HTTP referer header against the URI of the conforming version to determine whether the link to the non-conforming version came from the conforming version. The non-conforming version is only served if the HTTP referer matches the URI of the non-conforming version. Otherwise, the user is redirected to the conforming version of the content. Note that when comparing the URI in the HTTP referer header, non-relevant variations in the URI, such as in the query and target, should be taken into account.

Examples

Example 1: Interactive demonstrations of physical processes

An online physics course uses a proprietary modeling language to provide interactive demonstrations of physical processes. The user agent for the modeling language is not compatible with assistive technology. The site includes a script that uses the HTTP referer to ensure that unless users attempt to access the interactive demonstration from a page that contains a conforming description of the process and models, the server redirects the request to a conforming page which contains a link to the non-conforming version. Students may choose to access the non-conforming, interactive version, but those who do not are still able to learn about the process.

Example 2: Using Http referer in PHP

The following example illustrates how this technique can be used in PHP. It includes two files, conforming.php and non-conforming.php which work together to ensure that the only way to access non-conforming content is from conforming content.

conforming.php:

Example Code:


<!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:

Example Code:


<?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");
}
?>					
    				

Tests

Procedure

Where WCAG conforming alternatives are provided for non-conforming content:

  1. Identify pages that do not conform to WCAG at the conformance Level claimed where accessible alternatives are served based on HTTP Referrer.

  2. Visit the URI of the non-conforming content.

  3. Verify that the resulting page is one of the following:

    1. a conforming alternate version for the non-conforming content

    2. a page that includes a link to both the conforming alternate version and the non-conforming content

Expected Results

  • Check #3.1 or #3.2 is true.


SVR4: Allowing users to provide preferences for the display of conforming alternate versions

Applicability

Content created using server-side scripting to store preferences.

This technique relates to:

Description

The objective of this technique is to provide a mechanism for users to select a preference for an alternate conforming version of a Web page.

Providing preferences to allow users to view conforming alternate versions can be accomplished in several ways. One common method is to provide a link which triggers a server-side process that sets a session or persistent cookie that the Web server uses to modify the page or redirect the user to the alternate version. Other methods include providing user-specific choices that are stored as part of the user's login information for a system where users sign in to access a Web page or service.

Users requiring an alternate version will need the mechanism provided in the non-conforming page to be accessible in order to find and use it. The mechanism itself should conform to the accessibility level being claimed.

Examples

Example 1: Setting a session or persistent cookie to store a user preference

A Web site offers a link to a "preferences" page on pages within the site. On this page, there is an option to view an alternate version of the site. There may be various aspects of the page that are affected, or the user may be opting to view an entirely alternate version of the site. The preference may be to display a version of the site where video included on the site displays captioning, or it may be offered because the primary site contains accessibility conformance issues that are addressed only via the alternative.

A Web page author may choose to handle this preference via a cookie, which may be handled via a server-side scripting language such as PHP.

The preferences page may be offered as follows:

Example Code:

 <!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>

The form is submitted to the pref.php file for processing. A cookie is set, and in this simple example the user's browser is directed to the site home page.

pref.php:

Example Code:

<?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
    }
?>

The home page starts with code that implements the user's preference.

index.php:

Example Code:

<?
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>
...

For a login-based system, the preference is stored in the user's database record and referred to by the server-side script generating the pages for the user to view.

Resources

Resources are for information purposes only, no endorsement implied.

Tests

Procedure

  1. Change a preference for how pages on the site are displayed.

  2. Check that the preference itself or a link to that page where it can be set can be reached from each non-conforming page.

  3. Check that Web pages are displayed according to the selected preference.

  4. Check that when the preference(s) are set, the Web page conforms as claimed.

  5. Verify that the resulting page is a conforming alternate version for the original page.

Expected Results

  • Checks #2 and #3 are true.


SVR5: Specifying the default language in the HTTP header

Applicability

Server-side technologies, including server-side scripting languages and server configuration files for setting HTTP headers.

This technique relates to:

Description

The objective of this technique is to provide information on the primary language or languages in a Web Page, in order to identify the audience of the content. The Content-Language HTTP header can contain a list of one or more language codes, which can be used for language negotiation between a user agent and a server. If the language preferences in a user agent are set correctly, language negotiation can help the user to find a language version of the content that suits his/her preferences.

Note that the Content-Language HTTP header does not serve to identify the language used for processing the content. The content processing language can be identified by means of other techniques, such as the attributes lang and xml:lang in markup languages.

This technique ensures that the primary language of the document, as specified for example in the lang or xml:lang attribute, is listed in the Content-Language HTTP header.

Examples

Example 1: Setting content language in Java Servlet and JSP

In Java Servlet or JavaServer Pages (JSP), developers can use response.setHeader("Content-Language", lang), in which "lang" stands for a language tag (for example, "en" for English):

Example Code:

…
public void doGet(HttpServletRequest request, HttpServletResponse response)
    throws ServletException, IOException 
{
…
  response.setHeader("Content-Language", "en");
  PrintWriter out = response.getWriter();
…
}

Example 2: Setting content language in PHP

In PHP, developers can send a raw HTTP header with the header method. The following example sets the language to French:

Example Code:

<?php  header('Content-language: fr');  …  ?>  

Resources

Resources are for information purposes only, no endorsement implied.

W3C Internationalization FAQ: HTTP and meta for language information

Best Practice 9: Using HTTP or a meta tag to indicate audience in Internationalization Best Practices: Specifying Language in XHTML & HTML Content - W3C Working Group Note 12 April 2007.

Hypertext Transfer Protocol -- HTTP/1.0 (IETF Request for Comments 1945) (plain text)

Hypertext Transfer Protocol -- HTTP/1.1 (IETF Request for Comments 2616) (plain text)

header in the PHP Manual.

Tests

Procedure

  1. Use a Live HTTP Header viewer to find the value of the "Content-Language" header.

  2. Check that this value matches the default language of the Web page.

Expected Results

  • Step #2 is true.