CEATEC JAPAN 2010 ウェブアクセシビリティセミナー

【NT-14：Part2】
ウェブアクセシビリティ規格 JIS X 8341-3:2010 の詳細


／パート2、「ウェブアクセシビリティ規格 JIS X 8341-3:2010 の詳細」ということで、情報通信アクセス協議会、ウェブアクセシビリティ基盤委員会副委員長、株式会社インフォアクシア代表取締役社長、植木 真さまにご講演いただきます。よろしくお願いします。

植木／こんにちは。
多数お集まりいただき、ありがとうございます。
休憩時間中にスクリーンに映していたんですが、セッションのスライドは、さっきいじってしまったので、今夜中にサーバに上げます。
明日以降ダウンロードしてください。
URLはhttp://www.infoaxia.com/ceatec.zipです。
zipファイル形式でサーバに置きますので。


自己紹介です。梅垣さんと同じように基盤委員会の副委員長という立場、もう1つ、実装ワーキンググループ、テクニカルな問題を扱うWGの主査をしています。
普段はウェブアクセシビリティのコンサルタントとして、主に大手企業のクライアントさんのお手伝いをしています。
今日はこんな流れでお話しします。
イントロダクション、ワーキンググループの紹介をして、基本的なワークフロー、JISに対応しようと思った時、コンテンツ制作の現場でどう対応すればいいか、ワークフローを紹介します。
WAICのサイトに膨大なドキュメントが公開されていて、その見方を紹介しながら、ワークフローという形で各種ドキュメントを紹介します。
1時間という短い時間なので、最後に1つだけ達成基準の例を紹介して終わりたいと思います。

WAIC主催のセミナーを9月2日に東京女子大学で開催しましたが、そちらにも参加された方？
挙手をお願いします。
数名いらっしゃいますね。
顔見知りの方々ですが、その時とほぼ同じ内容です。
その方は、おさらいということで聞いてください。

私が主査のWGは、実装ワーキンググループという名前です。
何をやっているか。
WCAG 2.0のドキュメントが各種出ていますので、これらの日本語訳をしてそのメンテナンスをしている。
ドキュメント管理の仕事が1つです。
今日話しますが、2010年版JISで新しく取り入れた考え方として、アクセシビリティ・サポーテッドという聞き慣れない考え方がありますが、ブラウザと支援技術を使った検証作業をしています。
後は達成基準や個別の実装方法として、ドキュメントがたくさんありますが、グレーゾーンが少なからずあります。
「こういう場合はこういう解釈でいいだろうか」など、それらについては、随時、問題が上がってくれば議論して解決し統一見解を示しています。
参加の今年度メンバーはご覧のようなメンバーで、ミツエーリンクスさん、日立公共システムエンジニアリングさん、富士通ソフトウェアテクノロジーズさん、慶應義塾大学の中根さんは、ご自身も全盲でScreen Readerのユーザでもあり、かつアクセシビリティの専門家としてパイオニア的な方です。
ベンダー企業さんからはアドビシステムさんと、マイクロソフトさんに参加していただいています。
Flash、PDFとか、MicrosoftならブラウザのIE、機能は今度どうなるかなど、鍵を握っている企業の2社。
企業サイトの運営者、ウェブマスターを代表する形で、キヤノンマーケティングジャパンの増井さん、委員長でもある渡辺さんもメンバーです。

梅垣さんのセッションは、概論的な大枠の話でした。
私はここから、現場目線の話をしていこうと思います。
皆さんが普段どういう形でウェブコンテンツに関わっているか、これにはウェブサイトもあれば、イントラのサイトもあるし、ウェブアプリケーション、ウェブシステムなどもあると思います。
大きく2つにわけます。
そのオーナー、ウェブサイトならウェブマスターという立場、作ってもらう立場の人、マネジメントする立場か、或いはそういう人から仕事をもらって、コンテンツを作る、アプリケーションを開発する、制作開発のどちらかを教えて下さい。

ウェブマスターとか、コンテンツをマネジメントする立場の人？手を挙げて下さい。
半分弱ぐらいですね。
逆に制作者、開発者、作る人は？
やや多い。
6対4ぐらいで、作る方が多いようですね。

規格票ですが、JISはウェブ上で閲覧する、これはPDFファイルで閲覧するか、もしくは規格票を購入する形で内容を見ることができます。
購入の場合は、紙の冊子状態の規格票かPDFファイルのどちらかを選べます。
2010年版、改正されたJIS X 8341-3:2010を購入した人？
意外と少ないですね。
買ってはないけど、中身を見た人？
2割いるか、いないか。
全くみてませんという人？
半分くらいですね。分かりました。

スライドは規格票の何ページに関連するか、右下に小さく出てきます。
後日規格票とあわせて振り返っていただくと、より理解が深まります。

最初にウェブアクセシビリティの確保・向上に関する要件として、主に作る前、企画・設計段階の話です。
それに該当するのは、箇条6、6番目のセクションです。
ウェブアクセシビリティの確保・向上に関するもの。
何が書いてあるかというと、1番目としては、等級を決めましょうと。
どの等級で達成していくか。
A、AA、AAAとあります。
官公庁や自治体の案件であれば、AAを目指すのが妥当かと思います。
公共分野でない、民間企業さんに関してはまずはAをやってみることを私はお薦めします。
AAもどんな達成基準があるかを見てみて、もし可能であれば、対処できるようであれば、AAを目指してもいいと思います。
でも、AAは結構難しい達成基準、ちょっと工数がかかるような達成基準も含まれていますので、あまり無理をせず、まずはAからきちんと満たしていくことをお薦めしたいと思います。
それから、等級は3つありまして、AAAというのが一番高いレベルです。
当然、達成基準の数が一番多くて、より広い範囲のユーザをカバーすることができるのですが。
「うちのサイトはAAAで行くぞ」と、サイト全体の目標にすることは、推奨しません。
かなりというか、非現実的、或いは、現時点ではやりようがない達成基準も実際に含まれています。
最初は意気込んで、「やるんだったら一番上を目指す」とAAAでやられるケースもあるかもしれないんですが、基本的には推奨しません。
Aから確実にやっていくのが良いと思います。
それから、依存するウェブコンテンツ技術。
これも新しい考え方です。
説明が長くなってしまうところですが…。
JavaScript、2004年版のJISを解釈すると、JavaScriptを使って何かコンテンツを提供していたという場合、当然、JavaScriptをオフにしているユーザー、もしくはJavaScriptをサポートしていないブラウザとか、支援技術を使っているユーザのためにJavaScriptがオフでも同じ機能が使えるようにしましょうと。
つまり、代替コンテンツを提供しましょうというのが基本的な考え方としてありました。
今回の改正によって、JavaScriptオン、使える状態を前提にするかというのをコンテンツ側が決めることができるようになりました。
なので、依存するウェブコンテンツ技術は必ず試験結果を表示するときに出さなければいけないんですが、HTMLとCSSはどんなコンテンツをとっても、依存する技術として挙げると思うのですが、ここにJavaScriptも並べた場合、JavaScriptがオフの環境については考えなくていいと。
JavaScriptがオンであることを前提にして、すべての達成基準を満たしていれば、その等級を満たしているという考え方になります。
そう考えていくと、FlashやPDFはどうしようということになります。
現状、Flash、PDFに関してはそろそろAdobeさんからW3C経由で、実装方法のドキュメントが公開されることになります。
例えば、Flashですが、トップページに小さく埋め込んであって、しばらく見ているとアニメーションに切り替わって、2〜3つぐらいのバリエーションで目を引くような仕掛けがあったりしますが、あのFlashに関しては、依存するウェブコンテンツ技術という扱いにすれば、やはり同じようにFlashを使えないユーザのために、代替コンテンツを提供する、つまりHTML版を提供する必要がなくなります。
多くの場合、Flash、PDFに関しては、例えば、Flashですべての達成基準を満たせるかというと、厳しい場合も少なくありませんので、慎重に判断すべきです。
アクセシビリティ抜きにしても、検索ロボット、また、SEOという言葉もありますが、それに対してはあまりよくないという側面もあります。
ですから、アクセシビリティだけでなく、トータルで判断する必要があります。
JISに適合する上では、JavaScript、Flashも依存する技術としてあげるのであれば、「代替コンテンツを提供しなくてもよい」となります。
ですから同じAの等級を満たしていると宣言しているサイトであっても、あるサイトは、JavaScriptオンが前提かもしれないし、あるサイトはJavaScriptオフが前提になっているかもしれない。
同じ等級を満たしていても、使っている技術、前提となっている技術が変わるということがあり得ます。
これは機会があればまたゆっくり説明したいところです。

3番目に、実際に達成基準を満たすのにどういう実装方法、テクニックを使うかを選定していきます。これは、実際に日本語訳のドキュメントを見せながら説明します。
今回、達成基準はすべてWCAG 2.0と同じ達成基準を採用していますので、公開している解説書、実装方法集…技術書と言う人もいますが、WCAG 2.0が提供しているドキュメントを見ることでそのままJISでも使うことができるようになっています。
一番気になるコンテンツに対する要件ということで話していきます。
目次を見ますと、箇条6の次に、箇条7というのがあって、ここにウェブコンテンツに関する要件があります。
梅垣さんも紹介していた通り、2004年版では、どのページを見ても、しかも前半はカラーを使っていたりで、見た目も色鮮やか…とは言いませんが、スクリーンショットであったり、ソースコードのサンプルなどが入っていて、かなり具体的でわかりやすく書かれていました。

ところが、2010年版、改正された規格票は全くそういうものがありません。
基本的に要件だけ粛々と書き連ねられています。
基本的に技術に非依存。
それから、新しい技術にも対応していくというのは、梅垣さんもお話されていました。
どのテクノロジー、ウェブコンテンツ技術を使っていても当てはまるような達成基準の書き方になっています。
HTMLベースのウェブページにも当てはまるし、FlashやFlexなどのアプリケーションにも適応できる書き方になっています。
若干、読んでもわかりづらい達成基準、規格になっているかもしれません。
この辺は2004年版の時はかなり具体的に書きすぎてしまいました。
HTMLでは、当時はテーブルレイアウトが全盛の時代でしたが、CSSレイアウトにすぐに切り替わってしまって、テーブルレイアウトを前提にしていたような記述は、すぐに時代遅れになって、使えなくなってしまいました。
言うまでもないですが、ウェブの世界はすごいスピードで進化していきます。
また、JIS自体が5年ごとにしか見直しができないということで、2004年からの5年間でかなり変わってきていますから、この次の5年後、またどう変わるかは予測もつかないところがあります。
そこで、極力、具体的なことは書かないような規格になっています。
例えば、レイアウトテーブル。2004年版には5.4b）、表組み要素をレイアウトのために使わないことが望ましいとなっていました。
この要求事項が言いたかったのは、音声読み上げ順序をちゃんとしましょうと。
言い回しのせいだと思うのですが、レイアウトテーブルを使うこと自体がダメだとの誤解を与えてしまったという背景があります。
2010年版では、そのへんが配慮してあって、正確な読み上げ順序はプログラムが解釈可能でなくてはならない。
フォーカスの移動順序にも言及しています。
どちらもHTMLでもFlashでもPDFでも何を使っていても当てはまる達成基準の書きっぷりになっています。
これを読んだだけでは、分かるような分からないようなという、モヤモヤが残るかもしれません。

レイアウトテーブルのついでに話しますが、おそらく、もう使うことはないと思いますが、もしレイアウトテーブルを使う場合、W3Cの実装方法集の目次ですが、不適合事例が挙げられています。
レイアウトテーブルを使う場合、th要素、caption要素、空ではないsummary属性を用いてはいけません。summary属性には「レイアウトテーブルです」などというどうでもいいことが書かれている場合もあり、こういったものを使っちゃダメですよ、これを使っていると達成基準を満たしたことになりませんよと。
もしレイアウトテーブルを使う場合は、このへんも気をつけていただきたいと思います。
今日は、内容はあまり踏み込みません。

レイアウトテーブルに関しては、禁じてはいません。
使うこと自体に問題があるわけではないですが、W3CのWCAG 2.0でもCSSレイアウトを使うことを推奨しています。
達成基準が何を意図しているのか、何をしろと言ってるか、コンテンツをどうしろと言っているかを、しっかり理解して、どのテクノロジやテクニックを使うかを判断していただくことになります。

規格票を読んでも分からない、という話をしました。
じゃ、どうするか。
「注記」にW3Cが公開している、Understanding、Techniquesが参考になるとあります。
WCAGがどういう構成になっているか。
WCAG 2.0がJISで言うと規格票に該当します、要求事項が書かれているドキュメント、それを解説するUnderstandingと実装方法を解説するTechniquesとなっています。
WCAG 2.0には、ガイドラインと達成基準の必要最低限だけが書かれています。
各達成基準について詳細を解説しているのが、understandingです。
HTMLだったら、こういうテクニックを使えば達成基準を満たせますよという一覧があります。
一覧をクリックすると、1個1個のテクニック、それから不適合事例も含まれますが、そのドキュメントが出てきてかなり詳細なレベルまで。
ここまで来ると、ようやくサンプルのソースコードや、モノによっては、スクリーンショットが入っています。
実際のスクリプトを組み込んだサンプルへのリンクが張ってあったりもします。
ここでようやく具体的な情報が出てくるという、この3段階の構成になっています。
W3Cも同様にガイドライン自体の本文をそう簡単に変えられない。
実際に1.0から2.0になるまで10年近くかかっています。
勧告文書自体は、そうそういじれないので、それ以外の文書で補完していこうと。
日々変わっていく具体的なテクニックレベルの話は、周辺文書を用意してそちらで提供しようと。
UnderstandingとTechniqueは随時追加・更新できます。今、現にFlashのドキュメントが追加されようとしているし、PDFやSilverlightについてもAdobeとMicrosoftがそれぞれ作成中ということです。
今後、順次追加されます。
2010年版JISは、WCAG 2.0と同じ達成基準を採用しています。
UnderstandingとTechniquesを日本語に訳すと、そのままJISの解説書として使えます。
WAICでは、この2つのドキュメントの飜訳をやっています。

具体的に1つずつの文書を見ていきます。
達成基準の7.2.4.1、ブロックスキップに関する達成基準。複数のウェブページ上で繰り返されているコンテンツのブロックをスキップできるメカニズムを利用可能でなければならない。
2004年版の対応をしてきた人は、「あ、似たようなものがあったな」と、思い浮かぶと思います。
スキップリンクを提供しようというのが、2004年版だと5.3 h)にあります。共通に使われるナビゲーションなどのハイパーリンク及びメニューは、
読み飛ばせるようにするのが望ましいとあります。
注意していただきたいのは、よく読むと、要求されている内容が変わっています。
2004年版では「読み飛ばせるようにするのが望ましい」と。
それが2010年版では、「通過できるメカニズムが利用可能でなければならない」
「読み飛ばせる」と「通過できる」は似たような気もしますが、ちょっと違います。実は大きく変わります。
このへんを解説書、Understandingを見ながら日本語で読み解きます。
WCAG2.0の解説書の2.4.1のページを見ます。
達成基準の番号ですが、WCAG 2.0は3桁です。
頭に7を付けると2010年版になります。
7.2.4.1がブロックスキップの達成基準です。
7を取ると、WCAG2.0の同じ達成基準の番号となります。
実際のページは後ほど。
達成基準の意図というのがあり、ここにコンテンツ内を1つずつ順を追って行き来している利用者がウェブページのメインコンテンツへ直接移動できること。
つまり、Screen Readerの読み上げを聞いているユーザだけじゃない、というのがなんとなくここで見えてきます。
確信は持てないかも知れませんが。
さらに、具体的メリットということで、キーボードまたはキーボードインタフェースだけを利用者がより少ないキーストロークだけでコンテンツに到達できるようになる。
この達成基準を満たすとそういうメリットがあると。
ここではじめて、画面を見てマウス操作ができないので、キーボードだけで操作するユーザにも達成基準は意味があるというのが明確になります。
事例もいくつか挙げられています。
ページの先頭に、そのメインの記事へジャンプするリンクがあると。
このリンクを使わないとキーボードを仕様している利用者は、メインの記事に到達するまでにTabキーを押しながら、40前後のリンクを通り抜ける必要がある。
またScreen Readerの利用者は200も単語を聞かないといけない。
だから、繰り返されているブロックをスキップして、メインコンテンツまですぐにたどりつけるようなメカニズムを提供しましょうということになります。
これだけだと、よくわからないと思うので、具体的な例を。
世界的に有名な例です。
「ニューヨーク・タイムズ」という、アメリカの新聞社のサイトです。
これはトップページですが、ヘッダー部分があります。
普通はナビゲーションバーと言って、各コーナーの入口がこのように並んでいます。
左にサブメニューがずらずらと並んでいて、3カラムくらいに分かれていて、メインコンテンツがあります。
ページをパッと開く。画面を見て、マウスを使っている人が野球の写真を見て、この記事を読んでみようと思って、見出しのリンク先に行こうと思ったら、普通に迷いもなく、リンクにマウスポインタをあててクリックするだけです。
ところが、例えば、画面を見ているけれども、マウス操作ができなくて、キーボード操作だけでパソコンを使っている人がこのページに来たときに、このリンクを押そうと思ったら、とんでもない話です。
Tabキーを1回押すと、最初のリンクにフォーカスが当たって、破線の囲み罫線が出てきます。
これがフォーカスです。基本的に、Tabキーを押して、フォーカスを移動させていきます。
いま左側の検索窓にフォーカスがありますが、検索ボタンに行って、また右側に行って…ここから左側のサブメニュー…これを延々と。
50個以上あるような。
これを延々、Tabキーをひたすら押して、押して、まだ続きます。
やっと、次に来て、左側のリンクにフォーカスが当たっているので、すぐに右に行きたいんですが、また下に下りていってという感じで、いつまで経ってもたどり着かないという問題があります。
どのページにもあるような、サブメニューとか、もしあればグローバルメニューがあればまた別ですし、検索のボタンなどもそうです。
繰り返し、どのページでも使われているようなものがあれば、必要がない時は無視して、そのままメインコンテンツにすぐに入っていけるような仕組みを提供しましょうというものです。
同じように、Screen Readerのような読み上げのユーザの場合は、何もそういうメカニズムがないと、同じように、どうでもいい、毎回毎回同じリンクを聞いて、聞いて初めて、そのページのメインコンテンツにたどり着けるという状況が発生します。
そのことを先ほどのスライドで言っていました。
今のようなページですと、Tabキーを何回も押さないといけなかったり、いくつも単語の読み上げを聞かないと目的のコンテンツ、メインの記事にたどり着けません。
Understandingでこのように確認していくと、達成基準の意図がまずわかります。
それを満たすことにより、どんなメリットを、どういうユーザに対して提供できるか。
実際の事例や、達成基準を満たすことができる実装方法、不適合事例も確認することができます。
やはりどの達成基準も何を要求しているかを確認することが重要で、そのためには、規格票だけでは不十分です。
解説書、Understandingの日本語訳を最初はしっかり読んで、１つ１つの達成基準についてしっかり理解していくことが必要です。

実際に、解説書がどんなふうになっているかと言うと…これがWCAG 2.0のドキュメントの翻訳です。
しばらくいくと、目次があります。そして、達成基準が1.1.1から始まります。
達成基準のタイトルが並んでいます。
先ほどのは2.4.1でしたので、そこをクリックしてみると、「達成基準2.4.1を理解する」というドキュメントが出てきます。
達成基準の意図が最初にあります。これをしっかり読んでいただいて、何が必要かと。
これを満たすことによって、どういうユーザにどういうメリットが提供できるかを確認します。
事例なども参考にしながら、最後に、達成基準を満たすためにどういう実装方法があるかということで、「達成基準を満たすことができる実装方法」というセクションがあります。
この達成基準だと、大きく2つに分かれていて、それぞれの中に3つないし4つのテクニックが書かれています。

解説書を見て、意図を理解して、どんなユーザにどんなメリットがあるか確認していくと、最後に、どういう方法を使えばいいかの実装方法の一覧が出てきます。
ここで、1個1個リンクをクリックすれば、テクニック文書に行って、その詳細を見ることができます。

例えば、スキップリンクの実装方法で、1番目にあったG1、 メインコンテンツエリアへ直接移動するリンクを各ページの先頭に追加するというのがあります。
Techniquesの文書も、最初に解説があります。
この解説を読んでいくと、「リンクが画面に表示されていることが必要である」という一文が出てきます。
2004年版の時のスキップリンクでは、暗にScreen Readerのユーザを想定していたので、「読み飛ばせる」という言葉が使われていましたが、画面上見えなくても良い。
よくスタイルシートで、画面の外に出すという実装されていました。見えなくても良いという認識でしたが、今回の改正で、それだけでなくて、キーボードだけで操作しているユーザのことも考えて、まず画面で見て確認できなければダメだと要求事項が変わってきています。
このTechniques文書の最後に、チェックポイントがあります。
そこを見ても、そのリンクが常に表示されている、またはキーボードフォーカスを受け取ったときに画面に表示されるかのどちらかでないといけないと書かれています。

この実装方法のチェックポイントです。
ポイントは最初にフォーカス可能なコントロールであること。
つまり、そのページを開いたときに、一番最初にキーボード操作で、Tabキーなんかを使ってフォーカスを移動させようとした時、一番最初にフォーカスが当たるのが、このスキップリンクでないといけないということ。
もう1つが、先ほどのとおり、そのスキップリンクは常に表示されているか、もしくはキーボード・フォーカスを受け取ったら画面に表示されるようにしましょう。
そうしないと、画面を見てキーボードだけで操作しているユーザには、スキップリンクの存在がわかりません。
解説書と、実装方法まで一通り順を追って確認していくことによって、それぞれの達成基準が何を要求しているのかより明確になってきます。
このスキップリンクですが、実際に、早速実装しているサイトがあります。
富士通さんのサイトが少し前にリニューアルされまして、このリンクを実装しています。

見た目には、スキップリンクらしきものが出てきていないんですが、Tabキーを押して…。
このページで1回Tabキーを押したら、ページの上からグレーの帯が降りてきて、「このページの本文へ移動」というのが出てきました。
これは実は通常は画面の外、上に隠れていますが、このページでキーボード操作でフォーカスを移動させると、1つ目にフォーカスがあたるのが、このスキップリンクになっていて、かつキーボードフォーカスを受けとると表示されるようになっています。つまり、必要な人にだけ見える。
似たような実装をしてるもので、マウスポインタにも反応してしまうものもあるが、この場合はマウスポインタが通っても反応せず、キーボードフォーカスを受け取った時だけ表示される。
これによって、必要としているユーザ、画面を見て、キーボードだけで操作しているユーザには確実に見えて、それ以外のユーザには邪魔にならないという実装です。
これを富士通さんは実装しています。

ちょっと戻ります。
ブロックスキップの達成基準ですが、HTMLの場合は、もう1つ選択肢があります。
見出しのマークアップをしましょう、というのがあります。
つまり、スキップリンクを提供するか、見出しのマークアップのどちらかをやればいいということになってます。
同じ富士通さんのサイトをサンプルに。
Operaというブラウザですが、Operaにはキーボードユーザのために、シングル・ショートカットキーが提供されています。
Sキーを押すと、富士通のロゴが青い囲みになりましたが、これはフォーカスです。
これによって見出し要素、h1とかでマークされているところにジャンプできます。
ニューヨークタイムスのサイトを思い出してください。
あのサイトもちゃんと見出しのマークアップがされていれば、どれだけいらないリンクが繰り返されていても、ショートカットキーを使って目的のコンテンツに飛んでいくことが出来ます。
Wを押すと1個ずつ戻ります。
富士通さんの場合は、スキップリンクを付けることと、見出しのマークアップをきちんとやることの両方を実装し、より広い範囲で多くのユーザをカバーしようという考え方があるんだと思います。

話がそれますが。
alt属性を空にしましょうという話があります。
基本的には代替テキストを書きましょうということですが、時と場合によって、むしろ空にしましょうと。
その場合、例えば、細かい話ですが、alt=“ “と、スペースを入れて使う人がいます。
これに関しては、空白を入れても入れなくてもいいですが、どちらにしても何も入れなくていい、という細かいところまで文書化されています。
人によって、「入れるべき」「入れないほうがいい」と考え方がありました。
ある程度これについても、方向性を示す文書となっています。
label要素を使って関連づけましょうというのがあります、よくチェックボックスやラジオボタンにはlabel要素が使われていますが、テキストフィールとやセレクトメニューなども関連づけないとダメですよと書かれています。
ドキュメント化されていることによって、今までまちまちだった解釈が揃ってくるというメリットもあります。

では、どの実装方法を用いてもいいのか。
2.4.1に戻ります。
スキップリンクを提供するか、見出しのマークアップみたいに、文書構造のマークアップでもブラウザやScreen Readerがジャンプできるので、どっちでもいいよというのが、理論上の話です。
加えて、全ての実装方法がUnderstandingに挙げられているわけではありません。
8割ぐらいは、ドキュメント化されていますし、多くの場合はこの中のどれかを選べばいいでしょう。
また、今までやってきたものが、どこかにあるはずです。
が、100％ドキュメント化するのは無理なので、全てがドキュメント化されているわけではないし、今後技術が進歩したり、ブラウザや支援技術側の機能が向上することで、違うテクニックを使っても達成基準が要求していることを満たせる可能性があります。
その場合、Understandingにあげられていない独自の方法を使ってももちろんOKです。
ただし、利用者にとって利用可能であることを確認しなければならない、という条件はつきます。
基本的には自分で考えた文書化されていない方法を使うこともOKになっています。

では、どういう実装方法を使えばいいか、もしくはどういう実装方法を使わなければいけないか。
箇条6に書かれています。
まず、実際にユーザが使えなきゃダメですよと。
使えるかどうかを確認するのは設計・開発する人の責任です。
つまり、多くの場合は規格票を読んでいるあなたの責任ですよと。
例えば、よくある例としてはHTMLでimg要素のlongdesc属性があります。これは、普通はimg要素を使う場合は、alt属性で代替テキストを提供しますが、それがあまりにも長くなる場合には、longdesc属性を使って別ページに画像の詳細な解説を用意しておく。
そこにlongdesc属性でリンクをはる。
ユーザはリンクを辿ることで、フローチャートとかシステム設計図などの入り組んだ画像でも必要な情報を得ることが出来る、longdesc属性があります。
これ自体はほとんどのブラウザや支援技術でサポートされていません。
ですが、HTMLの仕様書には書いてあるので、longdesc属性は正しいことです、仕様に準拠していますと言えます。
が、現実としては、longdesc属性を使ってリンクをはってある別ページには、ほとんどユーザは行けない、その存在すら分からないという事態が起きます。
ですので、理論上正しいとか仕様に書いてあるからではなく、ユーザが実際に使えるかどうかを、ちゃんと確認しましょうという考え方です。
これをAccessibility Supported情報と呼びます。
つまり日本語のウェブサイトなら、日本のユーザが使っているブラウザや支援技術でちゃんと使えるかを確認した上で、実装方法を選びましょうということです。
これは、附属書のAに書いてあります。
後日、規格票をじっくり読んでいただければと思います。
Understandingの解説書にも詳細に解説されています。
スライドにURLがありますので、時間をみつけて読んでください。

Accessibility Supportedとは何か。
ユーザが使える、仕様しているブラウザや、要素や属性をサポートしているか。
サポートしていればそれがAccessibility Supportedであると。
その実装方法を使っていれば達成基準を満たせますよという話です。
longdesc属性の話に限らず、仕様に準拠しているイコール、アクセシビリティ・サポーテッドとは限りませんというのが注意点になります。

じゃ、どうやってサポーティド情報を確認すれば良いのか。
附属書には、アクセシビリティ・サポーテッド情報というのを作りましょうと。その情報は、誰が作ってもいいのですが、制作者、技術ベンダーなど。誰でも良いと書いてあります。
ちなみに、WCAG 2.0でも同じようなものを使っています。
具体的な完成イメージだったりしますが。
どうやって作成するか。
当然検証するわけですから、テストファイルが必要になります。
そのテストファイルを使って、ブラウザ、もしくはブラウザと支援技術との組み合わせを使って検証しましょうと。実装されている方法1個1個について、その実装方法を実際に使ってみたテストファイルを作ると。
それを例えば、ブラウザ単体で、キーボードだけで操作してみるとか、あるいはScreen Readerの読み上げで情報が得られるか確認するという検証をすることになります。
ただ、話としてはわかる話だとは思いますが、やってみようと思うと、いくつか問題がすぐに出てきます。

まず1つ目に、テストファイルの制作工数。
対象になる実装方法ですが、現時点で、全部カウントすると350ぐらいあります。
少なくとも350のテストファイルを、皆さん1人1人が作って、それを検証するのか。
そんなにたくさんテストファイルを作る時間はないということに直面します。
さらに、テストファイルを作るに当たって、制作の工数も必要ですが、その前に1個1個理解していく必要があります。
つまり文書を読み込む必要があります。
さらにブラウザ、支援技術、いろんな組み合わせが考えられるし、バージョンもあります。例えば、IE1つ取っても、IE6、7、8と3つあります。
ブラウザに限らずOSもそうですし、支援技術にしても、いろんなバージョンがあります。
また、Screen Readerだけでなく、他にも支援技術と呼ばれるものがあったりします。
そうするとOSとブラウザと支援技術、それぞれバージョン違いまで考えると、とんでもない組み合わせの数になり、そんなに検証できないでしょうと。
この辺は、W3Cも何も動いていないのが現状で、考え方だけを示して、どのブラウザがサポートしていればいいか、いくつのブラウザが、いくつのScreen Readerがサポートしていれば良いかの目安すらW3Cでは示していません。

こう考えていくと、まず、皆さん1人1人にやっていただくのはまず無理でしょう。
ということで、我々WAICのほうで、皆のリソースを手弁当で持ち寄って、ボランティア作業と言ってもいいですが、無報酬の作業で、ドキュメントを翻訳する、ドキュメントを元にテストファイルを作る、テストファイルを使って検証するという作業を、ここ数年かけて、改正される前から。
WCAG 2.0が勧告になったのは2008年12月ですので、2009年くらいからそういう準備を粛々と進めてきていました。
WAIC発足前から始まっているので、WAICの委員会やWGのメンバーでない人にも、かなりお手伝いいただきました。名前は時間がないので読み上げませんが。
ドキュメントの翻訳であったり、テストファイルの翻訳であったり。
本当に多くの方達のご協力をいただいて、とんでもない作業量をこなすことができています。

Understanding で実装方法の一覧を確認しました。
どれを使おうかなと考える前に、どれがアクセシビリティ・サポーテッドなのかを確認しないといけない。
どのテクニックだったら、ユーザが実際に使っているブラウザや支援技術でサポートされていて、この実装方法を使ったコンテンツを利用できるかを確認していきます。
その際に参考になるのが、アクセシビリティ・サポーテッド検証結果。
検証結果の一覧表ですが、達成基準ごとに並べられていたテクニックの番号があって、結果として、これはマルこれはバツと。或いは、一部OKであればサンカクと。
その一覧があります。
これを見ていただいて、全部マルであれば迷わず、これはOKだという判断ができますが、バツがいくつかあったり、サンカクが入っているような場合には、ユーザ数はどれが多いかなど、いろいろな要素で判断していただき、これなら大丈夫だろうというものを選んで実装してもらうという流れになります。
これまでに検証した利用環境・ブラウザは全部で10種類です。
ブラウザ単体で言うと4つ。
ブラウザの場合は、表示されるかとか、マウスで操作できるかとか、キーボードだけで操作できるかというチェックをしています。
Screen Readerの場合は、読み上げができるか、もちろんキーボードだけで操作できるかの確認をしています。
ただ、Windows XPとIE6をベースにした検証をしてきていますが、そろそろ、IE 8、Windows 7をベースにした検証もやっていかないといけないかという認識をWGではしています。追加の作業を検討しているところです。

達成基準に戻りますがHTMLの場合、スキップリンクを提供するか見出しのマークアップをするかの二択になりますが。
実際に結果を見てみると、どれも帯に短し、たすきに長しという感じで、スキップリンクに関しては、ユーザ数の多いScreen Readerがサポートできていないという現実があったり。
あるいはキーボードだけで操作するユーザのことを考えると、先ほどの見出しをジャンプしていくのは、Operaという、日本ではユーザ数が少ないブラウザにしか搭載されていない。
どっちを使っても、「う〜ん、何か物足りない、不十分な感じがする」というところがあります。おそらく富士通さんもその辺を認識して、では、両方提供しようと、使えるほうを使ってもらえればということで、両方実装されているのかなと思います。

このように検証結果を踏まえて…。
ドキュメントを読み込んで、理解して、テストファイルを使って、実際にいろいろな組み合わせを検証してというと、大変な作業にも思えるわけですが、おそらく皆さんも今まで無意識に…と言っても、当然、ユーザが使えるかどうかは意識されてきたと思います。
ところが、隅々まで調べることはできなかったと思いますので、今回、このテストファイルを作ったことと、検証作業を行ったということで、かなり細かいところまで検証結果がはっきりして、何がどこまでサポートされているかがわかるようになったと思います。
一度、この検証結果をご覧いただけたらと思います。

テストファイル、検証作業ですが、日本がおそらく一番世界で最初に取り組みました。
我々が世界中見渡しても最初にやった事例ということになると思います。
つまり、W3Cはコンセプトだけ提示して、具体的な方法は何も提示していませんでした。
そんな中JISが改正されたので、日本はすぐに必要だという認識で、WAICを中心にしてやりました。
これはおそらく世界で初めての試みだろうと思います。
実際、W3Cにも報告をしたんですが、そのテストファイルちょうだいという話もありました。

検証して分かったのは、全部がマルになるのは、意外と少なかった。
今回特に初期設定を基本としました。
実際にはユーザさんは、自分のニーズにあわせて設定やオプションを変更することが多いと思いますが基本的に初期設定にそろえました。
英語圏と比較すると、日本のScreen Readerは機能的に落ちるかなと。
支援技術のベンダーさんにも、何か、働きかけの必要があると思います。
テストファイルも一通り作り、公開していますが、まだ完全だとは全く思っていません。
その点で、是非、皆さんからフィードバックをいただければと思います。
この中にも「HTMLならまかせて」という人や「CSSなら自信がある」「Scriptなら任せろ」など、それぞれ得意分野があると思うので、その視点から重点的に気づいたことがあればフィードバックいただけると、大変助かります。
すべて我々でやれると思わないので、ご協力いただけると助かります。
今後、やるべきこととして、マル、バツ、三角の結果が出ているので、1個1個どう判断すればいいか、何らかで示さないといけないとワーキンググループで認識しているので、これから解説を作ろうと思っています。
支援技術のベンダーさんへの情報提供も必要だと思いますし、テストファイルの品質向上も目指しています。

時間が過ぎてしまいました。最後、駆け足で。
2010年版で、基準が具体的になりました、という話でいつも例に挙げているので、聞いたことがある方もいると思います。
例えば、色のコントラストについて「充分な」とか「見やすい」という言い方でした。
コントラストが十分か見やすいかは人によって違うし、判断が付かないところがあります。
2010年版では、「4.5対1」のコントラスト比がなければならないと基準が具体化されています。
これによってツールを使って誰がチェックしても同じ結果が出ます。
「十分」とか「見やすい」というのは、人によって違うと思います。
幕張メッセさんのサイトですが。
「お知らせ」をチェックします。
このスポイトで文字の色を選択します。
背景の色も同じように。
これは、条件が悪いのを選びましょうというのがあるので、これは白い縁取りが入っているので。
そうすると、3.4しかないですよ、4.5ないので、この組み合わせはバツです。
これは誰がチェックしても同じ結果が出ます。
2004年版と比べて検証しやすくなっている一例です。
同様に、AAAだと7対1という更に強いコントラストが求められています。
このへんは、また時間をみつけてご覧になってください。

まとめです。
規格票だけでは、分かりにくいというのが、2010年版の特徴と言えるでしょう。
それは具体的な記述を一切していないからで、そのかわりにWCAG2.0の解説書できちんと情報提供されていますし、更に具体的なテクニックも、実装方法集で確認できます。
ここまでセットにして2010年版だと理解していただければと思います。

さらにユーザが使えるかどうか確認しましょう、ということでテストファイル作成と検証作業は、皆さんを代表する形でWAICでやっています。
実装方法集のドキュメントには1個1個の判定基準があるので、それにそってチェックすることで、正しく実装できているか確認できるよう、文章化されて明確になっているのが特徴です。

2004年版JISをいろんな人が見ていたと思いますが、あいまいな記述が多かったので、それをどう解釈するかは、人によって違っていました。
なかには一言も書いてないことを言い出す人もいて、かなりムチャクチャな状況がありました。
2010年版の改正で、WAICのほうで統一見解とか、ドキュメントを出しています。それはすべてW3CのWCAGのWGでやっています。
同じ認識の上でビジネスをやっていける基盤が作れるのかなと思います。
いろんなドキュメントを基盤委員会のサイトで公開しています。
皆さんの得意分野の視点から何か気づいたことがあれば、どんな小さいことでもかまわないので、是非、フィードバックをいただければと思います。
私のセッションは以上です。

／植木さま、ありがとうございました。
皆さま、今一度、盛大な拍手をお願いします。


植木／質問の時間はないですかね。

／厳しいですね。

植木／何かあれば、個別に声をかけていただければ。

／これをもちまして、ウェブアクセシビリティセミナーのパート2を終わります。
次の講演の準備に入りますので、申し訳ありませんが、一旦退場をお願いします。

植木／廊下を出たところにいますので、質問があれば声をかけてください。梅垣さんは仕事の都合で帰ったので、梅垣さんのお話の内容も私が質問をお受けします。