This Web page lists Server-side Scripting Techniques from Techniques for WCAG 2.0: Techniques and Failures for Web Content Accessibility Guidelines 2.0. Technology-specific techniques do not supplant the general techniques: content developers should consider both general techniques and technology-specific techniques as they work toward conformance.
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.
Server-side technologies, including server-side scripting languages and server configuration files with URLs or URL patterns for redirects.
This technique relates to:
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.
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)
.
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
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");
?>
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 are for information purposes only, no endorsement implied.
Use standard redirects: do not break the back button! (W3C QA Tip).
HTTP 301 Permanent Redirection Techniques by Shailesh N. Humbad.
Interface javax.servlet.http.HttpServletResponse in the Java Servlets 2.3 API documentation.
header in the PHP Manual.
Apache Module mod_alias in the Apache HTTP Server Version 2.2 Documentation describes how redirects can be specified in Apache 2.2.
Module mod_alias in the Apache HTTP Server Version 1.3 Documentation describes how redirects can be specified in Apache 1.3.
(none currently listed)
Find each link or programmatic reference to another page or Web page.
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.
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.
Step 2 is false AND step 3 is true.
If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.
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:
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 Requirement 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.
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
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 are for information purposes only, no endorsement implied.
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.
Visit the URI of the non-conforming content.
Verify that the resulting page is one of the following:
a conforming alternate version for the non-conforming content
a page that includes a link to both the conforming alternate version and the non-conforming content
Check #3.1 or #3.2 is true.
If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.
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:
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.
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.
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.
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");
}
?>
Where WCAG conforming alternatives are provided for non-conforming content:
Identify pages that do not conform to WCAG at the conformance Level claimed where accessible alternatives are served based on HTTP Referrer.
Visit the URI of the non-conforming content.
Verify that the resulting page is one of the following:
a conforming alternate version for the non-conforming content
a page that includes a link to both the conforming alternate version and the non-conforming content
Check #3.1 or #3.2 is true.
If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.
Content created using server-side scripting to store preferences.
This technique relates to:
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.
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 are for information purposes only, no endorsement implied.
Change a preference for how pages on the site are displayed.
Check that the preference itself or a link to that page where it can be set can be reached from each non-conforming page.
Check that Web pages are displayed according to the selected preference.
Check that when the preference(s) are set, the Web page conforms as claimed.
Verify that the resulting page is a conforming alternate version for the original page.
Checks #2 and #3 are true.
If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.
Server-side technologies, including server-side scripting languages and server configuration files for setting HTTP headers.
This technique relates to:
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.
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();
…
}
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 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.
Use a Live HTTP Header viewer to find the value of the "Content-Language" header.
Check that this value matches the default language of the Web page.
Step #2 is true.
If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.