7月17日に行われたAccSell Meetup #002 『アクセシビリティーで総選挙』に参加してきました、アクセシビリティのセミナーに来るのは久しぶりです。
早めにつくもエルタワーへの道順がわからずに若干迷子に・・・
地下から行くことを諦めて、
地上に出てGoogleMapを頼りにLタワーに。
時間がありすぎたので、
地下のサイゼリアで時間を潰してからセミナー会場に向かいました。
（エレベーターでガジラボ陣営と遭遇）
セッション1：ネット選挙とアクセシビリティ（中根雅文）
▼ネット選挙解禁ーー一般的に何がどう変わったのか
・「ネット選挙解禁」はあくまでも「ネットを使った選挙運動の解禁」
・候補者によるWeb、Twitterなどソーシャルメディア、
メールなどを使った選挙活動が可能
・有権者による選挙運動も基本的に可能、ただしメールは不可。
▼これまでの選挙におけるアクセシビリティの問題
有権者の情報収集
・公職選挙法で許されていた方法のみによる選挙運動が可能、
ポスター、はがき、政見放送、
街宣車、立ち会い演説会、その他特定の文書配布など
・報道を通じた情報
・選挙公報（ポスティング、新聞織り込み）
これまでの情報源の問題点
・選挙運動ー 比較的積極的に動かなければ情報を得られない
・報道（テレビ、新聞）ー視聴覚障碍者にとって充分アクセシビリティが高いとはいえない
・選挙公報ー 視覚障碍者に行き渡らない
（視覚障害者の団体に所属していると来る場合がある）
政見放送のアクセシビリティ
・障碍者の立候補ー 聴覚障碍者の立候補者の手話通訳を代理者が音声にすることはNGだった。
余談：投票のアクセシビリティ
・点字投票（投票所に行ければ）
→どこの投票所でも点字投票用の機器を準備している。
今後ネット投票が解禁されるとWebのアクセシビリティなどの問題が発展してくる
・代理投票
▼ネット選挙解禁でアクセシビリティはどう変わるのか、変わったのか
・Webサイトの活用ーー これまでの配布物にアクセスできない有権者の情報源が増える
（TwitterやFacebook）
・動画サイトの活用ーー 政見放送が見られない、
立ち会い演説会に行けない有権者の情報源が増える
▼ネット選挙解禁では変わらなかったこと
・選挙管理委員会が発行する選挙公報（PDF）のアクセシビリティは無いに等しい
（東京都選管の場合）→画像スキャンしただけのもの
・候補者が出したものをそのまま提携しなければならない、
という大原則が影響しているものと思われる
→法律上は漢字が間違っていようがそのまま乗せなければならない
・法改正、法解釈の変更が必要
余談：総務省の情報提供
・候補者名簿は総務省のサイトでも公開されている
・当初、画像をスキャンしただけのPDFだけが掲載された
・視覚障碍者などから声で透明テキストが付加されたバージョンも掲載された
・別バージョンにする必要があるのか？
▼今、求められること、今後求められること
・現状を補うために各政党、各候補者による
アクセシビリティを確保した情報提供がきわめて重要
・全ての国民に確実に情報が伝わるようにするための取り組みが求められる
・投票にいけない人を救済する仕組みのさらなる検討も必要
セッション2：［デモ］スクリーン・リーダーによるWebアクセス（中根雅文+植木真）
植木さんが出すお題を中根さんがスクリーンリーダーで解決する
（JWASでFirefox）
▼Googleで自民党のWebサイトを見つける
1.Googleサイトで検索エディットを探す
2.検索ボックスに入力（入力した文字を読み上げる）
3.ヘディングキーを読み上げてトップページを探す
4.参議院選挙のサイトを選択
5.一番下に自民党のサイトへのリンクがあり、到達。
▼各政党の政策を探しているというシュチュエーションで
「自民党はTPPをどうしようとしているのかの公約」を検索を使わずに見つける
1.見出しリスト一覧をJWASの機能で表示する（注目のキーワードにあたりをつける）
2.JAWSの検索機能でTPPを検索する
3.TPPのリンクを発見
4.TPPに関するリンク一覧は表示できたが、TPPの公約は見つけられない
5.TOPページに戻る
6.Newsを探してみる→見つけられない
7.アクセスランキングを探してみる
8.アクセスランキングの公約ページを見る（別サイト）
9.見出しでジャンプしながらサイト内を探す
10.JWASの見出しリスト機能を使う→同じ見出しばっかりある
11.拡大する世界戦略のページを見るがない。
12.それっぽいものへのリンクを探す
13.ページがダメなのでギブアップ
▼民主党のTPPのマニフェストを調べる
1.JWASの機能で見出し一覧を表示する→政策のところにあると想定する
2.参院選マニフェストを見つけ、読み始める。
3.PDFのダウンロードリンクを発見する（音声版マニフェストを掲載しているが必要？）
4.PDFを開く
（FirefoxのPDFリーダーは一部解釈が違うところがあるのでAcrobat Readerを使用）
※PDFの場合は本の体裁になっていることがあるので、
最初の数ページでどこになにがあるかあたりをつける。
セッション3：アクセシビリティLIVEチェック アナタならどうする？ワタクシならこうする！（植木真）
▼アクセシビリティのチェック方法
・JIS X 8341-3:2010の達成基準は「検証可能」であるとされている
-もとになっているWCAG2.0の”Testable”な達成基準をそのまま採用しているから
▼検証可能≠ツールでチェック可能
アクセシビリティのチェック方法
・ツールによるチェック
・人間によるマニュアルチェック
-目視による確認
-スクリーンリーダーによる検証
-キーボードだけでの操作確認 など
・ツール＋マニュアルチェック
▼今日使用するチェックツール
・Web Accessibility Toolbar 2012J Beta
・Web Developer
Firefox
Chorome
・カラーコントラストアナライザー 2013J
▼レポーティング例
ヒューリスティック評価のように問題点と改善点を表記してレポーティングする。
▼アクセシビリティライブチェック
普段どのようにチェックしているのかをデモします。
▼今日チェックする主なポイント
・HTMLのコーディング(7.4.1.1)
・言語指定(7.3.1.1、7.3.1.2)
・ページタイトル(7.2.4.2)
・見出しのマークアップ(7.1.3.1など)
・フォーム・コントロール(7.1.3.1など)
・画像の代替テキスト(7.1.1.1)
・リンクテキスト(7.2.4.4、7.2.4.9)
・色(7.1.4.1、7.1.4.3)
・キーボード関連(7.2.1.1など)
・動き・点滅・スクロール(7.2.2.2)
▼みんなの党をサンプルとしてチェック
植木さんがチェックする際は達成基準順ではなく、逆引きでチェックしている
▼HTMLのコーディング
４つのポイント
7.4.1.1 構文解析 [等級 A]
マークアップ言語を用いて実装されている コンテンツにおいては、
仕様で認められているものを除いて、要素には完全な開始タグ及び終了タグがあり、
要素は仕様に準じて入れ子になっており,要素には重複した属性がなく、
かつ、どのIDも一意的でなければならない。
※Firefoxのバリデーターを使う
※エラーを１つづつみて、４つのポイントの間違いを探していく
▼言語指定
7.3.11 ページの言語[等級A]
それぞれのウェブページの主たる自然言語がどの言語であるかを、
プログラムが解釈可能でなければならない。
7.3.1.2 部分的に用いられている言語 [等級 AA]
コンテンツの一節又は語句それぞれの自然言語がどの言語であるかを、
プログラムが解釈可能でなければならない。
ただし、固有名詞,技術用語,どの言語なのか不明な語句及び、
すぐ前後にあるテキストの言語の一部になっている単語又は語句は除く。
※FIrefoxのソースコードでlang属性があるかチェックする
※ページ自体を見て、英語ページがないか同様にチェックする。
▼ページタイトル
7.2.4.2 ページタイトル [等級 A]
ウェブページには,主題又は目的を説明した
タイトルがなければならない。
※若干主観が入る
※SEO的にも重要
▼見出しのマークアップ
7.1.3.1 情報及び関係性 [等級 A]
表現を通じて伝達されている情報,構造及び関係性は、
プログラムが解釈可能でなければならない。
プログラムが解釈可能にすることができないウェブコンテンツ技術を用いる場合は、
それらはテキストで提供されていなければならない。
7.2.4.1 ロックスキップ [等級 A]
複数のウェブページ上で繰り返されているコンテンツのブロックをスキップできる
メカニズムが利用可能でなければならない。
7.2.4.6 見出し及びラベル [等級AA]
見出し及びラベルは,主題又は目的を説明していなければならない。
7.2.4.10 セクション見出し [等級AAA]
セクションの見出しを用いてコンテンツを体系化していなければならない。
※Firefoxのデベロッパーツール「h要素を枠で囲う」を使ってチェック
※見出しの順番などにも留意（文書構造）
▼フォーム・コントロール
7.1.1.1 非テキストコンテンツ [等級A]
利用者に提示されるすべての非テキストコンテンツには、
同等の目的を果たす代替テキストを提供しなければならない。
ただし、次の場合は除く。
a) コントロール、入力非テキストコンテンツが、
コントロール又は利用者の入力を受け付けるものであるとき、
その目的を説明する識別名を提供している。
7.1.3.1 情報及び関係性 [等級 A]
表現を通じて伝達されている情報,構造及び関係性は、
プログラムが解釈可能でなければならない。
プログラムが解釈可能にすることができないウェブコンテンツ技術を用いる場合は、
それらはテキストで提供されていなければならない。
7.3.3.2 ラベル又は説明文 [等級A]
コンテンツが利用者の入力を要求する場合は、
入力箇所のラベル又は入力方法についての説明文を提供していなければならない。
7.4.1.2 プログラムが解釈可能な識別名、役割及び 設定可能な値 [等級A]
すべてのユーザインタフェースコンポーネント
(フォーム,リンク及びスクリプトが生成するコンポーネントなどを含む。)では、
識別名及び役割は、プログラムが解釈可能でなければならない。
また、利用者が設定可能なステータス、プロパティ及び値は、
プログラムが設定可能でなければならない。かつ、
ユーザエージェントがこれらの項目が変更された通知を受け取ることができなければならない。
7.2.4.6 見出し及びラベル [等級AA]
見出し及びラベルは,主題又は目的を説明していなければならない。
※フォームのコーディングは一石５鳥ぐらい
4/5→普通にフォームコントトールしてラベル付けしていれば問題ないはず
※firebugでソースを見て、フォームにタイトル属性・ラベルがないことをチェック
▼画像の代替テキスト
7.1.1.1 非テキストコンテンツ [等級A]
利用者に提示されるすべての非テキストコンテンツには、
同等の目的を果たす代替テキストを提供しなければならない。
ただし、次の場合は除く。
f) 装飾、整形及び非表示 非テキストコンテンツが、
装飾だけを目的にしているとき、見た目の整形のためだけに用いられているとき、
又は利用者に提供されるものではないとき、
支援技術が無視できるように実装されている。
※firefoxのツールバーでaltを表示させてチェック
基本的にはバナー画像の文字を入力してあるかチェック
※Webデベロッパーツールでソースを確認
→候補者の顔写真と名前に２カ所にリンクがある、
スクリーンリーダーだと２回読み上げられるので１つに纏めるのがベストプラクティス
※ヘッダーにalt属性がまったくない
→cssで背景として作成されている
→Windows7のハイコントラストモードにしてチェックしてみると、
ナビゲーションが真っ黒になって見えなくなってしまう。
※cssで画像置換が流行っていたこともがあるが、
情報を伝える画像についてはimg要素を使う。
▼リンクテキスト
7.2.4.4 文脈におけるリンクの目的 [等級 A]
それぞれのリンクの目的が、リンクのテキストだけから、
又はプログラムが解釈可能なリンクの文脈を、
リンクのテキストと合わせたものから解釈できなければならない。
ただし、リンクの目的が一般的にみて利用者にとってあいまい（曖昧）な場合は除く。
7.2.4.9 リンクの目的 [等級AAA]
それぞれのリンクの目的がリンクのテキストだけから特定できるメカニズムが
利用可能でなければならない。
ただし、リンクの目的が一般的にみて利用者にとってあいまい (曖昧)な場合は除く。
※IEのツールバーで「リンクの一覧を出す」を使って、
文言だけでリンク先がわかるかチェックする
→「こちら」とか「RSS」が複数ある場合とか。
▼色
7.1.4.1 色の使用 [等級A]
情報を伝える、何が起こるか若しくは何が起きたかを示す、利用者の反応を促す、
又は視覚的な要素を区別する視覚的な手段として、色だけを使用してはならない。
7.1.4.3 最低限のコントラスト [等級AA]
テキスト及び画像化された文字の視覚的な表現には、
少なくとも4.5:1 のコントラスト比がなければならない。ただし、次の場合は除く。
a) 大きな文字サイズの大きなテキスト及びサイズの大きな画像化された文字には、
少なくとも3:1 のコントラスト比がある。
b)附随的 テキスト又は画像化された文字において、
次の場合はコントラストの要件は該当しない。
アクティブではないユーザインタフェースコンポーネントの一部である、
装飾だけを目的にしている、だれ(誰)も視覚的 に確認できない、
又は重要な他の視覚的なコンテンツを含む写真の一部分である。
c) ロゴタイプ ロゴ又はブランド名の一部である文字には、コントラストの要件はない。
※カラーコントラストアナライザーを使う
▼キーボード関連
7.2.1.1 キーボード操作 [等級 A]
コンテンツのすべての機能は、
個々のキーストロークに特定のタイミングを要することなく、
キーボードインタフェースを通じて操作可能でなければならない。
ただし、その根本的な機能が利用者の動作による始点から終点まで続く
一連の軌跡に依存して実現されている場合は除く。
7.2.4.3 フォーカス順序 [等級 A]
ウェブページが順番にナビゲートできて、
そのナビゲーション順序が意味又は操作性に影響を及ぼす場合、
フォーカス可能なコンポーネントは意味及び操作性を保持した順序で、
フォーカスを受け取らなければならない。
7.3.2.1 オンフォーカス [等級 A]
いずれのコンポーネントも、
フォーカスを受け取ったときに状況の変化を引き起こしてはならない。
7.2.4.7 視覚的に認識可能なフォーカス [等級 AA]
キーボード操作が可能なユーザインタフェースには、
キーボードフォーカスの状態が視覚的に認識できる操作モードがなければならない。
※Firefoxでタブキーを順番に押していって、
ドットのインジケーターが表示されているか、
変な挙動がないか、順番などをチェック
▼動き・点滅・スクロール
7.2.2.2 一時停止,停止及び非表示
動きのある、点滅している、スクロールする、
又は自動更新する情報に対しては、
次のすべての事項を満たしていなければならない。
a) 動き、点滅及びスクロール、動きのある、点滅している、
又はスクロールしている情報が、自動的に開始し、5秒よりも長く継続し、
かつ、その他のコンテンツと並行して提示される場合、
利用者がそれらを一時停止、停止又は非表示にすることのできるメカニズムがある。
ただし、その動き、点滅又はスクロールが必要不可欠な動作の一部である場合は除く。
※動きを一時停止できるようになっているかチェック
例：日立製作所→一時停止ボタンを付けている
▼最後に
・スクリーンリーダーは意外と使わない
ただしARIA的なUI（プリケーション化しているサイト）は要チェック
（ポップアップ、スライダー、アコーディオン）
・出来の悪いサイトほど、時間がかかる
・ARIA的なUIも時間がかかる・・・
・今後はツールも出てくるのかしら？
・ユーザーテストも実施できれば理想
・JIS対応の試験には必須ではない
Q&Aタイム
Q1:モバイルのアクセシビリティは？
A1:スマートフォンなどのフリックのアクションなどが、
ボイスオーバーで使えるか気をつける必要がある。
現状ではまだまだノウハウはたまっていない。
例：イギリスのBBCがモバイルのアクセシビリティガイドラインを公開している。
http://www.bbc.co.uk/blogs/internet/posts/Accessibility-Mobile-Apps
Q2: 達成基準3.15にある「G86：中等教育レベルを超えた読解力」
を評価する方法はどのようにチェックすればよいのでしょうか？
A2:チェックできるアルゴリズムがないので検証対象に入れない。
（英語圏だとボキャブラリーなどがあるらしい）
Q3:達成基準3.15を満たすことのできる実装方法について。
「次の実装方法のどれか１つを用いて」と条件付けがされ、
複数の実装方法が提示されている時はどれか一つを満たせばよいとわかりますが、
何も条件がなく、複数の実装方法が提示されている場合がありますが、
その場合提示された全ての実装方法をクリアしないと
達成基準を満たしたことにならないのでしょうか？
A3:WCAG2.0に掲載されているものはあくまでも例。
達成基準を満たしているかをチェックし、最適なものを使う。
例：4.1.1
1~4までおススメ順番に並んでいる
Q4:フォントサイズの指定にremを採用したいと考えています。
rem指定に関しては現時点で達成基準を満たす実装方法に、
記載されていないかと思いますが、
実装方法になりやり方が全て達成基準を満たしていないことになってしまうのでしょうか。
A4:remを使って達成基準を満たせればOK。手段に制限はない。
Q5:Youtubeとかの動画などのコントロールにフォーカスしたときに、
フォーカスが外れない場合がある。
A5:昔はあったが今は少なくなってきた。ある場合は適当にマウスでクリックする。
■雑感
アクセシビリティはWebディレクターとしては絶対押さえておかないといけないとは思うのですが、なかなか集中して学ぶ機会と実践する機会がないので、どうしていけばいいのか迷うところですねー。
コメント