この記事はフラー株式会社 Advent Calendar 2024 の11日目の記事です。
10日目は @furusax さんで、「ISUCON14に出場して惜しくも優勝を逃しました（全体126位）」でした。

はじめに

私の体感では、ReactでWebアプリを作るときにRadix UIや React Aria といったUIコンポーネントライブラリの存在は欠かせないものになっています。

欠かせないものなので、新規でプロジェクトを作成する際は、必ず「どのUIコンポーネントライブラリを使うか」もセットで検討しています。

だんだんそれが当たり前になってきて、「なんでUIコンポーネントライブラリに頼るのか」を気にすることがなくなってきてしまったので、この機会に思い返してみようと思います。

UIコンポーネントライブラリに頼る理由

考えてみた結果、大きく分けて2つくらい理由がありそうだなと考えています。
具体的には以下です。

実装工数を大幅に削減できる
コンポーネントの使用方法を守ることで、アクセシビリティをある程度担保できる

これだけ書いてもよく分からないので、下でもう少し詳しく書きます。

実装工数を大幅に削減できる

やはりこの理由が大きいのですが、DialogやToast、Tooltipなど、作るのが大変なUIコンポーネントを簡単に扱えるようになるのは大きいです。

もしUIコンポーネントライブラリに頼ることができない場合、必要に応じて自作する必要があるので、複雑なUIコンポーネントが増えるほど、UIコンポーネントの実装工数も純増してしまいます。

そして、実装したUIコンポーネントもメンテナンスをする必要があり、UIコンポーネント起因のバグへの対処もすることになります。

結果、Webアプリのコアとなる機能の実装へ割くことができるパワーも少なくなってしまうので、よくないことばかり起きてしまいます。

UIコンポーネントライブラリを頼ることによって、これらの問題点を解消し、Webアプリの価値を高めることに注力できるのは大きなメリットだと思います。

もちろん、将来的にUIコンポーネントライブラリがメンテナンスされなくなったときに、別のUIコンポーネントライブラリを探したり、自力で代替のUIコンポーネントを自作しないといけないというリスクを背負うことにはなります。
しかし、そのリスクを鑑みても、享受できるメリットのほうが大きいと感じています。

コンポーネントの使用方法を守ることで、アクセシビリティをある程度担保できる

今年のアクセシビリティ回りの大きなニュースとして、民間事業者の合理的配慮の義務化がありました。
参考: https://www.gov-online.go.jp/useful/article/202310/2.html#c1

これによって、アクセシビリティを確保することがより一層求められるようになってきたと考えています。

ただ実際問題として、アクセシビリティを確保するのは結構難しいです。
個人的に一番難しいのは、ARIA Authoring Practices Guideに従ってアクセシブルなコンポーネントを作ることです。

アクセシブルなコンポーネントを作る関門は3つあると思っています。
具体的には以下の3つです。

適切なセマンティクスの提供
キーボードナビゲーション
フォーカス制御

ARIA Authoring Practices Guideを読むことで、上記3つをどう担保すればよいかは分かります。
しかし、それを実装に反映するには高いスキルが必要になってきます。

以上を踏まえると、UIコンポーネント側でアクセシビリティ回りの実装を担保できるのは十分なメリットだと思っています。

ただ、ここで気を付けたいのは、「実装者にアクセシビリティの知識はある程度必要である」という点です。
「コンポーネントの使用方法を守ることで」と書いてあるのはここが理由で、UIコンポーネントも使い方を間違ってしまうと、アクセシビリティを確保することができません。

例えば、Radix UIにおけるAlert Dialogコンポーネント、Dialogコンポーネントは、機能的にそんなに違いはありません。
違いは使われているロールにあり、それぞれ alertdialogロール、dialogロールが使用されています。

MDNには

通常のダイアログとの違いは、alertdialog ロールはアラート、エラー、またはワーニングが発生した場合にのみ使用するべきであることです。言い換えれば、ダイアログの情報とコントロールがユーザーの即時の注意を必要とするとき、dialog の代わりに alertdialog が使用されるべきです。この区別をするのは開発者次第です。

とあり、alertdialogロール、dialogロールの意味に違いのあることが分かります。

もし実装者がこのことを知らずにAlert Dialogコンポーネント、Dialogコンポーネントの使い分けを行うと、支援技術に適切な意味が伝わらず、読み上げソフトを使用しているユーザーが混乱してしまう原因になってしまう恐れがあります。

以上から、UIコンポーネントライブラリの使い方もある程度気を付ける必要があると思っています。
大抵UIコンポーネントライブラリのドキュメントに、準拠するデザインパターンへのリンクがあるので、そこを参照しながら知識をつけていけるとよいかな......?と思っています。

おわりに

自分なりにUIコンポーネントライブラリに頼る理由を言語化してみました。

こういうことを明確にしておくと、何か判断を行うときの重要な指針になったりするので、今後も定期的に振り返っていきたいなと思っています。

明日は @Mgtantheta さんで「【Android】Navigation ComposeのSafe Argsについて(フォルダの分け方など)」です!