国際協調

• 達成基準がWCAGと同一
• WCAG WGが開発した諸資料やWCAG 2.0用のツールを流用できる
• グローバルサイトの運営がしやすい

非技術依存

• ウェブコンテンツ技術（HTML, CSS, FLASH…）とその実装方法を含まない形で規定されている
• だからRIA（Rich Internet Application）などの新技術にも対応できる（はず）

テスタビリティ

• 試験方法も規格化されている
• チェックツールあるいは専門家、ユーザによる客観的判断が可能（のはず）

また、WCAG 2.0にないJISだけの特徴として、

• サイト開発プロセスの各段階で配慮すべき事項を箇条6で規定
• 箇条8の試験方法は，欧州の考え方も取り入れている

より詳しい解説はWAICの「JIS X 8341-3:2010の概要」をお読みください。（ページをPDFで書き出し、iPadなどに入れておくと便利です）

ここまでで、改正JISの大まかなアウトラインはつかむことができたでしょうか。次回からは、最初にかかげた三つのテーマごとにセミナーの内容まとめていきたいと思います。

三つのテーマ

• 理解と普及（渡辺さん）
• 実装方法（植木さん）
• 試験方法（梅垣さん）

アクセシビリティの「もの差し」

JIS X 8341-3:2004の登場によって、アクセシビリティという一つの「配慮」が普及した一方、大きな課題もまた明らかになりました。それは「試験方法が規定されていない」ということです。旧規格だけでは、適合性評価も各人の裁量に頼らざるをえず、第三者による客観的評価が難しい状況でした。

このような状況に対応すべく登場したのが「JIS X 8341-3:2010　箇条８」なのです。

箇条８：試験方法

1. 適合試験の要件
2. 試験の手順
3. 試験結果の表示

箇条８は、WCAG2.0の「適合性」となるべく照応するよう規定されていますが、WCAGがあくまで勧告（国際的ではあっても）なのにくらべ、JISでは工業規格であるという利点を活かし、試験方法自体の規格化に成功しています。また、具体例に乏しい新規格のなかにあっては唯一、以下の図表が掲載されており、WCAG2.0よりもとっつきやすい印象です。

1. 実装チェックリスト
2. 達成基準チェックリスト
3. 試験結果表示の例（ウェブページ単位）
4. 試験結果表示の例（ウェブページ一式）

梅垣さんによれば「2010は丁寧に、迷わないように、検証可能なかたちで書いてある。めざすのは、アクセシビリティのもの差し」。

普及から品質へ

具体的な手順やチェックリストの作成方法についてはまた後日考えるとして、最後の「試験結果の表示」の重要性について梅垣さんは、

1. 文書化すると証拠になる
2. 発注者や第三者が追試できる
3. 納品されたものを合否判定できる
4. サイトなら、うそを見破ってクレームが言える

結果として、「市場原理が働いて品質向上が見込める」。これは公共調達にもいえることです。商用にしろ公共にしろ、上記の理由でユーザ評価がいわゆる「消費者の声」といった個人的主観的なものではなく、JISベースの客観的意見として運営側も扱わざるをえないことになり、いずれは受発注の納品要件として盛り込まざるをえなくなるからです。

このように、すべての人が箇条８で定義された試験方法に準じることにより、送り手・受け手の客観的評価が可能になり、最終的にはWEBサイト自体の品質にフィードバックされていく。このような好循環をもたらす試験可能性、つまり「テスタビリティ」こそ、改正JISの大きな成果だと思います。

1. 国際協調
2. 非技術依存
3. テスタビリティ

それぞれのキーワードについて、ここから考えていきたいと思います。

規格票の閲覧・購入

閲覧：JISC(日本工業標準調査会)
「X8341-3」で検索してください。

購入：JSA Web Store
同じく「X8341-3」で検索してください。

規格票は入手したが、とっつきにくいという方は、まずWAICの「JIS X 8341-3:2010 解説」を一読され、全体像をざっくりと把握しておくことをおすすめします。

規格票の構成

目次は以下のとおりです。

• 序文
• 箇条1：適用範囲
• 箇条2：引用規格
• 箇条3：用語及び定義
• 箇条4：ウェブアクセシビリティの達成等級
• 箇条5：一般的原則
• 箇条6：ウェブアクセシビリティの確保・向上に関する要件
• 箇条７：ウェブコンテンツに関する要件
• 箇条８：試験方法
• 附属書A（参考）この規格を満たすウェブコンテンツ技術及びその実装方法の選び方
• 附属書B（参考）WCAG2.0との整合性
• 附属書C（参考）JIS X 8341-3:2010とJIS X 8341-3:2004との比較
• 附属書D（参考）参考文献
• 解説

以上、計62ページ。附属書と解説をのぞくと、規格票そのものは実質33ページしかありません。このなかでウェブコンテンツ制作者がもっとも注目すべきは、箇条4、7、８の合計22ページ。この三つだけでもざっと目通しすることをおすすめします。それぞれの内容は以下のとおり。

箇条4「ウェブアクセシビリティの達成等級」

改正JISでは、アクセシビリティの適合の程度を、「ウェブコンテンツのアクセシビリティ達成等級」と規定しており、以下の三つにわかれます。それぞれの等級が具体的にどんな達成基準（2004年度版の「個別要件」）を満たせばよいのかをリストアップしているのがこの箇条４です。

1. 等級AAA（トリプルエー・達成基準数61）上級（以下、例えとして）
2. 等級AA（ダブルエー・達成基準数38）中級
3. 等級A（シングルエー・達成基準数25）初級

今後われわれが目標とすべき等級について、渡辺さんによれば「AAが目標。Aはあくまで最低限のレベル」。「AAA適合は推奨しない」（植木さん）。

箇条７「ウェブコンテンツに関する要件」

箇条７＝WCAG2.0
箇条4で等級別にリストアップされていた達成基準（個別要件）をひとつずつ規定しているのが箇条７で、本規格のコアともいえる重要な部分です。なぜなら箇条７は細分に到るまでWCAG2.0ガイドラインと合致しているからです。もっと具体的にいうと、細分箇条7.1.1.1の「7」をとると、そのままWCAGと番号まで一致しています。ちなみに箇条4の「達成等級」もWCAGの「レベル」を置き換えたもので、実質的にはおなじものです。詳しくは附属書B「WCAG2.0との整合性」を参照してください

箇条７の構成自体も当然ながらWCAGと以下のように合致しています。四つの原則の下には、総計12のガイドラインが配置（7.1.1, 7.1.2…）されており、ガイドラインの下には、 さらに達成基準が並ぶ（7.1.1.1 …）という3階層になっています。

四つの原則と12のガイドライン（カッコ内の数字は達成基準数）

• 7.1：知覚可能に関する原則
  • 7.1.1 ：代替テキストに関するガイドライン（1）
  • 7.1.2：時間の経過に伴って変化するメディアに関するガイドライン（9）
  • 7.1.3：適応可能に関するガイドライン（3）
  • 7.1.4：識別可能に関するガイドライン（9）
• 7.2：操作可能に関する原則
  • 7.2.1：キーボード操作可能にに関するガイドライン（3）
  • 7.2.2：十分な時間に関するガイドライン（5）
  • 7.2.3：発作の防止に関するガイドライン（2）
  • 7.2.4：ナビゲーション可能に関するガイドライン（10）
• 7.3：理解可能に関する原則
  • 7.3.1：読みやすさに関するガイドライン（6）
  • 7.3.2：予測可能に関するガイドライン（5）
  • 7.3.3：入力支援に関するガイドライン（6）
• 7.4：頑健性（ロバスト）に関する原則
  • 7.4.1：互換性に関するガイドライン（2）

達成基準の総数：22+20+17+2=61

国際協調
このように改正JISがWCAGと合致しているのは、何もそっくりそのまま頂戴したからではなく、逆にWCAG2.0がJIS2004年度版の成果を取込んだという経緯によるものです。この事実はわれわれウェブコンテンツ制作者にとって大変な福音となるでしょう。なぜなら、2010年版に適合すると、自動的にWCAG2.0適合となるため、複数の規格を配慮する手間が今後なくなるからです。もうひとつ、たとえばCSSハックのように、国内外の制作者が問題意識を共有し、知恵を分かち合い、実装テクニックを共有（ライブラリ化）するためのフレームが整ったことにもなります。これが一つめのキーワード、「国際協調」の利点です。

非技術依存
ウェブコンテンツ制作者は、各等級が要求する実装テクニックを求められることになるのですが、改正JISはこれらの具体的な実装例についてはあえて何も書いていません。具体例、図版ともに豊富であった2004年度版と比較すると、今回の改正版はひたすら文字ばかりで、実に色気のない印象を受けるでしょう。これが二つ目のキーワード「非技術依存」と関係があります。

簡単にいうと、ウェブコンテンツ制作者は、達成基準さえ満たしていれば、HTML,PDF,FLASH,Javascript、もしくはその他のどんなウェブコンテンンツ技術を用いても（ユーザ側が利用可能な技術であれば）いいということです。目的さえ達成できていれば、手段は問わないというわけです。「代替コンテンツは最後の手段」（梅垣さん）。

このように、2010年度版は規格そのものが技術の発展に翻弄されないよう、あえて技術とは距離をおいた形で策定されているのです。

次回は、三つ目のキーワード「テスタビリティ」と箇条８について考えてみたいとおもいます。

さて、WEBアクセシビリティのJIS規格「JIS X 8341-3:2004」（高齢者・障害者配慮設計指針 情報通信における機器、ソフトウェア及びサービス第３部：ウェブコンテンツ）の登場からすでに７年がたちました。県内でも同規格に配慮したWEBサイトがぼちぼち公開される一方、現場ではあいかわらずモヤモヤした状況が続いています。そして昨年8月20日、改正版にあたる「JIS X 8341-3:2010」がついに公示されました。

さらに今回のJIS改正に歩を合わせる形で、政府内でも障害者権利条約の話し合いのなかでWEBアクセシビリティを要件化しようという動きがはじまっています。規格の要件化による制作者側の負担増を心配する声もある一方で、むしろ大きなビジネスチャンスであるという意見も多数きかれます。さまざまな意見が並び立つなか、現場の人間、つまりWEBを発注する側・制作する側にすれば関心はあっても、いったい何から手をつけたらよいのか、最初の一歩がなかなか踏み出せないというのが現状です。

昨年9月２日、東京女子大で行われた「規格の策定者が解説する「JIS X 8341-3:2010」は、正にこのような疑問に応えるべく開催されたものです。策定者本人から直接話がきける滅多にないチャンスということで、チケットは即完売。追加分でなんとか確保しましたが、この盛況ぶりはおそらく業界の関心度をそのまま反映したものといえるでしょう。

主催はINSTAC（インスタック：情報通信アクセス協議会）内のWAIC（ウェイク：ウェブアクセシビリティ基盤委員会）。昨年8月4日に発足したばかりの会ですが、WEBアクセシビリティ関連の情報はまずWAICから、という意識がすでに広まりつつあります。

右から、植木さん、渡辺さん、梅木さん

WAIC内には、さらに三つのワーキンググループがあり、それぞれ以下の方々を主査に活動しています。

1. 理解と普及：渡辺隆行（東京女子大学　現代教養学部教授）
2. 実装方法：植木真（株式会社インフォアクシア）
3. 試験方法：梅垣正宏（日本障害者協議会）

実際に改正JISを学ぶ際にも、このように切り分けると理解が早いと思います。インフォアクシアの植木さんは「辻ちゃん・ウエちゃんのアクセシビリティPodcast」でもお馴染み。あと裏方のなかに大学の先輩がいたので挨拶したら「君のことは覚えていない」といわれガッカリしました。ちなみにWAICは全員ノーギャラ、すべてボランタリーな活動だそうです。

次回からはいよいよJIS X 8341-3:2010の全容について、WAICのお話を交えながらせまってみたいと思います。

2年前の2008年末にはWebの国際規格であるWCAG2.0が公示され、日本のWebJISもそれに合わせて間もなくという雰囲気だったと思いますが、年を経てようやく新しくなるとのことです。関係者の皆さまは本当に大変なことだったと思います。

これに合わせて新しいWebJISを学ぶセミナーなども開催されるそうで、予定が合えばぜひ参加してみたいと思っています。東京は遠いですが…。

すでにWCAG2.0の翻訳版など参考資料に目を通していますが、公示されたらちゃんとチェックし、誰もが使いやすいWebサイトの制作とサービスに活かしたいと思っています。

最初にリニューアルしようと話し合ってから時間は経ちましたが、ようやく第一段階完了という感じで公開しました。

板橋さんのサイトということで、制作作業の確認は主に板橋さんが普段使われている音声読み上げソフトでチェックをしていただきました。板橋さんはスクリーンリーダー(Windowsの操作補助ソフト)としてPCトーカー、音声ブラウザ(ブラウザ操作に特化したソフト)としてボイスサーフィンを使用されています。

ちなみに私の方はスクリーンリーダーはNVDA、音声ブラウザはホームページリーダーを使ってチェックを行いました。計4つの音声読み上げソフトを使用しての制作チェックは自分にとっては初めてでしたが、青森県内でも珍しいのではないかと思っています。

以前からアクセシビリティに配慮した作りを続けてきたつもりなので、制作とチェックの大方は予想していたよりもスムーズに進んだのではないかと思います。板橋さんもこちらが制作したものに対して随時適切な修正指示を返してくださいました。

今回のように音声読み上げソフトが制作過程に多く関わったケースはなかったので、気づいた点をいくつかピックアップしたいと思います。

画像に代替テキストを入れれば画像もチェックしてもらえる

至極当たり前のことですが、目の不自由な方はサイトに表示してある画像を視覚的に理解することはできません。しかし、どんな画像かを客観的に説明する説明文(代替テキスト)を画像に入れておけば、音声読み上げソフトがその内容を読み上げてくれるため、画像についてもチェックを行っていただけます。

実際今回でも「全盲」か「盲目」かの表記について、代替テキストを入れて説明することで内容を漏らさず板橋さんに伝え、レスポンスをいただくことができました。

箇条書きリストは番号を読み上げない場合がある

ちょっと専門的な話ですが、数字付きの箇条書きリスト(ol要素)でコードを書くと、標準では数字付きの箇条書きリストとして表示されます。しかし読み上げソフトによってはこの数字を読み上げてくれる場合と読み上げてくれない場合がありました。

これに気づいたのはCDに収録されている曲名を番号付きで紹介したいという板橋さんのご意見から把握したもので、最初はol要素で記述していたのにおかしいなと思っていました。が、確かに読み上げソフトによっては番号付きで読み上げてくれる場合と、番号を読み上げてくれない場合があることが分かりました。ちなみにソフトによっては箇条書きリスト(ul要素)で書いても数字を読み上げてくれるケースもありました。

この問題については何度かコードの書き方を直してみました。まずは数字付きの箇条書きリストol要素でCDの曲名を書く際に、各曲名の頭に曲順の数字も手入力して付けてみました。しかしイメージ通りに数字と曲名を読み上げてくれるケースと、数字を二度読み上げてしまうケースが出てきたのでこれは却下。

次に、箇条書きリスト(ul要素)でCDの曲名と、曲名の頭に数字を手入力して入れてみたところ、ほぼどの読み上げソフトでも「数字：曲名」が意図したとおりに読み上げられました。こうした結果から、CD紹介のページでは曲番号を手入力してあります。ちょっとHTML(ホームページを構築する言語)を知っている方からみればおかしいと思われるかもしれませんが、こうした理由があるということで理解していただけるとありがたいです。

PCトーカーでは、リンクの文字(アンカーテキスト)を読み上げず、アドレスを読み上げる

板橋さんに指摘していただいて気づいたのですが、PCトーカーではリンクを設定している文字、いわゆるアンカーテキスト部分の読み上げについて、文字を読み上げずリンク先のアドレス(http://といった部分)を読み上げるようです。

これについての対策として、リンク要素にtitle属性として、アンカーテキストと同じような、もしくはリンク先のページを端的に表す文字情報を入れることで、PCトーカーにtitle属性の内容を読み上げさせることができるそうです。しかしtitle属性に入力した文字情報は、他の音声読み上げソフトではアンカーテキストとtitle属性の内容二つを読み上げるケースもあるようでした。

アクセシビリティ関連の情報と照らし合わせて検討しましたが、title属性は設定せずそのままにすることにしました。このことから、アドレス自体もそのページの内容を想起させるような文字列になっていると、ページ移動する前になんとなく次のページの内容が想像つく場合があることもわかりました(板橋さん談)。

その他気を付けた点としては、リンクをクリックした際に極力新規でウインドウが立ち上がらないようにしました。これは音声読み上げソフトユーザーとしては強制的にページが切り替わることになり、混乱するきっかけになることがあるからという理由です。ページ内に埋め込んでいるtwitter(ツイッター)のリンク(新規ウインドウが立ち上がるリンク)についてはこちらで制御できないのでやむを得ませんでしたが、その他のリンクは極力同一ページで移動するようにしています。

また、最近よく見かける、ページ内をスムーズにスクロールして移動する機能(ページ下からページの上までスルスルっとアニメーションして移動するようなタイプ)については今回設定しませんでした。理由としては、あの機能については大抵Javascriptが使用されているのですが、あのリンクをクリックした場合、読み上げソフトによっては正常に読み上げ順序が移動しない場合があるからです。ページ上には表示していない、ナビゲーションスキップや本文へのスキップリンク等の挙動もこれに関連して正常でなくなる場合があります。この機能について今回はベストな解決策が見つからなかったため、機能として付けないことにしました。

大体以上のようなことに配慮しましたが、同時に作りきれなかった部分もまだ多くあります。例えば音声読み上げソフトでも正常に操作できる動画プレイヤーの実装や、お問い合わせフォームの適切なアクセシビリティ配慮、ブログ更新情報部分の適切なマークアップなどは諸所の理由からできなかったので、いずれ機会をみて実装したいと考えています。

オープンソースのCMSソフト「ネットコモンズ」で作られたサイトを視覚障碍者さんが使う音声読み上げソフトで読み上げた場合にどうなるかの続きです。

音声読み上げソフトでの読み上げ具合ついてはIJBL2のISHI-JUN（イシジュン）さんにご協力いただきました。ISHI-JUNさんは全盲で、普段から音声読み上げソフトを使用されています。その辺りについては非常に詳しく、ご自身のブログでもたびたび紹介されています。ISHI-JUNさんにはネットコモンズで作られたサイトを3つほど音声ブラウザでチェックしていただき、感想を戴きました。

当初の予想ではかなり読みづらいのではないかなと勝手に考えていたのですが、意外にもISHI-JUNさんからは「思ったより読みやすく感じた」とのことでした。チェックしていただいたサイトの中には、アクセスカウンターの表示部分は読めないものの、リンクでアクセス状況を読み上げることのできるページへ移動できたり、音声ブラウザ対応ページへの配慮がされているなど好評価のようでした。

一方でテーブル要素のサマリー属性(summary)の内容を記述している場合はその内容が都度読み上げられ、煩わしさを感じたとのことでした(ただこの辺りはソフトの設定で回避可能だそうです)。また、今回チェックしていただいたサイトではないのですが、音声ブラウザではサイトがフレームで分割されているのが分からなかったことがあるそうです。

今回の結果については個人的には意外でした。というのも、テーブルタグでレイアウトを組んでいるサイトは基本的にアクセシブルではないと単純に考えている部分もあったので、これについては大いに勉強になりました。もちろんテーブルで文字や画像を配置することにより、ページの見た目上の文章の流れと、音声読み上げでの文章の流れが異なる場合があることや、画像や文字の色味など、全盲の方のみではチェックしきれない部分もあるかと思います。

また、上で触れたようにサイトがフレーム構造になっていること自体気付けない場合もあるということで、この辺りの問題についても障害を抱えた方だけでなく、健常者や制作者など異なる立場の人たちで連携し合うことが大切なのではないかなと感じました。

実はこのW3AもCMSソフトで構築してあります。W3Aで使用しているのはWordPress(ワードプレス)というソフトで、オープンソースで開発されているものです。CMSソフトは先にも言ったように多くの種類があり、機能も仕様も様々です。そのため、中にはアクセシビリティに配慮しにくいものもあります。

今仕事仲間と少しずつ始めているのが、ネットコモンズというCMSソフトで作られるサイトをアクセシビリティにもっと配慮できないかという件です。ネットコモンズはオープンソースで開発されており、標準で様々な機能(アンケート・グループウェア・ToDoリスト・掲示板などなど)が備わっている高機能なCMSソフトですが、サイトのデザインや構造をデザイナーがカスタマイズするのが難しい仕様となっています。試しに自分も少し見てみたのですが、簡単なデザインの調整であればできそうなものの、純粋に一からデザインしたものを実装するにはかなり手間がかかりそうな印象でした。

また、ネットコモンズを使用して出力したサイトは、テーブル(table)タグが多く使用されることも分かりました。テーブル(table)タグとは、ホームページを作る際に使用する言語「HTML」の数ある機能のうち、表を作成するものです。以前はサイトのデザインレイアウトを作る目的で使用されることが多かったのですが、近年ではCSSという技術でレイアウトを作ることが主流になり、テーブルタグは純粋に表などの表示に使用されることが多くなりました。

ネットコモンズはその仕様上、テーブルタグがかなりHTML内に多く使用されるようで、このあたりが音声読み上げソフトにどのくらい影響を及ぼすのか気になり、ネットコモンズで作られたいくつかのサイトを知り合いの視覚障碍者の方にチェックしていただいたり、自分でもオープンソースのスクリーンリーダー「NVDA」を使用して読み上げてみるなどしました。この結果については後日お知らせしたいと思います。

ページ内からFlashコンテンツを見つけるのも容易で、通常はO(オー)ボタンをクリックすればすぐに見つけられました。以下ミツエーリンクスさんから手順の引用です。

NVDAでFlashコンテンツを操作する方法

1. アクセシビリティPodcastなどのアクセシブルなFlashコンテンツを含んだページに、NVDAとInternet ExplorerまたはFirefoxを用いてアクセスします。
2. Oキーを押して、「埋め込みオブジェクト クリッカブル」と読み上げられたところでEnterキーを押します。
3. TabキーやShift+Tabキーを押して、ボタンの名前が読まれることを確認してください。
4. 「再生ボタン」と読まれたところでEnterキーを押すと、Podcastコンテンツの再生が始まります。

ただしこの機能も、Flash側がアクセシビリティに配慮された作りでなければ機能しませんのであしからず。制作者はNDVAを使用してHTMLだけではなくFlashコンテンツのアクセシビリティもチェックできると良いですね。

最近新規登録することが無かったので知らなかったのですが、今までは画像による認証のみだったそうで、視覚障害者の方には困難な仕組みだったわけですが、音声認証も加わったことで、よりアクセシビリティに配慮されたと言えるかもしれません。

音声が日本語であることも一つの重要なポイントかもしれませんね。Googleでは先んじて音声認証システムが導入されていましたが、こちらは英語の音声なために非常に聞きとりづらい印象がありましたが、Yahoo!Japanのものは日本語音声なので比較的聞きとりやすい気がします。

一つ気になったのは、私の環境(Firefox)ではCSS(スタイルシート)を外した状態だと音声を再生することができませんでした。この辺りにも配慮されているとなお良いかもしれませんね。ともあれアクセシビリティがまたひとつ広がりを見せたような気がします。