Share
Embed
Transcript
47 slides
-
自己紹介 • ymrl(やまある) • freee株式会社 プロダクトデザイン部 デザインリード • 元エンジニア、いまデザイナー •
freeeの社内向けデザインシステムを作る(デザイン・実装・運用)傍ら、 Webアクセシビリティの向上施策や社内教育をしています -
今日話すこと • アクセシビリティについての説明 ◦ アクセシビリティに取り組む意味 ◦ 具体的にどんなことをするのか • 開発チームみんなでアクセシビリティをやっていくには ◦
freee株式会社で、これまでにやってきたこと ◦ これを聞いている皆さんにやってみてほしいこと -
ユーザビリティとアクセシビリティ ユーザビリティ: • ユーザーや利用状況を特定した 上での、使いやすさの度合い • 特定の条件で目標を達成する 効果・効率・満足度の高さ • 狭く深い
• 頂点を極める アクセシビリティ: • ユーザーや利用状況を特定せず、 あらゆる条件で使える度合い • 等しく目標を達成できる ユーザーや利用状況の多さ • 浅く広い • 裾野を広げる -
アクセシビリティが高い状態の例 • PCでもスマートフォンでも、最適なレイアウトで快適に利用できる • 文字がくっきりとした色使いで書かれていて、老眼でも読みやすい • マウスでもキーボードでもタッチパネルでも操作できる • 動画に字幕がついていて、聴覚障害者でも内容が理解できる •
ナビゲーションに使われる言葉に一貫性があり、迷子になりにくい • マシンリーダビリティが高く、スクリーンリーダーでも難なく利用できる -
障害ってなんだろう • 「障害者」ではなくても、困ること・不便を感じることはいろいろある • 一時的に障害を負うことがある ◦ 眼鏡が壊れた、両手を怪我した、体調が悪い…… ◦ マウスの電池が切れた、イヤホンが無い…… •
「障害者」として括られなくても、生活に困ることのある人たちもいる ◦ 妊娠している、幼い子供がいる、持病がある、年を取った…… • アクセシビリティによって助かるのは、必ずしも「障害者」だけではない -
障害者を取り巻く状況にも目を向けると • 法定雇用率: ある程度以上の規模の事業主は障害者を雇用する義務がある ◦ 従業員43.5人以上の事業主は、2.3% ◦ 「障害者が使えない」ことによって大口顧客を逃がすおそれがある • 障害者の周囲の人が、そういう製品を選んでくれるだろうか
◦ 障害者が使う必要があるときにサポートできると限らない ◦ 頻度の多いもの・プライベートな情報を扱うものは特に負担が大きい • 障害者の数が少ないとしても、それ以上の機会損失に繋がるおそれがある -
今はまだ、法的なリスクは低いかもしれない • アメリカ合衆国ではWebアクセシビリティ関連の訴訟が数年前から増加 ◦ Americans with Disabilities Act(ADA: 障害を持つアメリカ人法) ◦
欧州を中心に、各国でWebアクセシビリティ関連の法整備が進んでいる • 日本では障害者差別解消法の改正が2021年成立(2024年6月までに施行) ◦ 民間企業が「合理的配慮」を行うことが、「努力義務」から「義務」へ ◦ 東京都障害者差別解消条例では、実はもう「義務」になっている • 日本でも近いうちに、大きな法的リスクとなる可能性が高い -
アクセシビリティ、いつからやりだすのか • ユーザーから見れば、会社のフェーズは関係ない ◦ 不便を強いられる人は、会社が小さいなら悲しまない・怒らないのか? • 自分自身の主観としては、早いうちからやるべきだったと思うことは多い ◦ サービスの根幹に関わる部分に問題があると、あとから改修しづらい ◦
組織が複雑になるにつれ、各所の調整のコストが大きくなっていく ◦ 組織が大きくなるにつれ、悪いデザインや実装の模倣・コピペが加速 • アクセシビリティは最初から、製品の品質の前提となっているべき -
ここまでのまとめ • 障害者ってそんなに数が多くないんでしょ? ◦ アクセシビリティの対象は、障害者だけではない ◦ 1人が製品を使えないことで、その周囲や所属組織も導入が難しくなる • 日本では訴訟にもならないし、法的なリスクもそんなにないよね? ◦
近い将来に法的リスクが大きくなっている可能性が高い • そういうのは大きな会社になってからやればいいでしょ? ◦ 会社の大きさは、ユーザーにとってはの関係ないこと ◦ 製品の根幹部分の問題や各所に大量にバラ撒かれた問題は対処が難しい -
• 対象は障害者や高齢者だけではなく、多くの人にとって価値があるから ◦ 一時的に障害者と同じ状態になったりすることがある • 利用状況を制限しない、より柔軟に使える製品を目指すことができるから ◦ 思いもよらぬ場面・人に使われる余地を作っておくことができる • あとで後悔するようなものをリリースしたくないから
◦ アクセシビリティを高める方法が存在する以上、やらない理由がない ◦ 法的なリスクが高まる可能性も高い、あとから直すのはコストも大きい なぜアクセシビリティに取り組むべきなのか -
アクセシビリティを加点法で捉える • 減点法で捉えるアクセシビリティ ◦ やってないと怒られるもの ◦ 完璧にしておかないといけないもの ◦ 特別なターゲットに対して特別なことをするもの •
加点法で捉えるアクセシビリティ ◦ みんなを幸せにするためのもの ◦ やればやるほど品質が上がるもの ◦ すべての人に対する普遍的なもの -
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を実際に使っている全盲のユーザー(中根さん)がいたので、 インタビューや飲み会をして、どう使っていて何に困っているのかを聞いた ◦ 当時のfreeeは、ITエンジニアでもある中根さんがあれこれ工夫して、 どうにか使えてるいる状態だということがわかってきた ◦
「まずは中根さんが使える状態にしよう」という目標が生まれた • その後、中根さんがfreeeに入社、さらにもう1人全盲の社員も入社して、 「全盲」のユーザーのことは想像しやすい状況になっている -
優先的に対応するべき範囲を見定める • 全ての機能・全ての画面をいきなりアクセシブルにしていくのは難しい • freeeでは、個人事業主向け機能、法人の従業員向け機能を優先 ◦ 個人事業主向け: 帳簿付け、請求書、確定申告など ◦ 従業員向け:
勤怠、給与明細、経費清算、年末調整など ◦ これらの機能を使う上で、『詰む』ようなところは最優先で直す • これらの機能が使えないと社内でも困るので、直さないわけにいかない -
独自ガイドラインの整備 • WCAGの達成基準は多く、文章も難解で開発現場で参照しづらかった ◦ 文章が抽象的で、独特の書き方がされていてとっつきにくい ◦ AAAの達成基準には、達成が困難なものも含まれる • WCAGをベースに、freee アクセシビリティー・ガイドラインを策定した
◦ freeeで達成したい項目に絞り、MUST/SHOULDの2段階に整理 ◦ 対象となるコンテンツごとに、具体的な文章で説明 ◦ 参考情報として、目的やチェックの方法などの解説をつける -
アクセシビリティの工夫をデザインシステムに蓄積 • すべてのエンジニアやデザイナーがアクセシビリティに詳しいわけではない ◦ 教育だけでカバーしていくのは難しい • freeeでは、「Vibes」というデザインシステムを作って、 何も考えなくてもある程度アクセシビリティが高い状態になるようにした ◦ VibesのUIコンポーネントを組み合わせてデザインし、実装すれば、
「平均点くらい」の一定以上のレベルが担保される • Vibesはアクセシビリティに限らず、フロントエンドの品質向上や 開発生産性の向上をターゲットにしているので、導入されやすい -
チェックリストとチェック体制の整備 • リリースされる成果物のアクセシビリティをチェックするだけでなく、 開発の各フェーズのためのチェックリストを作った ◦ デザイナー向け、エンジニア向け、QA向け • QAチームでの運用が特に定着していて、多くの新機能がチェックされている ◦ 既存機能の改善や、より上流でのチェックの普及はまだ課題がある
• チェックの結果をアクセシビリティの取り組み全体の改善に活用 ◦ ガイドラインやチェックリスト自体の改善をする ◦ NGになりがちな場所をデザインシステムでカバーできるようにする -
研修メニューに組み込む • 開発に関わる部署の人たちには、アクセシビリティの研修を2時間実施 ◦ 実際にキーボードによる操作やスクリーンリーダーによる操作を体験 ◦ 開発時にどんなことに気をつけるのか知ってもらう • 最近、全ての新入社員向けの45分の研修メニューもスタート ◦
アクセシビリティとは何か、なぜやるのか ◦ 会社での普段の生活でどんなことに気をつければいいのか • 社内で使っている資料を公開してあります https://developers.freee.co.jp/entry/a11y-training