デザインシステムで アクセシビリティ品質が 担保できなかった 「3つの理由」

登壇情報:
https://www.mt-tokyo.net/mtddc2025/speaker/speaker3092662.html

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

Transcript

1. デザインシステムで アクセシビリティ品質が 担保できなかった 「3つの理由」 SmartHR アクセシビリティエンジニア 田嶋幸智子 (たじまん)
2. すべてのページ写真撮影 OK #MTDDC で資料投稿しています！ 2
3. 自己紹介 • たじまん (田嶋幸智子 ) • SmartHR(2024/08〜) • アクセシビリティエンジニア • 前職自社開発のフロントエンドエンジニア • @schktjm 3
4. （簡単なSmartHRの会社紹介） 4
6. SmartHR Design Systemとは • 概要 ◦ SmartHR Design Systemは、サービスに関わるすべての人 が プロダクトに限らず SmartHRらしい表現をするための基 準や素材をまとめたもの • 構成要素 ◦ 基本原則 :「SmartHRらしさ」や「4つの価値観」を定義 ◦ 基本要素 : ロゴ、色、タイポグラフィ、アイコンなど ◦ 3つのコンテンツカテゴリ ▪ プロダクト : UIコンポーネントや実装コードなど ▪ コミュニケーション : マーケティング・広報向け ▪ アクセシビリティ : 誰でも使えるサービスにするための チェックリストやガイドライン 6 ( smarthr.design/ )
7. デザインシステムと アクセシビリティ品質向上のための取り組み • アクセシビリティ品質定義やガイドラインの作成 • アクセシブルなコンポーネントライブラリの提供 • カスタムeslintルール等仕組みの作成 7
8. アクセシビリティ品質基準・ガイドラインの作成 高いアクセシビリティ品質を実現するた めに、開発方針や、アクセシビリティの 品質基準を定めています。 • 開発方針 • アクセシビリティの品質基準 8
9. アクセシブルなコンポーネントを提供する SmartHRのアプリケーションをつくるためのコンポーネン ト集です。 アクセシブルなコンポーネントを提供することで、使うだけ でプロダクトをアクセシブルにします。 • SmartHR Design System • GitHub - kufu/smarthr-ui: React components for creating SmartHR applications. 9
10. カスタムeslintルール等仕組みをつくり導入する コンポーネントだけではなく、 Eslintのカ スタムルールやその他アクセシブルなプ ロダクトを作るための仕組みを導入して います。 10 アクセシビリティを担保するために ESLintの独自ルールを作っている話
11. これだけ完璧なデザインシステムがあれば、 アクセシビリティもすぐに達成基準達成！ となりませんでした 11
12. 今日はデザインシステムだけでは なぜアクセシビリティ品質が担保できなかったのか 「3つの理由」と それぞれどう解決しているかをお話します。 12
13. 目次 1. 完璧なデザインシステムで防げなかった事件紹介 2. 理由1: 最低要件に対する認識のズレ 3. 理由2: 情報を利用するハードル 4. 理由3: 専門組織によるおまかせ状態 5. 対策 13
14. デザインシステムでは防げなかった 事件紹介 14
15. ケース1: 存在しない ID事件 15
16. 課題: チェックボックスのアクセシブルネームがな い問題 カスタマイズされたチェックボックスにて、「アクセシブル ネーム」がない課題が発生しました！ アクセシブルネームがないと、スクリーンリーダーなど支 援技術がチェックボックスの機能や役割を伝えることがで きません。 Accessibility Visualizerを利用するとアクセシブル ネームがあるか簡単に確認できます [※1] 16
17. 対策: コンポーネントを新しくつくりました！ アクセシブルネームを持つ要素を指定で きる aria-labelledby属性 の指定を必須 にしました そのため、このコンポーネントを使用すれば アクセシブルネームが無いという問題がかな らず防げる ...! 17
18. 起きたこと → でたらめな文字列が 渡された 文字列が渡されているためエラーにはならないが、 存在しない IDなのでアクセシブルネームは設定されない 18
19. 😵 19
20. ケース2: 文字列は文字列でも空文字列事件 20
21. 課題: 入力要素はアクセシビリティ NGが発生しが ち問題 ユーザーが「操作」する必要がある入力要素には アクセシビリティ的に気をつける点がたくさんあり ます！ 21
22. 対策: これさえやればアクセシブルになるようにコ ンポーネントを実装しました！ • コンポーネントに可視ラベルを用意する • 入力要素全体を <form> で包む • エラーが発生したら、 props.errorMessages に渡す 22
23. 必要な要素は、型や eslintで補足 • Propsの型で縛りつつ、 JSDocにてpropsの解説を追加 • 使い方が間違っているものは、 eslint のエラーにて解説するように smarthr-ui を使用すればアクセシビリティの課題は 発生しないように！ 🎉 23
24. 起きたこと → 空文字で回避する例が起きた 空文字を渡しているため、 eslint や TypeScriptエラーは回避しているが、ラベルは ついていない、、、 ※ kufu はSmartHRのGitHub Organization名です 24
25. 機械的なチェックは通っても「アクセシブル」からは 遠のいている状態に ...orz TypeScriptによる型を縛ったり、 eslint ルールを強化しても回避されてしまう可能性 が生じた 25
26. もちろん、 意図的にアクセシビリティを下げたわけで はありません 26
27. 理由1: 最低要件に対する認識のズレ 27
28. まず、それぞれ何を MUSTと考えているのか？ アクセシビリティ本部は 「プロダクトが誰でも使える状態にする こと」 役割が違えば優先順位も変わる プロダクトエンジニアは 「早く価値を届けること」 28
29. アクセシビリティ本部の狙い • smarthr-ui をアクセシブルにして、プロダクト はほぼアクセシブルな状態に • アクセシビリティ課題がありがちなコンポーネン トや、特殊な実装は eslint でアクセシブルに • のこりを人の手でアクセシブルにして完璧 29
30. 狙っていた動き • 新規機能の実装をする • 理由がわからないエラーがでたのでコミットできない！ • 解説を読んだら理由がわかった！ • 修正してコミット！ →すごいアクセシブル！ 30
31. 早くリリースするために • 新規機能の実装をする • 理由がわからないエラーがでたのでコミットできない！ • 一旦回避してコミット！ →回避したものは忘れられて問題となる、、、 31
32. しかし、なにかがおかしい 🤔 アクセシビリティ品質を実装時から高くすれば、 最初から価値が高い状態で届けられるはず 32 もしかしたら、 現在の開発プロセスには「アクセシビリティ品質」を 考 慮・評価する機会がない のかもしれない
33. SmartHRに求めるアクセシビリティ品質基準 • 目標とする品質基準 ◦ JIS X 8341-3:2016 のレベルA + α • 品質達成のための方法 ◦ 新規開発時 : ウェブアクセシビリティ簡易チェックリスト [※2]を満たす ◦ 既存の改修 : アクセシビリティ本部がやるため開発チームには求めない 33
34. SmartHRに求めるアクセシビリティ品質基準 • 目標とする品質基準 ◦ JIS X 8341-3:2016 のレベルA + α • 品質達成のための方法 ◦ 新規開発時 : ウェブアクセシビリティ簡易チェックリスト [※2]を満たす ◦ 既存の改修 : アクセシビリティ本部がやるため開発チームには求めない 34 この複雑さにより、新規開発時の品質基準の前提を知らないかも
35. 35 アクセシビリティ品質を 考慮・評価する機会が開発プロセ スにない可能性 知っていたけど できなかった 新機能開発時に、 アクセシビリティ品質基準達成を前 提条件としていることが 知られていない可能性 知っていなかった 教訓: なぜアクセシビリティ品質が低くなるのか
36. 理由2: 情報を利用するハードル 36
37. 1. 実装中にLintエラーが出る 2. エディタ上の解説（ JSDoc/エラー文）を読む 3. 「なるほど、アクセシビリティにはこれが必要なのか」と理解する 4. 正しく実装する 37 「品質向上」と「スキルアップ」の一石二鳥 理想的な開発フロー エラーメッセージを「教育コンテンツ」として利用
38. エラーの一次的な回避を選択していた • 空文字で回避 • 存在しない IDをaria-labelledbyに渡す 38 実際にアクセシビリティの問題となったコードでは
39. 機能実装と学習の両立の難しさ • メインタスク： 脳のメモリを占有する機能実装 • アクセシビリティ学習： 専門外の領域への理解が必要 👉 同時進行は、あまりに「高い壁」 39 要因①
40. 学習ハードルの見積もりの甘さ • 学習のハードル ◦ 知識がある側にとっての「親切な説明」 ◦ 知識がない側にとっては「未知の専門用語の羅列」 • 心理的なハードル ◦ スキル不足を自覚している人ほど、新しい概念の習得 を実際以上に高い壁に感じてしまう 40 要因② 👉ハードルを飛び越えるには必要性や余裕、興味等きっかけが必要
41. 教訓: エラーは教育コンテンツとしてなり得ない • Lintや型定義でガチガチに固めれば品質が守れるは、間違い • 習慣や知識の土台がなければ、ルールは回避される 41
42. 理由3: 専門チームが存在することによる弊害 42
43. デザインシステムによる嬉しい効果 43 smarthr-ui によって、コンポーネントを組み合わせただけで高い品質のフロントエン ドができるようになった 👏 新しいプロダクトではアクセシビリティの NGが激減した 🎉 アクセシビリティの悩みや相談が減り、プロダクトエンジニアは機能 開発に集中できるようになった
44. しばらく経つと、、、 以前では見かけなかった見落としによる基本的な NGが発見された！ 44
45. エンジニアの意識の変化 「何も考えなくてもできる」から、関心を持たなくても成立するようになった 45
46. 専門チームがいるという安心感の錯覚 「アクセシビリティ本部がいる」ことによって最終的な品質の担保はするから安心 してねというメッセージになってしまったのかもしれない 46 ✗ アクセシビリティ本部が品質を担保する ◯ アクセシビリティ本部がいなくても、品質が保たれる
47. 教訓 • システムは「考えるきっかけ」を奪ってはいけない • アクセシビリティは「みんなでやる」文化と仕組みの両方で担保するべし 47
48. 対策 48
49. まず今までの学び • 最低要件に対する認識のズレを減らす • スキル獲得のためのコストを低くする • アクセシビリティ品質向上はみんなでやるものとする 49
50. 3つの対策を計画中です 1. 品質の定点観測 2. 人の育成 3. 意識の醸成 50
51. 現状の課題：品質が見えない • テスト実施は不定期 ◦ テスターリソース不足など様々な都合によりタイミングを見て実施していた • 「現在の品質」がわからない ◦ テストをしてから共有していたため、現在の状況を把握する手段がない 1. 品質の定点観測 51
52. 解決策：品質の定点観測 • 手法：ページの無作為抽出 ◦ 試験コストを下げ、短期的に繰り返し実行可能に • 効果：品質の可視化と意識向上 ◦ 現在地を知る ： 自チームの品質や他との比較が可能 ◦ 競争と鼓舞 ： 品質の高い /低いを可視化し、改善を促す 1. 品質の定点観測 52
53. 2. 人の育成 いままで「 アクセシビリティ好きな人がわいわい集まり知見を共有する場 」として「アク セシビリティマスターの会」というものがありました。 この「アクセシビリティマスター」の 役割を定義 しつつ、アクセシビリティスキルを育て る場として活用することにしました。 53
54. アクセシビリティマスターの再定義 1. 体制と役割 ◦ 各チームに 1名配置を目標 ◦ プロダクトの品質に責任を持つ 2. 育成サイクルの実践 ◦ 実際のNG箇所をアクセシビリティエンジニアと相談しながら修正 ◦ 修正で得た知見を「マスター会」でチーム横断共有 ２. 人の育成 54
55. 3. 意識の醸成 これはまだ計画段階ですが「アクセシビリティ品質は必須項目」という意識付けをする ための計画を考えています。 • トップダウンで広く共有してもらう • コンプラ研修のように定期的に研修を実施する など 55
56. 意識の醸造がなぜ必要なのか語る記事がでました アクセシビリティ本部を統括する方のブ ログをご覧ください https://note.com/oujimiyahara/n/n60 1f5972c02a 56
57. まとめ アクセシビリティ品質向上は、仕組みをつくって終わりではなくそれが当たり前となる 文化を育んでこそ成り得るもの！ 仕組みづくりと、アクセシビリティをみんなでやる文化づくりをしてプロダクトのアクセ シビリティ品質向上をより強固にしよう！ 57
59. ありがとうございました 59
60. 資料 • ※1: Webアクセシビリティ用語「アクセシブルな名前（アクセシブルネーム）」の 解説 • ※2: ウェブアクセシビリティ簡易チェックリスト • ※3: ユーザーはいかにテキストを読まないか – U-Site 60