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

by tokimari

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

土岐真里奈（tokimari）サイバーエージェント AmebaLIFE事業本部フロントエンドエンジニア Ameba Accessibility Teamでアクセシビリティの普及に取り組んでいる酒とハンドメイドが好きな二児の母

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

今日お話しすることアクセシビリティって何？アクセシビリティ、あるある問題（デザイン編）  なぜやるの？  Amebaではどうしてる？  何からはじめればいい？

Slide 5

Slide 5 text

アクセシビリティって何？

Slide 6

Slide 6 text

アクセシビリティって何？対象のサービスやコンテンツへのアクセスのしやすさ、利用しやすさ

Slide 7

Slide 7 text

ユーザビリティとのちがい ● アクセシビリティより幅広い利用者・状況で利用できるか ● ユーザビリティ特定のユーザーが有効的に、効率的に、満足度高く利用できるかアクセシビリティを向上することで、ユーザビリティも向上することが多々ある

Slide 8

Slide 8 text

ユーザビリティとのちがい（例）コードの修正前・修正後を示す画面 GitHubのコード変更の修正前・修正後を表す画面

Slide 9

Slide 9 text

ユーザビリティとのちがいこれでもわかる？ GitHubのコード変更の修正前・修正後を表す画面に私が一部手を加えたものを、2型2色覚の人の典型的な見え方をシミュレーションした図

Slide 10

Slide 10 text

ユーザビリティとのちがいこれなら？ GitHubのコード変更の修正前・修正後を表す画面を、2型2色覚の人の典型的な見え方をシミュレーションした図

Slide 11

Slide 11 text

ユーザビリティとのちがいこれなら？ GitHubのコード変更の修正前・修正後を表す画面を、2型2色覚の人の典型的な見え方をシミュレーションした図

Slide 12

Slide 12 text

ユーザビリティとのちがい ● アクセシビリティ ○ 色の識別が困難なユーザーでもどちらが修正前・修正後かが理解できる ● ユーザビリティ ○ 色の識別が困難ではないユーザーが、「赤は修正前・緑は修正後」と直感的にわかりやすく、効率的に情報を理解できる ● 情報を色だけで区別すると「アクセシビリティ」上の問題がある

Slide 13

Slide 13 text

ユーザビリティとのちがいこうするともっと、わかりやすい区別に使っている要素： ● 色 ● オブジェクト（+, -） ● レイアウト GitHubのコード変更の修正前・修正後を表す画面（２カラム表示）

Slide 14

Slide 14 text

ユーザビリティとのちがい色の区別が難しくても、わかりやすい区別に使っている要素： ● （色） ● オブジェクト（+, -） ● レイアウト GitHubのコード変更の修正前・修正後を表す画面（２カラム表示）を、2型2色覚の人の典型的な見え方をシミュレーションした図

Slide 15

Slide 15 text

アクセシビリティ、あるある問題デザイン編

Slide 16

Slide 16 text

● WCAG（Web Content Accessibility Guidelines）を参考に ○ アクセシビリティの世界的なガイドライン ○ WCAG 2.2には86個の達成基準（守るべきこと） ● 適合レベルA, AA, AAAで分類される ○ A：最低限の基準。達成できないと、支援技術を使っても利用できない ○ AA：望ましい基準。達成できないと、支援技術なしでは利用できない ○ AAA：発展的な基準。達成できると、よりアクセスしやすくなる場合がある ● Aの中でも「非干渉」と呼ばれる4つは特に致命的な問題を起こす ○ 他のコンテンツまで利用できなくなる可能性があるアクセシビリティの問題の分類

Slide 17

Slide 17 text

1. 他のコンテンツまで利用できない（非干渉） 2. 利用できない（A） 3. 利用にはツールが必要（AA） 4. より利用しやすくするために（AAA）アクセシビリティの問題の分類

Slide 18

Slide 18 text

1. 他のコンテンツまで利用できない（非干渉） ● 動画やアニメーションを自動で再生している ○ 5秒以上続く場合、集中できなくなり他のコンテンツを理解できない ○ →自動で再生しない or 停止できるようにする ● 音声を自動で再生している ○ スクリーンリーダーでは、画面上の文字を音声で読み上げて操作している ○ 3秒以上続く音声が自動再生されると操作自体ができなくなる

Slide 19

Slide 19 text

● 点滅（1秒に3回以上）している動画・アニメーションがある ○ 「ポケモンショック」と呼ばれる、1997年に起きた有名な放送事故 ○ 攻撃の演出で、4秒間で106回点滅 ○ 視聴者が「光過敏性発作」などを起こし救急搬送 ○ 一つのテレビ番組を見ていたことで700人近くが病院に搬送されたのは、世界のテレビ史上初の出来事であったとされるポケモンショック - Wikipediaより抜粋 1. 他のコンテンツまで利用できない（非干渉）

Slide 20

Slide 20 text

1. 他のコンテンツまで利用できない（非干渉） 2. 利用できない（A） 3. 利用するにはツールが必要（AA） 4. より利用しやすくするために（AAA）アクセシビリティの問題の分類

Slide 21

Slide 21 text

2. 利用できない（A） ● 色だけでコンテンツを区別している ○ 色覚特性を持つユーザーや、白黒印刷で理解できない ○ →色以外の要素でも区別できるようにする（オブジェクト、レイアウトなど） GitHubのコード変更の修正前・修正後を表す画面（２カラム表示）

Slide 22

Slide 22 text

● エラーのある入力項目にエラー内容を表示していない ○ 「どれ？」 ○ 「どうすればいいの？」 2. 利用できない（A）エラーのある入力項目を示していないエラーのある箇所をハイライトし、エラー内容を表示している

Slide 23

Slide 23 text

● 入力欄に入力内容を示すラベルがない（プレースホルダーをラベルに使っている） ○ 「何を入力していたんだっけ？」 ○ プレースホルダーテキストは色が薄過ぎて視認性が低い（読めない） 2. 利用できない（A）プレースホルダーで入力内容を示しているラベルで入力内容を示している

Slide 24

Slide 24 text

2. 利用できない（A） ● ジェスチャーだけでしか操作できない（スワイプ、ピンチイン・アウト、ドラッグ＆ドロップなど) ○ スマホに不慣れな人はこの操作方法に気付けない ○ 身体的な障害や持ち方によっては、スワイプができないため操作できないこの機能自体はとても便利この機能「だけ」だとダメ左にスワイプして削除エリアを表示し、そのままスワイプして削除する操作方法

Slide 25

Slide 25 text

2. 利用できない（A） ● ジェスチャーだけでしか操作できない（スワイプ、ピンチイン・アウト、ドラッグ＆ドロップなど) ○ 画面上の文字を知覚できれば操作できる ○ タップ操作だけでも操作できる左上の編集ボタンをタップし、リストの×ボタンをタップするか、左スワイプで削除エリアを表示する操作方法

Slide 26

Slide 26 text

Slide 27

Slide 27 text

3. 利用にはツールが必要（AA） ● テキストや文字画像のコントラストが低い ○ 中度のロービジョンの人が読めない ■ 弱視・高齢者 ○ 閲覧状況・環境・デバイスによっては読めない ■ メガネを忘れてしまった ■ 炎天下の作業現場 ■ モニターの輝度 ■ 投影したとき ○ →文字色：背景色は4.5:1以上にする低いコントラスト #d9d9d9 1.41:1 高めのコントラスト #757575 4.65:1

Slide 28

Slide 28 text

3. 利用にはツールが必要（AA） ● 操作可能なUIのフォーカスの状態が見えない ○ キーボードで操作するユーザーには、どこにフォーカスしているかわからず操作できないフォーカスが表示されていないフォーカスが表示されている

Slide 29

Slide 29 text

3. 利用にはツールが必要（AA） ● 画面を400%まで拡大すると、情報が見切れてしまう ○ ロービジョンのユーザーが画面・文字拡大時にコンテンツが見切れたり、横スクロールしないと読むことができない ○ →レスポンシブデザイン（適切に折り返されるよう）にする画面拡大するとコンテンツが見切れ、横スクロールもできないので読むことができない画面拡大すると適切に折り返され、横スクロールなしに全ての情報を読むことができる

Slide 30

Slide 30 text

Slide 31

Slide 31 text

4. より利用しやすくするために（AAA） ● パララックスアニメーションを止められない ○ 酔う（めまい、吐き気、偏頭痛などを起こす） ○ →モーションがなくても理解・利用できるデザインにする ■ 「視差効果を減らす」「アニメーションの削除」などの設定をオンにしている時にモーションを停止できるようにする

Slide 32

Slide 32 text

● パララックスアニメーションを止められない（例）「視差効果を減らす」設定をしていない時の表示画面表示時にムービーが自動ではじまり、スクロール時にも背景で動画が動いていたり、スクロールに応じて要素が動く。右下に停止ボタンがある。「視差効果を減らす」設定をオンにしている時の表示初期表示のムービーはカットされ、スクロール後の20のロゴもなく、アニメーションもほぼなくなっている。右下の停止ボタンもない。ページで得られる情報量は同じ。 4. より利用しやすくするために（AAA） Ameba20周年記念サイト | つくる、つむぐ、つづく、Ameba LIFEより

Slide 33

Slide 33 text

● タップエリアが44px × 44pxよりも小さい ○ 指のサイズよりも小さいものは誤タップしてしまう 4. より利用しやすくするために（AAA）画像: ユーザーインターフェイスのデザインのヒント - Apple Developerより

Slide 34

Slide 34 text

なぜやるの？

Slide 35

Slide 35 text

1. ユーザビリティを向上するため 2. 誰でもいつでも利用できるようにするため 3. あらゆるデバイスやブラウザに対応しやすいから 4. 法令遵守のため 5. デザインの判断基準として

Slide 36

Slide 36 text

Slide 37

Slide 37 text

「アクセシビリティ＝障害者対応」ではない ● 誰でも（利用者） ○ 障害者、高齢者、子どもでも、スマホに不慣れな人でも、初めてきた人でも ● いつでも（状況） ○ 電車内で音声が出せないときでも ○ 炎天下の作業現場で画面が見づらいときも 2.誰でもいつでも利用できるようにするため

Slide 38

Slide 38 text

2.誰でもいつでも利用できるようにするため「アクセシビリティ＝障害者対応」ではない ● 誰でも（利用者） ○ 障害者、高齢者、子どもでも、スマホに不慣れな人でも、初めてきた人でも ● いつでも（状況） ○ 電車内で音声が出せないときでも ○ 炎天下の作業現場で画面が見づらいときもあくまでアクセシビリティの恩恵を受けるユーザー属性の一つ

Slide 39

Slide 39 text

3.あらゆるデバイスやブラウザに対応しやすいから ● 画面拡大や文字拡大に対応できるデザイン ○ →あらゆるサイズのデバイスでも表示可能に（レスポンシブデザインにできる） PC向けの表示 400%まで拡大したところ。SPのレイアウトになっている SP向けの表示

Slide 40

Slide 40 text

● 実装も改善することで ○ →画面上の「何が重要か・どんな意味か」などを読み取れるように ■ 見出し、画像の意味、リンク先との紐付け、メインコンテンツ、補足情報など ● 結果的に ○ 障害者向けのソフトウェアやデバイスだけでなく ○ スマートウォッチなどの新しいデバイス、ブラウザにも適応できるように ● アクセシビリティを高める → 他デバイス・ブラウザへの転用性も高まる 3.あらゆるデバイスやブラウザに対応しやすいから

Slide 41

Slide 41 text

● 2024年4月、障害者差別解消法が改正 ● 民間事業者にも「合理的配慮の提供」が義務化された ● 障害を理由に利用できないなどの問い合わせを受けた場合、建設的な対話を通じて代替手段を提案し、合理的な範囲での柔軟な対応が求められる 4.法令遵守のため画像：リーフレット「令和６年４月１日から合理的配慮の提供が義務化されました」 - 内閣府 https://www8.cao.go.jp/shougai/suishin/sabekai_leaﬂet-r05.html より

Slide 42

Slide 42 text

どういうこと？？？難しそう…

Slide 43

Slide 43 text

（例）ユーザーの声「視覚障害者です。　ブログ記事の投稿ができません。」

Slide 44

Slide 44 text

ユーザー自身の障害を理由に利用を断るのは「不当な差別的取扱い」にあたる（NGな返信例）「視覚障害者の方はご利用いただけません」「視覚障害者の方のブログ記事投稿はサポート対象外です」

Slide 45

Slide 45 text

4.法令遵守のためどうすれば？ ● 具体的な情報をヒアリングし、原因と改善が可能かを検討 ● すぐに改善できない場合 ○ 理由と暫定的な対処方法や代替手段の提案など ○ 状況に応じた対応案の検討が必要 ○ 例：〜〜の次のボタンを実行すると投稿できる、メールでブログ投稿ができる普段のお問合せ対応と同じ

Slide 46

Slide 46 text

アクセシビリティ上の問題を放置すると？ ● 問い合わせごとに、個別に検討し対応が必要になる ○ 障害の程度は人それぞれ、困りごとや解決法もバラバラ ○ 「視覚障害者＝テキストが読めない」といった決めつけはNG ● 改善すると？ ○ 問い合わせたユーザー以外も使えるようになる（今後の個別対応が不要に） ○ 継続的に負担を軽く、より効果的に提供できる 4.法令遵守のため

Slide 47

Slide 47 text

5.デザインの判断基準としてテキストや文字画像は文字色：背景色のコントラスト比を4.5:1以上にするというガイドライン低いコントラスト #d9d9d9 1.41:1 高めのコントラスト #757575 4.65:1

Slide 48

Slide 48 text

なぜ4.5:1？

Slide 49

Slide 49 text

5.デザインの判断基準として ● WCAG：定量的な指標をもとに基準値を定めている ● 80歳前後の高齢者の、典型的な視力0.5のコントラスト感度に合わせて設定されている達成基準 1.4.3: コントラスト (最低限)を理解するより要約

Slide 50

Slide 50 text

5.デザインの判断基準として ● 特定のユーザーや特定の状況下での限界値を、それぞれの経験や想像でカバーするのは難しい ○ デザイナーごとに判断軸がブレることも ● アクセシビリティの定量的指標を判断基準に

Slide 51

Slide 51 text

5.デザインの判断基準として ● 各OSのデザインガイドラインもアクセシビリティをベースに設計 ○ コントラスト比についても記載あり（左）Color and eﬀects - Accessibility | Apple Developer Documentation より（右）Contrast ratios - Accessibility designing – Material Design 3 より

Slide 52

Slide 52 text

デザインの判断基準としてアクセシビリティを「追加の対応項目」ではなく「デザインの要件」として捉えている

Slide 53

Slide 53 text

Amebaではどうしてる？

Slide 54

Slide 54 text

デザインシステムでのしくみ化

Slide 55

Slide 55 text

デザインシステムでのしくみ化 Spindleカラーパレットを適切に使えばコントラスト比が担保される ● UIで使われる全ての色 ● どこにどの色が使われるかの定義 ● 全てコントラスト比を考慮詳しくは「Ameba」15年の負債を払拭するカラーパレットのメソッド | CyberAgent Developers Blog で！

Slide 56

Slide 56 text

デザインシステムでのしくみ化コンポーネント単位でアクセシビリティチェックを実施 ● 情報や関係性を明確にする[基本必須] ● 色だけで伝えない[基本必須] ● テキストのコントラストを確保する[基本必須] ● キーボード、タッチデバイスで操作できる[基本必須] ● 現在位置を確認できる[できれば] Spindle UI UnderlineTabのDesign Docより抜粋

Slide 57

Slide 57 text

● 用語の統一 ○ アメーバ → Ameba ○ アメーバブログ → Amebaブログ ○ Ameba ID → アメーバID ● 文章校正デザインシステムでのしくみ化

Slide 58

Slide 58 text

デザインシステムでのしくみ化 Figmaプラグインエンジニア向けのtextlintのルールセットや Slack botとして展開

Slide 59

Slide 59 text

ここで一句 Spindle 使っていればアクセシブル

Slide 60

Slide 60 text

何からはじめればいい？

Slide 61

Slide 61 text

● 1人でも取り組めるものをまずはやってみる ○ コンポーネント単位、画面単位など ● 自慢する ○ 何がアクセシビリティ上の問題になるのか ○ どう使い勝手が向上するのか ○ 社内Slack、チームのSlackでメンバーに向けて ○ スタッフブログ、Xでユーザーに向けて小さなアウトプットからはじめる

Slide 62

Slide 62 text

● デザインや実装だけではできないことも多い、続かない ● 興味を持ってくれた（くれそうな）人を仲間に誘う ○ 個別に、直接誘う（募集してもだめ、皆それぞれ忙しい） ○ 共感して一緒に取り組む人が3人いればチームに ● チームができれば継続しやすい ○ Ameba Accessibility Teamは、メンバーが入れ替わっても持続するチームに ○ （2017年に活動を始めてから、私は２回休職しています） 2人目の仲間をつくる

Slide 63

Slide 63 text

Amebaでの取り組み例 ● 輪読会 ● スクリーンリーダー体験会 ● オンボーディング、研修 ● レビュー・テストに、アクセシビリティ観点のチェック項目を追加 ● 抜き打ちテスト（イベント的に） ○ 今日のデザインワークショップ ● アクセシビリティ改善ワークショップ ○ バナーのコントラスト改善 ○ わざとアクセシビリティに問題のあるLPを作ってコードレビューしたり継続するしくみをつくる

Slide 64

Slide 64 text

Amebaでの取り組み例 ● システムやプロジェクト単位でアクセシビリティ方針を作成する ○ 無理な目標を掲げない ■ はじめから完璧を目指すと挫折しやすい ■ ある人には、1つの改善だけでも「使える」ようになるかも ○ やる、やらないを明確にしておく ■ 後から手戻りするロスを防ぐ ○ 他職種を巻き込み合意を得る ■ →小規模なチーム単位がやりやすい ■ やる→自慢→前例になる→仲間を増やす継続するしくみをつくる

Slide 65

Slide 65 text

おすすめのインプット書籍見えにくい、読みにくい   「困った！」を解決するデザイン   デザイニング  Webアクセシビリティ   Webアプリケーション   アクセシビリティ 

Slide 66

Slide 66 text

おすすめのインプット勉強会 ● 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（オンライン開催＋各地でパブリックビューイングなど） ○ アクセシビリティの祭典（神戸）

Slide 67

Slide 67 text

Webで知れる ● ウェブアクセシビリティ導入ガイドブック｜デジタル庁 ○ 考え方、取り組み方のポイントを解説する、ゼロから学ぶ初心者向けのガイドブック ● accrefs ○ 有志メンバーで運営されているWebアクセシビリティの参考資料まとめ ● AAA11Y Accessible Website Gallery ○ アクセシビリティに配慮したWebデザインギャラリー・サイトおすすめのインプット

Slide 68

Slide 68 text

おすすめのインプット各社のガイドライン ● Ameba Accessibility Guidelines ○ Amebaの開発・運用者向けのガイドライン ○ アクセシビリティに馴染みがなくてもわかりやすく ● freeeアクセシビリティー・ガイドライン ○ アクセシビリティー・チェック・リスト ○ アクセシビリティー・チェックのためのツール ● アクセシビリティ | SmartHR Design System ○ 簡易的なチェックリスト ○ はじめてガイド ○ UIデザイン使用性チェックリスト

Slide 69

Slide 69 text

Thank you! https://spindle.ameba.design/ AmebaA11y ameba-accessibility