READYFOR AdventCalendar 2020 12/09 UIの実装で考えていること, 気をつけたいこと

READYFOR にフロントエンドの業務委託として参加している yamanoku です。
現在、デザインシステムを活用したSPAでのコンポーネント実装に携わっています。

私がWeb UIコンポーネント（以下: UI）を実装する中で個人的に大切にしていることについてを某LT会にて発表しました。今回はその内容と、加筆したものを記事にして紹介してみます。

例：ボタンUIを実装する際に気をつけること

いろいろな文脈があるとは思いますが、まず最初にこれは「リンクとしてのボタン」なのか「何かを動かすためのボタン」なのか「送信するボタン」なのかというのを考えます。

`<button>` のボタンである場合

type 指定をする
- 指定をしないとデフォルトで submit（送信）と決まってしまうので設定する
disabled の考慮
- リンクボタンと違って操作できる・できないが設定できる
- 操作できないときのスタイルはどうなっているか
onClick の挙動
- keydown まで考慮してしまうと Firefox ではスペース操作で2回挙動するバグが存在するので注意が必要
デフォルトのスタイルを消すための考慮
- apperance: none; のほか border, background-color, margin, padding などを必要に応じてリセットする必要がある

`<a>` のボタンである場合の考慮

ハイパーリンクとして視覚的に認識できるか
- <button> ではないと判別できるものはあるか
  - 使いどころを分けているか（流用する危険性はないか）
  - Storybookのようなコンポーネントリストで見たとき判別できるようにしているか
    - 使用例があるとベター
href は存在しているか
- 遷移先のURLは存在するか
- 存在しない場合、リンクとしてフォーカスができなくなる

ボタンとしての共通の考慮

リンクや何かしら挙動させる・送信するボタンである時の共通の考慮事項です。

フォーカスアウトラインの制御
- outline を消していないか
- ホバー状態とは別個に考えているか
押された時（active）の見た目や状態をどうするか
ボタン内部にテキスト情報が含まれているか
- アイコンだけしか内包されていない場合は aria-label で何者かを証明してあげる
  - <span class="icon-search" aria-label="Search"></span>

ざっと一例でした。もっとニーズを広げてみるともう少し考えることがありそうです。

なぜ考慮しないといけないのか

UIデザイン単体のものを画面で当てはめた時にそれが違ったりすることがあります。
これは私の経験ですが ~Link と命名されたUIデザインがあったので、当初は <a> で実装していました。
ですが、これは実際に画面上に当てはめてみると「クリックをしてモーダルを開閉するためのもの」として使われるものでした。
インタラクションとしてのものは <button> で表現してあげたほうが適切です。

なので このUIは一体何をするものなのか が共通解としてできているとベターだと思います。
そうすることで双方のコミュニケーションコストも解消してスムーズに開発ができ、より広い層のユーザーをカバーすることにも繋がります。

もちろん業務でやる以上スケジュールやコストとの相談も出てくると思うので、１人で突っ走るよりかは どこまでの何が必要なのか を皆で話し合えるようになるといいかもしれません。

セマンティクスであることは「いらない」考慮を減らしてくれる

ちなみに上述したボタンUIについてですが、aタグやbuttonタグではなく、divというもので考えることも可能です。

<div>Button</div>

もちろんこれだけではボタンとしての機能を確保できません。

<div
  class="button"
  role="button"
  tabindex="0"
  onClick="ClickHandle"
  onKeyUp="KeyUpHandle"
  onKeyDown="KeyDownHandle">
  Button
</div>

こうした情報が最低限必要になります。

<button
  type="button"
  onClick="ClickHandle">
  Button
</button>

しかしセマンティクスな表現をしてあげるとこれだけで済みます。
正しいHTMLを選択することで実装コストも減り、利用するユーザに最低限の正しい機能を提供できるということにも繋がります。

つまりこれは いらない考慮をする 機会を減らしてくれるので、積極的に正しいHTMLを書いていくべきです。

実装時参考にしているもの

私がUIを実装しているとき、参考にしているものを紹介します。

HTML Living Standard

HTMLの仕様書。内包できるものや使い方といったことを見返す時に役に立っています。

Web Accessibility Tutorials

アクセシビリティを考慮したコンポーネント作成例。あらゆる人が使えるように考える点で参考になります。

ソシオメディア | ヒューマンインターフェースガイドライン

ソシオメディアが公開しているヒューマンインタフェースデザインでの指針。GOODやBADといった例も載っているのでそうしたプラクティスに則っているかを確認できます。

UIというものに向き合ってみて学べたこと

「このUIは一体何をするものなのか」ということを自分なりに考えてみた結果、結論としてちゃんと納得させるような習慣がつけられるようになってきました。

たとえばコンテンツを内包するもの（container, wrapper）の最大幅を考える時、皆さんはどういう基準や判断でその数値を決めていますでしょうか。

サイトやアプリの設計によるものなので絶対の正解はありませんが、私のサイトでは最大文字数のため考えるようにしています。そのため最大幅の数値は ch で設定しています。

最大幅について

メインコンテンツの最大幅は80chに設定しています。chはチェーンと呼ばれ、文字のサイズによって可変する単位です。

この設定にすることのメリットとして、長文が読めない読字障害の利用者のサポートができたり、文字サイズが大きくなるに従ってテキストの一部が欠けて読めなくなるような事態も発生しにくくなります。
https://github.com/yamanoku/yamanoku.github.io/blob/dev/EXPLAINING_PORTFOLIO_SITE_ja.md#最大幅について

このようにWeb上で表現されているものの意味を突き詰めて考えてみると、それが１つのフレームワークとしてどこかで流用でき、迷いない意思決定がしやすくなると思っています。

おわりに

ブラウザを通じてユーザーに良い体験を提供するため、考慮していくことや考えていくことはどんどん増えてきていくかもしれません。そうした中で常に正しいものを提供していくというのは大変なことです。

私が今回記事として書いたものも間違った考慮となっている場合があるかもしれません。そうなったとき、間違っている部分があったとしたらすぐに気づいて直していけるようにしていく体制も必要だと感じます。

そして、みんなで良いUIとは何か？というものを考えながら作っていけるといいなと願っています。

明日はtoyocさん記事になります。お楽しみに 🎉🎉🎉

Discussion