水無月ばけらのえび日記

PDFは含まれる?

• 技術は問わないので対象
• 代替コンテンツを用意するというアプローチはアリ

ではMicrosoft Word文書は?

• OK (達成基準を満たしさえすれば良い)。WordのほうがPDFよりもアクセシビリティ・サポーテッドな可能性はある
• しかしできればHTMLがおすすめ

別ドメインのサイトの扱いは?

• 「ウェブページ一式」の定義参照
• そのサイトの目的による
• 目的によっては別サイトとみなすこともできる

動画をYoutubeに置いた場合の扱いは?

8.1.3の第三者コンテンツ除外要件に該当するか? 第三者コンテンツを修正しようと思えばできるケースになるか?

• 再生されるコンテンツが第三者のものというわけではない
• 自分のサイトに埋め込んでいる場合、実装技術としてYoutubeを利用しているだけで、第三者のコンテンツとは言えない (3.1.3のウェブページの定義では、埋め込みコンテンツはウェブページに含まれる)
• 埋め込みではなく、Youtubeにリンクしているだけの場合は試験対象外

どの製品を対象とすれば良い?

• 自分でアクセシビリティ・サポーテッドを検証することもできるが、WAICのアクセシビリティ・サポーテッド情報を参照するのが良い
• WAICの判断に従っている、と言った方が楽
• 達成等級AとAAに関しては、WAICに情報がある
• アクセシビリティの構成要素のひとつであるユーザーエージェントは重要だが、JIS X9341-3はコンテンツの規格なので手が出せない
• WAICは現実とのギャップをできるだけ埋めたいと考えてる
• 日本の支援技術はレベルが低い。オープンソースのNVDAはどんどん手を入れられる

印刷物をそのままPDF化している場合、オリジナルがアクセシブルでない (たとえばコントラストが低い) 場合はどうするか

• 少なくともそのPDFは達成等級AAには適合できない
• AAを諦めるのも方法の一つ
• そもそも、スキャンしたPDFは画像情報なので代替テキストが必要になる
• PDFは非常に大きな問題
• 7.2.4.10 (セクション見出しに関する達成基準) がAAAなのは、見出しがない過去の文書を移行する場合などを想定している

スマートフォンなど特定デバイス用のコンテンツは?

• ガイドラインの対象

スマートフォン用コンテンツは3.1.4の「ウェブページ一式」に含まれる?

• 「スマートフォン用です」という別の目的とも考えられる
• JISの検査ではウェブページ一式の範囲を書くことになっているので、そこで決められる
• 規格票p33「JIS X 8341-3:2010 に基づく試験結果表示の例」を参照

機種依存文字は?

• アクセシビリティの問題とは、障害のない人と障害のある人が差別される問題。一般ユーザーにも読めないものはアクセシビリティの問題とは考えない
• ちなみに 7.2.4.4「文脈におけるリンクの目的に関する達成基準」の但し書きに「リンクの目的が一般的にみて利用者にとって曖昧(あいまい)な場合は除く」とあるのも同様で、元々意味不明なリンクの場合はアクセシビリティの問題ではないと考える

AjaxなどのTechinqueは?

• W3CのWAI-ARIAで策定中
• まもなくLast callのワーキングドラフトが出るはず

ブロックスキップの富士通の例は7.3.2.5との兼ね合いでどうなのか?

※富士通のブロックスキップのサンプルでは、tabキーでフォーカスを移動すると突如「本文へ」リンクが出現します。7.3.2.5は「利用者の要求による状況の変化に関する達成基準」で、「状況の変化は利用者の要求によってだけ生じるか，又はそのような変化を止めるメカニズムが利用可能でなければならない。」というもの。

• 抵触すると言えば抵触するようにも思えるが……
• 違うページに飛ばされたりするわけではないので「状況の変化」には該当しないと考える

画像化された文字を禁止できなかったのか。ナビゲーション等が拡大できないのは厳しいのではないか

• テキストサイズ変更については 7.1.4.4「テキストのサイズ変更に関する達成基準」、7.1.4.8「視覚的な表現に関する達成基準」で規定
• 画像化文字はテキストではないので含まれないが、7.1.4.5「画像化された文字に関する達成基準」で「できるだけテキストにするように」という基準がある
• WCAG2.0は、全部テキストにしろというところまでは踏み込んでいない

※7.1.4.9に「画像化された文字に関する例外のない達成基準」がありますので、「達成等級AAAの基準として存在する」という回答でも良かったような。

Webアプリケーションの試験については?

• ページ数が無限にあるようなケースもある
• Webアプリケーションの試験については整っていない部分もある
• AjaxについてはWAI-ARIAを待つ必要があり、まだ試験できない状態

HTML5は?

※「5」を「ファイブ」と発音していたのが口述筆記では「HTMLファイル」となってしまっていましたが、HTML5です。

• アクセシビリティの問題は、新技術が来たときに対応が遅れること
• 支援技術の対応も遅れている
• →やがてHTML5対応の実装方法も提案されるはず、後追いにはなる
• 正式勧告にならないと手がつけられない、というスタンスかもしれない
• 現状では、支援技術やブラウザサポートがまだまだという前提でやるしかない
• 達成基準を満たしていれば良いので、規格への適合はできる
• ゼロか一かではなく、少しでも規格を満たすことが大事

富士登山ガイド2004

• 達成基準: 富士山に行こう! 登ろう! → 5合目までA 8合目AA 山頂AAA
• 登山技術: 登山ルート、装備……
• 試験: スタンプ、GPS、証拠写真……

• 1万ページをどう試験する?
• 欧州UWEM(うーむ) 試験の方法 http://wabcluster.org (wabcluster.org)
• サンプリングEIAO WAM 自動化テスト http://www.eiao.net (www.eiao.net)

• 国内調達・A市の入札要綱(H21)
• 事業の背景: 「JIS X 8341-3に準拠できておらず……」5. JIS X 8341-3 のうち、必須要件 (18件) を満たすこと。
• 基準が不明瞭→真面目にやる会社は仕事が取れなくなる、目視から測定へ

検査の方法

箇条8で検査の方法について規定している

• 8.1.1 a) ウェブページ単体: 埋め込みコンテンツなど全て。代替コンテンツも含む。ちなみに2004年JISは「代替ページ」を認めていなかったが、これは、「JISに適合していないページを認めるのはおかしい」という意見があったため。2010年版JISでは代替ページを許容している。
• 8.1.1 b) 一連のプロセス: フォームなどは一連の流れ全てがアクセシブルでなければならない。リンクを辿る手順は含まれない。
• 8.1.2 ウェブページ一式単位: ひとかたまりのコンテンツ、ウェブサイト。

ウェブページ一式の検査

1万ページのサイトを全て試験するのは現実的でないので、抜き取り検査を行うことができる。UWEMの1.2と同じ選択方法

ランダムと非ランダムの組み合わせがオススメ。確率による統計的な保証に加えて、重要ページは確実に検証できる。

問題が見つかった場合

• ランダムの場合 → 他にも問題が多数ある可能性があることを示唆している。その場所だけ直すという対応は不可。サンプリングをやり直して再試験
• 全試験、非ランダムの場合 → その場所を直せば良い
• いずれの場合も、試験で問題が発見されなくなるように対応する。ツールの自動チェックも併用すると良い。
• 試験をするコストそのものよりも、試験をパスするためのコストが問題。逆に言うと、「試験に通らない」というリスクを負ってでも試験するほどの自信があるということ

第三者がコンテンツを追加する場合

運営者以外の者がサイトにコンテンツを追加する場合、そのコンテンツがアクセシブルでない場合がある。たとえば配信される広告、Webメールのメール本文など。

• 運営者が修正できないコンテンツの場合のみ、除外して試験して良い。例: Webメールのテキストを事業者は書き直せない
• 運営者が修正できるコンテンツの場合、2営業日以内に修正する体制があれば除外して良い

• 相互に行き来できるなど、細かい要件がたくさんある(結構厳しい)
• 代替ページは最後の手段と考えるべき。たとえば、FlashならFlash自体をアクセシブルにする

依存していない技術

• 例: Flash でメニューを表示しているが、同じ機能をHTMLでも提供 (Flashに依存していない)
• 4つの基準を満たす場合(他のアクセシビリティを妨害しない)のみ除外して良い

試験の手順

• 技術を確認 (実装要件の確認)
• 実装チェックリストの作成 (どんな技術で実装するのか)
• 試験方法
  • 自動チェック AC: Automated Check
  • 自動発見 AF: Automated Find
  • 人が検証 HC: Human Check
• 7.2.1.1 の実装チェックリスト例
  • http://ciaj.or.jp/access/web/docs/jis2010-test-guidelines/icl-7.2.1.1.html (ciaj.or.jp)
  • http://ciaj.or.jp/access/web/docs/jis2010-test-guidelines/icl-index.html (ciaj.or.jp)

試験結果の表示

• 表示 = 文書化して人に見せる (公開とは限らない)
• 調達では、試験結果を添付すること
• ウェブでは、公開すること
• 文書化すると証拠が残る。発注者や第三者が追試できる

適合性評価

• JIS Q 17000
• 認証機関はないのでJISマークは使えない
• 自己適合宣言: 自ら評価して宣言する (JIS Q 1000 など)。ただしコンテンツ以外にも「品質責任者がいる」「品質管理部門の出荷検査」など厳しいハードルがある
• 「JIS X 8341-3:2010 対応度表記ガイドライン」
  • 適合
  • 準拠 (試験全て合格)
  • 一部準拠 (試験一部合格。満たせなかった理由と達成のスケジュールを追加表記)
  • 配慮し試験 (試験結果は問わない)
  • 配慮 (試験不要)
  • いずれも「JIS X 8341-3:2010 対応度表記ガイドラインの表記法による」と書いて表示すること

やさしいだけじゃダメ

• 障害者制度改革推進会議「3. 障害を理由とする差別の禁止」……合理的配慮を提供されないことが「障害を理由とする差別」に含まれる旨を規定
• ウェブにおける合理的配慮とは? どの程度の配慮をしていれば「差別していない」と言えるのか
• 合理的配慮 = 過度の負担がなければやるべき、JIS X 8341-3:2010 はそのものさし
• 訴訟リスク → 試験による確認が有効、「ちゃんとやっている」と証明できる
• 総務省 みんなの公共サイト運用モデル (www.soumu.go.jp)

試験を生かす

• 真面目な会社と不真面目な会社を峻別できる
• 良いコンテンツを正当に評価できる
• 水が低い方に流れているのをなんとか戻したい(特に公共調達)
• 民間の品質マーク?

実装方法について

• 1. 目標とする等級を決定し、達成基準を確認。AAAを目標にすることは推奨しない
• 2. 依存するWebコンテンツ技術を決定
  • 2004: JavaScriptオフでも同じ機能を使える必要がある
  • 2010: 依存する技術を決める、「JavaScriptに依存して達成」も可能。慎重に判断すべきはFlash、PDF

技術非依存

• 2004版: 図版やサンプルコードが豊富
• 2010版: サンプル何もなし。具体的なコード = 特定の技術に依存
• 2004年版の例 (HTML依存): 「表組みの要素をレイアウトのために使わないことが望ましい」
• 2010年版では、「7.1.3.2 正確な読み上げ順序」「7.2.4.3 フォーカス移動順」の達成基準を満たせば良い
• 技術に依存しなくなったが、抽象的で分かりにくい表現になってしまった。規格表だけでは具体的な実装方法は分からない (序文で「この規格には記載していない」と明言している)。箇条6.の注記でWCAG2.0の関連文書群を参照する形になっている。
• WCAG2.0も、本体はRecommendationだが、関連文書はnoteとなっている。Recommendationは標準化プロセス抜きに更新すべきでないが、noteは随時更新することができる

似た規定だが微妙に異なるもの

• 2004年版 5.3.h ナビゲーション読み飛ばし: 「読み飛ばせるようにすること」
• 2010年版 7.2.4.1 ブロックスキップ: 「通過できるメカニズムが利用可能」
• 具体的なメリット: キーボード又はキーボードインターフェイスだけを使用している利用者
• 「達成基準の意図」が重要。どんなユーザーにどのようなメリットがあるのか、各達成基準の要件を正しく理解することが重要となる。
• 例: フォーカスを受け取ると出現するナビゲーションリンク(富士通が実装しているもの)

独自に実装しても良い

• 6.3注記、WCAG2.0にない実装方法を用いても良い
• ただし、利用者にとって利用可能であることを確認しなければならない。仕様上は定められているが実装されていない機能は駄目

アクセシビリティ・サポーテッド

• 実際にブラウザや支援技術がサポートしている (対応している、実装されている) ということ
• 難題: テストファイルの制作工数
  • Techinques項目300以上、全てを理解する必要がある
  • ブラウザと支援技術の組み合わせ数は膨大、どこまで検証すれば良いのか。W3Cは目安すら示していない
• WAIC → jQueryと同じようなライブラリという発想
• テストファイルはW3Cも作成していないため、テスト項目はWAIC独自のもの

検証から分かったこと

• 全ての環境でサポートされる実装は意外に少ない
• 日本のスクリーンリーダーは機能面で劣る
• かといってコンテンツ制作側が頑張るのもどうなのか。ベンダー側の対応を期待しても良いのではないか
• 何をもってアクセシビリティ・サポーテッドとするのか。現在は初期設定でテストしているが、初期設定にこだわる必要はないのかもしれない

新しい達成基準

• 手話通訳 (AAA)
• 拡張した音声ガイド (AAA)……音声、副音声だけだは不足する場合、一時停止してナレーションを入れる (Flashによる実装のサンプルあり)。Flashに関しては「Flash Techniques for WCAG2.0 (www.w3.org)」が検討中。
• 複数のナビゲーション
• フォーカスを消さない
• 読解レベル、中学生にも分かるように(AAA) …… 漢字を簡単にするだけで良い、という話ではない。海外では readability test も行われている
• 音のコントラスト(AAA)

変わった基準

• 仕様への準拠 → Well-formed相当であれば良い
• ページタイトル → タイトルが固有であることを求めなくなった (とはいえ固有であることは推奨される)
• コントラストの具体化 → 4.5:1 など。リンクテキストのコントラストについての基準を見落としがちなので注意。アンダーラインを取る場合、リンクと他のテキストとのコントラストも3:1以上必要とされる
• リンクテキストと文脈 → 達成基準Aでは文脈も含めてリンク先の内容が分かれば良いとされた (「こちら」リンクを許容)。AAAではリンクテキスト単独で分からなければならない
• 画像化された文字 → 達成基準AAでは、テキストで表現できるならテキストにする。テキストでは意図通りにならない場合は画像にしても良い。達成基準AAAでは、ごくわずかな例外を除いて全てをテキストにする必要がある
• 収録済みの映像コンテンツ → A、AA、AAAで全て異なる基準。くわしくはWCAGを
• キーボード操作 → キーボードトラップ(例:Flashから出られない)、オンフォーカスでの遷移禁止
• 具体的な比較は付属書Cを参照

ウェブアクセシビリティ基盤委員会の紹介

JIS X 8341-3:2010 入門