Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
開発チームみんなで取り組むアクセシビリティ
Search
ymrl
February 17, 2022
Technology
0
21k
開発チームみんなで取り組むアクセシビリティ
Developers Summit 2022
での登壇資料です
Google Slidesで閲覧するにはこちら
ymrl
February 17, 2022
Tweet
Share
More Decks by ymrl
See All by ymrl
Webサイトのアクセシビリティにどう向き合う? / How Should We Approach Web Accessibility?
ymrl
0
21
いま求められるソフトウェアのアクセシビリティ / Essential Accessibility in Software Today
ymrl
1
790
アクセシビリティを意識したプロダクトづくり / Creating Products with Accessibility in Mind
ymrl
0
20k
「Webアプリケーションアクセシビリティ」著者の会社 (freee, サイボウズ, SmartHR) での取り組みは実際どんな感じ?
ymrl
3
20k
やっぱりやりたいのはUIデザインだった
ymrl
0
25k
freeeのアクセシビリティの取り組みの紹介
ymrl
0
21k
アクセシビリティ アプリを企画する時点で考えること
ymrl
1
21k
Web技術基礎 for インターン
ymrl
1
7.4k
Webアクセシビリティ関連業務のためにブックマークレット書いてる
ymrl
0
200
Other Decks in Technology
See All in Technology
日本版とグローバル版のモバイルアプリ統合の開発の裏側と今後の展望
miichan
1
120
Amazon Kendra GenAI Index 登場でどう変わる? 評価から学ぶ最適なRAG構成
naoki_0531
0
100
alecthomas/kong はいいぞ / kamakura.go#7
fujiwara3
1
300
アップデート紹介:AWS Data Transfer Terminal
stknohg
PRO
0
170
Snykで始めるセキュリティ担当者とSREと開発者が楽になる脆弱性対応 / Getting started with Snyk Vulnerability Response
yamaguchitk333
2
180
How to be an AWS Community Builder | 君もAWS Community Builderになろう!〜2024 冬 CB募集直前対策編?!〜
coosuke
PRO
2
2.8k
1等無人航空機操縦士一発試験 合格までの道のり ドローンミートアップ@大阪 2024/12/18
excdinc
0
140
第3回Snowflake女子会_LT登壇資料(合成データ)_Taro_CCCMK
tarotaro0129
0
180
LINEスキマニにおけるフロントエンド開発
lycorptech_jp
PRO
0
330
MLOps の現場から
asei
6
630
KubeCon NA 2024 Recap: How to Move from Ingress to Gateway API with Minimal Hassle
ysakotch
0
200
Oracle Cloudの生成AIサービスって実際どこまで使えるの? エンジニア目線で試してみた
minorun365
PRO
4
270
Featured
See All Featured
Practical Orchestrator
shlominoach
186
10k
Build The Right Thing And Hit Your Dates
maggiecrowley
33
2.4k
Building Better People: How to give real-time feedback that sticks.
wjessup
365
19k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
247
1.3M
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
29
2k
Testing 201, or: Great Expectations
jmmastey
40
7.1k
Automating Front-end Workflow
addyosmani
1366
200k
Writing Fast Ruby
sferik
628
61k
Building an army of robots
kneath
302
44k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
2
160
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
Navigating Team Friction
lara
183
15k
Transcript
開発チームみんなで取り組む アクセシビリティ 2022.02.17 Developers Summit 2022 17-E-4 ymrl
自己紹介 • ymrl(やまある) • freee株式会社 プロダクトデザイン部 デザインリード • 元エンジニア、いまデザイナー •
freeeの社内向けデザインシステムを作る(デザイン・実装・運用)傍ら、 Webアクセシビリティの向上施策や社内教育をしています
今日話すこと • アクセシビリティについての説明 ◦ アクセシビリティに取り組む意味 ◦ 具体的にどんなことをするのか • 開発チームみんなでアクセシビリティをやっていくには ◦
freee株式会社で、これまでにやってきたこと ◦ これを聞いている皆さんにやってみてほしいこと
「アクセシビリティ」 ってご存知ですか?
アクセシビリティとは accessibility a11y
アクセシビリティ = アクセスできる度合い • 誰にでも、どんな状態でも使える度合い • 利用環境、年齢や性別、身体能力などを問わず、等しく利用できる • 障害者や高齢者に対して、専用の対応をすることではない
ユーザビリティとアクセシビリティ ユーザビリティ: • ユーザーや利用状況を特定した 上での、使いやすさの度合い • 特定の条件で目標を達成する 効果・効率・満足度の高さ • 狭く深い
• 頂点を極める アクセシビリティ: • ユーザーや利用状況を特定せず、 あらゆる条件で使える度合い • 等しく目標を達成できる ユーザーや利用状況の多さ • 浅く広い • 裾野を広げる
アクセシビリティが高い状態の例 • PCでもスマートフォンでも、最適なレイアウトで快適に利用できる • 文字がくっきりとした色使いで書かれていて、老眼でも読みやすい • マウスでもキーボードでもタッチパネルでも操作できる • 動画に字幕がついていて、聴覚障害者でも内容が理解できる •
ナビゲーションに使われる言葉に一貫性があり、迷子になりにくい • マシンリーダビリティが高く、スクリーンリーダーでも難なく利用できる
なぜ、 アクセシビリティに 取り組むのか
なぜアクセシビリティに取り組むべき? • 障害者が利用できず困っているらしいというのを聞いたから • 海外ではアクセシビリティが低いと訴訟リスクがあるらしいから • なんとなく、やらなきゃいけないような気がするから
なぜアクセシビリティに取り組まない? • ウチのサービスが使えない障害者って全人口の▪▪%しかいないんでしょ? その程度の人数にコストをかけるより、別の機能を作ったほうがいいよね? • アクセシビリティの訴訟が起きているのって、欧米だけでしょ? ウチのお客さんは日本だけだから、関係ないよね? • ウチみたいなベンチャーにはアクセシビリティなんてやる余裕ありません。 そういうのは大きな会社になってからやればいいでしょ?
「じゃあ、今はいいかな……」 ってなってしまいがち
障害者ってそんなに 多くないんでしょ問題
障害ってなんだろう • 「障害者」ではなくても、困ること・不便を感じることはいろいろある • 一時的に障害を負うことがある ◦ 眼鏡が壊れた、両手を怪我した、体調が悪い…… ◦ マウスの電池が切れた、イヤホンが無い…… •
「障害者」として括られなくても、生活に困ることのある人たちもいる ◦ 妊娠している、幼い子供がいる、持病がある、年を取った…… • アクセシビリティによって助かるのは、必ずしも「障害者」だけではない
障害者を取り巻く状況にも目を向けると • 法定雇用率: ある程度以上の規模の事業主は障害者を雇用する義務がある ◦ 従業員43.5人以上の事業主は、2.3% ◦ 「障害者が使えない」ことによって大口顧客を逃がすおそれがある • 障害者の周囲の人が、そういう製品を選んでくれるだろうか
◦ 障害者が使う必要があるときにサポートできると限らない ◦ 頻度の多いもの・プライベートな情報を扱うものは特に負担が大きい • 障害者の数が少ないとしても、それ以上の機会損失に繋がるおそれがある
訴訟になるのは 欧米だけでしょ問題
今はまだ、法的なリスクは低いかもしれない • アメリカ合衆国ではWebアクセシビリティ関連の訴訟が数年前から増加 ◦ Americans with Disabilities Act(ADA: 障害を持つアメリカ人法) ◦
欧州を中心に、各国でWebアクセシビリティ関連の法整備が進んでいる • 日本では障害者差別解消法の改正が2021年成立(2024年6月までに施行) ◦ 民間企業が「合理的配慮」を行うことが、「努力義務」から「義務」へ ◦ 東京都障害者差別解消条例では、実はもう「義務」になっている • 日本でも近いうちに、大きな法的リスクとなる可能性が高い
ウチがやるのは まだ早い気がする問題
アクセシビリティ、いつからやりだすのか • ユーザーから見れば、会社のフェーズは関係ない ◦ 不便を強いられる人は、会社が小さいなら悲しまない・怒らないのか? • 自分自身の主観としては、早いうちからやるべきだったと思うことは多い ◦ サービスの根幹に関わる部分に問題があると、あとから改修しづらい ◦
組織が複雑になるにつれ、各所の調整のコストが大きくなっていく ◦ 組織が大きくなるにつれ、悪いデザインや実装の模倣・コピペが加速 • アクセシビリティは最初から、製品の品質の前提となっているべき
ここまでのまとめ • 障害者ってそんなに数が多くないんでしょ? ◦ アクセシビリティの対象は、障害者だけではない ◦ 1人が製品を使えないことで、その周囲や所属組織も導入が難しくなる • 日本では訴訟にもならないし、法的なリスクもそんなにないよね? ◦
近い将来に法的リスクが大きくなっている可能性が高い • そういうのは大きな会社になってからやればいいでしょ? ◦ 会社の大きさは、ユーザーにとってはの関係ないこと ◦ 製品の根幹部分の問題や各所に大量にバラ撒かれた問題は対処が難しい
• 対象は障害者や高齢者だけではなく、多くの人にとって価値があるから ◦ 一時的に障害者と同じ状態になったりすることがある • 利用状況を制限しない、より柔軟に使える製品を目指すことができるから ◦ 思いもよらぬ場面・人に使われる余地を作っておくことができる • あとで後悔するようなものをリリースしたくないから
◦ アクセシビリティを高める方法が存在する以上、やらない理由がない ◦ 法的なリスクが高まる可能性も高い、あとから直すのはコストも大きい なぜアクセシビリティに取り組むべきなのか
アクセシビリティを加点法で捉える • 減点法で捉えるアクセシビリティ ◦ やってないと怒られるもの ◦ 完璧にしておかないといけないもの ◦ 特別なターゲットに対して特別なことをするもの •
加点法で捉えるアクセシビリティ ◦ みんなを幸せにするためのもの ◦ やればやるほど品質が上がるもの ◦ すべての人に対する普遍的なもの
アクセシビリティ 具体的にやること
デザイニングWebアクセシビリティ https://www.borndigital.co.jp/book/5388.html
WCAG (Web Contents Accessibility Guidelines) • W3CによるWebアクセシビリティのガイドライン ◦ 原文 https://www.w3.org/TR/WCAG21/
◦ 日本語訳 https://waic.jp/docs/WCAG21/ • WCAGの内容がISOやJISの規格になっている • 今年の6月にはWCAG 2.2が勧告される予定(これ以上遅れなければ) ◦ What’s New in WCAG 2.2 Working Draft https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/
WCAGの達成基準 • A、AA、AAAの3段階のレベル分け ◦ Aは必ず達成してほしい、AAAは達成が比較的難しい • Webアクセシビリティの4原則 ◦ 知覚可能 —
個々の情報が「存在すること」を知覚できる ◦ 操作可能 — クリックや文字入力を受け付けるものを操作できる ◦ 理解可能 — 個々の情報が何を表現しているのか理解できる ◦ 堅牢 — 上記3つが、Webブラウザの種類や世代を超えて実現している
具体的な改善の例 • 画像に代替テキストをつける: 1.1.1(A) • Webサイトに埋め込まれている動画に字幕をつける: 1.2.2(A) • 文字の色をコントラスト比の高い配色に変更する: 1.4.3
(AA), 1.4.6 (AAA) • レスポンシブレイアウトにする: 1.4.10 (AA) • ボタンなどをキーボードで操作できるようにする: 2.1.1(A), 2.1.3(AAA) • エラーメッセージの表示方法や内容を丁寧にする: 3.3.1(A), 3.3.3(AA)
アクセシビリティは職域を超えてみんなで取り組む • 「エンジニアだけでやる」「デザイナーだけでやる」は不可能 ◦ 配色や見た目の問題はエンジニアだけでは直せない ◦ マークアップやインタラクションの問題はデザイナーには直しづらい • 開発チーム全体で取り組んでいかないと、アクセシビリティは向上しない ◦
何をどれくらいやる必要があるのかを、関わる全員で合意する ◦ 外注するものがある場合には、発注先とも合意を作っておく
freee株式会社での事例
4年分のまとめ記事があります https://developers.freee.co.jp/entry/freee-a11y-2018 https://developers.freee.co.jp/entry/freee-a11y-2019 https://developers.freee.co.jp/entry/freee-a11y-2020 https://note.com/magi1125/n/ncc519a490f6c
ミッションやビジョンに紐付ける • 会社のミッションやビジョンから、アクセシビリティをやる理由を定義する ◦ ミッションやビジョンの文言と、アクセシビリティの関係を考えてみる • 何をどれくらい優先してやるべきかを判断する根拠になる • 前向きな姿勢でアクセシビリティに取り組めるようになる
https://corp.freee.co.jp/mission/
freeeがアクセシビリティに取り組む理由 • ミッション「スモールビジネスを、世界の主役に。」 • ビジョン「だれもが自由に経営できる統合型経営プラットフォーム。」 • 説明文「だれもが自由に自然体で経営できる環境をつくっていきます」 • 多様性に溢れるスモールビジネスに関わる人たちを一人も取り残さず、 一人ひとりが主役になれるようにする、その環境をつくるためにやる
実際に困っているユーザーのことを知る • 身近に該当する人がいないと、実際に困るユーザーのことを想像しづらい • freeeを実際に使っている全盲のユーザー(中根さん)がいたので、 インタビューや飲み会をして、どう使っていて何に困っているのかを聞いた ◦ 当時のfreeeは、ITエンジニアでもある中根さんがあれこれ工夫して、 どうにか使えてるいる状態だということがわかってきた ◦
「まずは中根さんが使える状態にしよう」という目標が生まれた • その後、中根さんがfreeeに入社、さらにもう1人全盲の社員も入社して、 「全盲」のユーザーのことは想像しやすい状況になっている
優先的に対応するべき範囲を見定める • 全ての機能・全ての画面をいきなりアクセシブルにしていくのは難しい • freeeでは、個人事業主向け機能、法人の従業員向け機能を優先 ◦ 個人事業主向け: 帳簿付け、請求書、確定申告など ◦ 従業員向け:
勤怠、給与明細、経費清算、年末調整など ◦ これらの機能を使う上で、『詰む』ようなところは最優先で直す • これらの機能が使えないと社内でも困るので、直さないわけにいかない
独自ガイドラインの整備 • WCAGの達成基準は多く、文章も難解で開発現場で参照しづらかった ◦ 文章が抽象的で、独特の書き方がされていてとっつきにくい ◦ AAAの達成基準には、達成が困難なものも含まれる • WCAGをベースに、freee アクセシビリティー・ガイドラインを策定した
◦ freeeで達成したい項目に絞り、MUST/SHOULDの2段階に整理 ◦ 対象となるコンテンツごとに、具体的な文章で説明 ◦ 参考情報として、目的やチェックの方法などの解説をつける
https://a11y-guidelines.freee.co.jp/
アクセシビリティの工夫をデザインシステムに蓄積 • すべてのエンジニアやデザイナーがアクセシビリティに詳しいわけではない ◦ 教育だけでカバーしていくのは難しい • freeeでは、「Vibes」というデザインシステムを作って、 何も考えなくてもある程度アクセシビリティが高い状態になるようにした ◦ VibesのUIコンポーネントを組み合わせてデザインし、実装すれば、
「平均点くらい」の一定以上のレベルが担保される • Vibesはアクセシビリティに限らず、フロントエンドの品質向上や 開発生産性の向上をターゲットにしているので、導入されやすい
チェックリストとチェック体制の整備 • リリースされる成果物のアクセシビリティをチェックするだけでなく、 開発の各フェーズのためのチェックリストを作った ◦ デザイナー向け、エンジニア向け、QA向け • QAチームでの運用が特に定着していて、多くの新機能がチェックされている ◦ 既存機能の改善や、より上流でのチェックの普及はまだ課題がある
• チェックの結果をアクセシビリティの取り組み全体の改善に活用 ◦ ガイドラインやチェックリスト自体の改善をする ◦ NGになりがちな場所をデザインシステムでカバーできるようにする
https://developers.freee.co.jp/entry/a11y-training
研修メニューに組み込む • 開発に関わる部署の人たちには、アクセシビリティの研修を2時間実施 ◦ 実際にキーボードによる操作やスクリーンリーダーによる操作を体験 ◦ 開発時にどんなことに気をつけるのか知ってもらう • 最近、全ての新入社員向けの45分の研修メニューもスタート ◦
アクセシビリティとは何か、なぜやるのか ◦ 会社での普段の生活でどんなことに気をつければいいのか • 社内で使っている資料を公開してあります https://developers.freee.co.jp/entry/a11y-training
freeeで使用している研修資料の一部 https://developers.freee.co.jp/entry/a11y-training
アクセシビリティの 取り組みを始めるには
アクセシビリティの取り組みに必要そうなこと • アクセシビリティに取り組んでいくことへの合意の形成 • ユーザーの利用状況やデザイン・実装への理解の醸成 • アクセシビリティ対応方針の策定 • アクセシビリティチェックや修正のフロー構築
freee 社のアクセシビリティガイドラインとチェックリストを丸ごと導入した (hey Product Blog) https://tech.hey.jp/entry/2021/12/24/112102
freeeで作っているもの、ぜひ使ってください • freeeアクセシビリティー・ガイドライン https://a11y-guidelines.freee.co.jp/ • アクセシビリティー・チェック・リスト https://a11y-guidelines.freee.co.jp/checks/index.html • 研修資料 https://developers.freee.co.jp/entry/a11y-training
• フィードバックもお待ちしています
おわりに • アクセシビリティは、可能性をより高めるものだと思っています ◦ 製作者の思いもよらないユーザー、場面、目的に製品を広められる ◦ 障害などを理由に諦めていたものごとに挑戦できるようになる • 皆さんが、関わっている製品のアクセシビリティを少しでも高められ、 そして1人でも多くの人に価値を届けられれば嬉しいです