2018年7月1日にD2D アクセシビリティ勉強会 2018年・夏がJUSO Coworkingで開催されました。
今回の勉強会は「子連れOKな勉強会にしたいと考えています。」とのことでお子様連れの参加者の方々もいらっしゃりワイワイ柔らかい雰囲気となりました。

今回は私がくたびれていたのでw「アクセシビリティの祭典 2018」で今回のイベントの宣伝はしたものの、当日はイチ参加者として勉強しておりました。

Bootstrap4から読み解くアクセシブルかつレスポンシブなコーディング

さらにアクセシビリティに配慮されたBootstrap4のコードを読み解きながらアクセシビリティを読み解くセッション。
Bootstrapの用意されたコンポーネントを使えば、アクセシブルなサイトを手軽に作ることができる！のか？

Bootstrap4のコードを実際に見た印象では、WAI-ARIAの属性がしっかり入ってて「おぉここまでしっかり入れてくれていると自分で調べて入れる必要がないのでとても楽なのでは？」と感じました。

ただ…じゃあコピペしてそのまんま使えるのか？というとやっぱりWAI-ARIAの属性の中身を変更する必要もあるし、IDと紐付けられる属性はチャンとIDに合わせてあげる必要があるので、最低限の知識をもって対応する必要があるなと。
当たり前ですが…

例えば～パンくずリスト内にあるaria-label=”breadcrumb”は、日本人に分かりやすいように”breadcrumb”を”パンくずリスト”と変更するとか。

IDと関連付けされてコンテンツの説明を付け足すことができるaria-labelledbyなども、参照先のIDがあっているのかは確認の必要があります。

そしてカルーセル問題…
Bootstrap4のカルーセルはキーボード操作には対応しているけど、このままじゃあチョットという話。

自動的に5秒より継続する動きのあるコンテンツは、その他のコンテンツと平行して表示される場合、動く要素をユーザーがとめることができる必要がアリ。
動く要素というのに人間は自然と反応してしまって注意・意識がそれてしまうのを防ぐためです。

Bootstrap4のカルーセルの場合、カルーセル上にマウスを重ねるとスライドショーは停止されます。
けど、マウスをカルーセルに重ねて停止したところで、他の操作ができない…それが問題。
達成基準に対応するなら停止ボタンをつけるべし。。。

デフォルトカラーもそのまま使っちゃうと4.5:1のコントラストがたりないパーツがあるので、気をつけよう！

またページネーションについては、やりすぎ感がある…との話や、そこはaタグでrole=”button”じゃなくてbuttonのタグを使ってほしいわーなどダメだしもチョイチョイありましたが、絶賛、更新されているようなので、今後に期待です。

質問にあった、多言語サイトの場合のWAI-ARIA属性はどうなる？ですが、変数を使ってCMSで制御できればベストだけど、現状厳しいなら日本人が分かる程度の英語にしては？ということでした。
なので、出来るならlabeldbyでコンテンツに表示されたテキストを参照するのがベターという話もありました。

スマホで手軽に読み上げ機能を試してみよう！

VoiceOverとTalkBackの簡単マニュアルが配られました。

マニュアルを見ながら実際にいろんなサイトを聞いてみると、いろんな気づきがあるものですね。
まずは、早すぎて何言ってるかわからないので私はかなり低速で聞いていましたw。
ヤフーニュースは記事の一覧にいくまでに時間がかかりすぎる～という意見から、W杯（ダブリューさかずき）と読み上げられることの違和感…でも情報としては間違ってはいないので、過剰な親切心は不要とのこと。

アクセシブルなコーディングに便利なツールを持ち寄り紹介しよう！

・Web Developerツール
私はFirefoxのアドオンで使っていますが、画面を見ながら画像altの確認が出来るのが超便利です。

・WAVE
みるくさんからのおすすめツール。早速これもFFのアドオンに追加しました。
英語ですが、画面になんのタグで組まれているのかが表示されるので、これもページの確認するのにいいかも！
サイドにアクセシビリティに関する細かい情報も表示されます。

さいごに

アクセシビリティのレベルの説明があったときに「簡単なことから広くやっていく。」という話がありました。
狭い範囲でAAAを目指すくらいならAAの範囲をひろげたほうがいいし、AAを目指すならまずはAの範囲をひろげてみようというイメージ。

私も、アクセシビリティの勉強会はいろいろ参加していますが、バリバリやってる感じではありませんw。
スイマセン…でも出来る範囲からやろうと思っているし、時間があったらaltを見直してみようとか、手直し入れてみようとかはあります。

なので、大きな目標よりも小さいことからやってね～と言われるとちょっとホッとするというか、安心して地味に頑張ろうって思います。
(*・`д・)

今回のイベントは開催準備をまるで手伝えなくてすいませんでしたが、とても楽しめましたw。

@HissyNC、@SawadaStdDesign、@milk54、ありがとうございましたー

D2D アクセシビリティ勉強会 2018年・夏　ツイートまとめ

投稿 D2D アクセシビリティ勉強会 2018年・夏に参加してきました！ は CodingMania に最初に表示されました。

そのアクセシビリティの祭典のイロモノ枠wとして歌あり寸劇ありで気軽に楽しくWebアクセシビリティについて知ってもらおうとD2Dとして第一回からセッションにも参加しています。

セッションにも参加～とか言ってますが、私が話すのはD2Dについてだけなので2,3分なんだけどw、人前で話すのはホント苦手なので、今回も知ってる人がたくさん来てくれていたのでとっても助かりました。スタッフの方にも「大丈夫！」と声かけてもらったり。
ありがとーです(*´▽｀*)

今年は前日準備からstaffとして参加もしたのですが、準備しながらもいろんな気づきがありました。

壇上で行われる手話が見えやすいように最初から座席に「聴覚障害者の方の席はこちら」的な紙を座席に貼るのですが、そもそもそういった決めつけをこちらがするのはどうなのか？という話です。
聴覚障害者の方も自分で自由な席に座りたいよね～っていうのをみんなで話をして結局席を案内する紙はやめました。

壇上で行っていただく手話通訳者さんの位置もUDトークの画面に近いほうが今は流行りですっていうのを聞いて配置換え。
流行りというか、手話で分からなかった部分をすぐ横のUDトークの画面に表示される文字で追えるっていうのが利点で最近はこのパターンが多いとこのと。

UDトークは初めて体験しましたがオドロキでしたね！
壇上左手にあるスクリーンにリアルタイムで日本語と英語のテキストが字幕として表示されます。
日本語の修正が入れば自動的に英語も修正され修正されたところは色が変わり変更を知ることもできます。
私も耳で聞いて「なんていった？」ってことも文字で追えるのでとても便利で楽でした。

早速、【運用レポート】アクセシビリティの祭典2018が掲載されていましたので、詳しくはこちらで。

当日セッションの前半は、Webというよりももっと広い範囲での各々のアクセシビリティに対する取組みや考え方、技術の紹介などが多かったように思います。

その中でも「障害がある無し関係なく情報を知って生活を便利にする」。というのはとても腑に落ちました。
新しいデバイスや技術の登場で出来ることの範囲が増えているけど、結局その情報を知っていないと意味ないもんな～と。
(｡ ・д・)-д-)ふむふむ

後半は、Web制作に寄ったセッションが多かったかな。

画像を認識して写真から情報を読み取るツールの紹介がありました！
「Computer Vision 」

これでalt付けれるんじゃないの～？って話もありましたが、まぁそういう未来かCMSは出るんじゃないの…マジでって思ったね。

「インクルーシブ」というのはいろんなセッションに出てきたので今年のキーワードですね。
私も最近「インクルーシブHTML+CSS & JavaScript」読んでますけど、超分かり易くて読みやすいのでオススメです。

最後に…

実は一日タイムキーパーをしてセッションすべてを見ていたにもかかわらず、なかなか内容まで頭が回らず、簡単にタイムテーブルにメモして、次の日動画で気になるセッションを追いかけました。
なので、動画配信・録画されていたことは大変助かりました。ε-(´∀｀*)ﾎｯ

D2Dの次回のイベント「D2D アクセシビリティ勉強会 2018年・夏」の告知も宣伝のかいあり、順調に参加者も伸びてよかった！

また来年も開催されるとのこと。
毎年、バージョンアップされてるアクセシビリティの祭典に期待しています。

前日準備中に素敵なポストカードをいただきました。神戸の景色とカラーがとても綺麗。
Manabu_Takemotoさん、ありがとうございました。
早速、部屋に飾ろうと思います！(*≧∀≦*)

投稿 アクセシビリティの祭典 2018に参加してきました！ は CodingMania に最初に表示されました。

勉強会でやったこと。

前半はセッション2本立て。場の雰囲気をしっかり作ってもらいました。
その後グループに分かれて「アクセシビリティ間違い探し」をしました。

初参加の方も多くいらっしゃいましたが、グループに分かれて作業することでセッションの内容も含め、いろんなことを話しすることができました。

否応なくグループにして課題をだして「さぁやってみよう～」というスタイル。
毎回このスタイルで勉強会をしていますが、いっきに人との距離が縮まり協力できる姿勢がどのグループにも出てきます。ドキドキしますが得るものは大きいです。

それに意外とみんな自分から話すんですよね。

グループの発表では、自分が気づかなかったことを他のグループが気づいて疑問視したり「そういう考えがあるのか～」と感心したり。
「なんで気づかなかったんだろう」と凹んでみたり。

チェックの仕方にも、性格や個性がでてて面白かったですね。
該当のページを見て勘で「ここだ！」となったり、ツールで「ここが怪しい」となったり、チェックシートを頭から読みチェックをする人もいたり、まさに様々。
そうやって自然とチームワークが芽生え時間内にどのチームも結果を出していました。

勉強会の準備遅れてました。。。

2015年は二か月に一回のシリーズものとして開催。
今年は１回ということで時間は十分にあるなーと楽観している間にいろんな勉強会の日程にも重なり予定していた時期よりかなり遅れた9月開催となりました。

実際2015年の11月に「来年もやろう！」と決起したにも関わらず「まだ時間はある。。。」と思い続けて後回しに考えてた私のまったり度合が悪かったと反省しております。

腰が重い、の一言なんですが、、、もうちょっと段取りよくできないものか？というのはこれからの私の課題なのかもしれません～みんなどうやってんの勉強会？

にもかかわらず会場も内容も本当にベストな状態で整えてもらって、当日は本当に今年は1回ポッキリだったけど、やってよかったなーって酔いしれておりました。

来年もやろうかな（←本当か？

懇親会はもんじゃ！

「もんじゃ食べてみないわー」って話からもんじゃのお店を教えてもらって行ったのですが、まさかの「セルフ！」

ちょっどうやってやるの～？とおおいに盛り上がったので、久しぶりの外での懇親会も人数合わせが大変だったけど、十分楽しむことができきました！

最近の勉強会は、会場でそのまま懇親会も多いですねー。
準備が必要かもしれないけど、移動や人数をあんまり気にしなくていいので次はそういう風なのもいいかも。

ちなみに澤田さんから「もんじゃは空気」っていうありがたい名言をいただいたこともここに記録しておきますw。

ではまた！

投稿 「D2D アクセシビリティ勉強会2016」を開催して感じたこと。 は CodingMania に最初に表示されました。

最終回のあとのオマケということで、htmlとCSSの完成を目指しました。
CSSはページを三分割してグループごとに実装。その後、グループ発表をして、一つにまとめました。

勉強会のツィートまとめ

@SawadaStdDesignさんのオマケ会 D2D アクセシビリティ勉強会資料
「アクセシブルなCSSをつくろう」

結局どうする？新着リストとキービジュアル

前回、グループごとに作ったhtmlを一つにまとめていく中で、どっちを採用するか？という意見交換と多数決を行いました。

新着リスト

リストタグ（ul,li）でくくるのか、定義・説明リスト（dl,dt,dd）でくくるのか？

私は、ほぼ定義リストで組んでいて、理由としてはどんなデザインが来ても扱いやすいのと、dtタグ一つに対して、ddを複数配下におけることなど汎用性が高いかなーと思って使っています。
でも、確かにリストタグの方が分りやすいのかもなぁと思ったりもしました。

多数決としては、定義・説明リストの方が多かったので、D2Dのサイトではこちらを採用。
ちなみに、どちらのタグが正解というものはありません。このあたりは適宜自分で判断していきましょう。

キービジュアル

画像の上に文字（リード文）が載っている。どうする？
「気になること、本当に知りたいこと。ここにあり〼。」

普段なら、画像に勉強会の風景というaltを入れて、文字はテキストで画像の上に載せる。という方がほとんどだったと思います。
が、この枡記号を読めないスクリーンリーダーがあります。。。ならどーする？

ココで、そういう意見もあるのかーとハッとしたのは、「ます」を読まなくても意味は通るから別にいいんじゃない？という考え。
たしかに「気になること、本当に知りたいこと。ここにあり。」でとまってもまぁイケる！

ただ、今回はアクセシビリティ勉強会ですからね！チャント全てを伝えることに注力してやってきましたので、キービジュアルは一枚の画像で対応することになりました。

音声ブラウザのNVDAが進化していた！

第6回 の勉強会でやったフォームのhtmlですが、
＞※html5で用意されている”required”は、現状　音声ブラウザのNVDAで「無効なエントリー」と読み上げられてしまう。。。のでWAI-ARIAのaria-required=”true”を入れましょう。
とう話があったのですが、これが解消されております！

旧）

<input type="text" id="name" aria-required="true" />

新）

<input type="text" id="name" required />

グループに分かれてのCSS実装

私のグループに振り分けされたデザインは、実は大きな山場となるデザインがなくwww。
全くこれといったネタがありません。。。スイマセン！！！

ウッカリ忘れがちになってしまうのは、
・:hoverだけでなく:focusも指定する！
・aタグのスタイルにoutline:none;をしてしまう
↑この設定があるととキーボード操作時にどこにフォーカスが当たっているのかサッパリわからなくなってしまうので、これを消してはダメです！
これねー、結構上層のCSSで消されてることが多々ありますので。チェックです。

こんなところでしょうか。。。（汗

所感

8回に渡ってアクセシビリティ勉強会やってきましたが、最初フワフワしていた私の考えも無事着地することができました。
おそらく他のアクセシビリティ勉強会に行っても吸収力が今までと違う感じになってると思います！

串カツも行ったし、来年はお好み焼きだー！！

投稿 オマケ回 D2D アクセシビリティ勉強会：続コーディング編 は CodingMania に最初に表示されました。

勉強会のツィートまとめ

@SawadaStdDesignさんの第7回 D2D アクセシビリティ勉強会資料
「D2Dサイトをアクセシブルにマークアップ」

今回の勉強会の目指すところ

第5回で選ばれたデザインを元にhtmlのマークアップ。

アクセシブルなHTMLの見本になる、
そして　誰が見てもアクセシブルなHTMLだ！と絶賛されるコーディングを目指します。

グループ発表で気づいた個人的メモ抜粋

別サイト（同ドメインから抜ける）に移動するというアナウンスは必要ですか？

• 見ている人にとってその情報必要なのか？
• 同じナビゲーション（体裁）の中に一つだけ性質の異なるリンクが入るので、あえての親切心。

キービジュアルは<header>、<main>それとも独立させる？

• グループごとに解釈が違い、バラバラの結果に。

role＝属性は、W3Cのバリデーターで警告表示されるようになった。。。

• <main role="main">
  訳）main、それはmain
  同じコトを言っているので、roleの表示は重複するので不要。

• 現在は、過渡期なので警告ですが、将来エラーが返ってくる可能性も！

【ご指摘いただきましたので追記します。2015/09/02】
すべてのrole属性に警告が出るのではなくランドマークrole属性の例として記載しています。
詳しくは A vocabulary and associated APIs for HTML and XHTML

タイトルの扱い。

• 見出しは後に続くコンテンツを要約（短くしたもの）と考えると、タイトルの下はコンテンツが続くべき。
• 独立したタイトルというのはおかしくないか？

ロゴマークの代替テキストはどう入れる？

• 見たままでOK!ですが、英数大文字が続くとDESIGN（デーイーエスアイジーエヌ）となってしまうので注意。
• 参考模範解答では、alt=”D2D(Dev&Design Draft)”
• ちなみにワタシのチームは、alt=”Develop&amp;Design Draft”
  と親切心で入れてしまいました、冗長すぎるのであまりよくありません。。。
  入れるならalt=”Dev&amp;Design Draft”
  といったところでしょう。

アイコン画像のaltに冗長な説明は不要。

• altに悩んだ場合は、何を示すために入れたのかに立ち返る。
• アイコンが見える人も見えない人も等しく同じ情報を得られることが大切。差が出てはいけない。

「枡記号」をどう入れる？

• 文字参照で「〼」表示できますが、これを読めないスクリーンリーダーがあります。
• どのグループも音声ブラウザを配慮し、一枚画像にalt=””で対応。
• 参考模範解答では、「ます」の文字をCSSで見えないようにして、音声ブラウザに対応されていました。

<p>ここにあり<span aria-hidden="true">&#x303C;</span><span class="not_appeared">ます</span>。</p>
<style>
.not_appeared {
    position: absolute;
    overflow: hidden;
    margin: -1px;
    padding: 0;
    width: 1px;
    height: 1px;
}
</style>

所感

最近おぼえた「role＝属性」がW3Cのバリデーターで警告表示になるというのには、ショックを隠しきれませんでしたが、html5が順調に育っているんだなと前向きにとららえることにします。

やっと出会えたのに、もうお別れな感じがなんとも悲しいですけど。。。（知るのが遅すぎたというのは置いといて）

また今回はマークアップが目的だったので、グループごとに分かれて手を動かすのは楽しかったです。
グループの中でもどうする？これは？など議論をするといい刺激になります。
Gitもフォローいただきましてナントカ思い出せたし（また忘れそうだけど）。

最後に、@SawadaStdDesignさんのスライドの中にあった「100点満点のサイトが１つ増えることよりも、50点のサイトが10個増えることの方が大事。」に胸が熱くなりました。ちょっとづつでも積み上げるヨ！

投稿 最終回 D2D アクセシビリティ勉強会：コーディング編 は CodingMania に最初に表示されました。

勉強会のツィートまとめ

@SawadaStdDesignさんの第6回 D2D アクセシビリティ勉強会資料
「アクセシブルな入力フォームを作ろう」

@milk54さんの第6回 D2D アクセシビリティ勉強会振り返り
第6回 D2D アクセシビリティ勉強会でアクセシブルなフォームを作成！

今回は勉強会の振り返りというより勉強会で学んで、日々できるフォームの書き方をズラリまとめてみました。

label要素でテキストラベルとテキストフィールドを関連付ける。

例）

<label for="name">名前</label>
<input type="text" id="name" />

例）必須項目の場合

<label for="name">名前<span>[必須]</span></label>
<input type="text" id="name" aria-required="true" />

※html5で用意されている”required”は、現状　音声ブラウザのNVDAで「無効なエントリー」と読み上げられてしまう。。。のでWAI-ARIAのaria-required=”true”を入れましょう。

上記問題は解決しております。required=”required”を使用しても問題ありませーん。

<label for="name">名前<span>[必須]</span></label>
<input type="text" id="name" required="required" />

例）ラジオボタンの場合

<p id="inquiry">お問い合わせの種類</p>
<div role="radiogroup">
<input id="kubun01" type="radio" name="kubun" value="A" aria-labelledby="inquiry"/><label for="kubun01">Aについて</label>
<input id="kubun02" type="radio" name="kubun" value="B" aria-labelledby="inquiry"/><label for="kubun01">Bについて</label>
<input id="kubun03" type="radio" name="kubun" value="C" aria-labelledby="inquiry"/><label for="kubun01">Cについて</label>
</div>

※ラジオボタンはhtmlのfieldsetでグループ化、legendを使ってタイトルを明示したいところですが、読み上げソフトで現状対応していないので、WAI-ARIAを使ってグループ化と紐付けします。
チェック項目をrole=”radiogroup”でくくりグループ化します。
タイトル部分にid=”inquiry”、チェック項目[input]には、それぞれaria-labelledby=”inquiry”でタイトルとチェック項目を紐付けします。
また、チェック項目のクリッカブル範囲を大きくとりたいので、labelでinputタグをくくります。

label要素を使えないなら、title属性で代用する。

例）入力する項目が二つに分かれてる場合。郵便番号ナド

<label for="postnum">郵便番号</label>
<input type="text" id="postnum" title="郵便番号前の3桁">-<input type="text" title="郵便番号後ろの4桁">

※本来ならラベルとテキストフィールドが一対がベスト。でもラベル一つに対してテキストフィールドが二つの場合は、title=””を使います。

入力項目に説明文や例を表示

例）

<label for="kana">ふりがな</label>
<p id="kanaNotice">ひらがなで入力してください。</p>
<input type="text" id="kana" aria-describedby="kanaNotice"/>

※入力する時に気をつけてほしい説明文などはテキストフィールドにフォーカスがあたった時点で読み上げてほしいので、ここもWAI-ARIAを使って紐付けします。
説明文にid=”kanaNotice”をあて、テキストフィールド[input]にaria-describedby=”kanaNotice”で紐づけます。

html5のplaceholderを使ってテキストフィールド内に入力例など表示できますが、イザ入力しようとしてカーソルを入れると消えちゃう。。
私も結構便利でよくやるのですが、消えるというのはあまりよろしくないんですね。
出来ればテキストフィールドより前にちゃんと記載するのがベターです。

検索ボタン

例）

<!-- <label for="searchbox">キーワード検索</label> --!>
<input type="search" id="searchbox" placeholder="検索キーワードを入力してください">
<button type="submit"><img src="img/btn_search.png" alt="検索する"></button>

※ページ上部によくある検索フォームなどはlabelがなくてもまぁよしとされているようです。
周知の事実というかボタンとテキストフィールドが隣どうしで設置され、目的を理解しやすい間違えないだろうという解釈のようです。
参考：G167: 隣接するボタンを用いて、テキスト・フィールドの目的をラベル付けする

といってもlabelをつけて、CSSで画面上見えなくする（display=”none;”を使うと読み上げないスクリーンリーダーがあるのでダメ）手法をとっているCSSフレームワークもあります。

DOMの順序と表示順序を一致させる

フォームが２カラムとかになり、htmlの順序と質問の順序が違ってくる場合は、tabindex=”数字”を使ってキーボードで移動する順番を指定できます。
通常、上から順番になっているフォームは特に指定はいりません。

メールの入力

例）

<input type="email" value="" />

※type=”email”を指定するとエラーチェックをしてくれる便利なやつですが、このチェックが厳しすぎる～半角が入ってもエラーになってしまうので、使うときはちょっと考えよう。

電話番号の入力

例）

<input type="tel" value="" />

※エラーチェックはしないけど、スマホで入力モードが数字になるので便利♪

勉強会を終えて。。。

私のチームでは、ラジオボタンだとスマホではチェックしにくいので、セレクトボックスのほうが使いやすいのでは？という話がでました。
これは、時々の判断だと思うのですが、ラジオボックスの最大の利点は画面に項目がズラリ表示されているので親切だということです。
また、スマホのドラムロール（慣れると便利なんだけど）に戸惑う人も多いようです。

選択項目の数やターゲット層を考えて、ちょっと確認すべきところかも。

今回は結構テンパってました（汗 けれど、とてもスッキリした会になりました。ちょっとは苦手意識がうすれたかもw

投稿 第6回 D2D アクセシビリティ勉強会：フォーム編 は CodingMania に最初に表示されました。

今回コードと離れた勉強会ということで、私は単純に楽しんで過ごしてしまい、、、メモが。。。
とりあえず、振り返ります！

勉強会のツィートまとめ

@SawadaStdDesignさんの第5回 D2D アクセシビリティ勉強会資料
「アクセシブルなワイヤーフレーム設計～ビジュアルデザイン」

@milk54さんの第5回 D2D アクセシビリティ勉強会振り返り
第5回 D2D アクセシビリティ勉強会でアクセシブルなデザインを作成！

今回の勉強会のめざすところ

お題は「D2Dのサイト」
1ページのサイトを作成します。
グループに別れてアクセシブルなデザインを作成します。
目標は「アクセシブルなサイトはダサイ」というイメージを払拭するデザインを作る！！！

ワイヤーを作るまえに

作るにあたって@SawadaStdDesignさんからありがたい説明。ワイヤー編。
私がナルホドーと思ったところを抜粋しますよー！

作り手が何を見せたいかよりも、相手に何を見せなければいかないのか？
求められているものは何か？が大切です。

情報をリニアライズする。
レイアウトの位置ではなく、順序が大切。
情報を縦にならべるということで、情報の優先度が分かります。
また、読み上げソフトの順序にも関係しますよね。

見出しは大切ですが、すべてのエリアに必須ではありません。

↓
こういうレイアウトってよくある気がしました。。。が、これではパッっと見たときに文書構造がわかりません。

余白や見出しの入れ方で文書構造が分かるようにしましょう。

とはいっても、すべてのエリアに見出しが必要ではありません。
スライドショーのエリアに「スライドショー」っていう見出しは不要だよねって感じ。

【要点】

• 順序どおり、欠落なく読めるレイアウト
• 一貫したナビゲーション/ラベル/名前（表記ゆれしない）

20分でワイヤーを作る！

最低限な要素として、
・ロゴ
・メインビジュアル
・ナビゲーション
・About
・活動紹介
・活動報告ブログ
・Contact

と言った感じを元にグループごとに作成しました。

各チームワイヤーは下記リンクよりご確認ください。

Aグループのワイヤーフレーム

Bグループのワイヤーフレーム

Cグループのワイヤーフレーム

Dグループのワイヤーフレーム（上）
Dグループのワイヤーフレーム（下）

20分という短い時間の中でしたが、
・「About」は分かりづらいので「D2Dとは」に変更した
・勉強会の開催予定が一番知りたいことなので上位に表示した
・「D2Dとは」が情報として高いのでコッチが一番上
・「Contact」を「お問い合わせ」に変更した
・参加者の声を大きく表示した　などなど

レイアウトの相違は勿論、情報設計からグループカラーがしっかり分かれていました。
こうなるとデザインが、俄然楽しみ☆とニヤニヤしておりました♪

デザインを作るまえに

作るにあたって@SawadaStdDesignさんからありがたい説明。デザイン編。
ナルホドポイントを勝手抜粋しますよー！

「押せる感のあるボタン」など要素の意味を伝えるデザインが重要

感覚的な特徴だけでなく、テキストでも情報を伝える。
色だけでなくテキストでも伝える。
例）右の大きな丸いボタン
↓
右の大きな丸い「実行」ボタン

見出しは、大小関係を見た目で分かるようにする。

文字のコントラストに気をつける。写真の上にテキストがのってる場合は特に注意する。
コントラストを図るツール「カラー・コントラスト・アナライザー」を使えば便利。
または、モノクロにするのも手っ取り早い。
グラデーションを背景にしている場合など、コントラストに注意！

UDフォントは、ふところが広めで文字が小さくなっても読みやすいです。

ナビゲーションの現在地表示も有効。

【要点】

• 知覚できる色/形状/レイアウト
• 操作を妨げない動き/点滅/スクロール
• 一貫した識別性

2時間でデザインを作る！

各グループにデザイナーさんは２人以上という構成だったので、デザインを複数人で仕上げるという普段やらないであろう方法だったと思いますが、さすがプロ！
二時間でちゃん各グループ「どや！」というデザインがあがってまいりました。
スゴー(＠_＠;)

各グループ特徴

【Aグループ】
・ロゴを目立たせたい＝モノクロ調のデザインを採用
・たっぷりめに余白をとって、次のコンテンツとも差別化を図る
・キービジュアルは、写真を変更してもOKなように、キャッチコピーの下に白地を引いて文字コントラストを確保
Aグループの最終デザイン

【Bグループ】
・ドアキーパーと連携して告知できるよう更新の手間を配慮
・お問い合わせフォームに「イベントのお知らせを登録する」という項目追加
・全体を白背景で文字コントラストを配慮
・キービジュアルは、写真を思い切ってボカして、上にのってるキャッチコピーの視認性を確保
Bグループの最終デザイン

【Cグループ】
・左ナビあり！！！
・キービジュアルの上のキャッチコピーはピンクの透過した背景を引いてコントラスト確保
Cグループの最終デザイン

【Dチーム】
・キャッチコピーを目立たせたいので、キービジュアルに写真は使わずキャッチコピーを大きく表示。
・活動実績には、申込み時に使ったイベントビジュアルを使って勉強会カラーを出せるようにする。
Dグループの最終デザイン

文字のコントラストなかなか大変です。特に写真の上に文字をのっけるとなると。。。
「カラー・コントラスト・アナライザー」などのツールをつかって、文字色と背景色のコントラストを計る場合、文字の形が分かればいいので、文字色は文字の真ん中を色でOKだそうです。

番外編：フォームとか。。。

今回のサイトにはお申し込みフォームがあったのですが、フォームのアクセシビリティについては多く触れておりません。

というのも次回「アクセシブルなフォーム！」をやるからでーす♪

でも、番外編として諸々豆知識でましたので、書きます！

• フォーカスインジケーターをCSSで消さない
  a{outline:none;}　→ これダメよ。
  これを消してしまうと、どの要素にフォーカスがあるかが分からなくなります。
• フォームの入力ヒントは、プレースホルダーに入れるよりも入力するinputの前に記載するほうがいいです。
  プレースホルダーは、入力しようとカーソル入れると消えてしまうので、別に記載しましょう。
• 入力項目と入力欄は近くに配置するようにする。
  入力項目が右詰め、入力欄は左詰めに配置している場合、画面を大きく表示したら離れちゃう～というレイアウトはよくありません。
• フォーム入力後の確認画面は、大切な情報を預かるフォームでなければ必須ではありません。

私の雑感

今回は、グループ作業ということでGitHubを使ったんですけど、みんなサッササッサとデータあげたりDLしたり、全然使えてた。
私はちょっとドキドキしてたけどねw。

「GitHubが使えないとナンチャラ」みたいなこともよく言われていたけど、しらない間に技術が浸透していってるんだなぁ。。。としみじみ思いつつ、置いてけぼりを食らわないようにコツコツやっていかないとね！

次回、おそらく6月は「フォーム！」に的を絞ってやる予定です！

投稿 第5回 D2D アクセシビリティ勉強会：デザイン編 は CodingMania に最初に表示されました。

勉強会のツィートまとめ
↑
今回は、誰かがやってくれてて、、、あざます。

最初に気をつけるべきことの説明がありました

どちらにもいえる基本

• マウス操作だけを前提とせず、キーボードやタッチパネルでも操作できるようにしよう。
  キーボード用／マウス用のイベントを両方使えるようにしよう。
  キーボードだけを使ってアクセスできますか～？
  メモ：onClickは機器に依存しないから便利☆
• フォーカス順序は、HTMLソースの順序（親子関係）と見た目の順序をあわせよう。
  フォーカス順序がイケてない場合はtabindexを使う
• css無効時にちゃんと、文書構造が保たれていますか？
• フォーカス移動だけで勝手に遷移させないようにしよう。
• スクリーンリーダーでの音声読み上げに対応しよう。
  画像にalt属性を入れる
• 将来に向けてキレイなマークアップをしましょう！
  WAI-ARIAでUAに役割を伝えましょう

プルダウンメニュー

• ナビゲーションは、サイトにとって大切なものなのでJavaScript無効時も使用できるようにしましょう。デザインは崩れてもいいけど、情報が取れなくなる（末端ページへの導線がなくなる）のは問題です！

カルーセル

• フォーカスの移動で利用者がコンテンツ内（カルーセル）に閉じ込められないようにする
• コンテンツを意味のある順序で並べよう
  カルーセルで言うと、画像リストのあとにコントロールボタンというカンジ
• 理解できるだけの十分な時間を与えられること
• 切り換えられる画像上の情報（特に文字情報）を理解するだけの時間の配慮をしよう
• 自動で動いているカルーセルなどは一時停止／再開できるようにする
• JavaScript無効時でも、カルーセルに含まれる全ての画像を表示され、すべてのリンク先に遷移できるようにする。
  上記が満たせない場合は、noscript要素で代替手段を提供するなど。

※本当はもっともっともっと細かくあったんですが、書ききれませんでした。。。
よって～私なりにココは最低抑えておこう！というところをまとめております。

グループに分かれて、いざやってみよう！

「プルダウンメニューチームB、C」と「カルーセルチームA」に分かれて二時間みっちり手を動かしましたヨ

毎度のことですが、やっぱり手を動かすと時間の進みがスゴイ！！！あっという間です。

グループ発表

カルーセルAチーム

「slick」というプラグインが結構デフォルトでイケてる！
slick – the last carousel you’ll ever need

・キーボードのTABキーと矢印キーで操作ができる。
・js無効時には、全ての画像を表示し、遷移も可能。
・css無効時でも、リスト構造が保たれている。

ただし、自動（auto）で使った場合、マウスホバーではカルーセルを停止するが、キーボードのフォーカスでとまらなかったー
オートプレイしなかったら、アクセシブルです。。。

オートプレイで使いたい場合は、他をさがすかカスタマイズ（一時停止ボタン・再生ボタンの追加）が必要です。

プルダウンメニューBチーム

イチから作りましたが時間切れのため、マウスアウトで下層が出たまま。。。
WAI-ARIA対応
nav role=”navigation”
li class=”menu-item has-dropdown” role=”menuitem”

よさげなプラグイン見つけたよ
Superfish v1.7.5 – jQuery menu plugin by Joel Birch

プルダウンメニューCチーム

イチから作ってナントカできたけど、ソースの整理が、、、
３階層までがんばった！

プルダウンメニューデモページ

やってから気づいた注意すること

カルーセル

• よくあるcurrent表示の●●○●って、白が現在地表示なんだけど、色だけじゃなく大きさで示したほうが伝わる
• カルーセルはやっぱりdivじゃなくてUl要素
• 左右（< >）←こういうのもコントラストに気をつける
• フォーカス時のアウトラインを目立つようにする
• ul要素に「role=”navigation”」、img要素に「role=”menuitem”」を定義することで「ナビゲーション」「メニュー項目」と読み上げることができる。 （少しでも役割を伝えるために）

プルダウンメニュー

• プルダウンメニューの下層があるのかないのかが分るようなアイコンをつける。
  下向き▼みたいななやつ。
• Tabキーですべてのリンクを移動できるのは確かにアクセシブルだけど、ナビゲーション後方のメニューにサッと行きたいときは、矢印キーで移動できるというのも大変便利です。

使う前によ～く考えよう！

@milk54さんが、「みなさん、悲しいお知らせです」。。。から今日のまとめははじまりました。

私は、もしかしてこの勉強会からサヨナラとか！！！と半分涙出そうになってたんですが、そうじゃなかった♪ほっ（*´∇｀*;△

そうじゃなくって！「プルダウンメニューとカルーセル」はアクセシビリティ的に相性が悪い！！っていう話でした。
「だから！使う前に本当にそれが必要なのか考えて～」

(」ﾟﾛﾟ)｣(｣ﾟﾛﾟ)｣(｣ﾟﾛﾟ)｣ｵｵｵｵｵｯｯｯ

今日勉強したばっかなのに～～～ルルル～
一瞬ポカンて私はなったんだけど、@milk54さんと@SawadaStdDesignさんの話を聞いて、確かに。。。って考えさせられました。

プルダウンメニューの悪いとこ

• プルダウンメニューなのか気づかない。下矢印▼の表示もCSSならスクリーンリーダーで読み上げられない。WindowsのハイコントラストモードではCSSの背景画像は見えない。
• 最初から中身が見えない。
• 比較できない（並べてみることができないから）
• 操作付加が高い、複雑。

カルーセルの悪いとこ

• そんなに見せたいものあるの？
• 2枚目以降は見てない。
• 全て読む前に切り替わってしまう。すぐに理解できない人は意外と多い。
• イライラする。イラッとさせるのは、最悪のユーザー体験につながる！
• 読ませたいのは本文じゃないの？
• ギャラリーは別。
• 意味がわからない。どんなにアクセシブルにしても、スクリーンリーダーでは、動きは伝わらない。

そうはいってもまだまだ避けられそうにない現実。でも、使う前によ～く考えることが大切というコトでした。
そして、使うならチャント今日の勉強を活かしてできる限りアクセシブルなもので行こう！

D2D Dev & Design Draftの宣伝

ウェブのテクニカルな内容とデザイン的な内容を横断した、特定のプロダクトや技術に限定しない勉強会。いろんな勉強会やってます！
次回以降のイベントについて通知を受け取りたい方は、DoorKeeperでメンバー登録できます。
D2Dのdoorkeeperページ

3月はGitやるみたいですヨ～☆

投稿 第4回 D2D アクセシビリティ勉強会：プルダウンメニューとカルーセル は CodingMania に最初に表示されました。

毎度のコトながら、進行スケジュールが大きくオーバーしたのは、言うまでもありません。。。みなさま、いつも付き合ってくれてありがとうございますです。m(*- -*)mｽ･ｽｲﾏｾｰﾝ

勉強会のツィートまとめ
↑
ブログで紹介しきれない情報もいっぱいですので、サッと見るだけでも勉強になる！

では、振り返りますよ！

グループに分かれてウェブアクセシビリティの達成等級：Aを実際にチェック

ウェブアクセシビリティの達成等級：Aチェック項目をやりました。

チェックしたサイトは「第15回宝塚映画祭」

もともとかなり時間がかかるであろうと予測し、グループを３つ作りそれぞれチェックする担当を決めてのスタート！
グループAは、7.1.1.1から7.1.2.3まで。
グループBは、7.1.3.1から7.2.1.2まで。
グループCは、7.2.2.1から7.4.1.2まで。といった感じで進んだのですが、、、全然終わらない～～～

「ココはこうだから○？」「いやそうじゃなくってこれはこういう意味では？」からはじまり「適用（有る無し）と適合（マルバツ）」がゴッチャになるし、普段はこうしてるよ。などの脱線もあり（私のチームだけだろうか。。。）

これが終わったころには、もう日が落ちかけてたね。。。。

各チームの結果発表！と答え合わせ

チェックの結果だけでなく、躓いたところや疑問をみんなで共有できるよう、チームリーダーにチェックのプロセスを発表してもらいました。

その後、@milk54さんと@SawadaStdDesignさんに前もってJISチェックを行ってもらった結果と、今日グループで出した結果を照らし合わせて、解釈の仕方や疑問に思っていたことを全員でディスカッション！
これからやりたいことなども出てきて、勉強会の終わる気配がwww、みんな熱いゼ！

最終的に、チェック項目のなかで×が一つでもあれば、等級Aを満たしているとはいえません。
ですが、今日チェックした「第15回宝塚映画祭」サイトは、しっかり○もたくさんあったので、「等級Aに一部準拠している」という結果になりました。

今回、ご協力いただきました「第15回宝塚映画祭」の関係者の皆様、本当にありがとうございました！来年も、できればよろしくお願いしますw

今日一日のまとめ

これが、正解！というわけではありませんが、みんなで出した答えや気づきをまとめました。

7.1.1.1

⑤img，area要素，appletのalt属性に適切な代替テキストを記述する。
・altのつけ方は、いろいろ場所や入り方によってあると思いますが、文字が入っている画像は、文字通りのaltをつけましょう
・映画のタイトルの場合、alt=”映画のタイトル：ナントカ”という風につけるのも親切かもしれないねー

⑥隣り合う画像とテキストのリンクが同一のhref属性値を持つ場合、画像とテキストを1つのa要素でマークアップする

⑧a要素のリンクの目的を説明するリンクテキストを提供する
・よくある「詳細を見る」ですが、Shift + Hキー等で見出しを読み上げれば文脈をたどることができるため、実用上の問題はほとんどないと考えることができる。（フォーカスを移動させないで理解できることが条件）

参考G53: リンクテキストとそれが含まれている文章中のテキストとを組み合わせて、リンクの目的を特定する

②CSSで指定する画像は、装飾的なものだけである
・これは、たとえ製作者が「これは装飾なんだ！」と主張しても文字が入るような画像は背景画像に指定はいけません。

7.1.3.2

②単語の文字間にスペースやタグを用いない
単語の文字間なので、「、」「。」の後は、スペースが入っててもOK!勿論altにも同じことがいえます。だからと言って、余白のためにスペースを入れる事は避けましょう。基本的に余白はCSSで設定しましょう。

7.1.4.1

③リンク又はコントロールを色だけで識別している箇所の視覚的な手がかりを補足するために、周囲にあるテキストとのコントラスト比を 3:1 以上にする
・できればリンクのhover状態の色もコントラスト比を考えるべき

その他、話題にあがったもの～

• カルーセルは停止・再開ができるようにする
• カルーセルのマークアップは、liがベター
• カルーセルのナビなどにforcusがあたっているか分るようにする
• カルーセルは、タブ移動した場合ぬけれるようにする
• 動画などを背景にしたり、背景にアニメーションがあるものは、ユーザーが止めることができるようにする。背景動画とか結構あるけど、ありゃダメだったか。
  参考2.2.2 一時停止、停止、非表示: 動きのある、点滅している、スクロールする、又は自動更新する情報に対しては、次のすべての事項を満たしている： (レベルA)
• ページ上部にある、ロゴ画像は、装飾ではないので、画像を入れたらいい
• 見出しを太字にするためだけに入れる<strong>はあまりよくありません
• JSやCSSを切ったとき、情報が線形になった状態で、情報は伝わりますか？
  例）「右側のボタン」などの表記はCSSが崩れるとダメですよね～

所感

実際のチェックは大変でした。本当に日本語から「ハテ？」といったカンジで、どのグループもそこがなかなか大変だったのでは？と思います。

だた、今回の勉強会がこのシリーズの中で一番、実践的な収穫が大きかったのでは？と思います。やっぱり実際のサイトだったしね。

まとめにも、たくさん出てきていますが、やっぱり議論の中心となったのは「スライダー」www！
まだまだスライダーは活躍しそうですし、来年はココに的を絞ってやろうかな？と考えています。

あとグローバルナビゲーション（ドロップダウンつき）もタブ移動でどう見せる？とういのも意見ありましたねー

うんうん。来年も盛りだくさんになりそー！！！

今年の最後に感謝を！
「D2D アクセシビリティ勉強会」をシリーズ化できたこと、協力してもらった方々、勉強会に参加していただいた方々、あと、巻き込まれちゃった@SawadaStdDesignさんw。。。本当に感謝しております！！来年もどうぞよろしくお願いします！

では、次回は二月ですよー！乞うご期待☆

投稿 第3回 D2D アクセシビリティ勉強会：アクセシビリティをチェックしてみよう！ は CodingMania に最初に表示されました。

個人的には、キーボードの「j」「k」で画面がスクロールできたり、facebookやTwitter、Gmailでは「shift + ?」でショートカット一覧が表示されるというのは、オドロキとさすがだなという感じでした。チャンとやってるんだなー。
Firefoxでは、「F7」キーで、キャレットブラウザモードというのがあって、Webページにカーソルが表示され、キーボードでテキストを選択できるとか。

本編では、アクセシビリティの実装で悩んだときに、一人で解決する方法。アクセシビリティに関する情報の位置づけから、どう辿って情報を探し出すのかを基礎から話をしていただきました。

@SawadaStdDesignさんに勉強会当日のスライドを公開していただきました。
「JIS X 8341-3:2010 を一人で読めるようになろう」

タイトルが面白すぎ！！ですが、かなりチャントしたみるくさんの勉強会レポです。こちらも是非！
第2回 D2D アクセシビリティ勉強会で短く熱く語ったり長く縛ったり。

はじめに

WAICというのは、ウェブアクセシビリティ基盤委員会のこと。
WCAG2.0というのは、ウェブコンテンツ・アクセシビリティ・ガイドラインのこと。W3C勧告。英語。

忘れてはならない、アクセシビリティの一般的原則！

・知覚可能＝情報の存在を知り、得られなきゃダメ
・操作可能＝操作が出来なきゃダメ
・理解可能＝得た情報は理解できなきゃダメ
・頑健性＝様々なユーザーエージェントが解釈できなきゃダメ

引用//当日のスライドP30より

この情報が本当に大切！なにかに迷ったらココで調べます。

・ウェブ・コンテンツ・アクセシビリティ・ガイドライン（WCAG）2.0
・WCAG 2.0 解説書
・WCAG 2.0 実装方法集
・アクセシビリティ・サポーテッド（AS）情報

ウェブアクセシビリティ基盤委員会のサイトの下のほうにあります。

アクセシビリティ・サポーテッド（AS）情報というのは、WAICが日本のユーザエージェントで調査した結果及びその実装方法が達成基準を満たしているかどうか細か～く掲載されています。
こんな情報があったのか…と言ったら叱られそうだけど、全く存じ上げずスイマセンでした。

敷居が高くてなかなか踏み込めない「JIS X8341-3:2010」は、2015年版の公示に向けて準備されているようです。
PDFは購入可能。今回は冊子を拝見することができましたが、文字だらけで正直心が折れました。。。

実践してみました！

勉強会の後半では、実際にみんなで情報を探してみるというのをやりました。

【お題】テーブルに要約を付けた方がいいと聞いたので、追加することにした。

私のチームでは、まず①WAICのサイトから「③WCAG 2.0 実装方法集」のページで実装方法を確認しました。
ズラリと実装方法が掲載されているので「table」で検索にかけて、「④H73: table要素のsummary属性を用いて、データテーブルの概要を提供する」を探し出します

ここで、達成基準 1.3.1 (情報及び関係性)に情報が属することと。コード例の「summary属性」を使ってテーブルの説明をいれることを確認しました。

その後、実際に利用者が利用可能であるかどうか（達成基準を満たしているかどうか）を判断するため「①アクセシビリティ・サポーテッド（AS）情報」の③2014年6月版 HTML形式で、確認します。
達成基準 1.3.1ということは、前に（JIS X 8341-3:2010の箇条７の）「7」をつけて、「④7.1.3.1 情報及び関係性に関する達成基準」をリスト上から見つけます。
ここの表内に「⑤H73-1: table要素のsummary属性を用いて、データテーブルの概要を提供する」のページを確認すると、見解としては「要注意」ですね。

注意点・備考にその説明があります。
今回で言うと、スクリーンリーダーのPC-Talkerが対応していない。2014年2月現在のHTML5の仕様案にはsummary属性は含まれておらず、廃止される方向である。っていう感じで要注意。

テスト結果の詳細には、ユーザーエージェント（ブラウザなど）のバージョンごとに細かくテストした結果が掲載されています。

所感

調べるのにそんなに手間がかかるの～？と思われた方もいらっしゃるかもしれませんが、日常よくやるjQueryのプラグイン探しと比較すれば、手順があって答えを書いてあるページがあるんです。ダイジョーブデキル！

勉強会での話にもありましたが、コーディングするときによく決めるブラウザをどこまでフォローする？という話をアクセシビリティをどこまでフォローする？もあわせてちゃんと決めなくてはいけないねーという話もありました。
それによって、やるべきことが変わってくるということですね。

ちなみにスクリーンリーダーのシェアは、PC-Talkerが8割。利用者が多いのでフォローするメリットも高いですねーという話もありました。

第一回の質問より、下記リンクをここにも掲載しておきます。
・等級A準拠ページを作るのに満たすべき達成基準がパッと見てわかる一覧
・達成基準を満たせる実装方法の一覧

今回、初めての勉強会振り返り記事を書きました。
あんなに勉強会に行っているのに、このアウトプットの少なさは課題であったので、文章の練習がてら今年はちょっとづつ出したいですね。。。

投稿 第2回 D2D アクセシビリティ勉強会：基礎編 は CodingMania に最初に表示されました。