このウェブページは、「WCAG 2.0 達成方法集 : WCAG 2.0 の達成方法と失敗例」におけるサーバーサイドスクリプトの達成方法を掲載している。ウェブコンテンツ技術特有の達成方法は、「一般 (General)」の達成方法に取って代わるものではない。コンテンツ制作者は適合に向けて作業する際には、「一般 (General)」の達成方法とウェブコンテンツ技術特有の達成方法の双方を考慮に入れる必要がある。
ウェブコンテンツ技術特有の達成方法は、あらゆる状況で WCAG 2.0 の達成基準と適合要件を満たすコンテンツを作るために使うことができる技術を指しているわけではない。 コンテンツ制作者はその技術の限界に注意を払い、障害のある人にアクセシブルな方法でコンテンツを提供す必要がある。
達成方法についての情報は、WCAG 2.0 達成方法集のイントロダクションを参照のこと。他のウェブコンテンツ技術の達成方法一覧については、目次を参照のこと。
サーバーサイドスクリプト言語、及びリダイレクトための URL 又は URL パターンのあるサーバー環境設定ファイルを含む、サーバーサイドのウェブコンテンツ技術
これは、次の達成基準に関連する達成方法である:
この達成方法の目的は、あるページ (利用者によって要求されたページ) が別のページにリダイレクトされたために、二つの新しいページが間断なく読みこまれることによって引き起こされる混乱を回避することである。いくつかのユーザエージェントは、利用者を指定された秒数の後に別のページにリダイレクトする HTML の meta 要素の使用をサポートしている。これは、一部の利用者、特にスクリーンリーダーを使用している利用者にとって、ページをアクセシブルではないものにしている。サーバーサイドのウェブコンテンツ技術は、利用者を混乱させないリダイレクトを実装する方法を提供している。サーバーサイドスクリプト又はサーバー環境設定ファイルで、3xx 番台のステータスコード、及び転送先の URL の Location ヘッダーを持つ適切な HTTP レスポンスをサーバーが送るようにできる。ブラウザがこのレスポンスを受けると、ロケーションバーが変わり、ブラウザは新しい URL のリクエストをする。
Java サーブレット又は JavaServer Pages (JSP) では、開発者は HttpServletResponse.sendRedirect(String url) を使用できる。
コード例:
…
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
…
response.sendRedirect("/newUserLogin.do");
}このコードは、302 ステータスコード (「Found」) 及び新しい URL の Location ヘッダーを含むレスポンスをユーザエージェントに送る。また、response.sendError(int code, String message) で、ステータスコードとしてインタフェース javax.servlet.http.HttpServletResponse で定義されている定数の一つを用いて、別のステータスコードに設定することも可能である。
コード例:
…
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
…
response.sendError(response.SC_MOVED_PERMANENTLY, "/newUserLogin.do");
}アプリケーションがセッションに依存するために、アプリケーションが URL のリライトに HttpServletResponse.encodeURL(String url) を使用するなら、メソッド HttpServletResponse.encodeRedirectURL(String url) が HttpServletResponse.sendRedirect(String url) の代わりに使用されるべきである。また、HttpServletResponse.encodeURL(String url) で URL をリライトして、それから HttpServletResponse.sendRedirect(String url) にこの URL を渡すことも可能である。
VBScript で書かれた Active Server Page (ASP) では、開発者は Response.Redirect を使用できる。
コード例:
Response.Redirect "newUserLogin.asp"又は
コード例:
Response.Redirect("newUserLogin.asp")以下のコードは、特定の HTTP ステータスコードを含む、より完全な例である。
コード例:
Response.Clear
Response.Status = 301
Response.AddHeader "Location", "newUserLogin.asp"
Response.Flush
Response.EndPHP では、開発者は header メソッドで生の HTTP ヘッダーを送ることができる。以下のコードは、301 ステータスコードと新しい場所を送る。ステータスが明示的に設定されないなら、リダイレクトのレスポンスは HTTP ステータスコード 302 を送る。
コード例:
<?php
header("HTTP/1.1 301 Moved Permanently");
header("Location: http://www.example.com/newUserLogin.php");
?>以下の例のようにして、開発者は Apache ウェブサーバーがリダイレクトを処理するように構成できる。
コード例:
redirect 301 /oldUserLogin.jsp http://www.example.com/newUserLogin.doこの参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。
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.
(今のところ、なし。)
別のウェブページ又はウェブページへのリンク又はプログラムによる参照を見つける。
評価されているウェブページ一式における URI への各リンク又はプログラムによる参照において、参照されたウェブページがクライアントサイドリダイレクトを引き起こすコード (例えば、meta 要素又はスクリプト) を含むかどうかを確認する。
評価されているウェブページ一式における URI への各リンク又はプログラムによる参照において、参照された URI がリダイレクトを引き起こさない、又は、タイムアウトなしのサーバーサイドリダイレクトをするかどうかを確認する。
2. の結果が偽であり、かつ 3. の結果が真である。
この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。
.htaccess をサポートしているウェブサーバー (一般的には Apache) 内にあるコンテンツで、コンテンツの適合版が不適合版の代替として提供されているもの
これは、次の達成基準に関連する達成方法である:
この達成方法の目的は、コンテンツの不適合なバージョンも利用可能な場合に、利用者が常にアクセシブルなバージョンにアクセスできることを保証することである。WCAG に適合していないフォーマットでコンテンツが提供される際でも、アクセシブルではないコンテンツの代替版が提供されていれば、そのサイト全体が適合していることになる。適合要件 4 は代替版が不適合なコンテンツ又はその URI からたどることができることを要求している。
不適合のコンテンツの中からアクセシブルなリンクを提供することは常に可能ではないため、この達成方法では制作者が不適合のコンテンツにその代替版として提供される URI、又は不適合のバージョンと代替版双方へのリンクを含むページからしかアクセスできないようにするために Apache のモジュール「mod_access」を使う方法について説明する。
次の .htaccess ファイルは、「accessible.html」からのリクエストではない限り、「inaccessible.html」から「accessible.html」へのリダイレクトを要求する Apache の mod_redirect モジュールを使用している。
コード例:
# アクセシブルではないコンテンツへのリクエストがaccessible.html
# という名前のファイルから来た場合、アクセシブルではないバージョン
# の表示を許可する環境変数をセットする。
SetEnvIf Referer .*(accessible.html)$ let_me_in
<FilesMatch ^(inaccessible.html)$>
Order Deny,Allow
Deny from all
Allow from env=let_me_in
</FilesMatch>
# リクエストがaccessible.html以外から来た場合、
# エラーとしてアクセシブルなバージョンがある場所へと
# リダイレクトする。
ErrorDocument 403 /example_directory/accessible.htmlこの例では、ドキュメントが複数のフォーマットで利用可能なディレクトリ構造を前提とする。そのフォーマットのうちのひとつは WCAG に宣言しているレベルで適合しておらず、「jna (全くアクセシブルではない: Just Not Accessible)」というファイル拡張子を使用している。これらのファイルは、.htaccess ファイルとともに全て「jna」というフォルダに保存されている。この .htaccess ファイルは、アクセシブルではないバージョンが存在しないページから、.jna の拡張子を持つファイルへの直接リクエストを、全ての利用可能なフォーマットが記載されているインデックスページへとリダイレクトするのを保証している。
コード例:
# アクセシブルではないコンテンツへのリクエストが
# http://example.com/documents/index.htmlにあるファイルから来た場合、
# アクセシブルではないバージョンの表示を許可する環境変数をセットする。
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>
# リクエストがhttp://example.com/documents/index.html以外から来た場合、
# エラーとしてアクセシブルなバージョンがある場所へと
# リダイレクトする。
ErrorDocument 403 http://example.com/documents/index.htmlこの参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。
.htaccess ファイルの使用に基づいてアクセシブルな代替が提供されるところで、宣言している適合レベルで WCAG に適合していないページを特定する。
不適合のコンテンツの URI を開く。
結果となるページが次のうちのいずれかであることを確認する:
不適合のコンテンツの適合している代替版
適合している代替版と不適合のコンテンツの両方へのリンクを含むページ
3.a. 又は 3.b. の結果が真である。
この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。
サーバーサイドのスクリプトを用いて生成されたコンテンツで、コンテンツの適合したバージョンが HTTP リファラによって不適合バージョンの代替として提供されているもの
これは、次の達成基準に関連する達成方法である:
SVR3 に関するユーザエージェントサポートノートを参照のこと。
この達成方法の目的は、不適合及び適合したバージョンが両方提供されているときに、利用者がコンテンツのアクセシブルなバージョンを取得できることを保証することである。
適合要件 1 は、「適合している代替版」がある限り、不適合なページが適合の範囲内に含まれることを認めている。コンテンツ制作者にとって、不適合なコンテンツの中から適合しているコンテンツへのアクセシビリティ サポーテッドなリンクを含むことは常に可能とはいえない。そこで、不適合のバージョンへは適合しているページからしか到達できないようにするために、コンテンツ制作者はサーバーサイドのスクリプト技術 (例：PHP、ASP、JSP) に依存しなければならなくなる。
この達成方法は、不適合のコンテンツへは、適合しているページからしか到達できないことを保証するための、HTTP referer により提供される情報の利用方法について説明する。HTTP referer ヘッダーはユーザエージェントによって設定され、(もしあれば) ユーザエージェントが不適合なページを参照する際のページの URI を含む。
この方法を実装するために、コンテンツ制作者は不適合なページそれぞれについて、コンテンツの適合しているバージョンの URI を特定する。ページの不適合なバージョンへのリクエストを受け取った際に、サーバーは HTTP referer ヘッダーの値と、適合しているバージョンの URI を比較して、不適合バージョンへのリンクが適合しているバージョンからのものであるかどうかを判断する。不適合バージョンは HTTP referer が不適合バージョンの URI と一致したときにだけ提供される。それ以外の時には、利用者はコンテンツの適合したバージョンへとリダイレクトされる。HTTP リファラヘッダー内の URI を比較する際に、URI 中にクエリーや target のような関連のない変化も考慮に入れる必要があることに注意すべきである。
オンラインの物理の授業では、インタラクティブな物理プロセスのデモを提供するために専用のモデリング言語を使用する。そのモデリング言語のためのユーザエージェントは支援技術との互換性がない。そのサイトは利用者が適合するプロセスとモデルの説明を含むページからインタラクティブなデモにアクセスしようとしない限り、サーバーがそのリクエストを不適合バージョンへのリンクを含む、適合しているページへとリダイレクトする、HTTP リファラを使用するスクリプトを含んでいる。生徒は不適合のインタラクティブなバージョンへのアクセスを選択する事ができるが、そうしない生徒もプロセスについて学ぶことができる。
次の例は、この達成方法が PHP でどのように使われるかを説明している。conforming.php と non-conforming.php という不適合なコンテンツへのアクセスが適合しているコンテンツからのみとなるようにするために連携する二つのファイルを含む。
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>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:
コード例:
<?php
// リクエストが「conforming.php」という文字列を含むファイルから来た場合、ページをレンダリングする。
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=utf-8" />
<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
}
// 参照するページがconforming.phpではない場合、利用者を適合しているバージョンにリダイレクトする。
else {
header("Location: conforming.php");
}
?>実装例として Conforming content が利用できる。
不適合コンテンツに対して、WCAG に適合している代替版が提供されている場合:
HTTP リファラに基づいてアクセシブルな代替版が提供されている場合、宣言している適合レベルで WCAG に適合していないページを特定する。
不適合のコンテンツの URI を開く。
開いたページが次のうちの一つである:
不適合のコンテンツの適合している代替版
適合している代替版と不適合のコンテンツの両方へのリンクを含むページ
3.a. 又は 3.b. の結果が真である。
この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。
設定を保存するためにサーバーサイドのスクリプトを用いて生成されたコンテンツ
これは、次の達成基準に関連する達成方法である:
この達成方法の目的は、ウェブページの適合している代替版の設定を利用者が選択できるメカニズムを提供することである。
利用者が適合している代替版を見ることができるような設定を提供するにはいくつかの方法が可能である。一般的な方法としては、ウェブサーバーがページを修正する、又は利用者を代替版にリダイレクトするのに使うセッション又は永続的なクッキーを設定するサーバーサイドのプロセスのトリガーとなるリンクを提供する方法がある。他の方法には、利用者がウェブページ又はサービスにアクセスする際にサインインするシステムへのログイン情報の一部として利用者ごとの選択肢を提供する方法がある。
不適合なページで提供されるメカニズムは、代替版を必要とする利用者が、それを探して利用するためにアクセシブルである必要がある。そのメカニズム自体は宣言しているアクセシビリティレベルに適合しているべきである。
あるウェブサイトは、サイト内のページには「設定」ページへのリンクを提供している。このページには、サイトの代替版を見るためのオプションがある。好みによってページのさまざまな見方があるかもしれないし、利用者はサイトの完全な代替版を見たいかもしれない。その設定はサイト上で動画が含まれる部分ではキャプションを表示するものかもしれない。また、主となるサイトが、代替版からしかわからないアクセシビリティ適合についての問題を含んでいるために提供されているのかもしれない。
あるウェブページの制作者はクッキーを使って設定を扱うことがある。それは、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>
<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>フォームは処理のためにpref.phpのファイルへと送信される。クッキーが設定され、この単純な例では、利用者のブラウザはサイトのトップページへと移動する。
pref.php:
コード例:
<?php
if(isset($site_pref)) {
setcookie("site_pref",$site_pref, time() + (86400 * 30)); //30日に設定
header("location: http://www.example.com"); //トップページへとリダイレクト
}
?>トップページは利用者の設定を実装するコードから始まる。
index.php:
コード例:
<?
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>
...ログインを必要とするシステムでは、設定は利用者のデータベース記録に保存され、利用者が見るページを生成するサーバーサイドのスクリプトによって参照される。
この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。
そのサイトのページの表示方法についての設定を変更する。
各不適合なページから、設定そのもの、又は設定できるページへのリンクにアクセスできることを確認する。
ウェブページが選択した設定に応じて表示されることを確認する。
設定が行われた時に、ウェブページが宣言通りに適合していることを確認する。
結果となるページが元のページの適合している代替版となっていることを確認する。
2. 及び 3. の結果が真である。
この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。
サーバーサイド技術 (HTTP ヘッダーを設定するサーバーサイドのスクリプト言語及びサーバー設定ファイルを含む)
これは、次の達成基準に関連する達成方法である:
この達成方法の目的は、コンテンツの対象者を特定するために、ウェブページの主たる自然言語に関する情報を提供することである。HTTP Content-Language ヘッダーには、一つ以上の言語コードのリストを含めることが可能で、ユーザエージェントとサーバーとの間での言語ネゴシエーションに用いられる。ユーザエージェントで言語設定が正しく設定されていれば、言語ネゴシエーションによって利用者は自分が設定した自然言語に合うコンテンツを見つけることができる。
ただし、HTTP Content-Language ヘッダーは、コンテンツを処理するのに用いられる自然言語を特定するためのものではないことに注意しなければならない。コンテンツを処理する自然言語は、マークアップ言語の lang 属性や xml:lang 属性などによって特定することができる。
この達成方法は、lang 属性または xml:lang 属性の例で明記されているように、文書の主たる自然言語を HTTP Content-Language ヘッダーで挙げるようにするものである。
訳注: 言語ネゴシエーション (language negotiation) というのは、Accept-Language によるコンテントネゴシエーションのことを指していると思われるが、このときネゴシエーションに使われるのは "Content-Language" ではなく、クライアントが送る "Accept-Language" の値であると考えられる。
Java サーブレット又は JavaServer Pages (JSP) では、開発者は response.setHeader("Content-Language", lang)を用いることが可能で、"lang" は言語タグを表す (例えば、英語なら "en"):
コード例:
…
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException
{
…
response.setHeader("Content-Language", "en");
PrintWriter out = response.getWriter();
…
}PHP では、開発者は header メソッドで生の HTTP ヘッダーを送ることができる。次の例では、自然言語をフランス語に設定している:
コード例:
<?php header('Content-language: fr'); … ?> この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。
W3C Internationalization FAQ: HTTP and meta for language information
Declaring metadata about the language(s) of the intended audience in Authoring HTML: Language declarations - W3C Working Group Note 3 June 2014.
RFC 7321 3.1.3.2. Content-Language
header in the PHP Manual.
Live HTTP Header ビューアを用いて、"Content-Language" ヘッダーの値を調べる。
訳注: 「Live HTTP Header」が正確に何を指すのか不明であるが、代わりに各種ブラウザの開発ツールで確かめることができる。リソース読み込み時間の測定 | Tools for Web Developers | Google Developers、ネットワークモニター - 開発ツール | MDN、Microsoft Edge DevTools - Network - Microsoft Edge Development | Microsoft Docs がそれぞれ参考になる。
その値がウェブページの主たる自然言語と一致していることを確認する。
2. の結果が真である。
この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。