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

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

このページについて

2017年6月9日(金)に、時代工房で第1回「京都でウェブアクセシビリティたいらげ会」を開催しました。このページはその記録です。最初の「あいさつ」は、あらかじめ原稿を書いていたので、その全文。以降は、録音していた内容の抄録です。

終わりには、たいらげ会後にいただいたフィードバックと、それを元にした反省。あと、感想等を載せていますので、勉強会開催を考えている方は読むといいかもしれません。

参加人数は結果的に14名。19時開始21時終了で、おわったあと、9名ほど残って、ビールを11缶飲みました。

あいさつ

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

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

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

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

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

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


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

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

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

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

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

そこで日本工業規格である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

まとめ

「原則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

まとめ


ここで、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属性のことではない。

まとめ

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

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

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

キーワード

時間依存メディア
音声、動画、スライドショー(カルーセル)など。

まとめ

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

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

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

キーワード

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

まとめ

「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

まとめ

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

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

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

まとめ

「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

まとめ

「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

まとめ

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

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

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

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

まとめ

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

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

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

まとめ

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

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

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

まとめ

「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」

収録済の音声しか含まないファイル及び収録済の映像しか含まないファイルは、ここで扱われている。ライブの音声しか含まないファイル及びライブの映像しか含まないファイルは、以下で扱われている (この段落の 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 非テキストコンテンツ ライブの音声しか含まないコンテンツ及びライブの映像しか含まないコンテンツ」

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

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(支援技術)。

まとめ


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

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

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

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

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

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

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

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

WCAG 2.0 附録 A: 用語集の説明、忘れてね?(も)

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

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

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

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

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

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

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

雑多な反省

関連記事

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

次回

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

(以上)

このエントリーをはてなブックマークに追加

障害当事者がアクセシビリティチェックをしています この製品は障害者が制作に関わっています

ページの終端です。ページの先頭へ