社内にアクセシビリティ改善を広める際に意識したこと

Hatena Engineer Seminar #25 アクセシビリティ編: https://hatena.connpass.com/event/283800/
Google Slides: https://docs.google.com/presentation/d/1kZM2f9bCIpxe7DLCyHVSXRQfd3FrjJoUH4NBMixrtIE/edit?usp=sharing

Transcript

1. 社内にアクセシビリティ改善を 広める際に意識したこと id:miki_bene/@benevolent0505 2023/06/06 Hatena Engineer Seminer #25 1
2. 自己紹介 • id:miki_bene / @benevolent0505 • マンガ投稿チーム Webアプリケーションエンジニア ◦ フロントエンド・バックエンド両方やる人 2
3. 今日の話 • アクセシビリティ改善を広める際に意識したこと ◦ 2020年頃から社内に発信して エンジニアセミナーの1テーマに出来る程になった • 以下の人に参考になるように ◦ アクセシビリティ改善を始めようとしている人 ◦ 自分以外にも改善活動を広めたいと思っている人 3
4. 今日の前提 • 今日の話は Web アクセシビリティが前提 ◦ 「Web アクセシビリティの改善を広めるには」という話 • モバイルアプリ等にも活かせる部分はあると思う 4
5. アジェンダ • アクセシビリティについて • 社内にアクセシビリティについて広める理由 • アクセシビリティ改善を広める際に行ったこと • 改善を広める際に意識して伝えたこと 5
6. アクセシビリティについて 6
7. アクセシビリティについて • accessibility = アクセスのしやすさ • 全ての人がどんな状況でも利用できるようにするもの • 障害のある方など、特定の人に向けたものではない 7
8. 8 W3C - Accessibility (MDN日本語訳) > 「ハードウェア、ソフトウェア、言語、文化、所在地、物理的/精神的 能力にかかわらず、ウェブは基本的にすべての人に向けて設計されてい ます。ウェブがこの目的を達成できると、さまざまな聴力、視力、認知 能力をもつ人々がウェブにアクセスできるようになります。」 8 • https://developer.mozilla.org/ja/docs/Web/Accessibility • https://www.w3.org/standards/webdesign/accessibility
9. 誰でも不自由な状況になりうる • メガネのフレームが割れた ◦ → 拡大出来ないページは読めない • 利き手を骨折した ◦ → マウスのみで操作する UI が利用できない • 通信量制限で低速回線になった ◦ → 読み込み容量の大きいサイトが開けない 9
10. 社内にアクセシビリティに ついて広める理由 10
11. アクセシビリティ改善が必要 • 不自由な状況でもアクセシブルな作りならば利用できる • 様々な理由でアクセシビリティの問題は発生する ◦ 適切でないHTML要素の利用 ◦ UI設計時の考慮漏れ ◦ チェックが漏れてしまう • アクセシビリティ改善が必要になってくる 11
12. アクセシビリティ改善を広めたい • 周りを巻き込んで少しずつ改善を進めたい ◦ 1人で行うのは無理筋 • しかしアクセシビリティを認識する人は少ない ◦ 知っていても誤解していたり • 知らなければ改善できないので人を増やしたい 12
13. 自分が広め始めた当時の状況 • 自分が知り始めたのは 2020年頃 • 今ほどアクセシビリティの認識は高くなかった ◦ 2017年にエンジニアブログを出しているが、 それ以降の入社の人にはあまり認識されていなかったり ◦ 少しずつアクセシビリティ意識する - Hatena Developer Blog 13
14. 自分が広め始めた時の状況 14 "アクセシビリティ - 調べる - Google トレンド"
15. アクセシビリティ改善を広 める際に行ったこと 15
16. 広める際に行ったこと • チーム内でアクセシビリティ改善を実践し共有する • チーム外にもアクセシビリティの話題を共有する • グループウェアにアクセシビリティのページを作る 16
17. チーム内で改善を実践し共有する • まずは自分の手の届く範囲で改善して事例を積む ◦ 自分が担当した部分 ◦ Lighthouse等で自動検知した箇所 • この改善をチーム内に共有 ◦ 具体例を元に認識してもらう • 認識が広がってきたら徐々に コードレビューでコメントを入れていく 17
18. チーム外にも話題を共有する • フロントエンドについて話す場で話題に出す ◦ MTG や Slack チャンネルなど ◦ 話題に関連させたり、自分が実践したことを共有 • 話題が増えてきたらSlackチャンネルを作る ◦ なんでも話せる場を作る ◦ アプリエンジニアや他職種の方も気軽に参加できるように 18
19. チーム外にも話題を共有する • 面白工夫: Slackの通知設定の My keywords に 「アクセシビリティ」と入れる • 話題や質問にすぐ反応できるようにする 19
20. グループウェアにページを作る • Scrapbox にアクセシビリティのページを作り始めた • 自分の知識をまとめたり共有のため • 自分以外にも情報や知識を書いてくれる人がいた ◦ 思っていなかった効果 ◦ 自分以外にも関心を持つ人を知れた 20
21. 行ったことをふりかえる • 特別なことはやっていない • 実践・共有・仲間探しを行っていた ◦ 実践 ▪ 改善を実践 ◦ 共有 ▪ 話題を共有する ◦ 仲間探し ▪ グループウェアにページを作る 21
22. 改善を広める際に 意識して伝えたこと 22
23. 改善を広める際に意識して伝えたこと 23 • ユーザーは機能を利用できていない • アクセシビリティ改善による嬉しさ • アクセシビリティ改善を難しく捉えすぎない
24. ユーザーは機能を利用できていない • 知らないと「利用できない」ことがわからない ◦ なんとなく困っているといった理解で終わってしまう ◦ ユーザービリティ・おもてなしとの混同 • 困っている状況をはっきりさせる ◦ ユーザーの状況についての認識を揃える ◦ コンテンツは読めていない・機能は利用できない • ここを揃えてアクセシビリティの考え方に繋げる 24
25. ユーザーは機能を利用できていない • これだけでは改善のモチベーションになりづらい ◦ 道徳的な訴えで個人に依存してしまう ◦ 現実の難しさ ▪ 改善のコスパ, 要件や仕様にない, 他の不具合や開発との優先順位 • モチベーションを高める他の視点も必要 25
26. アクセシビリティ改善による嬉しさ • 支援技術を必要とする人以外にもメリットがある • アクセシビリティがユーザビリティに繋がるケース ◦ キーボード操作可能になることは色々と嬉しい ◦ 特にエンジニアにウケがいい • マシンリーダブルになることによるメリット ◦ テストの壊れにくさ / SEO ◦ もっとウケがよい • 様々な品質を向上できるもの 26
27. 改善を難しく捉えすぎない • 実際にやろうとすると知識の膨大さに面を食らう • WAI-ARIA を意識しすぎない ◦ ボタンなら button を使うなど、HTMLに元からある要素を使う ◦ セマンティクスを意識する • わかりやすいガイドラインにあたる ◦ WCAG のガイドラインは難しい ◦ freee さん / CyberAgent さんなどわかりやすいガイドラインへ ▪ https://a11y-guidelines.freee.co.jp/ ▪ https://a11y-guidelines.ameba.design/ 27
28. まとめ 28
29. まとめ (1/2) • アクセシビリティ改善を広める際意識したことを話した • 広めていった結果 ◦ エンジニアセミナーで1テーマに出来るくらいになった ◦ 多くのチームで改善を行う人が出てきた 29
30. まとめ (2/2) • 広め方は色々あるが、特別なことはない ◦ 意識して伝えたことの方が大切 • 今日の発表が改善をスタートする人の参考になれば幸い • 使ってもらえるユーザーの幅が広がることを素直に喜ぶ 30
31. 参考 • Webエンジニアとしていま知っておきたいWebアクセシビリティ • 少しずつアクセシビリティ意識する - Hatena Developer Blog 31