WCAG 2.0 達成方法集

Skip to Content (Press Enter)

サーバサイド・スクリプトの達成方法

このウェブページは、「WCAG 2.0達成方法集 : WCAG 2.0の達成方法と失敗例」におけるサーバサイド・スクリプトの達成方法を掲載している。ウェブコンテンツ技術特有の達成方法は、「一般(General)」の達成方法に取って代わるものではない。コンテンツ制作者は適合に向けて作業する際には、「一般(General)」の達成方法とウェブコンテンツ技術特有の達成方法の双方を考慮に入れる必要がある。

ウェブコンテンツ技術特有の達成方法は、あらゆる状況で WCAG 2.0 の達成基準と適合要件を満たすコンテンツを作るために使うことができる技術を指しているわけではない。 コンテンツ制作者はその技術の限界に注意を払い、障害のある人にアクセシブルな方法でコンテンツを提供す必要がある。

達成方法についての情報は、WCAG 2.0 達成方法集のイントロダクションを参照のこと。他のウェブコンテンツ技術の達成方法一覧については、目次を参照のこと。




SVR1: クライアントサイドではなく、サーバサイドで自動リダイレクトを実装する

適用(対象)

サーバーサイド・スクリプト言語、及びリダイレクトためのURL又はURLパターンのあるサーバ環境設定ファイルを含む、サーバーサイドのウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、あるページ(利用者によって要求されたページ)が別のページにリダイレクトされたために、2つの新しいページが間断なく読みこまれることによって引き起こされる混乱を回避することである。いくつかのユーザエージェントは、利用者を指定された秒数の後に別のページにリダイレクトするHTMLのmeta要素の使用をサポートしている。これは、一部の利用者、特にスクリーンリーダーを使用している利用者にとって、ページをアクセシブルではないものにしている。サーバーサイドのウェブコンテンツ技術は、利用者を混乱させないリダイレクトを実装する方法を提供している。サーバーサイド・スクリプト又はサーバ環境設定ファイルで、3xx番台のステータスコード、及び転送先のURLのLocationヘッダーを持つ適切な HTTPレスポンスをサーバが送るようにできる。ブラウザがこのレスポンスを受けると、ロケーションバーが変わり、ブラウザは新しいURLのリクエストをする。

事例

事例 1: JSP/サーブレット

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を渡すことも可能である。

事例 2: ASP

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

事例 3: PHP

PHPでは、開発者は header メソッドで生のHTTPヘッダーを送ることができる。以下のコードは、301ステータスコードと新しい場所を送る。ステータスが明示的に設定されないなら、リダイレクトのレスポンスはHTTPステータスコード302を送る。

コード例:


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

事例 4: Apache

以下の例のようにして、開発者は Apache ウェブサーバがリダイレクトを処理するように構成できる。

コード例:

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

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

(今のところ、なし。)

検証

チェックポイント

  1. 別のウェブページへのリンク又はプログラムによる参照を見つける。

  2. ウェブページ一式におけるURIのリンク又はプログラムによる参照において、参照されたウェブページがクライアントサイド・リダイレクトを引き起こすコード(例えば、meta要素又はスクリプト)を含んでいない。

  3. ウェブページ一式におけるURIのリンクやプログラムによる参照において、参照されたURIがリダイレクトしない、又は、一時停止なしのサーバーサイド・リダイレクトをしない。

判定基準

  • 2. 及び 3. を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


SVR2: 適合しているコンテンツからしか適合していないコンテンツにアクセスできないように、.htaccess を使用する

適用(対象)

.htaccessをサポートしているウェブサーバー(一般的にはApache)内にあるコンテンツで、コンテンツの適合版が不適合版の代替として提供されているもの

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、コンテンツの不適合なバージョンも利用可能な場合に、利用者が常にアクセシブルなバージョンにアクセスできることを保証することである。WCAGに適合していないフォーマットでコンテンツが提供される際でも、アクセシブルではないコンテンツの代替版が提供されていれば、そのサイト全体が適合していることになる。適合要件 4は代替版が不適合なコンテンツ又はそのURIからたどることができることを要求している。

不適合のコンテンツの中からアクセシブルなリンクを提供することは常に可能ではないため、この達成方法では制作者が不適合のコンテンツにその代替版として提供されるURI、又は不適合のバージョンと代替版双方へのリンクを含むページからしかアクセスできないようにするためにApacheのモジュール「mod_access」を使う方法について説明する。

事例

事例 1

次の.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

事例 2

この例では、ドキュメントが複数のフォーマットで利用可能なディレクトリ構造を前提とする。そのフォーマットのうちのひとつはWCAGに宣言しているレベルで適合しておらず、「jna(全くアクセシブルではない:Just Not Accessible)」というファイル拡張子を使用している。これらのファイルは、.htaccessファイルとともに全て「jna」というフォルダに保存されている。この.htaccess ファイルは、アクセシブルではないバージョンが存在しないページから、.jnaの拡張子を持つファイルへの直接リクエストを、全ての利用可能なフォーマットが記載されているインデックスページへとリダイレクトするのを保証している。/p>

コード例:


# アクセシブルではないコンテンツへのリクエストが
# 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

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

検証

チェックポイント

  1. 宣言している適合レベルでWCAGに適合していないページで、.htaccessファイルの使用によってアクセシブルな代替版が提供されているものを特定する。

  2. 不適合のコンテンツのURIを開く。

  3. 結果となるページが次のうちのひとつである:

    1. 不適合のコンテンツの適合している代替版

    2. 適合している代替版と不適合のコンテンツ双方へのリンクを含むページ

判定基準

  • 3.a.又は3.b.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


SVR3: 適合しているコンテンツからしか適合していないコンテンツにアクセスできないように、HTTP リファラを使用する

適用(対象)

サーバサイドのスクリプトを用いて生成されたコンテンツで、コンテンツの適合したバージョンが HTTP リファラによって不適合バージョンの代替として提供されているもの

これは、次の達成基準に関連する達成方法である:

ユーザエージェント及び支援技術によるサポート

SVR3 に関するユーザエージェントサポートノート (英語)を参照のこと。

解説

この達成方法の目的は、不適合及び適合したバージョンが両方提供されているときに、利用者がコンテンツのアクセシブルなバージョンを取得できることを保証することである。

適合要件 1は、「適合している代替版」がある限り、不適合なページが適合の範囲内に含まれることを認めている。コンテンツ制作者にとって、不適合なコンテンツの中から適合しているコンテンツへのアクセシビリティ・サポーテッドなリンクを含むことは常に可能とはいえない。そこで、不適合のバージョンへは適合しているページからしか到達できないようにするために、コンテンツ制作者はサーバサイドのスクリプト技術(例:PHP、ASP、JSP)に依存しなければならなくなる。

この達成方法は、不適合のコンテンツへは、適合しているページからしか到達できないことを保証するための、HTTP referer により提供される情報の利用方法について説明する。HTTP referer ヘッダはユーザエージェントによって設定され、(もしあれば)ユーザエージェントが不適合なページを参照する際のページの URI を含む。

この方法を実装するために、コンテンツ制作者は不適合なページそれぞれについて、コンテンツの適合しているバージョンの URI を特定する。ページの不適合なバージョンへのリクエストを受け取った際に、サーバは HTTP referer ヘッダの値と、適合しているバージョンの URI を比較して、不適合バージョンへのリンクが適合しているバージョンからのものであるかどうかを判断する。不適合バージョンは HTTP referer が不適合バージョンの URI と一致したときにだけ提供される。それ以外の時には、利用者はコンテンツの適合したバージョンへとリダイレクトされる。HTTP リファラヘッダ内の URI を比較する際に、URI 中にクエリーや target のような関連のない変化も考慮に入れる必要があることに注意すべきである。

事例

事例 1: インタラクティブな物理プロセスのデモ

オンラインの物理の授業では、インタラクティブな物理プロセスのデモを提供するために専用のモデリング言語を使用する。そのモデリング言語のためのユーザエージェントは支援技術との互換性がない。そのサイトは利用者が適合するプロセスとモデルの説明を含むページからインタラクティブなデモにアクセスしようとしない限り、サーバがそのリクエストを不適合バージョンへのリンクを含む、適合しているページへとリダイレクトする、HTTP リファラを使用するスクリプトを含んでいる。生徒は不適合のインタラクティブなバージョンへのアクセスを選択する事ができるが、そうしない生徒もプロセスについて学ぶことができる。

事例 2: PHP で Http リファラを使う

次の例は、この達成方法が PHP でどのように使われるかを説明している。conforming.php と non-conforming.php という不適合なコンテンツへのアクセスが適合しているコンテンツからのみとなるようにするために連携する 2 つのファイルを含む。

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>適合しているコンテンツ</title>
    	</head>
	<body>
		<h1>これは適合しているページです。</h1>
		<p>ここから、<a href="non-conforming.php">不適合なページ</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>不適合コンテンツ</title>
	</head>
	<body>
		<h1>これは不適合なページです。</h1>
		<p> <?php echo $_SERVER['HTTP_REFERER']; ?>から来たので、このページにあるコンテンツを見ることができます。
	</body>
</html>
<?php
}
// 参照するページがconforming.phpではない場合、利用者を適合しているバージョンにリダイレクトする。
else  {
header("Location: conforming.php");
}
?>

実装例として Conforming content が利用できる。

検証

チェックポイント

不適合コンテンツに対して、WCAG に適合している代替版が提供されている場合:

  1. 宣言している適合レベルで WCAG に適合していないページで、HTTP リファラの使用によってアクセシブルな代替版が提供されているものを特定する。

  2. 不適合のコンテンツの URI を開く。

  3. 開いたページが次のうちの一つである:

    1. 不適合のコンテンツの適合している代替版

    2. 適合している代替版と不適合のコンテンツ双方へのリンクを含むページ

判定基準

  • 3.a. 又は 3.b. を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


SVR4: 適合している代替版の表示に関する設定を利用者が行えるようにする

適用(対象)

設定を保存するためにサーバサイドのスクリプトを用いて生成されたコンテンツ

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、ウェブページの適合している代替版の設定を利用者が選択できるメカニズムを提供することである。

利用者が適合している代替版を見ることができるような設定を提供するにはいくつかの方法が可能である。一般的な方法としては、ウェブサーバがページを修正する、又は利用者を代替版にリダイレクトするのに使うセッション又は永続的なクッキーを設定するサーバサイドのプロセスのトリガーとなるリンクを提供する方法がある。他の方法には、利用者がウェブページ又はサービスにアクセスする際にサインインするシステムへのログイン情報の一部として利用者ごとの選択肢を提供する方法がある。

不適合なページで提供されるメカニズムは、代替版を必要とする利用者が、それを探して利用するためにアクセシブルである必要がある。そのメカニズム自体は宣言しているアクセシビリティレベルに適合しているべきである。

事例

事例 1: 事例1:利用者設定を保存するためにセッション又は永続的なクッキーを設定する

あるウェブサイトは、サイト内のページには「設定」ページへのリンクを提供している。このページには、サイトの代替版を見るためのオプションがある。好みによってページのさまざまな見方があるかもしれないし、利用者はサイトの完全な代替版を見たいかもしれない。その設定はサイト上で動画が含まれる部分ではキャプションを表示するものかもしれない。また、主となるサイトが、代替版からしかわからないアクセシビリティ適合についての問題を含んでいるために提供されているのかもしれない。

あるウェブページの制作者はクッキーを使って設定を扱うことがある。それは、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>サイト設定</title>
  </head>
  <body>
      <h1>サイト設定</h1>
      <form id="form1" name="site_prefs" method="post" action="pref.php">
          <fieldset>
              <legend>どのバージョンのサイトを見たいですか?</legend>
              <input type="radio" name="site_pref" id="site_pref_reg" value="reg" />
              <label for="site_pref_reg">サイトの主バージョン</label>
              <input type="radio" name="site_pref" id="site_pref_axx" value="axx" />
              <label for="site_pref_axx">アクセシビリティ適合バージョン</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>
...

ログインを必要とするシステムでは、設定は利用者のデータベース記録に保存され、利用者が見るページを生成するサーバサイドのスクリプトによって参照される。

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

検証

チェックポイント

  1. そのサイトのページの表示方法についての設定を変更する。

  2. 設定そのもの、又は設定できるページへのリンクが不適合なページそれぞれから到達できる。

  3. ウェブページが選択した設定に応じて表示される。

  4. 設定が行われた際に、ウェブページが宣言通りに適合している。

  5. 結果となるページが元のページの適合している代替版となっている。

判定基準

  • 2.及び3.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


SVR5: HTTP ヘッダーで主たる自然言語を指定する

適用(対象)

サーバサイド技術(HTTPヘッダーを設定するサーバサイドのスクリプト言語及びサーバ設定ファイルを含む)

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、コンテンツの対象者を特定するために、ウェブページの主たる自然言語に関する情報を提供することである。HTTP Content-Language ヘッダーには、一つ以上の言語コードのリストを含めることが可能で、ユーザエージェントとサーバとの間での言語ネゴシエーションに用いられる。ユーザエージェントで言語設定が正しく設定されていれば、言語ネゴシエーションによって利用者は自分が設定した自然言語に合うコンテンツを見つけることができる。

ただし、HTTP Content-Language ヘッダーは、コンテンツを処理するのに用いられる自然言語を特定するためのものではないことに注意しなければならない。コンテンツを処理する自然言語は、マークアップ言語の lang 属性や xml:lang 属性などによって特定することができる。

この達成方法は、lang 属性または xml:lang 属性の例で明記されているように、文書の主たる自然言語をHTTP Content-Language ヘッダーで挙げるようにするものである。

訳注:【WCAGワーキンググループに確認中】言語ネゴシエーション (language negotiation) というのは、Accept-Languageによるコンテント・ネゴシエーションのことを指していると思われますが、このときネゴシエーションに使われるのは "Content-Language" ではなく、クライアントが送る "Accept-Language" の値です。現在、原文の記述に誤りがないかどうかを確認中です。

事例

事例 1: Javaサーブレット及び JSP によるコンテンツの自然言語設定

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();
…
}

事例 2: PHP によるコンテンツの自然言語設定

PHP では、開発者は header メソッドで生の HTTP ヘッダーを送ることができる。次の例では、自然言語をフランス語に設定している:

コード例:


&lt;?php  header('Content-language: fr');  …  ?&gt;

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

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.

検証

チェックポイント

  1. Live HTTP Header ビューアを用いて、"Content-Language" ヘッダーの値を確認する。

  2. その値がウェブページの主たる自然言語と合致している。

判定基準

  • 2. を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。