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

by Tajima Sachiko

Slide 1

Slide 1 text

田嶋幸智子株式会社SmartHRアクセシビリティエンジニアコンポーネントライブラリで実現する、アクセシビリティの正しい実装パターン

Slide 2

Slide 2 text

「TypeScriptとReactで、 WAI-ARIAの属性を正しく利用する」トグルルーム 15:50~16:20 ✕ WAI-ARIA の詳しい使い方や全般的な注意点 ✕ TypeScriptのニッチな話話さないこと ○ コンポーネントライブラリの嬉しさ ○ コンポーネントライブラリでアクセシブルな実装をするときに気をつけていることこのLTで話すことはじめに

Slide 3

Slide 3 text

⚫ 2024年8月入社（入社して9ヶ月） ⚫ 前職はフロントエンドエンジニア ⚫ 最近ポケポケに課金するべきか悩んでいる SmartHR / アクセシビリティエンジニアたじまん (tajiman, schktjm) 自己紹介

Slide 4

Slide 4 text

※ チームトポロジーで定義されたチームのひとつ ⚫ アクセシビリティ本部というイネイブリングチーム※ に所属 ⚫ アクセシビリティスペシャリストとアクセシビリティテスターが同じチームにいるアクセシビリティの専門知識をもつエンジニアアクセシビリティエンジニア自己紹介

Slide 5

Slide 5 text

労働にまつわる社会課題をなくし、誰もがその人らしく働ける社会をつくる。 well-working 会社紹介

Slide 6

Slide 6 text

2015年のローンチ以降継続的に新プロダクトをリリースし領域を拡大していきますサービス紹介

Slide 7

Slide 7 text

急成長するプロダクトのアクセシビリティ品質を保つには 01

Slide 8

Slide 8 text

プロダクトを早くアクセシブルな状態で届ける【私たちが目指していること】アクセシビリティ本部のミッション

Slide 9

Slide 9 text

できるならしたいけどネすべての開発者をアクセシビリティマスターにするということではありませんアクセシビリティ本部のミッション

Slide 10

Slide 10 text

仕組みを作ろうとしていますすべての開発者がWAI-ARIAを完全に理解しなくてもプロダクトがアクセシブルになるアクセシビリティ本部のミッション

Slide 11

Slide 11 text

リッチなアプリケーションの状態や意味を支援技術に伝える HTML属性 WAI-ARIA(ARIA)とはアクセシビリティ文脈でよく聞く「ARIA」

Slide 12

Slide 12 text

大いなる力破壊することもできる強化することも ARIAは支援技術のウェブの体験を、アクセシビリティ文脈でよく聞く「ARIA」

Slide 13

Slide 13 text

WAI-ARIAはどのような場合に使うとよいでしょうか A. HTMLだけでは十分にセマンティクスを表現しきれないときにWAI-ARIAを利用します。 Q.WAI-ARIAはどのような場合に使えばいいの？アクセシビリティ文脈でよく聞く「ARIA」

Slide 14

Slide 14 text

判断するのむつかしい … 十分なセマンティクス？アクセシビリティ文脈でよく聞く「ARIA」

Slide 15

Slide 15 text

アクセシブルなコンポーネントライブラリを提供して、現場で判断コストを下げよう！アクセシビリティ文脈でよく聞く「ARIA」

Slide 16

Slide 16 text

コンポーネントライブラリで、アクセシビリティ品質を守る 02

Slide 17

Slide 17 text

SmartHRらしさを表現するための基準や素材 SmartHR Design System デザインシステム

Slide 18

Slide 18 text

SmartHR UI ⚫ Reactでつくられたコンポーネント集 ⚫ OSSとして公開されている ⚫ 社内の有志のメンバーによりメンテナンスされているコンポーネントライブラリ

Slide 19

Slide 19 text

⚫ アクセシビリティ品質を保つ ⚫ シンプルで誤用をしにくいつくりにする【大事にしていること】アクセシブルなコンポーネントをつくるために

Slide 20

Slide 20 text

実際のコンポーネントをもとに実践してみようアクセシブルなコンポーネントをつくるために

Slide 21

Slide 21 text

⚫ title: string; //必須 ⚫ children: ReactNode; //必須 ⚫ errorMessage?: ReactNode; ⚫ helpMessage?: ReactNode; … まず入力要素以外をまとめられそうアクセシブルなコンポーネントをつくるために

Slide 22

Slide 22 text

⚫ 様々な入力要素 ⚫ 前後の補足の文章や画像 childrenとして渡すものアクセシブルなコンポーネントをつくるために

Slide 23

Slide 23 text

etc. ①適切なラベルを紐づける ②説明テキストも紐づける ③エラー状態のとき色だけで表現しないアクセシビリティチェックポイントアクセシブルな実装を考える

Slide 24

Slide 24 text

※childrenにはInput要素とラベルには適さないアイコンが入っている状態 ① 適切なラベルを紐づけるアクセシブルな実装を考える

Slide 25

Slide 25 text

⚫ childrenに渡された入力要素にラベルがアクセシブルネームとして紐づくようにする ⚫ childrenは入力要素以外が入ることも許容する【ポイント】 ①適切なラベルを紐づける

Slide 26

Slide 26 text

コンポーネントライブラリで提供する入力要素に共通のデータ属性を定義する ①適切なラベルを紐づける

Slide 27

Slide 27 text

データ属性を使って入力要素を取得 ①適切なラベルを紐づける

Slide 28

Slide 28 text

childrenに入力要素以外が含まれていても、正しくラベルと紐づけられるように ①適切なラベルを紐づける

Slide 29

Slide 29 text

② 説明テキストを aria-describedbyで紐づける

Slide 30

Slide 30 text

⚫ 補足のテキストを入力要素を詳しく説明するものとして入力要素に登録する ⚫ スクリーンリーダー向けに補足テキストを無闇に増やすのではなく、表示している情報と揃えるということを意識する【ポイント】 ②説明テキストをaria-describedbyで紐づける

Slide 31

Slide 31 text

入力要素を詳しく説明するものとして紐づけされる説明要素のIDを連結して入力要素のaria-describedby に渡す ②説明テキストをaria-describedbyで紐づける

Slide 32

Slide 32 text

②説明テキストをaria-describedbyで紐づける

Slide 33

Slide 33 text

③ エラーを色だけで表現しない

Slide 34

Slide 34 text

⚫ 入力が想定される形じゃないことを色以外の情報でも伝えたい ⚫ バリデーション実行後、スクリーンリーダーにも何がエラーになったか伝わるように【ポイント】 ③エラーを色だけで表現しない

Slide 35

Slide 35 text

入力要素の入力が想定される形ではないことを表現できる props.errorMessage > 0 の場合、入力要素に aria-invalid=“true” をつける ③エラーを色だけで表現しない

Slide 36

Slide 36 text

③エラーを色だけで表現しない

Slide 37

Slide 37 text

エラー要素が追加されるとスクリーンリーダーユーザーに通知が出るエラー文言のラッパーに role=“alert” をつける ③エラーを色だけで表現しない

Slide 38

Slide 38 text

③エラーを色だけで表現しない

Slide 39

Slide 39 text

でも単体で使っちゃうとアクセシブルじゃなくなる！？これで、入力要素とを使えばアクセシブルになる状態になった！

Slide 40

Slide 40 text

入力要素をもしくはで囲むことを促すEslintの独自ルール smarthr/a11y-input-in-form-control

Slide 41

Slide 41 text

Eslintの独自ルールの話は、テックブログにあがっているので気になる方は見てください！

Slide 42

Slide 42 text

⚫ アクセシブルなコンポーネントライブラリを提供することでプロダクトを最初からアクセシブルにできる ⚫ 想定されるパターンや使い方をPropsやeslintを使って限定することで、意図通りのアクセシビリティを届けるまとめ

Slide 43

Slide 43 text

Q. コンポーネントライブラリにないパターンが出てきたらどうするの？ Q&A

Slide 44

Slide 44 text

⚫ 新規の概念が出てきたとき、アクセシビリティ本部がアクセシブルな実装を検討する ⚫ 場合によってはSmartHR UIに逆輸入する ⚫ プロデザが既存のパターンで表現できないか徹底的に検討しているので、プロダクトごとに微妙に異なる状態はない A. アクセシビリティ本部で実装の補助をしたりチェックをしています。 Q&A

Slide 45

Slide 45 text

We are hiring!! https://recruit.smarthr.co.jp/ ありがとうございました