Techniken für WCAG 2.0

Zum Inhalt

Server-seitige Scripting-Techniken für WCAG 2.0

Auf dieser Webseite werden Server-seitige Scripting-Techniken der Techniken für WCAG 2.0: Techniken und Fehler für WCAG 2.0 aufgelistet. Für Informationen zu den Techniken siehe Einführung in die Techniken für WCAG 2.0. Für eine Liste anderer Techniken lesen Sie das Inhaltsverzeichnis.


Inhaltsverzeichnis



SVR1: Server-seitige statt client-seitige Implementierung automatischer Umleitungen

Anwendbarkeit

Server-seitige Techniken, einschließlich server-seitiger Scripting-Sprachen und Server-Konfigurationsdateien mit URLs oder URL-Pattern für Weiterleitungen.

Die Technik bezieht sich auf:

Beschreibung

Das Ziel dieser Technik ist es, Verwirrungen zu vermeiden, die dadurch verursacht werden können, wenn zwei neue Seiten in schneller Abfolge geladen werden, weil eine Seite (diejenige, die vom Benutzer angefordert wurde) zu einer anderen weiterleitet. Einige Benutzeragenten unterstützen die Benutzung des HTML meta-Elements, um den Benutzer nach einer festgelegten Anzahl an Sekunden zu einer anderen Seite weiterzuleiten. Dies führt dazu, dass die Seite für einige Benutzer nicht mehr barrierefrei ist, besonders für Benutzer mit Screenreadern. Server-seitige Techniken stellen Methoden zur Verfügung, um Weiterleitungen auf eine Art zu implementieren, die Benutzer nicht verwirrt. Ein server-seitiges Script oder Konfiguration kann dazu führen, dass der Server eine entsprechende HTTP-Antwort mit einem Status-Code im 3xx range und einen Location header mit einer anderen URL sendet. Wenn der Browser diese Antwort erhält, ändert sich die Adressleiste und der Browser macht eine Anfrage mit dem neuen URL.

Beispiele

Beispiel 1: JSP/Servlets

In Java Servlets oder JavaServer Pages (JSP) können Entwickler HttpServletResponse.sendRedirect(String url) benutzen.

Code-Beispiel:

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

Dies sendet eine Antwort mit einem 302 Status-Code („Found“) und einen Location header mit dem neuen URL an den Benutzeragenten. Es ist auch möglich, einen anderen Status-Code mit response.sendError(int code, String message) festzulegen, wobei eine der Konstanten in der Benutzerschnittstelle javax.servlet.http.HttpServletResponse als Status-Code definiert wird.

Code-Beispiel:

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

Wenn eine Anwendung HttpServletResponse.encodeURL(String url) zum Umschreiben von URLs benutzt, weil die Anwendung von Sitzungen abhängig ist, sollte die Methode HttpServletResponse.encodeRedirectURL(String url) statt HttpServletResponse.sendRedirect(String url) benutzt werden. Es ist außerdem möglich, einen URL mit HttpServletResponse.encodeURL(String url) umzuschreiben und diesen URL dann an HttpServletResponse.sendRedirect(String url) zu übergeben.

Beispiel 2: ASP

In Active Server Page (ASP) mit VBScript können Entwickler Response.Redirect benutzen.

Code-Beispiel:

						  Response.Redirect "newUserLogin.asp"

oder

Code-Beispiel:

						Response.Redirect("newUserLogin.asp")

Der unten stehende Code ist ein vollständigeres Beispiel mit einem bestimmten HTTP Status-Code.

Code-Beispiel:

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

Beispiel 3: PHP

In PHP können Entwickler einen raw HTTP header mit der header-Methode senden. Der unten stehende Code sendet einen 301 Status-Code und eine neue Adresse. Wenn der Status nicht explizit festgelegt wird, sendet die Weiterleitungs-Antwort einen HTTP Status-Code 302.

Code-Beispiel:

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

Beispiel 4: Apache

Entwickler können den Apache Web Server so konfigurieren, dass er Weiterleitungen wie in dem folgenden Beispiel verarbeitet.

Code-Beispiel:

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

Ressourcen

Ressourcen sind nur zu Informationszwecken und keine offizielle Empfehlung.

(derzeit keine aufgelistet)

Tests

Vorgehensweise

  1. Finden Sie jeden Link oder programmtechnische Referenz zu einer anderen Seite oder Webseite.

  2. Prüfen Sie für jeden Link oder jede programmtechnische Referenz zu einem URI in der Reihe der zu evaluierenden Webseiten, ob die referenzierte Webseite Code enthält (z.B. meta-Element oder Script), der dazu führt, dass eine client-seitige Weiterleitung ausgelöst wird.

  3. Prüfen Sie für jeden Link oder jede programmtechnische Referenz zu einem URI in der Reihe der zu evaluierenden Webseiten, ob der referenzierte URI keine Weiterleitung ODER eine server-seitige Weiterleitung ohne Zeitlimit auslöst.

Erwartete Ergebnisse

  • Schritt 2 ist falsch UND Schritt 3 ist wahr.

Wenn dies eine ausreichende Technik für ein Erfolgskriterium ist, dann bedeutet das Scheitern an diesem Testverfahren nicht zwangsläufig, dass das Erfolgskriterium nicht auf irgendeine andere Art und Weise erfüllt wurde, sondern nur, diese Technik nicht erfolgreich implementiert wurde und nicht benutzt werden kann, um die Konformität zu erklären.


SVR2: Benutzung von .htaccess, um sicherzustellen, dass der einzige Weg, um auf nicht-konformen Inhalt zuzugreifen, von konformem Inhalt aus ist

Anwendbarkeit

Inhalt der auf einem Webserver, der .htaccess (typischerweise Apache) unterstützt, liegt, wo eine konforme Version des Inhalts als Alternative zu einer nicht-konformen Version bereitgestellt wird.

Die Technik bezieht sich auf:

Beschreibung

Das Ziel dieser Technik ist es sicherzustellen, dass Benutzer immer auf eine barrierefreie Version des Inhalts zugreifen können, wenn nicht-konforme Versionen ebenfalls zur Verfügung stehen. Wann immer Inhalte im einem Format bereitgestellt werden, das nicht konform zu den WCAG ist, kann die Site als Ganzes immer noch konform sein, wenn alternative Versionen des nicht barrierefreien Inhalts bereitgestellt werden. Konformitätsbedingung 4 verlangt, dass alternative Versionen von dem nicht-konformen Inhalt oder von dessen URI abgeleitet werden können.

Da es nicht immer möglich ist, einen barrierefreien Link von innerhalb des nicht-konformen Inhalts bereitzustellen, beschreibt diese Technik, wie Autoren Apaches Modul „mod_access“ benutzen können, um sicherzustellen, dass auf nicht-konforme Inhalte nur von URIs aus zugegriffen werden kann, die als alternative Versionen zu dem nicht-konformen Inhalt dienen, oder von Seiten aus, die Links zu sowohl der nicht-konformen als auch der alternativen Version enthalten.

Beispiele

Beispiel 1

Die folgende .htaccess-Datei benutzt das Apache-Modul mod_redirect, um Anfragen nach „inaccessible.html“ zu „accessible.html“ umzuleiten, außer die Anfrage kommt von „accessible.html“.

Code-Beispiel:

						# 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

Beispiel 2

Dieses Beispiel nimmt eine Verzeichnis-Struktur an, wenn Dokumente in mehreren Formaten zur Verfügung stehen. Eines der Formate erfüllt die WCAG nicht auf der angegebenen Stufe und benutzt die Dateierweiterung „jna“ (Just Not Accessible - einfach nicht barrierefrei). Alle diese Dateien sind in einem Ordner mit Namen „jna“ gespeichert mit einer .htaccess-Datei, die sicherstellt, dass jede direkte Anfrage nach einer Datei mit der Erweiterung .jna von Seiten aus, wo die nicht barrierefreien Versionen nicht schon zur Verfügung stehen, auf eine Indexseite weitergeleitet wird, auf der alle verfügbaren Formate aufgelistet werden.

Code-Beispiel:

						# 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

Ressourcen

Ressourcen sind nur zu Informationszwecken und keine offizielle Empfehlung.

Tests

Vorgehensweise

  1. Identifizieren Sie Seiten, die nicht auf der angegebenen Stufe konform zu den WCAG sind und wo barrierefreie Alternativen basierend auf der Benutzung der .htaccess-Dateien geliefert werden.

  2. Besuchen Sie den URI des nicht-konformen Inhalts.

  3. Verifizieren Sie, dass die daraus resultierende Seite eine der folgenden ist:

    1. eine konforme Alternativversion für den nicht-konformen Inhalt

    2. eine Seite, die sowohl einen Link zu der konformen Alternativversion als auch zu dem nicht-konformen Inhalt enthält

Erwartete Ergebnisse

  • Test #3.1 oder #3.2 ist wahr.

Wenn dies eine ausreichende Technik für ein Erfolgskriterium ist, dann bedeutet das Scheitern an diesem Testverfahren nicht zwangsläufig, dass das Erfolgskriterium nicht auf irgendeine andere Art und Weise erfüllt wurde, sondern nur, diese Technik nicht erfolgreich implementiert wurde und nicht benutzt werden kann, um die Konformität zu erklären.


SVR3: Benutzung eines HTTP Referer, um sicherzustellen, dass der einzige Weg, um auf nicht-konformen Inhalt zuzugreifen, von konformem Inhalt aus ist

Anwendbarkeit

Inhalt, der erstellt wurde, indem server-seitiges Scripting benutzt wurde, wo eine konforme Version des Inhalts als Alternative zu einer nicht-konformen Version bereitgestellt wird basierend auf HTTP Referer.

Die Technik bezieht sich auf:

Anmerkungen zur Unterstützung durch Benutzeragenten und assistierende Techniken

Da einige Benutzeragenten den HTTP referer header nicht unterstützen, so konfiguriert werden können, dass sie keinen senden oder hinter einem Proxy oder einer Firewall sind, die diesen streichen, ist es möglich, dass einige Benutzer nicht in der Lage sind, auf den nicht-konformen Inhalt zuzugreifen, wenn diese Technik implementiert wird.

Beschreibung

Das Ziel dieser Technik ist es sicherzustellen, dass Benutzer eine barrierefreie Version des Inhalts abrufen können in Fällen, in denen sowohl nicht-konforme als auch konforme Versionen bereitgestellt werden.

Konformitätsbedingung 1 erlaubt es, dass nicht-konforme Seiten im Rahmen der Konformität ausgenommen werden können, so lange sie eine „konforme Alternativversion“ haben. Es ist Autoren nicht immer möglich, die Barrierefreiheit unterstützende Links zu konformen Inhalten von innerhalb der nicht-konformen Inhalte einzufügen. Daher kann es sein, dass Autoren auf die Benutzung server-seitiger Scripting-Techniken angewiesen sind (z.B. PHP, ASP, JSP) um sicherzustellen, dass die nicht-konforme Version nur von einer konformen Seite aus erreicht werden kann.

Diese Technik beschreibt, wie man Informationen, die durch den HTTP referer bereitgestellt werden, benutzt um sicherzustellen, dass nicht-konforme Inhalte nur von einer konformen Seite aus erreicht werden können. Der HTTP referer header wird von dem Benutzeragenten gesetzt und enthält den URI der Seite (falls vorhanden), die den Benutzeragenten zu der nicht-konformen Seite verwiesen hat.

Um diese Technik zu implementieren identifiziert ein Autor für jede nicht-konforme Seite den URI für die konforme Version des Inhalts. Wenn eine Anfrage für eine nicht-konforme Version einer Seite erhalten wird, vergleicht der Server den Wert der HTTP referer header mit dem URI der konformen Version um zu bestimmen, ob der Link zu der nicht-konformen Seite von einer konformen Version kam. Die nicht-konforme Version wird nur ausgeliefert, wenn der HTTP referer dem URI der nicht-konformen Version entspricht. Andernfalls wird der Benutzer zu der konformen Version des Inhalts umgeleitet. Beachten Sie, dass, wenn Sie den URI im HTTP referer header vergleichen, nicht-relevante Abweichungen im URI, wie beispielsweise im query und target, berücksichtigt werden sollten.

Beispiele

Beispiel 1: Interaktive Demonstrationen physikalischer Prozesse

Ein Online-Physikkurs benutzt eine proprietäre Modellierungssprache, um interaktive Demonstrationen physikalischer Prozesse bereitzustellen. Der Benutzeragent für die Modellierungssprache ist nicht kompatibel mit assistierenden Techniken. Die Site beinhaltet ein Script, das den HTTP referer benutzt um sicherzustellen, dass der Server die Anfrage zu einer konformen Seite, die einen Link zu der nicht-konformen Version enthält, umleitet, außer wenn Benutzer versuchen, auf die interaktive Demonstration von einer Seite aus zuzugreifen, die eine konforme Beschreibung des Prozesses und des Models enthält. Es kann sein, dass sich die Studenten dazu entschließen, auf die nicht-konforme, interaktive Version zuzugreifen, aber diejenigen, die dies nicht tun, sind trotzdem dazu in der Lage, etwas über den Prozess zu lernen.

Beispiel 2: Benutzung von Http referer in PHP

Das folgende Beispiel veranschaulicht, wie diese Technik in PHP benutzt werden kann. Es enthält zwei Dateien, conforming.php und non-conforming.php, die zusammen arbeiten um sicherzustellen, dass der einzige Weg, um auf nicht-konformen Inhalt zuzugreifen, von konformem Inhalt aus ist.

conforming.php:

Code-Beispiel:

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

Code-Beispiel:

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

Vorgehensweise

Wo WCAG-konforme Alternativen für nicht-konforme Inhalte bereitgestellt werden:

  1. Identifizieren Sie Seiten, die nicht auf der angegebenen Konformitätsstufe WCAG-konform sind und wo barrierefreie Alternativen basierend auf HTTP Referrer geliefert werden.

  2. Besuchen Sie den URI des nicht-konformen Inhalts.

  3. Verifizieren Sie, dass die daraus resultierende Seite eine der folgenden ist:

    1. eine konforme Alternativversion für den nicht-konformen Inhalt

    2. eine Seite, die sowohl einen Link zu der konformen Alternativversion als auch zu dem nicht-konformen Inhalt enthält

Erwartete Ergebnisse

  • Test #3.1 oder #3.2 ist wahr.

Wenn dies eine ausreichende Technik für ein Erfolgskriterium ist, dann bedeutet das Scheitern an diesem Testverfahren nicht zwangsläufig, dass das Erfolgskriterium nicht auf irgendeine andere Art und Weise erfüllt wurde, sondern nur, diese Technik nicht erfolgreich implementiert wurde und nicht benutzt werden kann, um die Konformität zu erklären.


SVR4: Es dem Benutzer ermöglichen, Präferenzen zur Darstellung von konformen Alternativversionen zu bestimmen

Anwendbarkeit

Inhalt, der durch die Benutzung von server-seitigem Scripting zum Speichern von Einstellungen erstellt wurde.

Die Technik bezieht sich auf:

Beschreibung

Das Ziel dieser Technik ist es, einen Mechanismus für Benutzer bereitzustellen, um eine Einstellung für eine alternative konforme Version einer Webseite auszuwählen.

Die Bereitstellung von Einstellungen, um es Benutzern zu erlauben, konforme Alternativversionen anzusehen, kann auf verschiedene Arten erreicht werden. Eine gängige Methode ist es, einen Link bereitzustellen, der einen server-seitigen Prozess auslöst, der einen Cookie für eine Sitzung oder einen dauerhaften Cookie setzt, den der Webserver benutzt, um die Seite zu verändern oder den Benutzer zu der alternativen Version umzuleiten. Andere Methoden beinhalten die Bereitstellung einer benutzer-spezifischen Auswahl, die als Teil der Login-Informationen des Benutzers für ein System gespeichert ist in Fällen, in denen ein Benutzer sich einloggt, um auf eine Webseite oder einen Service zuzugreifen.

Für Benutzer, die eine alternative Version benötigen, muss der auf der nicht-konformen Seite bereitgestellte Mechanismus, barrierefrei sein, damit sie diesen finden und benutzen können. Der Mechanismus selber sollte auf der angegebenen Barrierefreiheitsstufe konform sein.

Beispiele

Beispiel 1: Setzen eines Cookies für eine Sitzung oder eines permanenten Cookies, um eine Benutzereinstellung zu speichern

Eine Website bietet einen Link zu einer Seite mit „Einstellungen“ auf Seiten innerhalb der Site an. Auf dieser Seite gibt es eine Option, um eine alternative Version der Site anzusehen. Es kann sein, dass verschiedene Aspekte der Seite betroffen sind oder der Benutzer entscheidet sich dazu, sich eine komplett alternative Version der Site anzusehen. Die Einstellung könnte so sein, dass eine Version der Site angezeigt wird, in der ein auf der Site enthaltenes Video Untertitel anzeigt, oder es kann angeboten werden, weil die Hauptsite Probleme mit der Konformität zur Barrierefreiheit enthält, die nur über die Alternative adressiert werden.

Der Autor einer Webseite kann sich dazu entschließen, die Einstellung über einen Cookie abzuwickeln, was über eine server-seitige Scripting-Sprache wie PHP verarbeitet wird.

Die Einstellungsseite kann wie folgt angeboten werden:

Code-Beispiel:

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

Das Formular wird zur Verarbeitung an die pref.php-Datei gesendet. Es wird ein Cookie gesetzt und in diesem einfachen Beispiel wird der Browser des Benutzers zur Homepage der Site geleitet.

pref.php:

Code-Beispiel:

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

Die Homepage beginnt mit Code, der die Einstellung des Benutzers implementiert.

index.php:

Code-Beispiel:

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

Bei einem System, das auf einer Anmeldung basiert, wird die Einstellung im Datenbankverzeichnis des Benutzers gespeichert und das server-seitige Script, das die Seiten zur Ansicht für den Benutzer generiert, greift darauf zurück.

Ressourcen

Ressourcen sind nur zu Informationszwecken und keine offizielle Empfehlung.

Tests

Vorgehensweise

  1. Ändern Sie eine Einstellung dazu, wie Seiten auf der Site dargestellt werden.

  2. Prüfen Sie, ob die Einstellung selber oder ein Link zu der Seite, auf der sie festgelegt werden kann, von jeder nicht-konformen Seite aus erreicht werden kann.

  3. Prüfen Sie, ob Webseiten entsprechend der ausgewählten Einstellung angezeigt werden.

  4. Prüfen sie, ob, wenn die Einstellung(en) festgelegt werden, die Webseite so konform ist wie angegeben.

  5. Verifizieren Sie, dass die daraus entstehende Seite eine konforme Alternativversion der Originalseite ist.

Erwartete Ergebnisse

  • Tests #2 und #3 sind wahr.

Wenn dies eine ausreichende Technik für ein Erfolgskriterium ist, dann bedeutet das Scheitern an diesem Testverfahren nicht zwangsläufig, dass das Erfolgskriterium nicht auf irgendeine andere Art und Weise erfüllt wurde, sondern nur, diese Technik nicht erfolgreich implementiert wurde und nicht benutzt werden kann, um die Konformität zu erklären.


SVR5: Angabe der voreingestellten Sprache im HTTP header

Anwendbarkeit

Server-seitige Techniken, einschließlich server-seitiger Scripting-Sprachen und Server-Konfigurationsdateien zur Festlegung von HTTP-Headern.

Die Technik bezieht sich auf:

Beschreibung

Das Ziel dieser Technik ist es, Informationen zu der oder den primären Sprache(n) einer Webseite bereitzustellen, um die Zielgruppe des Inhalts zu identifizieren. Der Content-Language HTTP-Header kann eine Liste mit einem oder mehreren Sprach-Codes enthalten, der für die Sprach-Verhandlung (language negotiation) zwischen einem Benutzeragenten und einem Server benutzt werden kann. Wenn die Sprach-Einstellungen in einem Benutzeragenten korrekt festgelegt werden, dann kann die „language negotiation“ dem Benutzer dabei helfen, eine Sprachversion des Inhalts zu finden, die seinen oder ihren Präferenzen entspricht.

Beachten Sie, dass der Content-Language HTTP-Header nicht dazu dient, die Sprache, die für die Verarbeitung des Inhalts benutzt wird, zu identifizieren. Die Sprache zur Verarbeitung des Inhalts kann durch andere Techniken identifiziert werden, wie zum Beispiel die Attribute lang und xml:lang in Auszeichnungssprachen.

Diese Technik stellt sicher, dass die primäre Sprache des Dokumentes, so wie diese zum Beispiel in den lang- oder xml:lang-Attributen spezifiziert ist, im Content-Language HTTP-Header aufgelistet wird.

Beispiele

Beispiel 1: Festlegung der Sprache des Inhalts in Java Servlet und JSP

Entwickler können in Java Servlet oder JavaServer Pages (JSP) response.setHeader("Content-Language", lang) benutzen, bei dem „lang“ für einen Sprach-Tag steht (zum Beispiel „en“ für englisch):

Code-Beispiel:

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

Beispiel 2: Festlegung der Sprache des Inhalts in PHP

In PHP können Entwickler einen raw HTTP header mit der header-Methode senden. Das folgende Beispiel setzt die Sprache auf französisch:

Code-Beispiel:

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

Ressourcen

Ressourcen sind nur zu Informationszwecken und keine offizielle Empfehlung.

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

Vorgehensweise

  1. Benutzen Sie einen Live HTTP Header-Viewer, um den Wert des „Content-Language“-Headers zu finden.

  2. Prüfen Sie, ob dieser Wert der Standard-Sprache der Webseite entspricht.

Erwartete Ergebnisse

  • Schritt 2 ist wahr.

Wenn dies eine ausreichende Technik für ein Erfolgskriterium ist, dann bedeutet das Scheitern an diesem Testverfahren nicht zwangsläufig, dass das Erfolgskriterium nicht auf irgendeine andere Art und Weise erfüllt wurde, sondern nur, diese Technik nicht erfolgreich implementiert wurde und nicht benutzt werden kann, um die Konformität zu erklären.