水無月ばけらのえび日記

bakera.jp > 水無月ばけらのえび日記 > Content-Languageでコンテント・ネゴシエーションを行うことができるのか?

Content-Languageでコンテント・ネゴシエーションを行うことができるのか?

2012年4月17日(火曜日)

Content-Languageでコンテント・ネゴシエーションを行うことができるのか?

更新: 2012年6月3日14時25分頃

ウェブアクセシビリティ基盤委員会 (waic.jp)のサイトには、「WCAG 2.0 実装方法集 (waic.jp)」という文書があります。これはTechniques for WCAG 2.0 (www.w3.org)を和訳したものです。

WCAG2.0の本体には、達成するべき基準が書かれているのですが、内容は抽象的で、具体的な実装方法までは書かれていません。たとえば、「利用者に提示されるすべての非テキストコンテンツには,同等の目的を果たす代替テキストを提供しなければならない」と規定されていても、それを具体的にどのような実装にすれば良いのかまでは書かれていません。それでは分からないので、具体的な実装方法は別のドキュメントにまとめられています。それがTechniques for WCAG2.0です。

このように文書が分けられている理由はいくつかあります。WCAG2.0が特定の技術 (たとえばHTML) に依存しない、汎用的な基準を定めることを目指したという点もありますが、本体はW3C Recommendationなので、頻繁な更新ができないという事情もあります。Recommendationの更新には時間がかかるので、新しい技術の出現に対応することが難しいわけです。Techniquesの方はNoteになっていて、それなりの頻度で更新できるようになっています。

つまりどういうことかというと、Techniques for WCAG 2.0はそれなりの頻度で更新されるということです。現在のTechniquesは2012年1月版となっています。しかし、和訳の方は2008年12月版のままで、かなり古くなってしまっています。

というようなわけで、新たに追加された項目をチェックしていたのですが、実装方法にSVR5というものが増えています。

IDの「SVR」は "Server" の意味で、SVR5はサーバ側の実装例の5番目のものという意味です。SVR5では、HTTP応答ヘッダのContent-Languageで言語を指定するというテクニックが紹介されています。そこまではまあ良いのですが、読んでみると微妙な記述が……。

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.

以上、SVR5: Specifying the default language in the HTTP header (2012年1月3日版) より

"can be used for language negotiation between a user agent and a server" とあり、Content-Languageを言語によるコンテント・ネゴシエーションに使うことができると書いてあるように読めます。しかし、Content-Languageをコンテント・ネゴシエーションに使うというのは聞いたことがありません。

普通、ネゴシエーションに使われるのは、ユーザーエージェントのHTTP要求ヘッダに入っているAccept-Languageです。サーバは、ネゴシエーションにAccept-Languageが使われていることを明示するために、Vary: Accept-Languageをつけて応答することがありますが、Content-Languageは使われません。サーバは300 Multiple Choisesや406 Not Acceptableで応答することがあり、このときはユーザーエージェントの側に選択がゆだねられますが、ここでもContent-Languageがネゴシエーションに使われるわけではありません。

無理矢理考えると、サーバからマルチパートで複数の言語を含んだ応答をして、それぞれのパートにContent-Languageをつけておけば選択できるような気もしますが、それはネゴシエーションとは言わないと思います……。

というわけで、この記述は何かが間違っているのではないかという気がしていますが、あるいは私が知らないネゴシエーション方法があるのかもしれません。

ではContent-Languageは何の役に立つのかというと、HTMLの場合はhtml要素lang属性をつけてやれば良いので、Content-Languageの出番はあまりありません。しかし、HTTPで転送されるのはHTMLだけではありません。プレーンテキストやダウンロードデータなどの場合、データ自身に言語を指定する機能はありませんので、HTTP応答ヘッダでの指定が意味を持ちます。

RFC2616の14.12 Content-Language には以下のような記述があります。

The primary purpose of Content-Language is to allow a user to identify and differentiate entities according to the user's own preferred language.

以上、RFC2616 14.12 Content-Language より

ここでは、ユーザーが設定した優先言語と違うかどうか識別できると言っています。たとえば、ユーザーの優先言語と違っていたら「このコンテンツは英語ですが自動翻訳しますか?」というアラートを出すブラウザがあります。HTML以外のコンテンツであっても、Content-Languageの指定があれば、そういった挙動ができるようになるかもしれません。

※2012-06-03追記: 結局、訳注をつけて公開しました: 「SVR5: HTTPヘッダーで主たる自然言語を指定する (waic.jp)」。

関連する話題: Web / アクセシビリティ / HTTP

人気のページ

最近の日記

関わった本など

デザイニングWebアクセシビリティ - アクセシブルな設計やコンテンツ制作のアプローチコーディングWebアクセシビリティ - WAI-ARIAで実現するマルチデバイス環境のWebアプリケーション体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践ウェブの仕事力が上がる標準ガイドブック 5 WebプログラミングWeb Site Expert #13Dreamweaver プロフェッショナル・スタイル [CS3対応] (Style for professional)

その他サイト