コンポーネントライブラリで実現する、アクセシビリティの正しい実装パターン

TSKaigi2025の登壇資料です

読みにくい場合は Google DriveにPDFを上げているため、そちらを変わりに参照ください
https://drive.google.com/drive/u/1/folders/1Dz93RP0DEHYDAJzUnqbdiEGgAxOb_dGc

Transcript

1. 田嶋幸智子 株式会社SmartHRアクセシビリティエンジニア コンポーネントライブ ラリで実現する、 アクセシビリティの正 しい実装パターン
2. 「TypeScriptとReactで、 WAI-ARIAの属性を正しく利用する」 トグルルーム 15:50~16:20 ✕ WAI-ARIA の詳しい使い方や全般的な注意点 ✕ TypeScriptのニッチな話 話さないこと ◦ コンポーネントライブラリの嬉しさ ◦ コンポーネントライブラリでアクセシブル な実装をするときに気をつけていること このLTで話すこと はじめに
3. ⚫ 2024年8月入社（入社して9ヶ月） ⚫ 前職はフロントエンドエンジニア ⚫ 最近ポケポケに課金するべきか悩んでいる SmartHR / アクセシビリティエンジニア たじまん (tajiman, schktjm) 自己紹介
4. ※ チームトポロジーで定義されたチームのひとつ ⚫ アクセシビリティ本部というイネイブリング チーム※ に所属 ⚫ アクセシビリティスペシャリストとアクセシ ビリティテスターが同じチームにいる アクセシビリティの専門知識をもつエンジニア アクセシビリティエンジニア 自己紹介
5. 労働にまつわる社会課題をなくし、 誰もがその人らしく働ける社会をつくる。 well-working 会社紹介
6. 2015年のローンチ以降 継続的に新プロダクトをリリースし 領域を拡大していきます サービス紹介
7. 急成長するプロダクトの アクセシビリティ品質を 保つには 01
8. プロダクトを早く アクセシブルな状態で 届ける 【私たちが目指していること】 アクセシビリティ本部のミッション
9. できるならしたいけどネ すべての開発者を アクセシビリティマスターにする ということではありません アクセシビリティ本部のミッション
10. 仕組みを作ろうとしています すべての開発者がWAI-ARIAを完 全に理解しなくてもプロダクトが アクセシブルになる アクセシビリティ本部のミッション
11. リッチなアプリケーションの 状態や意味を支援技術に伝える HTML属性 WAI-ARIA(ARIA)とは アクセシビリティ文脈でよく聞く「ARIA」
12. 大いなる力 破壊することもできる 強化することも ARIAは支援技術のウェブの体験を、 アクセシビリティ文脈でよく聞く「ARIA」
13. WAI-ARIAはどのような場合に使うとよいでしょうか A. HTMLだけでは十分にセマンティクスを表現 しきれないときにWAI-ARIAを利用します。 Q.WAI-ARIAはどのような場合に使えばいいの？ アクセシビリティ文脈でよく聞く「ARIA」
14. 判断するのむつかしい … 十分なセマンティクス？ アクセシビリティ文脈でよく聞く「ARIA」
15. アクセシブルな コンポーネントライブラリを提供して、 現場で判断コストを下げよう！ アクセシビリティ文脈でよく聞く「ARIA」
16. コンポーネントライブラリで、 アクセシビリティ品質を守る 02
17. SmartHRらしさを表現するための基準や素材 SmartHR Design System デザインシステム
18. SmartHR UI ⚫ Reactでつくられたコンポーネント集 ⚫ OSSとして公開されている ⚫ 社内の有志のメンバーによりメンテナンスされている コンポーネントライブラリ
19. ⚫ アクセシビリティ品質を保つ ⚫ シンプルで誤用をしにくい つくりにする 【大事にしていること】 アクセシブルなコンポーネントをつくるために
20. 実際のコンポーネントをもとに 実践してみよう アクセシブルなコンポーネントをつくるために
21. ⚫ title: string; //必須 ⚫ children: ReactNode; //必須 ⚫ errorMessage?: ReactNode; ⚫ helpMessage?: ReactNode; … <FormControl> まず入力要素以外をまとめられそう アクセシブルなコンポーネントをつくるために
22. ⚫ 様々な入力要素 ⚫ 前後の補足の文章や画像 childrenとして渡すもの アクセシブルなコンポーネントをつくるために
23. etc. ①適切なラベルを紐づける ②説明テキストも紐づける ③エラー状態のとき色だけで 表現しない アクセシビリティチェックポイント アクセシブルな実装を考える
24. ※childrenにはInput要素とラベルには適さ ないアイコンが入っている状態 ① 適切なラベルを紐づける アクセシブルな実装を考える
25. ⚫ childrenに渡された入力要素にラベルがアクセ シブルネームとして紐づくようにする ⚫ childrenは入力要素以外が入ることも許容する 【ポイント】 ①適切なラベルを紐づける
26. コンポーネントライブラリで提供する入力要素に 共通のデータ属性を定義する ①適切なラベルを紐づける
27. データ属性を使って入力要素を取得 ①適切なラベルを紐づける
28. childrenに入力要素以外が含ま れていても、正しくラベルと紐 づけられるように ①適切なラベルを紐づける
29. ② 説明テキストを aria-describedbyで紐づける
30. ⚫ 補足のテキストを入力要素を詳しく説明する ものとして入力要素に登録する ⚫ スクリーンリーダー向けに補足テキストを無 闇に増やすのではなく、表示している情報と 揃えるということを意識する 【ポイント】 ②説明テキストをaria-describedbyで紐づける
31. 入力要素を詳しく説明するもの として紐づけされる 説明要素のIDを連結して入力 要素のaria-describedby に渡す ②説明テキストをaria-describedbyで紐づける
32. ②説明テキストをaria-describedbyで紐づける
33. ③ エラーを色だけで表現しない
34. ⚫ 入力が想定される形じゃないことを色以外の 情報でも伝えたい ⚫ バリデーション実行後、スクリーンリーダー にも何がエラーになったか伝わるように 【ポイント】 ③エラーを色だけで表現しない
35. 入力要素の入力が想定される形で はないことを表現できる props.errorMessage > 0 の場合、 入力要素に aria-invalid=“true” を つける ③エラーを色だけで表現しない
36. ③エラーを色だけで表現しない
37. エラー要素が追加されると スクリーンリーダーユーザーに通 知が出る エラー文言のラッパーに role=“alert” をつける ③エラーを色だけで表現しない
38. ③エラーを色だけで表現しない
39. でも単体で使っちゃうとアクセシブルじゃなくなる！？ これで、入力要素と<FormControl>を 使えばアクセシブルになる状態になった！
40. 入力要素を <FormControl> もしくは <Fieldset> で囲むことを促すEslintの独自ルール smarthr/a11y-input-in-form-control
41. Eslintの独自ルールの話は、テックブログにあ がっているので気になる方は見てください！
42. ⚫ アクセシブルなコンポーネントライブラリを提供するこ とでプロダクトを最初からアクセシブルにできる ⚫ 想定されるパターンや使い方をPropsやeslintを使って限 定することで、意図通りのアクセシビリティを届ける まとめ
43. Q. コンポーネントライブラリにない パターンが出てきたらどうするの？ Q&A
44. ⚫ 新規の概念が出てきたとき、アクセシビリティ本部 がアクセシブルな実装を検討する ⚫ 場合によってはSmartHR UIに逆輸入する ⚫ プロデザが既存のパターンで表現できないか徹底的 に検討しているので、プロダクトごとに微妙に異な る状態はない A. アクセシビリティ本部で実装の補助を したりチェックをしています。 Q&A
45. We are hiring!! https://recruit.smarthr.co.jp/ ありがとうございました