第1回「京都でウェブアクセシビリティたいらげ会」の報告

2017年06月12日 更新 | タグ: アクセシビリティ, 技術情報

このページについて

あいさつ

本日の勉強会について少しだけ説明させていただきます。

初心者もおいでなので、勉強会の進め方にくわえて、ウェブアクセシビリティを勉強することの意味について簡単に触れさせていただきます。

今日はウェブアクセシビリティについて勉強したいと思っています。

高齢者および障害者を含むすべての利用者がウェブサイトを利用できるようにするには、どのようにウェブサイトを構築すべきか、あるいはどのように更新していくべきか、という勉強です。

深く勉強をしていくと、必ずしもこのひとたちだけが対象ではないと思うようになってくるのですが、高齢者、障害者というのは、ウェブ普及以前とウェブ普及以降で、情報の取得のしやすさが大きく変わった人たちです。

ウェブ普及以前は、他の人に頼らなければできなかった情報の取得や発信を、ウェブがあるおかげで、他の人に頼らずにできるようになった人たちです。あまり立ち止まりませんが、「頼ることが悪い」というわけでは、くれぐれもありません。

情報の流通の場面には、「情報を提供する側」と「情報を取得する側」があり、どちらも目的のためにある程度の知識が必要です。

しかし、「情報を提供する側」の知識と配慮が足らないと、「情報を取得する側」の負担はどんどん増えてゆきます。

今日、この場にいる方々は、みなさん「情報を提供する側」に関わる方々です。

どのように情報を提供したらいいのかを一緒に学ぶことで、その学習の成果から、恩恵を受ける人たちを飛躍的に増やすことができます。

しかし、みなさんの周りに、豊富に高齢者やあらゆる種類の障害者がいて、いつも意見やフィードバックをくれるということもないと思います。

そこで日本工業規格であるJIS X 8341-3:2016です。

JISには、ウェブアクセシビリティを確保するために気をつけるべきことが書かれています。

詳しい話は避けますが、JISは、ウェブ関連技術の標準化推進団体W3Cの分科会WAIが作ったWCAGというガイドラインとほぼ同じ内容です。

ので、JISを読むというのは、WCAGを読むのとほぼ同じ意味です。今日も、「JISたいらげ」とは言っていますが、WCAG2.0の解説書を読んでいきたいと思っています。

WCAG2.0の解説書はJIS X 8341-3の原案作成や普及活動を行っているWAICという団体が、英語から翻訳してくれた資料です。今日、ここには、翻訳作業に関わっておいでの方もいらっしゃるので、たいへん心強いと思っています。

今日の進め方ですが、あと少しだけ柴田が喋った後は、原則、ガイドライン、達成基準を全員で順番に読んでいきたいと思います。

一行読んでは、わからないところを挙手なりなんなりでアピールしてください。アピールが恥ずかしい人は、あとから聞くようにメモをとってもらってもいいです。

質問や、自分なりのまとめを聞いてほしい人は、原則、いつでも発言できるとしたいと思います。この手の発言の際、質問や発言のレベルは問わないので、自分なりに理解を深めていきましょう。

進め方についてもう一つ。JISは、解説がほかの達成基準に依存していることがあります。こういう場合は、文脈を見失わないために、今回はとりあえず、依存されている側の達成基準には深入りしないこととします。

いま「原則」「ガイドライン」「達成基準」という言葉を使いましたが、これに関連して、お手元の紙をご覧ください。

JISには、4つの原則、12のガイドライン、61の達成基準があります。達成基準はガイドラインでまとめられ、ガイドラインは原則でまとめられています。

あと、これだけは別途あとで触れますが、1つの「非干渉」が「原則1 知覚可能」に、3つの「非干渉」が「原則2 操作可能」のなかにあります。

「WCAG 2.0解説書 イントロダクション」に4つの原則がまとまっています。

今日のたいらげ会では、このページの「アクセシビリティの4つの原則を理解する」の4つの原則を読んだ後、「ガイドライン 1.1 を理解する」を読み、「非テキストコンテンツ 達成基準 1.1.1 を理解する」までいくくらいを目標にしたいと思います。

先ほども申しましたように、解説書はWCAG 2.0の翻訳です。原文は英語です。わかりやすさと正確さは、共存が難しいことがあるのですが、解説書は、より正確さを重視しているように見受けられ、それも理解のハードルを上げている一側面かと思います。

なんだか難しいこと書いてあるな、と思った時には、あえて英語の方をちらと見てみるのも有効です。

最後に、本日の成果物は、ウェブに公開しようと考えています。あまり成果物作成に時間をかけると、成果物公開が難しくなってしまう恐れがあるため、ほぼリアルタイムでメモを取ってゆきます。

メモの対象は、みなさんの発言をまとめたものになると思います。

そのメモの確認用に録音することをお許しください。成果物の公開や共有の仕方について、なにかしら、ご意見、ご要望等ございましたら、柴田に言ってください。

それでは、「原則1 知覚可能」からはじめましょう。

たいらげ会抄録

以下、勉強会の抄録です。流れは

1. 読む
2. わからない言葉を確認する
3. 簡単にまとめる

というかんじでした。

引用文中の強調箇所は、読んでいて引っかかったところです。

「アクセシビリティの4つの原則を理解する」から「原則1 知覚可能」

アクセシビリティの4つの原則を理解する

ガイドライン及び達成基準は、誰もがウェブコンテンツにアクセスして利用するために必要な土台となる、次の4つの原則を中心に構成されている。ウェブを利用したい誰もが、コンテンツに求めるのは次のことである

原則1 知覚可能 － 情報及びユーザーインタフェース･コンポーネントは、利用者が知覚できる方法で利用者に提示可能でなければならない。

これは、利用者が提示されている情報を知覚できなければならないことを意味する（利用者の感覚すべてに対して知覚できないものであってはならない）。

http://waic.jp/docs/UNDERSTANDING-WCAG20/intro.html#introduction-fourprincs-head

キーワード

知覚

あることがわかる。存在を認識できる

ユーザーインタフェイス

人が触れるもの。人とコンピュータの間にあるもの

コンポーネント

部品

利用者の感覚すべて

知覚どれかにひっかからないといけない。目が見えないなら音で、耳が聞こえないなら目で、両方ダメなら触覚で、など。

まとめ

• 情報の存在をわかることが大事。

「原則2　操作可能」

原則2　操作可能 － ユーザーインタフェース･コンポーネント及びナビゲーションは操作可能でなければならない。

これは、利用者がインタフェースを操作できなければならないことを意味する（インタフェースが、利用者の実行できないインタラクションを要求してはならない）。

http://waic.jp/docs/UNDERSTANDING-WCAG20/intro.html#introduction-fourprincs-head

キーワード

「及びナビゲーション」ってなに？

そもそも「ユーザーインタフェース･コンポーネント」にふくまれているのでは？ 物理的デバイス（「キー」などを含む）を含むのでは？ roleでは？ サイトのグローバルナビゲーションのことでは？……というわけで、オープンエンド。

インタラクション

inter+action。操作をすると機器が反応をする

利用者が実行できないインタラクション

入力せよ、選択せよという時に、それらができないようにしない。「マウスでクリック」をマウスでしか使えない、というのもそう。できないかもしれない操作を要求してはいけない。

まとめ

• 操作できないといけませんよ。

「原則3　理解可能」

原則3　理解可能 － 情報及びユーザーインタフェースの操作は理解可能でなければならない。

これは、利用者がユーザーインタフェースの操作と情報とを理解できなければならないことを意味する（コンテンツ又は操作が、理解できないものであってはならない）。

http://waic.jp/docs/UNDERSTANDING-WCAG20/intro.html#introduction-fourprincs-head

まとめ

• 情報の中身と操作方法が理解できないといけない。難しすぎてもダメ。
• アラビア語で書いてあったりすると、文字を「知覚」できても「理解」できないというのが例のひとつ。
• 素人にとっては、冒頭柴田の挨拶の

  JISは、ウェブ関連技術の標準化推進団体W3Cの分科会WAIが作ったWCAGというガイドラインとほぼ同じ内容です。

  は、知覚できても理解できない。

「原則4 堅牢性」

原則4 堅牢性 - コンテンツは、支援技術を含む様々なユーザーエージェントが確実に解釈できるように十分に堅牢でなければならない。

これは、利用者が技術の進歩に応じてコンテンツにアクセスできなければならないことを意味する（技術やユーザーエージェントの進化していったとしても、コンテンツはアクセシブルなままであるべきである）。

http://waic.jp/docs/UNDERSTANDING-WCAG20/intro.html#introduction-fourprincs-head

キーワード

支援技術

とりあえず「支援技術」という言葉が出てきたら、不正確ですが、慣れないうちはいったん「スクリーンリーダ」や「ピンディスプレイ」と読み替えると読みやすい

ユーザーエージェント

とりあえず「ブラウザ」で読み替えましょう。

まとめ

• まず「ブラウザで解釈できないとダメですよ」程度で理解しましょう。また「支援技術」がないと困る人たちを忘れてはダメですよ。
• ユーザエージェントが変わってしまうと、アクセスできないというような作りにしてはいけない。
• たとえばスペース区切りで表組みに見えるものを作った。スマートフォンの時代になって、画面幅が狭くなったら、意図しないところで改行が起こって、表組みに見えなくなった……とか。
• もちろん特定のブラウザ用のハックを使って、ほかブラウザで見られない、などというのも堅牢性の問題。

意見

「堅牢性」って、不思議な言葉。英語ではなんというの？ 「robust」。機密性やセキュリティを思い浮かべちゃう。でも、これは歴史的経緯でこうなっている。2.0翻訳当初はロバストってそのまま言ってた。

「テキストによる代替: ガイドライン 1.1 を理解する」

ガイドライン 1.1: すべての非テキストコンテンツには、拡大印刷、点字、音声、シンボル、平易な言葉などの利用者が必要とする形式に変換できるように、テキストによる代替を提供すること。

http://waic.jp/docs/UNDERSTANDING-WCAG20/text-equiv.html

まとめ

• 非テキストコンテンツ（動画、画像、音声とか）は、原則、テキストで代替できるようにすること

「ガイドライン 1.1の意図」

ガイドライン 1.1の意図

このガイドラインの目的は、すべての非テキストコンテンツが、テキストでも利用可能であるようにすることである。「テキスト」とは、画像化された文字ではなく、電子テキストを指す。電子テキストには、表現中立であるという類を見ない利点がある。すなわち、テキストは、視覚的、聴覚的、触覚的、又は任意の組み合あわせによってレンダリング可能だということである。結果として、電子テキストでレンダリングされる情報は、利用者のニーズを最もよく満たすどのような形態であれ提供可能なのである。テキストはまた、容易に拡大する、読字障害のある利用者にとっても理解しやすい形で音声読み上げをする、利用者のニーズを最もよく満たす触覚形式でレンダリング可能である。

http://waic.jp/docs/UNDERSTANDING-WCAG20/text-equiv.html

キーワード

レンダリング

およそ出力」を指す

触覚

とりあえず点字・ピンディスプレイ。「犬」という言葉は、犬の絵（場合によっては触ることができる）にできる例もある

まとめ

• テキストは可用性が高い。
• テキスト万歳。

「ガイドライン 1.1の意図 注記」

注記: コンテンツを記号に変換することは、発達障害や発話理解困難のある利用者のために図記号に変換することを含むが、記号はこういった用途に限定されない。

http://waic.jp/docs/UNDERSTANDING-WCAG20/text-equiv.html

キーワード

記号

先出の言葉では「シンボル」なので、統一されていた方が良さそう。

まとめ

• さきほどの「犬」の例に限らないよ、という意味。

「ガイドライン 1.1 の参考にすべき達成方法」

ガイドライン 1.1 の参考にすべき達成方法 (特定の達成基準に特有ではない達成方法)

このガイドラインにある各達成基準を満たすための達成方法は、この後に達成基準ごとに挙げられている。しかし、このガイドラインに対処するための達成方法がどの達成基準にも該当しない場合は、ここで挙げている。そういった達成方法は、どの達成基準を満たす上でも必須ではないし、十分でもないが、ウェブコンテンツの種類によってはより多くの利用者にとってよりアクセシブルにすることができるものである。

http://waic.jp/docs/UNDERSTANDING-WCAG20/text-equiv.html

まとめ

• 以降の達成基準でいろいろの場合が想定されているが、達成基準では想定されていない事例もあり得る。そういう場合は、1.1で説明されている対処を原則的に対応するようにしてくださいね。

ここで、Github登場！ もんどさんの翻訳見直ししたてのホヤホヤの1.1.1（このリンクはgithubへのリンクですが、以下、出典リンクはWAICにリンクします）を読みました。

1.1.1を読む前に、WCAGにはA、AA、AAAがあるという話がありました。とりあえず時代工房で営業用に話しているレトリック。

A

これを満たさないと、コンテンツに全くアクセスできなくなる人がいる。確実に達成しましょうね。

AA

これを満たすと、コンテンツを利用できる人が増える。なるべく達成しましょう

AAA

より快適になるが、達成が難しいものも含まれていますよ。

「1.1.1 非テキストコンテンツ」

1.1.1 非テキストコンテンツ: 利用者に提示されるすべての非テキストコンテンツには、同等の目的を果たすテキストによる代替が提供されている。ただし、次の場合は除く: (レベル A)

http://waic.jp/docs/UNDERSTANDING-WCAG20/text-equiv-all.html

まとめ

• 非テキストコンテンツについては代替テキストが必要。でも例外もあるので、それを読んでね。

「1.1.1 非テキストコンテンツ コントロール、入力」

コントロール、入力: 非テキストコンテンツが、コントロール又は利用者の入力を受け付けるものであるとき、その目的を説明する名前 (name) を提供している。 (コントロール及び利用者の入力を受け入れるコンテンツに関するその他の要件は、ガイドライン 4.1を参照。)

http://waic.jp/docs/UNDERSTANDING-WCAG20/text-equiv-all.html

理解のために、ちょっと先回り。同じページのちょっとしたにあるコレ。

コントロール又は利用者の入力を受け入れる非テキストコンテンツ、例えば、送信ボタンとして用いられる画像、イメージマップ、又は複雑なアニメーションなどの場合、名前は、少なくともその非テキストコンテンツが何で、なぜそこにあるのかを認識できるように、その非テキストコンテンツの目的を説明するために提供される。

http://waic.jp/docs/UNDERSTANDING-WCAG20/text-equiv-all.html#text-equiv-all-examples-head

キーワード

名前 (name)

たとえばlabel要素なんかnameと言える。inputのname属性のことではない。

まとめ

• 少なくとも「何がそこにあるのか」がわかれば（「知覚」できれば）、利用できなくても、次の一歩に繋がる。
• 実装方法については、達成方法集を読むと良い。
• Google Mapはiframeで提供されている時、title属性を使える。そこに「Google Map。インタラクティブな地図」とすれば「名前」と言える。

「1.1.1 非テキストコンテンツ 時間依存メディア」

時間依存メディア: 非テキストコンテンツが、時間に依存したメディアであるとき、テキストによる代替は、少なくとも、その非テキストコンテンツを識別できる説明を提供している。 (メディアに関するその他の要件は、ガイドライン 1.2を参照。)

http://waic.jp/docs/UNDERSTANDING-WCAG20/text-equiv-all.html

キーワード

時間依存メディア

音声、動画、スライドショー（カルーセル）など。

まとめ

• 最低限、これらも「そこになにがあるのか」を明示すること。「XXについての動画がある」と書くこと。
• よりしっかりした対応は1.2を参照すること。

「1.1.1 非テキストコンテンツ テスト」

テスト: 非テキストコンテンツが、テキストで提示されると無効になるテスト又は演習のとき、テキストによる代替は、少なくともその非テキストコンテンツを識別できる説明を提供している。

http://waic.jp/docs/UNDERSTANDING-WCAG20/text-equiv-all.html

キーワード

テスト

ほんとうに学校のテストだと思って良い。

まとめ

• altなど代替テキストで答えがわかっちゃうような代替テキストは用意しなくて良い。
• たとえば「おしべ」「めしべ」の画像がある。「どちらがおしべかを選ぶ」ときに代替テキストにそれぞれの名称を書いてしまうと、テストが破綻するので、「テスト用の画像」があることがわかるようにするとよい。

「1.1.1 非テキストコンテンツ 感覚的」

感覚的: 非テキストコンテンツが、特定の感覚的体験を創り出すことを主に意図しているとき、テキストによる代替は、少なくともその非テキストコンテンツを識別できる説明を提供している。

http://waic.jp/docs/UNDERSTANDING-WCAG20/text-equiv-all.html

まとめ

• たとえば「だまし絵」の感覚の体験はテキストによる代替で提供できないので、「だまし絵」がある、ということをわかるようにする。
• オーケストラの演奏の体験も耳の聞こえない人は体験できないし、ピカソの絵があるとして、それも目の見えない人には体験できない。こういう場合も、どういったコンテンツがそこにあるのかを説明するようにする。
• こういうときには代替テキストは仕事が難しい。

「1.1.1 非テキストコンテンツ CAPTCHA」

CAPTCHA: 非テキストコンテンツが、コンピュータではなく人間がコンテンツにアクセスしていることを確認する目的で用いられているとき、テキストによる代替は、その非テキストコンテンツの目的を特定し、説明している。なおかつ、他の感覚による知覚に対応して出力する CAPTCHA の代替形式を提供することで、様々な障害に対応している。

http://waic.jp/docs/UNDERSTANDING-WCAG20/text-equiv-all.html

まとめ

• CAPTCHAの代替テキストを提供してしまうと、CAPTCHAでなくなってしまうので、CAPTCHAだということを提示しておくこと。
• 単一のCAPTCHAでなく、複数のCAPTCHAを用意したりすること。

「1.1.1 非テキストコンテンツ 装飾、整形、非表示」

装飾、整形、非表示: 非テキストコンテンツが、純粋な装飾である、見た目の整形のためだけに用いられている、又は利用者に提供されるものではないとき、支援技術が無視できるように実装されている。

http://waic.jp/docs/UNDERSTANDING-WCAG20/text-equiv-all.html

まとめ

• ただただ飾りである非テキストコンテンツは支援技術が無視できるようにする。
• spacer画像や枠画像を読み上げたりすると大変煩わしい。
• そもそもこういったものはCSSで提供すべき。
• こういったものでもalt談義は尽きない。
• altをつけないと、ファイル名を読む環境もあったりして、altはあったほうがよい。

「1.1.1 非テキストコンテンツ この達成基準の意図 1」

この達成基準の意図

この達成基準の意図は、非テキストコンテンツにより伝達される情報を、テキストによる代替を用いることによってアクセシブルにすることである。

http://waic.jp/docs/UNDERSTANDING-WCAG20/text-equiv-all.html#text-equiv-all-intent-head

まとめ

• ここはほぼ同語反復。

「1.1.1 非テキストコンテンツ この達成基準の意図 2」

テキストによる代替は、利用者の要求に合わせてあらゆる感覚モダリティ (例えば、視覚、聴覚、又は触覚) を通じてレンダリング可能なので、情報をアクセシブルにするための最も重要な方法である。

http://waic.jp/docs/UNDERSTANDING-WCAG20/text-equiv-all.html#text-equiv-all-intent-head

キーワード

モダリティ

理解の手口の一つは「ニュアンス」と読み替える。あるいは「感覚モダリティ」と出てきたら、だいたい「感覚装置」くらいで読み替えるとひっかかりづらい。

レンダリング

他の箇所では「描画」という表現になっていることもあった。でも描画は視覚的なモダリティへのかたよりがあるので、より汎用性を高めるため、レンダリングとなっている。たとえば「聴覚向けには音声としてレンダリングする」。「表現」や「出力」という了解でもいいかも。

まとめ

• テキストによる代替は、汎用性が高い、素晴らしい方法だよ、ということ。

「1.1.1 非テキストコンテンツ この達成基準の意図 3」

テキストによる代替を提供することにより、情報を様々なユーザエージェントによって様々な方法でレンダリングすることを可能にする。

http://waic.jp/docs/UNDERSTANDING-WCAG20/text-equiv-all.html#text-equiv-all-intent-head

まとめ

• テキストで提供することで、いろんなブラウザであったり、スマートフォンだったりで利用できるようになる。

「1.1.1 非テキストコンテンツ この達成基準の意図 4」

例えば、写真を見ることのできない利用者は、合成音声を用いてテキストによる代替を読み上げさせることができる。また、音声ファイルを聞くことができない利用者は、テキストによる代替を読むことができるようにそのテキストによる代替を表示させることができる。将来的には、テキストによる代替は、情報を手話又は同じ言語のより単純な形式に、より容易に変換することも可能になるだろう。

http://waic.jp/docs/UNDERSTANDING-WCAG20/text-equiv-all.html#text-equiv-all-intent-head

まとめ

• 概ね読んで字の如しですが、ここでNHKでやっていたの手話実験の意見公募の話。「テキストから手話」という流れの可能性を感じさせる事例。

• 気象情報手話CG
• 5.1　人にやさしい情報提示技術 - NHK放送技術研究所

「1.1.1 非テキストコンテンツ CAPTCHA に関する注記 1」

CAPTCHA に関する注記

CAPTCHA は、アクセシビリティのコミュニティにおいて、議論の的になるトピックの一つである。Inaccessibility of CAPTCHA で説明されているように、CAPTCHA はもともと、機械的な自動処理を排除しようとして、人間の能力の効果を追求するものである。特定の障害のある利用者は、あらゆる種類の CAPTCHA が解釈できないであろう。

http://waic.jp/docs/UNDERSTANDING-WCAG20/text-equiv-all.html#text-equiv-all-intent-head

まとめ

• 画像認証などはそもそも人間かどうかを判別するもの。でも、支援技術なしでアクセスできない人にとっては、こういった仕組みを有効活用できない。

「1.1.1 非テキストコンテンツ CAPTCHA に関する注記 2」

しかし、CAPTCHA は広く使われており、WCAG ワーキンググループは、もし CAPTCHA が完全に禁止されてしまったら、ウェブサイトは CAPTCHA の使用を断念するのではなく、WCAG に適合しないことを選択するだろうと考える。

http://waic.jp/docs/UNDERSTANDING-WCAG20/text-equiv-all.html#text-equiv-all-intent-head

まとめ

• CAPTCHAを禁止することで、WCAGよりもCAPTCHAを選ばれちゃうと、困る。

「1.1.1 非テキストコンテンツ CAPTCHA に関する注記 2」

というわけで、すくなくとも以下の要件を満たすことを推奨する。

CAPTCHA を2つよりも多くのモダリティで提供する

http://waic.jp/docs/UNDERSTANDING-WCAG20/text-equiv-all.html#text-equiv-all-intent-head

まとめ

• 複数のCAPTCHA。視覚、音声など、複数作ること。2つより多くって、三つ目ってどんなの？ たとえばキーボードを特定の順番で押すという（key downをとる）とか、マウスの軌跡を見るとか。
• 「マウスの軌跡って、どうやるの」でしばらく議論。ここらへんかしら。
  • 人間とボットを「ワンクリック」で判別できるグーグルの新技術
  • reCAPTCHA-Google検索
  Googleはマウストラッキングだけじゃなくって、複数の情報を加味しているみたいです。

「1.1.1 非テキストコンテンツ CAPTCHA に関する注記 3」

CAPTCHA を回避できる、カスタマーサービスの担当者へのアクセスを提供する

http://waic.jp/docs/UNDERSTANDING-WCAG20/text-equiv-all.html#text-equiv-all-intent-head

まとめ

• CAPTCHAをつかわない1。電話とかしたら良い、とする。

「1.1.1 非テキストコンテンツ CAPTCHA に関する注記 4」

認証された利用者には CAPTCHA を要求しない

http://waic.jp/docs/UNDERSTANDING-WCAG20/text-equiv-all.html#text-equiv-all-intent-head

まとめ

• CAPTCHAをつかわない2。IPなどであらかじめ許可しちゃう。

「1.1.1 非テキストコンテンツ 以下に挙げる状況の他のどれにも該当しない非テキストコンテンツ 1」

下記のその他の状況のいずれも適用されない非テキストコンテンツ (例：グラフ、図表、録音した音声、写真、及びアニメーション) の場合、テキストによる代替はあらゆる感覚モダリティ (例えば、視覚、聴覚、又は触覚) によってレンダリング可能な形態で同じ情報を入手可能にできる。

http://waic.jp/docs/UNDERSTANDING-WCAG20/text-equiv-all.html#text-equiv-all-intent-head

まとめ

• 「下記のその他」がどこを指すのかでしばらく止まってしまいました。けっきょくもんどさんもいたので、「以下の段落」だと解釈。もんどさん補足はもう一つ「例外以外はテキスト代替をしてね、ということをまどろっこしく書いている」とも。
• グラフなんかどうしたらいいの？ まずは、「何のグラフなのか」を書く。さらにもうちょっとaltを丁寧にするのであれば、グラフを見た印象を書くのも良い。グラフはそもそも「視覚的に」わかりやすくするものだから、視覚的印象を書くのも間違いではないのでは。「お米の収穫高のグラフです。年々減少しています」など。
• グラフだとわかれば、人に尋ねることもできる。だから、まずグラフ（非テキストコンテンツ）があることがわかるのが、はじめの一歩。

「1.1.1 非テキストコンテンツ 以下に挙げる状況の他のどれにも該当しない非テキストコンテンツ 2」

短い、及び長いテキストによる代替は、非テキストコンテンツにある情報を伝達するのに必要に応じて用いられる。

http://waic.jp/docs/UNDERSTANDING-WCAG20/text-equiv-all.html#text-equiv-all-intent-head

まとめ

• 適切な代替テキストをつけましょう、程度ですすみます。

「1.1.1 非テキストコンテンツ 以下に挙げる状況の他のどれにも該当しない非テキストコンテンツ 3」

収録済の音声しか含まないファイル及び収録済の映像しか含まないファイルは、ここで扱われている。ライブの音声しか含まないファイル及びライブの映像しか含まないファイルは、以下で扱われている (この段落の 3 つ後の段落を参照のこと)。

http://waic.jp/docs/UNDERSTANDING-WCAG20/text-equiv-all.html#text-equiv-all-intent-head

キーワード

収録済み

現在進行形の「ライブじゃない」ということ。

XXしか含まない

「映像しか含まない」は、アニメーションGIFなんかが理解の助けになる。

まとめ

• ちょっと文章がわかりづらいけど、「ここで」は、「この段落で」くらいで読み、要は、代替テキストを用意してね、ということか。

「コントロール又は利用者の入力を受け入れる非テキストコンテンツ」は、先回りして読んでいるので飛ばしました。

「1.1.1 非テキストコンテンツ 時間依存のメディアである非テキストコンテンツ」

時間依存のメディアである非テキストコンテンツは、1.2 によりアクセシブルになる。しかし、利用者がそのメディアを利用したいことがもしあれば、利用者がどんな動作をするかを解決できるので、利用者がページ上でそのメディアに出会ったときに、そのメディアが何であるかを知ることが重要である。したがって、時間依存のメディアを説明する、及び／又はそのメディアのタイトルを示すテキストによる代替を提供する。

http://waic.jp/docs/UNDERSTANDING-WCAG20/text-equiv-all.html#text-equiv-all-intent-head

まとめ

• まず時間依存のメディアに関しては、1.1.1としては、何者であるかを明示することを求める。より詳しくは、1.2を参照すること。

「1.1.1 非テキストコンテンツ ライブの音声しか含まないコンテンツ及びライブの映像しか含まないコンテンツ」

ライブの音声しか含まないコンテンツ及びライブの映像しか含まないコンテンツの場合、それらと同じ情報を示すテキストによる代替を提供することは、はるかに困難なこともありうる。このようなタイプの非テキストコンテンツに対しては、テキストによる代替は説明ラベルを提供する。

http://waic.jp/docs/UNDERSTANDING-WCAG20/text-equiv-all.html#text-equiv-all-intent-head

まとめ

• 現在進行形の出来事について書き起こしテキストを用意するのは難しいので、やはり「なんのライブ音声なのか」を明示することをもとめている。

「1.1.1 非テキストコンテンツ テスト又は演習」

テスト又は演習が、部分的又は全体的に非テキストの形式で提示されなければならないことがある。……

http://waic.jp/docs/UNDERSTANDING-WCAG20/text-equiv-all.html#text-equiv-all-intent-head

まとめ

• わりと読んで字の如し。

「1.1.1 非テキストコンテンツ 特定の感覚的な体験」から「CAPTCHA」

言葉で完全に捉えられない特定の感覚的体験を作り出すことを主な目的とするコンテンツもある……

利用者が人間であることを証明するために用いられる、非テキストの試験……

http://waic.jp/docs/UNDERSTANDING-WCAG20/text-equiv-all.html#text-equiv-all-intent-head

このあたりは、ここに来る前に丁寧におさえたので、まとめも簡潔でした。

「1.1.1 非テキストコンテンツ 利用者が視覚的に確認したり、理解したりすることを意図していない非テキストコンテンツ」

利用者が視覚的に確認したり、理解したりすることを実際には意図していない非テキストコンテンツ。ページ上でテキストを移動させるために用いる透過画像、ログ解析のために用いる非表示の画像、情報を伝えていないが、単に空白を埋めて美しい効果を作り出すコーナーの渦巻きなどは、すべてこの例である。そのような画像にテキストによる代替を置くことは、スクリーンリーダーの利用者をそのページのコンテンツに集中できなくさせるだけである。しかし、形はどうあれコンテンツをマークアップしないことは、非テキストコンテンツがどのようなものか、(実際には何も見逃していていないにもかかわらず) どのような情報を見逃してたのかを利用者に推測させてしまうことになる。そのため、このような非テキストコンテンツについては、支援技術 (AT) がそれを無視して、かつ利用者に何も提示しない方法でマークアップ又は実装する。

http://waic.jp/docs/UNDERSTANDING-WCAG20/text-equiv-all.html#text-equiv-all-intent-head

キーワード

AT

Assistive Technology（支援技術）。

まとめ

• 空のaltやaria-hiddenを用いることで、無視できるようにする。

今回の反省とたいらげ会後のフィードバックと対策案

現時点のものです。（おそらく）増えます。指摘項目の後のカッコは理解の手がかりです（なんじゃそりゃ）。

どの箇所を読むのか、事前に教えて欲しかった。（も）

勉強会直前になって、1.1.1を読むなら原則から読まなきゃ、と気づき、急遽範囲が拡張されました。次回（あるとしたら）改善します。

「解説書」はかなりハードル高い。ターゲット想定をもうちょっと考えた方が良い。『デザイニングWebアクセシビリティ』（ピンク本）を読むとかするのは？（も）

「ハードル高い」という点については、あらためてそう思いました。ピンク本に関しては、あれは一人で読んでてくじけない本だと思えまして、一人で読むとくじけそうなほうを勉強会ネタにしたいと、今回自覚しました。

WCAG 2.0本体とWCAG 2.0 Understanding、Techniques for WCAG 2.0の関係を事前説明した方が良い（も）

まったくそうだと思います。それが今後の独習の助けになるものですね。次回（あるとしたら）は、そこを踏まえ直します。

WCAG 2.0 附録 A: 用語集の説明、忘れてね？（も）

忘れてました。これも大事ですね。

もんど、柴田の補足解説が役立った（こ）

もんどさんはもちろんですが、柴田がすこしでも役に立ったならよかったです。でも、一人ひとりにまとめてもらっていくのは、それなりに難度の高いことだということがわかりました。次回は僕の時代の中学校の英語の授業みたいに

1. 読む
2. 簡単にまとめる
3. 柴田（あるいは有識者）が解説を加える

を一つの流れにするとスムーズでは、と仮説を立てています。

そのほかのいただいた感想

そのまま転載するとちょっとアレなので、僭越ながら簡単にまとめます。「ちょっと待て」という方は柴田に連絡ください。

• 改良の余地はあるけど、まずまずの勉強会だったとおもう
• デバッグできた
• 更にスイッチが入った
• 社内勉強会でもやってみようと思う
• あったら次回も来る
• JISもWCAGも知らなかったので、きっかけになった
• 普段の読書をいかに流し読みしてるか、身についてないか色々と自分でも反省してしまいました。
• 読みながらまとめるのは、緊張もして難しかったが、集中はできた
• 文書はプリントアウトしてもらったのが良かった
• 「デザイニングwebアクセシビリティ」を会社で読み進めています
• 会後のビール座談会が有意義だった
• 最後に、「きょうやったこと」を総括してもらえると良かった

雑多な反省

• お茶をだしてなかった。テーブルにどかっと置くだけで、すすめるのを忘れていました……。
• 録音をしてなかった。いや、うちの書記がiPhoneで録音してくれていたので助かったのですが、ICレコーダ、電池買ってきてたのに、録音開始するのを忘れていました。（でべちゃんは途中で気づいていたそうです）

関連記事

小畑タカユキさんがレポートを書いてくださいました（「軽率な発言」なんてとんでもないですよ、小畑さん）。

• 大阪のアクセシビリティおじさんがゆく、第1回「京都でウェブアクセシビリティたいらげ会」 に参加するの巻。

次回

7月7日開催の可能性があります。@jidaikobo on Twitterで発信します。

（以上）

ツイートする