「アクセシビリティ」記事の一覧
以前tc-streetにポストした話題なのですが、（閲覧者に見てもらい、何らかの情報を伝えるという）プレゼンテーションを目的とするHTML文書と、音声読み上げなどUA（User Agent）側で様々に利用できるデータというものは、目的からして根本的に違うということがまだ理解されていないと感じます。
HTML文書もUAにレンダリングさせるという意味では「データ」なのかもしれませんが、実際にはプレゼンテーションを主眼とした文書として作られていることの方が多いのが現実です。その意味で、アクセシビリティ対策の根本とは、HTML文書をデータとして作成することにあると言えます。ですが、その結果としてプレゼンテーションの効果に疑問が出てしまうようでは、文書作成本来の意味が失われる面も出てきてしまいます。最近はこの辺の問題も意識されるようになってきた気配もあり、少しホッとしていますが（関連記事）。
さて、RSSやRDFによる記事配信が近頃話題になっていますが、アクセシビリティ対策を行うにあたっては、このように大元の情報から二次的に生成されたデータを利用する方が実効性が高いのでは？と最近思うようになりました。つまり、プレゼンテーションのためのHTML文書とUA側で独自に利用するためのデータ（メタデータも含む）を分離した二本立ての運用を行い、通常のWebブラウザは前者、音声ブラウザなどのUAや各種アプリケーションは後者を利用するという方法です。
この辺の問題については、以前に
複数媒体への展開を前提として情報を組む場面も存在しますが、その場合はどちらでも破綻しないことを前提とした中途半端なものになるか、展開する媒体に合わせた多重構成を採用した同一ソース（データ）から別のアウトプットを行うしかありません。ユニバーサルな情報提供という観点では後者のアプローチが適切かと思いますが、これは現状のアクセシビリティ対策とは質的にまったく異なるものです。
と書いた通り、このような二本立て運用の方がアクセシビリティ確保には効果があると元々考えていましたが、この方法では二本立て運用によるコストの増加が問題となってしまいます。
しかし最近のCMS（Content Management System、コンテンツ管理システム）の流行・一般化を見るにつけ、CMSによって開発／運用上のコストを削減することで、二本立て運用も可能なのではないか？と感じるようになってきました。このあたりの感覚の変化は、実際にこの「情報大工のひとりごと」をMovableTypeベースに置き換えて運用してみた実感によるものもあります（例えばMovableTypeを使用している場合、作成者が特に意識しなくともRDFファイルが自動的に生成されます）。HTML文書とデータの二本立て運用に関しても、この程度の敷居の低さを実現できるのであれば、現場レベルでの運用も何とかなるのではないでしょうか。
もちろん音声その他を中心とするUAで利用するためにはどのようなデータを配信すべきかなど、今後検討していく必要のある問題は山のようにあるでしょう。ですが、現状のように単一のHTML文書を無理やりユニバーサルドキュメントとして利用することよりも、将来的に利用価値の高い大元の情報を資産として残し、そこから様々な文書やデータを生成する方が、情報資産からより多くの価値を産み出すことができるのではないでしょうか。
2003.10.20追記
例に出したRSS/RDFおよびMovableTypeが独り歩きしてしまい、かえってわかりにくい文章になってしまったようです（ご指摘感謝です ＞ securecatのMT）。ということで、誤解を避けるべく少し修正しました。
アクセシビリティに注目が集まっている関係か、音声による情報提供が研究されるケースが増えているようです。もちろん本体よりも大きく重いマニュアルをなんとかしたい携帯電話や、安全上の問題からユーザーが紙面や画面をじっくり読む訳に行かない車載情報システムなど、音声による情報提供に注目せざるを得ない製品が増えつつあることも理由の1つでしょう。
さて音声で情報提供を行う場合ですが、ワンソースマルチユースで対応する場合と、専用コンテンツを用意する場合の2つのアプローチが考えられます。つまり、紙や電子媒体用の通常の文字表現テキストをそのまま利用するのか、それとも音声による情報伝達に最適化したコンテンツを別途用意するのか、ということです。また、すべての情報を音声で提供するのか、それとも音声による情報提供はポイントを絞って必要最小限にとどめ、製品やサービス全体の情報を（紙の冊子やWebサイトなどで）別途提供するのかによっても、音声コンテンツに求められる性質が変わってきます。
ただはっきりしているのは、特に高機能製品の取扱情報を提供するケースにおいて、ワンソース運用では音声情報としてまともに機能させるのは難しいということです。これは何故かというと、（紙にしろ電子にしろ）視覚表現を前提として設計した情報をそのまま流用しても、音声ではうまく機能しないからです。「alt属性の記述など各種アクセシビリティ対策をすることで、音声環境でも同等の使い勝手を提供できる」というような極論を目にしますが、とんでもない話です（もちろん何もしないよりは全然良いのですけれども）。
例えば、操作情報の枠組みは、見出しと導入文、操作文＋結果文のセット、サブ情報（ご注意＋ヒント）といった要素で構成されます。紙媒体では導入文内の概念説明が過剰だと感じた時点ですぐに飛ばし読みができますが、音声を聞いている場合はどうでしょう？ 音声では聞き飛ばし（斜め読み）がしにくいので、情報を必要最小限に絞り込む必要が出てきます。操作説明文であれば、実際の操作説明の前には、見出し（タスクのゴール）と見出しだけで説明しきれないタスクの補足情報、操作前に把握する必要のある重要な制約情報程度に限定する必要があるでしょう。概念説明や補足説明などの既存のマニュアルで重宝される情報に関しては、操作説明が終了したあとに必要に応じて参照できれば十分です。完全な情報を提供する機会を別途用意するのであれば、なおさらですね。
音声による情報提供で一番重要なのは、現在再生されているコンテンツは自分が必要としている情報なのか？を極めて初期の段階で把握できるようにすることです。これは視覚による情報提供では斜め読みで見当がつく場合が多いのに対して、音声ではある程度の量を聞いてみないと見当がつかないためです。ある程度の量を聞く＝それだけ時間がかかる訳ですから、この部分をしっかり意識する必要があります。お客様窓口電話番号に採用されることが多くなった自動応答システムで、自分が必要な情報がどれなのかわからなくなって途方に暮れた経験はありませんか？（この話、たぶん何かの機会に続きます）
情報大工のひとりごと