freee 株式会社
 春だ！既存プロダクトのWebアクセシビリティ
 改善ことはじめ
 自社プロダクトのアクセシビリティ改善、何から始めればいいか迷っているあなたへ
 2021年4月9日


2 開催に当たって
 ● 質問などはZoomのQ&Aに書き込んでください
 ● Twitterのハッシュタグは #freee_a11y です
 ● 本日の模様は録画して、後日公開する予定です


本日の概要
 ● 既存プロダクトのアクセシビリティー改善の第1歩
 ● freeeアクセシビリティー・ガイドラインと
 アクセシビリティー・チェックリスト
 ● 実践アクセシビリティー・チェック
 ● 鼎談：freeeで既存プロダクトのチェックが回り始めるまで
 3

既存プロダクトのアクセシビリティー改善の第1歩


社内アクセシビリティ向上活動のはじまりパターン
 5 1. アクセシビリティに取り組みたいと思う人が社内に出現する
 2. 社内チャット等でアクセシビリティチャンネルができ、情報が流れるようになる。そ こにリアクションする人が何人か現れる
 3. 有志によるアクセシビリティ関連書籍の輪読会が行われる
 4. おのおのが手を出せるところの改善を試みる
 5. 必要性や取り組みを社内でプレゼンしてみる
 Webアクセシビリティ書籍4兄弟 


そのあとどうするか：「新規」プロダクトの場合
 6 ● 三種の神器（人、合意、ツール）が揃えば自走し始める (freee Developers Blog) 
 ● やっていこうという人がチーム内にいる
 ● アクセシビリティが「満たすべき品質」としてキックオフ時に定義され、チーム内で 合意されている
 ● アクセシビリティを高めるためのデザインシステム、ガイドライン、チェックリストを ベースに開発が進行できる


では「既存」プロダクトは？
 7 ● 「おのおのが手を出せるところの改善を試みる」は、
 試してみて肌感を掴む的な文脈では大いに意味がある
 ● ただし、課題認識が「おのおの」に限られるので、
 チームとしての取り組みに移行しにくいところがある
 ● また、改善箇所が散発的になるので、
 まとまった形での改善を実感できるまでの期間が長くなりがち


既存プロダクト改善における有効打（仮説）
 8 ● まずは既存プロダクトに関わるチームで現状把握をする
 ○ 自分たちが日々触っているところがどのレベルなのかを
 みんなで把握できることが土台となる
 ● 機能的にコアなところを見定めて、そこからチェックする
 ○ 現状把握するにしても、全部をチェックすると大変。
 使えないと詰むところを定義し、そこからチェックする
 ● 「改善難易度」「ついでに乗れる波」「改善結果のまとまり」の
 バランスでロードマップを決める（後述）


現状把握
 する
 A11y学ぶ
 対応箇所
 検討する
 改善する
 評価する
 周知する
 9 既存プロダクト改善のサイクル


現状把握
 する
 A11y学ぶ
 対応箇所
 検討する
 改善する
 評価する
 周知する
 10 既存プロダクト改善のサイクル


①提供形態ご との画面リスト を作る
 ②使えないと 致命的かをス コア付けする
 ③Aに対して チェックリスト でチェックする
 ④結果をもと に対応難易度 を見積もる
 ⑥やっていき 順番を決める
 A：ユーザーサイド ⑤直近で手を 入れる予定を 確認する
 11 「現状把握する」 ＆ 「対応箇所検討する」
 B：技術サイド

①提供形態ご との画面リスト を作る
 ②使えないと 致命的かをス コア付けする
 ③Aに対して チェックリスト でチェックする
 ④結果をもと に対応難易度 を見積もる
 ⑥やっていき 順番を決める
 A：ユーザーサイド ⑤直近で手を 入れる予定を 確認する
 12 「現状把握する」 ＆ 「対応箇所検討する」
 B：技術サイド

13 ②使えないと致命的かをスコア付けする


①提供形態ご との画面リスト を作る
 ②使えないと 致命的かをス コア付けする
 ③Aに対して チェックリスト でチェックする
 ④結果をもと に対応難易度 を見積もる
 ⑥やっていき 順番を決める
 A：ユーザーサイド ⑤直近で手を 入れる予定を 確認する
 14 「現状把握する」 ＆ 「対応箇所検討する」
 B：技術サイド

⑥やっていき順番を決める
 15 どの提供形態の Web-PC, Web-モバイル, iOSアプリ, Androidアプリ… どの機能単位（画面）の サインアップ、ログイン、チュートリアル、ホーム、エディタ、投稿管理、設定、記事本 文… どのアクセシビリティ観点を 例1：操作方法やモダリティ（視覚・聴覚…）の単位：キーボード操作、スクリーンリー ダー、コントラスト、拡大やhover、動画や音声の字幕 
 例2：「チェッカーで見つかった範囲を潰す」といった手法単位 どんなやりかたで、 
 いつまでにやるか 例1：機能追加やリニューアルに乗じていっしょに 
 例2：目標設定をして、時間を一定割いて 
 例3：品質改善活動や20%ルール的な時間を使って 
 例4：デザインシステムの適用と一緒に 
 （※この場合はデザインシステムのアクセシビリティ担保が先に必要） 対応結果をどう評価するか 例：チェッカーの通過、開発チーム内でチェックリストでチェック、QAチームによる チェック、障害当事者によるユーザビリティテスト

16 「プレスやお知らせや記事出せそうな単位」で考える
 「どういう機能がどの状況でも使えるようになったか」というまとまりで考える。 
 逆に言うと、ガイドラインの達成基準やレベルにこだわりすぎないようにする 
 ● freee が「人事労務freee」のモバイルアプリをリリース。モバイルアプリの活用と勤怠機能の強化で、日々の勤怠入力を効率化 | プレスリリース
 ● 人事労務freee、年末調整をスクリーンリーダーで利用可能 画面内の項目を音声で読み上げて操作が可能に | プレスリリース
 ● アクセシビリティ向上の取り組みはだれもが使えるサービス開発の基本


17 みなさまの事例
 ● SmartHRの画面のカラーが新しくなりました 
 ● STUDIOサイトのアクセシビリティ強化のお知らせ 
 ● アメーバスタッフ『【改善のお知らせ】キーボードによるいいね!ボタンの操作ができるようになります』 
 ● サイボウズ Officeの各アプリケーションの詳細画面に見出しをつけました 
 ● Backlog リリース: アクセシビリティの改善をリリースしました！ 


①提供形態ご との画面リスト を作る
 ②使えないと 致命的かをス コア付けする
 ③Aに対して チェックリスト でチェックする
 ④結果をもと に対応難易度 を見積もる
 ⑥やっていき 順番を決める
 A：ユーザーサイド ⑤直近で手を 入れる予定を 確認する
 18 「現状把握する」 ＆ 「対応箇所検討する」
 B：技術サイド

19 (お知らせも出た)チェックリストをご活用ください
 freee、「アクセシビリティチェックリスト」を公開 


freeeアクセシビリティー・ガイドラインとアクセシ ビリティー・チェックリスト


freeeアクセシビリティー・ガイドライン
 https://a11y-guidelines.freee.co.jp/ 
 21

22 独自ガイドラインができる前
 ● 最初は経験知を集めたようなドキュメントが作られた
 ● 一般的にやるべきとされている内容は含まれていた
 ● チェックの実施方法、そのチェックの必要性などといった部分の記述にばらつき があった


23 効果的なチェックのために
 ● チェックをして見つかった問題が改善される必要がある
 ● その問題が、誰のどんな不便につながるのかを理解する必要がある
 


24 それってWCAGじゃないの？
 ● Web Content Accessibility Guidelines (WCAG) とその関連文書を読み込めば、 なぜ、なにを、どうすれば良いかは全部書いてある（はず）
 ● 文書が膨大
 ● 文書が難解
 ● WCAGの内容に対するアクセシビリティー低い問題


25 WCAGは難解
 SC 1.1.1:
 利用者に提示されるすべての非テキストコンテンツには、同等の目的 を果たすテキストによる代替が提供されている。 →画像には代替テキスト付けましょう →img要素にはalt属性付けましょう そして「非テキストコンテンツ」は画像だけではない。

26 SC 1.1.1がカバーするのはimgのaltだけじゃない
 ● WCAG 2.1のSCとfreeeのガイドラインの対応表がある
 ● SC 1.1.1に対応するのは7ガイドライン


27 独自ガイドラインで目指したこと
 ● 扱うコンテンツの種類ごとに、具体的にやるべきことを示す
 ● そのガイドラインが満たされているのかを確認する方法の明示
 ● そのガイドラインが誰のどんな不便の解消につながるのかを明らかにする
 ● そしてガイドラインとチェックリストができた


28 ガイドラインの使い方
 ● 作ろうとしているコンテンツの内容に合ったカテゴリーのガイドラインを確認する
 ● 各ガイドラインの意図などを、詳細情報や参考情報で確認する
 ● ガイドラインを満たしているかどうかのチェック方法を確認する（そしてチェックす る）


29 チェックリストの使い方
 ● 設計時、実装時、動作確認時のチェックを意識している
 ● 「対象」の欄で絞り込むことができる
 ● Google Drive上でチェックシートのコピーを作成して使うと、フィルターなどが利用 できる


実践アクセシビリティー・チェック


アクセシビリティー・チェックをするタイミング
 デザイナー、エンジニア、QAがそれぞれチェックするのが理想的。 
 freeeのチェックリストは、それぞれが「デザイン」「コード」「プロダクト」のチェックを行う設計 になっています。
 デザイナー
 エンジニア
 QA
 デザインの アクセシビリティ チェック コードの アクセシビリティ チェック プロダクトの アクセシビリティ チェック 31

32 freeeのアクセシビリティーチェックリスト
 Google スプレッドシートとして公開してあります
 https://a11y-guidelines.freee.co.jp/checks/checksheet.html
 


33 きょうのチェック対象ページ
 ● やまさんの森
 https://yama3nomori.jp/
 ● VANDLE CARD
 https://vandle.jp/
 ● 宇部興産株式会社
 https://www.ube-ind.co.jp/ube/jp/index.html
 ● きょうのConnpassイベントページ
 https://connpass.com/event/208365/ 


アクセシビリティー・チェックに使うツール (1 / 2)
 ● スクリーンリーダー
 ○ freee では Chrome + NVDA の組み合わせを標準にしています
 ■ PC-Talkerのほうがユーザーは多いかも（多いはず）
 ■ WAI-ARIAの新しめの仕様が使えて無料
 ■ しかし今日はMacのVoiceOverでデモします
 ● axe
 ○ アクセシビリティ上の問題を発見してくれるチェッカー
 ○ LighthouseのAccessibilityも中身はaxe
 ○ すべての問題が見つかるわけではないので過信しすぎないこと
 34

アクセシビリティー・チェックに使うツール (2 / 2)
 ● ブックマークレット
 ○ 一部のチェックには専用ツールとして用意している
 ● コントラストチェッカー
 ○ カラーコードを入力するとコントラスト比を計算してくれる
 ○ freeeでは WebAIM Contrast Checker を標準としている
 35

チェックの流れ (1/4) – axe
 ● ひとまずaxeを実行して、拾いやすいチェック項目を拾っていく
 ○ 文字のコントラスト比
 ○ フォームのラベル
 ○ 画像やアイコンの代替テキスト
 ● モーダルやアコーディオンなど、画面の一部が切り変わる場合は、
 切り変わりの前後でもaxeを実行してみる
 36

チェックの流れ (2/4) – キーボード操作
 ● 画面で行える操作がすべてキーボードで実行できるか試してみる
 ○ Tab / Shift+Tab で自然な順序でフォーカス移動できるか
 ○ どこにフォーカスがあるのかわかる表示になっているか
 ○ マウスホバーで表示されるようなものを開閉できるか
 ○ 画面のすべての機能をキーボード操作のみで操作できるか
 37

チェックの流れ (3/4) – スクリーンリーダー
 ● きちんとしたチェックでは、Chrome + NVDA を使用してください
 ○ NVDAの操作方法については「スクリーン・リーダーを用いたチェックの実施 方法」というページにまとめてあります
 ● 特にスクリーンリーダーでしかなかなかチェックできないものをチェック
 ○ メッセージの自動読み上げ
 ○ 独自で作ったUIやライブラリのUIが操作できること
 ■ セレクトボックスっぽいやつとか
 38

チェックの流れ (4/4) – その他のチェック
 ● ここまでのスライドは、すべてのチェックを紹介したわけではないので、
 実際にはチェックシートで上から順に見ていくのをおすすめします
 ○ 順序は必ずしも従わなくてもいいので、同じツールを使うチェックは
 まとめてやったほうが効率的です
 ● 「チェックの方法がわからないな」と思ったら、チェックシートの
 「参考リンク」を見てください
 39

鼎談
 freeeで既存プロダクトのチェックが回り始めるまで


Q&A


お知らせ
 freeeではアクセシビリティをやっていきたい
 デザイナー・エンジニアを大募集しております
 freee 採用情報
 UXデザイナー
 Webアプリケーションエンジニア
 (フロントエンド寄りフルスタック)