アクセシビリティのはじめかた デザイナー編

2024/7/19に開催されたアクセシビリティ入門会（ https://lu.ma/8ms836if ）の発表資料です。

下記リンクから、Google Slideでも閲覧できます。
https://docs.google.com/presentation/d/1QX-yJPJ6F2ZHpDqjW6fUl1-cgLDY7UCcngww2iVDTHo/edit?usp=sharing

Transcript

1. アクセシビリティのはじめかた デザイナー編 2024.07.19 アクセシビリティ入門会 tokimari
2. 土岐 真里奈（tokimari） サイバーエージェント AmebaLIFE事業本部 フロントエンドエンジニア Ameba Accessibility Teamでアクセシビリティの普及に取り組んでいる 酒とハンドメイドが好きな二児の母
4. 今日お話しすること アクセシビリティって何？ アクセシビリティ、あるある問題（デザイン編）
 なぜやるの？
 Amebaではどうしてる？
 何からはじめればいい？
5. アクセシビリティって何？
6. アクセシビリティって何？ 対象のサービスやコンテンツへのアクセスのしやすさ、利用しやすさ
7. ユーザビリティとのちがい • アクセシビリティ より幅広い利用者・状況で利用できるか • ユーザビリティ 特定のユーザーが有効的に、効率的に、 満足度高く利用できるか アクセシビリティを向上することで、 ユーザビリティも 向上することが多々ある
8. ユーザビリティとのちがい （例） コードの修正前・修正後 を示す画面 GitHubのコード変更の修正前・修正後を表す 画面
9. ユーザビリティとのちがい これでもわかる？ GitHubのコード変更の修正前・修正後を表す 画面に私が一部手を加えたものを、2型2色覚 の人の典型的な見え方をシミュレーションし た図
10. ユーザビリティとのちがい これなら？ GitHubのコード変更の修正前・修正後を表す 画面を、2型2色覚の人の典型的な見え方をシ ミュレーションした図
11. ユーザビリティとのちがい これなら？ GitHubのコード変更の修正前・修正後を表す 画面を、2型2色覚の人の典型的な見え方をシ ミュレーションした図
12. ユーザビリティとのちがい • アクセシビリティ ◦ 色の識別が困難なユーザーでもどちらが修正前・ 修正後かが理解できる • ユーザビリティ ◦ 色の識別が困難ではないユーザーが、「赤は修正 前・緑は修正後」と直感的にわかりやすく、効率 的に情報を理解できる • 情報を色だけで区別すると 「アクセシビリティ」上の問題がある
13. ユーザビリティとのちがい こうするともっと、 わかりやすい 区別に使っている要素： • 色 • オブジェクト（+, -） • レイアウト GitHubのコード変更の修正前・修正後を表す画面（２カラ ム表示）
14. ユーザビリティとのちがい 色の区別が難しくても、 わかりやすい 区別に使っている要素： • （色） • オブジェクト（+, -） • レイアウト GitHubのコード変更の修正前・修正後を表す画面（２カラム 表示）を、2型2色覚の人の典型的な見え方をシミュレーションした 図
15. アクセシビリティ、あるある問題 デザイン編
16. • WCAG（Web Content Accessibility Guidelines）を参考に ◦ アクセシビリティの世界的なガイドライン ◦ WCAG 2.2には86個の達成基準（守るべきこと） • 適合レベルA, AA, AAAで分類される ◦ A：最低限の基準。達成できないと、支援技術を使っても利用できない ◦ AA：望ましい基準。達成できないと、支援技術なしでは利用できない ◦ AAA：発展的な基準。達成できると、よりアクセスしやすくなる場合がある • Aの中でも「非干渉」と呼ばれる4つは特に致命的な問題を起こす ◦ 他のコンテンツまで利用できなくなる可能性がある アクセシビリティの問題の分類
17. 1. 他のコンテンツまで利用できない（非干渉） 2. 利用できない（A） 3. 利用にはツールが必要（AA） 4. より利用しやすくするために（AAA） アクセシビリティの問題の分類
18. 1. 他のコンテンツまで利用できない（非干渉） • 動画やアニメーションを自動で再生している ◦ 5秒以上続く場合、集中できなくなり他のコンテンツを理解できない ◦ →自動で再生しない or 停止できるようにする • 音声を自動で再生している ◦ スクリーンリーダーでは、画面上の文字を音声で読み上げて操作している ◦ 3秒以上続く音声が自動再生されると操作自体ができなくなる
19. • 点滅（1秒に3回以上）している動画・アニメーションがある ◦ 「ポケモンショック」と呼ばれる、1997年に起きた有名な放送事故 ◦ 攻撃の演出で、4秒間で106回点滅 ◦ 視聴者が「光過敏性発作」などを起こし救急搬送 ◦ 一つのテレビ番組を見ていたことで700人近くが病院に搬送されたのは、世界のテレ ビ史上初の出来事であったとされる ポケモンショック - Wikipediaより抜粋 1. 他のコンテンツまで利用できない（非干渉）
20. 1. 他のコンテンツまで利用できない（非干渉） 2. 利用できない（A） 3. 利用するにはツールが必要（AA） 4. より利用しやすくするために（AAA） アクセシビリティの問題の分類
21. 2. 利用できない（A） • 色だけでコンテンツを区別している ◦ 色覚特性を持つユーザーや、白黒印刷で理解できない ◦ →色以外の要素でも区別できるようにする（オブジェクト、レイアウトなど） GitHubのコード変更の修正前・修正後を表す画面（２カラム表示）
22. • エラーのある入力項目に エラー内容を表示していない ◦ 「どれ？」 ◦ 「どうすればいいの？」 2. 利用できない（A） エラーのある入力項目を示し ていない エラーのある箇所をハイライト し、エラー内容を表示している
23. • 入力欄に入力内容を示すラベルがない （プレースホルダーをラベルに使っている） ◦ 「何を入力していたんだっけ？」 ◦ プレースホルダーテキストは 色が薄過ぎて視認性が低い （読めない） 2. 利用できない（A） プレースホルダーで入力内容 を示している ラベルで入力内容を示している
24. 2. 利用できない（A） • ジェスチャーだけでしか操作できない （スワイプ、ピンチイン・アウト、ドラッグ＆ド ロップなど) ◦ スマホに不慣れな人はこの操作方法に気 付けない ◦ 身体的な障害や持ち方によっては、スワ イプができないため操作できない この機能自体はとても便利 この機能「だけ」だとダメ 左にスワイプして削除エリアを表示し、そのままスワ イプして削除する操作方法
25. 2. 利用できない（A） • ジェスチャーだけでしか操作できない （スワイプ、ピンチイン・アウト、ドラッグ＆ド ロップなど) ◦ 画面上の文字を知覚できれば操作できる ◦ タップ操作だけでも操作できる 左上の編集ボタンをタップし、リストの×ボタンをタップ するか、左スワイプで削除エリアを表示する操作方法
26. 1. 他のコンテンツまで利用できない（非干渉） 2. 利用できない（A） 3. 利用するにはツールが必要（AA） 4. より利用しやすくするために（AAA） アクセシビリティの問題の分類
27. 3. 利用にはツールが必要（AA） • テキストや文字画像のコントラストが低い ◦ 中度のロービジョンの人が読めない ▪ 弱視・高齢者 ◦ 閲覧状況・環境・デバイスによっては読めない ▪ メガネを忘れてしまった ▪ 炎天下の作業現場 ▪ モニターの輝度 ▪ 投影したとき ◦ →文字色：背景色は4.5:1以上にする 低い コントラスト #d9d9d9 1.41:1 高めの コントラスト #757575 4.65:1
28. 3. 利用にはツールが必要（AA） • 操作可能なUIのフォーカスの状態が見えない ◦ キーボードで操作するユーザーには、どこにフォーカスしているかわからず操作で きない フォーカスが表示されていない フォーカスが表示されている
29. 3. 利用にはツールが必要（AA） • 画面を400%まで拡大すると、情報が見切れてしまう ◦ ロービジョンのユーザーが画面・文字拡大時にコンテンツが見切れたり、横スク ロールしないと読むことができない ◦ →レスポンシブデザイン（適切に折り返されるよう）にする 画面拡大するとコンテンツが見切れ、横スクロール もできないので読むことができない 画面拡大すると適切に折り返され、横スクロー ルなしに全ての情報を読むことができる
30. 1. 他のコンテンツまで利用できない（非干渉） 2. 利用できない（A） 3. 利用するにはツールが必要（AA） 4. より利用しやすくするために（AAA） アクセシビリティの問題の分類
31. 4. より利用しやすくするために（AAA） • パララックスアニメーションを止められない ◦ 酔う（めまい、吐き気、偏頭痛などを起こす） ◦ →モーションがなくても理解・利用できるデザインにする ▪ 「視差効果を減らす」「アニメーションの削除」などの設定をオンにしている 時にモーションを停止できるようにする
32. • パララックスアニメーションを止められない（例） 「視差効果を減らす」設定をしていない時の表示 画面表示時にムービーが自動ではじまり、スクロール時に も背景で動画が動いていたり、スクロールに応じて要素が 動く。右下に停止ボタンがある。 「視差効果を減らす」設定をオンにしている時の表示 初期表示のムービーはカットされ、スクロール後の20のロ ゴもなく、アニメーションもほぼなくなっている。右下の 停止ボタンもない。ページで得られる情報量は同じ。 4. より利用しやすくするために（AAA） Ameba20周年記念サイト | つくる、つむぐ、つづく、Ameba LIFEより
33. • タップエリアが44px × 44pxよりも小さい ◦ 指のサイズよりも小さいものは誤タップしてしまう 4. より利用しやすくするために（AAA） 画像: ユーザーインターフェイスのデザインのヒント - Apple Developerより
34. なぜやるの？
35. 1. ユーザビリティを向上するため 2. 誰でもいつでも利用できるようにするため 3. あらゆるデバイスやブラウザに対応しやすいから 4. 法令遵守のため 5. デザインの判断基準として
36. ユーザビリティとのちがい • アクセシビリティ より幅広い利用者・状況で利用できるか • ユーザビリティ 特定のユーザーが有効的に、効率的に、 満足度高く利用できるか アクセシビリティを向上することで、 ユーザビリティも 向上することが多々ある
37. 「アクセシビリティ＝障害者対応」ではない • 誰でも（利用者） ◦ 障害者、高齢者、子どもでも、スマホに不慣れな人でも、初めてきた人でも • いつでも（状況） ◦ 電車内で音声が出せないときでも ◦ 炎天下の作業現場で画面が見づらいときも 2.誰でもいつでも利用できるようにするため
38. 2.誰でもいつでも利用できるようにするため 「アクセシビリティ＝障害者対応」ではない • 誰でも（利用者） ◦ 障害者、高齢者、子どもでも、スマホに不慣れな人でも、初めてきた人でも • いつでも（状況） ◦ 電車内で音声が出せないときでも ◦ 炎天下の作業現場で画面が見づらいときも あくまでアクセシビリティの恩恵を受けるユーザー属性の一つ
39. 3.あらゆるデバイスやブラウザに対応しやすいから • 画面拡大や文字拡大に対応できるデザイン ◦ →あらゆるサイズのデバイスでも表示可能に（レスポンシブデザインにできる） PC向けの表示 400%まで拡大したところ。SPのレイアウトになっている SP向けの表示
40. • 実装も改善することで ◦ →画面上の「何が重要か・どんな意味か」などを読み取れるように ▪ 見出し、画像の意味、リンク先との紐付け、メインコンテンツ、補足情報など • 結果的に ◦ 障害者向けのソフトウェアやデバイスだけでなく ◦ スマートウォッチなどの新しいデバイス、ブラウザにも適応できるように • アクセシビリティを高める → 他デバイス・ブラウザへの転用性も高まる 3.あらゆるデバイスやブラウザに対応しやすいから
41. • 2024年4月、障害者差別解消法が改正 • 民間事業者にも「合理的配慮の提供」が 義務化された • 障害を理由に利用できないなどの問い合 わせを受けた場合、建設的な対話を通じ て代替手段を提案し、合理的な範囲での 柔軟な対応が求められる 4.法令遵守のため 画像：リーフレット「令和６年４月１日から合理的配慮の提供が義務化されました」 - 内閣府 https://www8.cao.go.jp/shougai/suishin/sabekai_leaflet-r05.html より
42. どういうこと？？？ 難しそう…
43. （例） ユーザーの声 「視覚障害者です。 　ブログ記事の投稿ができません。」
44. ユーザー自身の障害を理由に利用を断るのは 「不当な差別的取扱い」にあたる （NGな返信例） 「視覚障害者の方はご利用いただけません」 「視覚障害者の方のブログ記事投稿はサポート対象外です」
45. 4.法令遵守のため どうすれば？ • 具体的な情報をヒアリングし、原因と改善が可能かを検討 • すぐに改善できない場合 ◦ 理由と暫定的な対処方法や代替手段の提案など ◦ 状況に応じた対応案の検討が必要 ◦ 例：〜〜の次のボタンを実行すると投稿できる、メールでブログ投稿ができる 普段のお問合せ対応と同じ
46. アクセシビリティ上の問題を放置すると？ • 問い合わせごとに、個別に検討し対応が必要になる ◦ 障害の程度は人それぞれ、困りごとや解決法もバラバラ ◦ 「視覚障害者＝テキストが読めない」といった決めつけはNG • 改善すると？ ◦ 問い合わせたユーザー以外も使えるようになる（今後の個別対応が不要に） ◦ 継続的に負担を軽く、より効果的に提供できる 4.法令遵守のため
47. 5.デザインの判断基準として テキストや文字画像は文字色：背景色の コントラスト比を4.5:1以上にする というガイドライン 低い コントラスト #d9d9d9 1.41:1 高めの コントラスト #757575 4.65:1
48. なぜ4.5:1？
49. 5.デザインの判断基準として • WCAG：定量的な指標をもとに基準値を定めている • 80歳前後の高齢者の、典型的な視力0.5のコントラスト感度に合わせ て設定されている 達成基準 1.4.3: コントラスト (最低限)を理解するより要約
50. 5.デザインの判断基準として • 特定のユーザーや特定の状況下での限界値を、それぞれの経験や想像 でカバーするのは難しい ◦ デザイナーごとに判断軸がブレることも • アクセシビリティの定量的指標を判断基準に
51. 5.デザインの判断基準として • 各OSのデザインガイドラインもアクセシビリティをベースに設計 ◦ コントラスト比についても記載あり （左）Color and effects - Accessibility | Apple Developer Documentation より （右）Contrast ratios - Accessibility designing – Material Design 3 より
52. デザインの判断基準として アクセシビリティを 「追加の対応項目」ではなく 「デザインの要件」として捉えている
53. Amebaではどうしてる？
54. デザインシステムでのしくみ化
55. デザインシステムでのしくみ化 Spindleカラーパレットを適切に使えば コントラスト比が担保される • UIで使われる全ての色 • どこにどの色が使われるかの定義 • 全てコントラスト比を考慮 詳しくは「Ameba」15年の負債を払拭するカラーパレットのメソッド | CyberAgent Developers Blog で！
56. デザインシステムでのしくみ化 コンポーネント単位で アクセシビリティチェックを実施 • 情報や関係性を明確にする[基本必須] • 色だけで伝えない[基本必須] • テキストのコントラストを確保する[基本必須] • キーボード、タッチデバイスで操作できる[基本必須] • 現在位置を確認できる[できれば] Spindle UI UnderlineTabのDesign Docより抜粋
57. • 用語の統一 ◦ アメーバ → Ameba ◦ アメーバブログ → Amebaブログ ◦ Ameba ID → アメーバID • 文章校正 デザインシステムでのしくみ化
58. デザインシステムでのしくみ化 Figmaプラグイン エンジニア向けのtextlintのルールセットや Slack botとして展開
59. ここで一句 Spindle 使っていれば アクセシブル
60. 何からはじめればいい？
61. • 1人でも取り組めるものをまずはやってみる ◦ コンポーネント単位、画面単位など • 自慢する ◦ 何がアクセシビリティ上の問題になるのか ◦ どう使い勝手が向上するのか ◦ 社内Slack、チームのSlackでメンバーに向けて ◦ スタッフブログ、Xでユーザーに向けて 小さなアウトプットからはじめる
62. • デザインや実装だけではできないことも多い、続かない • 興味を持ってくれた（くれそうな）人を仲間に誘う ◦ 個別に、直接誘う（募集してもだめ、皆それぞれ忙しい） ◦ 共感して一緒に取り組む人が3人いればチームに • チームができれば継続しやすい ◦ Ameba Accessibility Teamは、メンバーが入れ替わっても持続するチームに ◦ （2017年に活動を始めてから、私は２回休職しています） 2人目の仲間をつくる
63. Amebaでの取り組み例 • 輪読会 • スクリーンリーダー体験会 • オンボーディング、研修 • レビュー・テストに、アクセシビリティ観点のチェック項目を追加 • 抜き打ちテスト（イベント的に） ◦ 今日のデザインワークショップ • アクセシビリティ改善ワークショップ ◦ バナーのコントラスト改善 ◦ わざとアクセシビリティに問題のあるLPを作ってコードレビューしたり 継続するしくみをつくる
64. Amebaでの取り組み例 • システムやプロジェクト単位でアクセシビリティ方針を作成する ◦ 無理な目標を掲げない ▪ はじめから完璧を目指すと挫折しやすい ▪ ある人には、1つの改善だけでも「使える」ようになるかも ◦ やる、やらないを明確にしておく ▪ 後から手戻りするロスを防ぐ ◦ 他職種を巻き込み合意を得る ▪ →小規模なチーム単位がやりやすい ▪ やる→自慢→前例になる→仲間を増やす 継続するしくみをつくる
65. おすすめのインプット 書籍 見えにくい、読みにくい 
 「困った！」を解決するデザイン 
 デザイニング
 Webアクセシビリティ 
 Webアプリケーション 
 アクセシビリティ

66. おすすめのインプット 勉強会 • Discord「ウェブアクセシビリティ」 やXで情報収集 ◦ イベント情報、質問など、有識者も多く参加している ◦ 初心者向けのLT会もたくさん行われている • ウェブアクセシビリティLT&交流会 vol.2　7/21(日) 13:30 〜 15:30（明後日！） • アクセシビリティカンファレンス名古屋　9/7(土) 13:00〜 • アクセシビリティカンファレンス福岡　11/30(土) 12:30 〜 19:30 • 例年5月に開催 ◦ GAAD Japan（オンライン開催＋各地でパブリックビューイングなど） ◦ アクセシビリティの祭典（神戸）
67. Webで知れる • ウェブアクセシビリティ導入ガイドブック｜デジタル庁 ◦ 考え方、取り組み方のポイントを解説する、ゼロから学ぶ初心者向けのガイドブック • accrefs ◦ 有志メンバーで運営されているWebアクセシビリティの参考資料まとめ • AAA11Y Accessible Website Gallery ◦ アクセシビリティに配慮したWebデザイン ギャラリー・サイト おすすめのインプット
68. おすすめのインプット 各社のガイドライン • Ameba Accessibility Guidelines ◦ Amebaの開発・運用者向けのガイドライン ◦ アクセシビリティに馴染みがなくてもわかりやすく • freeeアクセシビリティー・ガイドライン ◦ アクセシビリティー・チェック・リスト ◦ アクセシビリティー・チェックのためのツール • アクセシビリティ | SmartHR Design System ◦ 簡易的なチェックリスト ◦ はじめてガイド ◦ UIデザイン使用性チェックリスト
69. Thank you! https://spindle.ameba.design/ AmebaA11y ameba-accessibility