UI の状態変化 : disabled の使いどころを考える

こんにちは、株式会社Gaji-Labo の UIデザイナー 水澤です。
今回はボタンや入力フォームなどの UI の状態変化のひとつ、disabled（無効化）について書きます。

個人的には「デザインデータとして用意はしておくけど、ほとんど使用してないかも」という感触があります。では disabled の使いどころとして自身がどう捉えているのか、大手・有名サイトなどを参考に整理してみました。

※記事中の例は、今回の整理のために他社サイトをキャプチャしたものです。

HTML の disabled属性とは

disabled は論理属性で、存在する場合、その要素は変更不可、フォーカス不可、フォームへの送信不可となります。ユーザーはそのコントロールやフォームコントロールの子孫を編集したり、フォーカスしたりすることができません。

引用元：https://developer.mozilla.org/ja/docs/Web/HTML/Attributes/disabled

例えばボタンや入力フォームに disabled属性を追加した場合、その要素は非活性になり、ユーザーはボタンを選択したり、フォーム内に入力・編集をすることができない状態になります。

そもそも disabled にするべきか検討する

もしサービスを利用している途中で操作できない要素が表示されたら、ユーザーは戸惑いながらもなんとか操作できないか試行錯誤します。その末にユーザー自身が解決できないと判断してしまったら、そのまま諦めてサービスから離脱してしまうかもしれません。

やみくもに disabled 状態のパーツを配置することは、アクセシビリティに問題が生じる可能性があります。また、せっかくサービスを利用してくれていたユーザーの離脱は、機会損失につながります。

単に disabled にするだけではこのような問題が起きやすいため、本当に disabled にするべきか、他により適切な方法がないかを検討するようにしています。

ECアプリで商品が在庫切れの場合

例えば ECアプリで商品を購入したいとき、在庫がない商品を購入することはできません。そのことをどのようにユーザーに伝えられると良いでしょうか。

購入ボタンを disabled にして、ユーザーに商品が購入できないことを一見してわかるようにするアイデアも考えられそうですが、andST：カート画面 のようにそもそも操作できない購入ボタンは非表示にする方法もあります。加えて、購入できない理由をエラーテキストで伝える方法も検討できます。

会員登録で入力内容に条件がある場合

サービスを利用するために会員登録をするシーンでは、ユーザーにいくつかの情報を入力してもらう必要があります。その中のパスワード情報は、セキュリティ観点から文字数などの条件があります。そのことをユーザーにどのように伝えられると良いでしょうか。

入力内容の条件が満たないときは完了ボタンを disabled にして、条件を満たしたときだけ選択できるようにする方法もありますが、ユーザーは完了ボタンを選択できない理由がわからず操作に迷ってしまうかもしれない懸念があります。

GU：新規登録画面 のように、あらかじめ満たさなければならない条件を示しておくことでユーザーが迷わず操作できるようになります。ボタンは常に選択できる状態にして、もし条件を満たしていない状態で選択されたときは操作が必要な項目箇所・必要なアクションを示すようにすると、入力項目が多い場合も修正しやすいです。

使いどころのポイント：disabled にするべき理由を整理する

では、disabled にするべき理由にはどのようなものが考えられるでしょうか。
例として以下を挙げます。

• 特定権限を持つユーザーが編集できる情報であることを示す
• 別の手続きを通す必要があることを示す

どちらにも共通しているのは、「その情報が編集できることはユーザーに伝えつつ、編集するには特定の条件・手続きが必要であることを明示している」という点です。基本的にはユーザーが制限なく操作できることを良しと考えて設計することが多いですが、ここではその情報を簡単に編集できないようにしている意図があるということです。

どういうことか、次で詳しく説明していこうと思います。

特定の権限のみが編集できる情報の場合

複数のユーザーが関わるサービスでは、ユーザーに付与される権限という概念が必要なこともあります。例えば一部の操作制限がある権限では、操作できない要素に対して disabled にする＆補足テキストを表示することで、ユーザーは「機能そのものはあるけど、自身のアカウント権限では操作できない」と判断できます。

参考に Googleドライブ：共有ドライブの設定画面 を掲載しました。この画面では、共有ドライブに対するアクセス設定を操作できますが、ユーザーにその権限がないためチェックボックスがすべて disabled に表示されています。チェックボックスにカーソルを乗せると「この設定を変更する権限がありません」というテキスト説明が表示されるため、ユーザーは操作できない理由を明確に理解できます。

別の申請フローを通す必要がある場合

編集手段はあるものの、誤操作を厳密に防ぐ必要がある情報に対して disabled 表示にしている場合があります。参考の 楽天証券：取引暗証番号再設定画面 のように、金融機関の手続きでは特に情報の取り扱いに注意が必要なため、簡単に情報を編集できないようにしています。

この画面では、取引を行うときに必要な暗証番号を変更できます。その変更手順として、事前に登録済みの携帯電話番号に SMS が送信され、それに記載されたワンタイムキーを入力するという工程があります。そのため、送信先となる携帯電話番号の情報がわかるように明示されています（添付画像では、青いボタンの左隣に携帯電話番号が表示されています）。

青いボタンの下に多くの注釈テキストが表示され、この中に携帯電話番号を変更したいときの案内も含まれています。情報量は多いですが、まずはユーザーにとって必要な情報を明示することが重要です。

おわりに

今回は UI の状態変化 : disabled の使いどころについて、自分なりの考えをまとめてみました。基本的には disabled は使わず、他により適切な方法がないかを考えることでアクセシビリティを損なわないようにしたいと考えていることが自分の中で整理できました。

もしこれを読んでくださっている方で「disabled の使いどころはこうしてるよ！」というご意見がありましたら、気軽に教えてもらえたら嬉しいです。