開発組織外の他業種も巻き込んでアクセシビリティに関する機運を高めつつある話

Google Slide: https://docs.google.com/presentation/d/1Do0pzGG_ZYnDMLkGT4UzsFT_kK-qfNq9sEVcOvo0Dg0/edit?usp=sharing

Transcript

1. 開発組織外の他業種も巻き込んで アクセシビリティに関する機運を ⾼めつつある話 2023.06.16 Helpfeel Tech Hour vol.3 Pasta-K / @pastak 1
2. • 質問は Slido #3629079 へ ◦ https://app.sli.do/event/9uXNnGetfdQ76KXC3nfbPF ◦ connpassのイベントページからもアクセスできます • 感想はTwitter #helpfeel_tech へ 2 質問‧感想などをSlidoやTwitterで受け付けています！
3. • Pasta-K / @pastak • Scrapboxチーム エンジニア ◦ 主な関⼼はWeb技術やフロントエンド • その他、採⽤‧技術イベントのプロデュースや運営なども ◦ このイベント (Helpfeel Tech Hour)やその他のエンジニア向けイベント ◦ Podcast 今出川FM ( https://podcasters.spotify.com/pod/show/notainc ) • 京都サンガF.C.サポーター 3 About me
4. • 社内でアクセシビリティ改善に取り組みを始めていくにあたって、どのよう にボトムアップの取り組みを⾏ってきたか • 取り組んだこととそれらの現状や結果などを紹介します ※ 基本的に断りのない場合はウェブのアクセシビリティに関する話です 今⽇の話 4
5. 5 ⼿を動かす具体的な改善の⽅法などはこちら https://speakerdeck.com/pastak/shou-wodong-kasiteshi-meru-akusesibiriteigai-shan
6. • アクセシビリティについて • なぜアクセシビリティに取り組むのか • 組織横断的にアクセシビリティへの理解を広めるための取り組み • エンジニア組織内でアクセシビリティの改善を実施するための取り組み 6 アジェンダ
7. アクセシビリティについて 7
8. • アクセシビリティ = accessibility = a11y • 誰もがほぼ同じコストでアクセスできるようにすること • 特定の誰かに向けたものではない 8 アクセシビリティとは
9. > ハードウェア、ソフトウェア、⾔語、⽂化、所在地、物理的/精神的能⼒にかか わらず、ウェブは基本的にすべての⼈に向けて設計されています。ウェブがこの ⽬的を達成できると、さまざまな聴⼒、視⼒、認知能⼒をもつ⼈々がウェブにア クセスできるようになります。(*1)(*2) > アクセシビリティは、障がいのあるユーザが情報を利⽤できるようにするだけ ではなく、あらゆるユーザがその能⼒や状況を問わず、情報を利⽤できるように することです。(*3) 9 アクセシビリティとは *1: 原文 https://www.w3.org/standards/webdesign/accessibility *2: MDN日本語版による翻訳 https://developer.mozilla.org/ja/docs/Web/Accessibility *3: https://developer.apple.com/jp/design/human-interface-guidelines/accessibility
10. • マウスが壊れて、キーボード を使うしかなくなった • ⾻折して腕が⼀時的に使えな くなった • スマートフォンの画⾯が割れ て液晶が映らなくなった • 視⼒が低い‧⾒えない 10 「あらゆるユーザー」の例 • イヤホンを忘れて、⾳声を再⽣ できない • ⽇本語を理解できない • ⼩さい字が読めない • ギガを使いすぎて通信制限に あった • ⾊覚特性を有している
11. なぜアクセシビリティに取り組むのか 11
12. • Helpfeelはこれまでも使いやすさや新たな体験を発明してきた • ユーザビリティはアクセシビリティの上に成⽴する • ユーザビリティを享受できるためにはアクセス可能であることが必要 12 ユーザビリティとアクセシビリティ 間嶋沙知、 読みにくい「困った！」を解決するデザイン、 マイナビ出版、 2022, P23
13. • エンドユーザーの中で「利⽤困難」な⼈が居ると、我々のサービスが選択さ れなくなってしまう ◦ アクセシビリティの⽋如は我々のサービスを選ばない‧選べない積極的理由になりえる ◦ 操作性が悪いなどで使い⾟いだけなら、利⽤はできる • 使えない⼈が多い状況では、どんなにユーザビリティを良くしても、それら の価値を発揮できない‧届けることが出来ない • アクセシビリティを担保して、多くのユーザーに使われる状況になればより 多くの「ユーザビリティ」に関する問題を発⾒できるのでは？ 13 使えないサービスは存在しないのと同じ
14. • 我々の考えるユーザービリティや体験を本当に万⼈に届けられているのか • ユーザービリティを考え続けてきた我々だからこそアクセシビリティに本腰 を⼊れて取り組むことで、更に価値を向上させられるのではないか ◦ 詳細はakiroomのトークで話してくれているはず • それらを届けるためには、エンジニアを中⼼としたプロダクトの改善のみな らず、SaaSビジネスを取り巻く各職種の協⼒が不可⽋ → 組織横断でアクセシビリティを理解し取り組むことが重要 14 我々のサービスの価値をしっかり届けるために
15. 組織横断的にアクセシビリティへの理解を広めるための 取り組み 15
16. SaaSはウェブアプリケーションが主体ではあるが、ユーザーがサービスにたどり 着くまでには多くの接点がある。それらのアクセシビリティは⼗分か？ • 新機能紹介のためのブログやプレスリリースのアクセシビリティ ◦ 利⽤しているSaaSやCMSはアクセシビリティのための⼗分な機能を有しているか • 展⽰会でのポスターなどの掲⽰物や動画CMなどのアクセシビリティ ◦ ⾊や⽂字の使い⽅は適切か。字幕などが適切に設定されているか。 • 営業資料のアクセシビリティ 16 なぜ職種を跨いで巻き込むのか
17. • SlackやScrapboxなどでテキストをスクリーンショットして貼っていないか • URLがあるものにURLを適切に合わせて提⽰しているか • ⽇本語を⺟語としないメンバーも居る • 我々はGyazoを開発して普段使っているからこそ適切に使い分けて欲しい 17 社内のコミュニケーションにおいてもアクセシビリティは重要
18. • アクセシビリティの重要度が理解されていないと、他業種から「もっと優先 度の⾼い開発事項があるからそっちをやってくれ」と⾔われることがある(*) ◦ N%ルールのようなものの範囲での取り組みでは影響に限界がある • 場合によっては顧客に影響のある改善や変更になることもあるので、顧客に 理解をしてもらうためのコミュニケーションを取ってもらう必要もある • ユーザビリティ改善、新機能開発、ビジネスのための開発などと同様に重要 性のある取り組みだと理解してもらって、社内で相互にアクセシビリティ改 善を応援‧評価できる⼟壌を作っていきたい 18 アクセシビリティと開発優先度 *: 実際に社内で共有された、前職時にアクセシビリティ改善に取り組もうとしたところ、そのような意見がありアク セシビリティ改善に取り組むことが出来なかったというエピソードより
19. • アクセシビリティへの向き合い⽅などを導⼊するための資料を⽤意した • 「Webアプリケーションアクセシビリティ」(技術評論社)などの書籍をはじ め、freeeさん(*1)やSmart HRさん(*2)などの各社が公開されているアクセシ ビリティに関する各種リソースなどを参考に社内向けにまとめ直したものを3 パート+1に分けて作成した ◦ 著者の皆さんや各社の関係者の皆さん、その他これまでアクセシビリティに関するあらゆる 情報をオープンにしてくださっている皆さんに感謝 19 職種を跨いだ「アクセシビリティ勉強会」の実施 *1: 全てのメンバーにアクセシビリティー研修を実施しはじめました + 研修資料を公開します - freee Developers Hub https://developers.freee.co.jp/entry/a11y-training *2: アクセシビリティ | SmartHR Design System https://smarthr.design/accessibility/
20. • アクセシビリティって誰のため？何のため？ ◦ アクセシビリティの価値がどこにあるのかについて伝える • アクセシビリティ、初めの⼀歩 ◦ コントラストや画像‧動画表現、またはHTMLでコーディングする際などにまずは⾒てみたい項⽬を紹介 ◦ ⾃分たちの仕事のどういうポイントがまずはキッカケになるかを探してもらう狙い • アクセシビリティの低い状態を体験しよう ◦ Chromeの⾊覚多様性のエミュレート機能 ◦ スクリーンリーダーの体験 ◦ マウス禁⽌でどこまで操作できるか • アクセシビリティについて話し合ってみよう ◦ それらを受けて感じたことや出来そうな取り組みについて各々に話してもらう 20 「アクセシビリティ勉強会」の内容
21. • Slackの #accessibility を開設。アクセシビリティの話題を誰でも持ち込んで 話せるように • アクセシビリティに関する社内のハブにする • インターネットなどで⾒掛けた、ちょっとしたアクセシビリティ関連の話題 を提供したりしている • ⾊んな⼈が混ざって話すことでモチベーションも維持できる ◦ ハードルが下がることにも繋がる（はず？） • 後述の a11y 作業Dayもこのチャンネルの Huddle を活⽤ 21 横断かつ継続的なコミュニケーション
22. • HelpfeelのLP(*)を⼀緒にLighthouseを⽤いて検証しながら、 アクセシビリティの観点からどのような改善が出来るか会話 ◦ Lighthouseの項⽬の⾒⽅や⼿動でチェックが必要な項⽬についても点検 ⽅法を伝授 • メニューの⼀部がTabでフォーカスできない • CMSがimgのaltにデフォルトでファイル名を挿⼊している • Helpfeelのオレンジ⾊をテキスト⾊に使うとコントラスト⽐を 保つことが難しくなる 22 デザイナーチームと⼀緒にサービスLPを観察する会 *: https://helpfeel.com/
23. エンジニア組織内でアクセシビリティの改善を実施する ための取り組み 23
24. • エンジニアお茶会(*)でアクセシビリティ改善に関する発表を実施 ◦ 前述の社内向け資料に加えて、⼀般的なアクセシビリティ改善事例や具体的な社内のアプリ ケーション改善例などの紹介 • a11y作業DAYの開催 ◦ ⾃分(pastak)がアクセシビリティ改善を実際にやる様⼦をSlackのHuddleで1⽇中垂れ流す⽇ をやってみた ◦ この場で各プロダクトに対して横断的に取り組みをしていくための取っ掛かりを作るべく作 業をしていた ◦ 興味ある⼈に覗きに来てもらって⼀緒に作業したり、会話‧議論をしたりなどが出来た 24 エンジニアをモチベートしてアクセシビリティ改善を推進 *: いわゆる「社内勉強会」のHelpfeel社内での名称。隔週水曜日に開催しています。 詳しくは https://blog.notainc.com/entry/2021/12/16/090000 を
25. • eslint-plugin-a11y-jsx/recommendを試しに有効にしてみて、各サー ビスでどれくらいのエラーが検出されるかを整理 ◦ 100を超えるエラーが記載された結果の⼀覧だけがやってくると驚きがあるので、どの項⽬が どういった内容で、どういった関連があるか。修正にどれくらいかかるか等を前述のエンジ ニアお茶会の場などで共有 ▪ この辺の⾒積もりや知⾒などはmackerelチームでの開発合宿での経験(*)が基に 25 各プロダクトに対して横断的に取り組みをしていくための取っ掛かり *: https://speakerdeck.com/azukiazusa1/mackerel-noakusesibiriteigai-shan-shi-li
26. • 各サービスでeslintでは検出されないような改善を⾏うPull Requestを作成 • 元々社内のプロダクトをお互いに普段からドッグフーディングしている関係 上、軽微な変更や改善などのPull Requestは越境して送る⽂化がある • ⽇常的なドッグフーディングからアクセシビリティの改善点について、以前 から気になっていた箇所などを中⼼にPull Requestを作成した ◦ <a>と<button>の適切な使い分け ◦ ランドマークロールの改善 ◦ モーダル関連のフォーカスの改善 • ⾃分たちのプロダクトのアクセシビリティが改善される様⼦を実際に⾒ても らって、a11y-jsxと併せて、モチベーションのキッカケに 26 各プロダクトに対して横断的に取り組みをしていくための取っ掛かり
27. • 実際にサービス⾃体をしっかりWCAGの基準などに載せていくための機運は 醸成できていそう • Helpfeelを中⼼に各プロダクト毎にオーナーシップを持って改善に取り組め るような形をチーム毎に模索している ◦ a11y-jsx/recommendに関連した変更をしながら、理解や議論を深めて⾏っている状態 • a11y作業DAYはまとめて1⽇取ると⾊々やれて良かったが、実際にはMTGな どとの調整が⼤変なので、隔週のオフィスアワーみたいな感じにしようかな と思っています ◦ 実際はそういう場がなくてもある程度Slackで会話が出来ている状態ではある 27 その後の結果と現状
28. • アクセシビリティへの理解や改善の推進にあたっては最初から越境すること を念頭に置いてやってきた結果、上⼿く周囲や社内を巻き込んで機運を醸成 できてきた ◦ 以前、フロントエンドのテストの改善などに取り組んだときはプロダクトに閉じてしまっ て、他のプロダクトに上⼿くそれらの知⾒を導⼊‧伝播出来なかったという反省があった • 職種の越境とプロダクトチームの越境をそれぞれ⾏った ◦ 職種を越えて/混ぜて、アクセシビリティへの理解を促進する会やコミュニケーションの実施 ◦ プロダクトを越えての改善や知識の共通化 ◦ それぞれのチームで⾜並みを揃えて取り組んでいく 28 まとめ: キーワードは越境
29. • 具体的なアクセシビリティ改善はこれから随時プロダクトや各種アウトプッ トに反映されていくと思います。乞うご期待。 ◦ それぞれプロダクトのコアの部分とアクセシビリティの関わりについての深化もこれから取 り組んでいきます • ぜひお気づきの点などありましたら、お近くの関係者に直接やTwitterなどで 教えてください。 • 質問‧感想などはSlidoへ ◦ https://app.sli.do/event/9uXNnGetfdQ76KXC3nfbPF 29 俺たちの戦いはこれからだ