サブミット (送信) ボタンをデフォルトで無効化しない
ウェブのフォームにおいて、サブミットボタンをデフォルトで無効化しておいて、ユーザーの入力不備がなくなったときにボタンを有効化する UI があります。たとえば、利用規約などの文書を読んで同意する旨のチェックを入れないと、あるいは、入力必須フィールドにすべて正しく情報を入れないと、ボタンがアクティブにならない、というものです。
このような UI は、主にアクセシビリティの観点で、以下の問題があります。
- そこに存在しているはずのボタンが使用できないことに対して、その理由をユーザーが理解できずに、混乱してしまう。(ユーザーの側に誤っているという自覚がなくても、ちょっとしたフォーマット不適合などの不備でボタンは無効化されたまま、というケースもある。)
- 無効化されたボタンには [Tab] キー操作でフォーカスを当てることができず、とりわけ視覚障害者ユーザーは、ボタンの存在を認知しにくい。(フォームの各フィールドに入力した後にサブミットボタンを押す、という流れを予測しにくい。)
- 無効化されたボタンは、グレーアウトされていることが多く、ラベルと背景色 (ボタンの塗りの色) とのコントラストが低いため視認しにくい。
解決案を検討する
こうした問題をなんとかするとして、いくつか、解決案を検討してみましょう。
ボタンが操作できない理由を伝える
なぜボタンが使用できないかをユーザーが理解できず、混乱してしまう可能性に対しては、その理由や有効化するための条件を、事前説明として (フォームの冒頭などに小さくでも) 記載するという解決が考えられるかもしれません。一見、インストラクションとしては丁寧ですが、その反面、読むべき情報が増えて冗長になってしまうという側面もあるので、ユーザーの学習負荷につながらないか、注意する必要があるでしょう。
また、ボタンを有効化するための条件を伝える手がかりとして、各フィールドにリアルタイムのバリデーションを仕込んでおく、という手も考えられかもしれません。ただ、あらかじめ (ユーザーが入力を行う前に) あたかもエラーのようなメッセージを提示してしまうと、かえってユーザー体験 (UX) を不快なものにしてしまう恐れがあります。適切なタイミングとトーンで、ダメ出しではなく行動を喚起するメッセージを提示したいものです。併せて、バリデーションをパスした際には、単にメッセージを消すのではなく、入力不備が解決された旨のメッセージを明示的に出力するとよいでしょう。そのメッセージ領域に aria-live を適用しておけば、スクリーンリーダーを介して利用する視覚障害者にとっても、ボタン有効化の条件をクリアしたことが知覚しやすくなります。
無効化されたボタンであってもフォーカスできるようにする
視覚障害者ユーザーが (たとえ無効化されたものであっても) ボタンの存在を認知しやすいように、[Tab] キー操作でフォーカスできるようにすべく、<button> 要素に disabled 属性の代わりに aria-disabled 属性を適用する、という解決が考えられるかもしれません。
そうすることで、ボタンにフォーカスが当たったとき、そのボタンが「使用不能」である旨をスクリーンリーダーを介してユーザーに伝達することはできます。加えて、より優れた UX のために、そのボタンを使用可能にするためにはどうすればよいかも併せて伝達したいところです。aria-describedby を用いて、(上記「ボタンが操作できない理由を伝える」のセクションで書いた) 事前説明と紐づける、などの工夫が考えられるでしょう。ただ上述のとおり、この事前説明は冗長な情報であるという側面もあるので、その点も踏まえて検討する必要があります。
無効化されたボタンであっても視認しやすいように十分なコントラストで配色する
ボタンの塗りの色については、そのボタンが無効化されている状態であれば、WCAG の規定上、コントラストの要件を問われることはありません (参考 : WCAG 2.1 達成基準 1.4.11 : 非テキストのコントラスト)。ただ、ボタンが有効化されたときの配色が「濃い塗り色と白抜き文字」である場合、そのボタンが無効化されていると「薄い塗り色と白抜き文字」という配色になることが多いため、テキスト (ボタンのラベル) と背景色 (ボタンの塗りの色) とのコントラストという点で考えると、無効化されたボタンの意味するところがユーザーに伝わりにくくなるというリスクはあるでしょう (参考 : WCAG 2.1 達成基準 1.4.3 : コントラスト (最低限))。
この問題を解決するために、無効化されたボタンであっても濃いめの塗り色を採用したり、あるいは薄い塗り色と濃い文字色の組み合わせを検討したりすることができるかもしれませんが、よほどうまく配色しないと、晴眼者ユーザーにとって、無効化された状態と有効化された状態の識別がかえって難しくなる恐れがあります。また、配色をこねくり回しすぎてしまうと結果的に、色の違いだけでボタンの状態 (無効/有効) の違いを識別させることにもなりかねません (参考 : WCAG 2.1 達成基準 1.4.1: 色の使用)。
多くのフォームでは「フールプルーフ」ではなく「フェイルセーフ」で十分なのでは？
このように検討してみると、サブミットボタンをデフォルトで無効化するという UI を、アクセシビリティの問題も解決したうえで実装するには、様々なことを考慮に入れる必要があると言えるでしょう。案外、実装コストがかかるな、という印象を持たれた方もいるのではないでしょうか。
そもそも、サブミットボタンを無効化する理由としては、「フールプルーフ (foolproof : 誤操作の未然防止)」を徹底したいという意図があるかもしれません。もちろん、ユーザーのつまずきをデザインで解決するにあたっては、まずは基本的にフールプルーフの考えかたは優先されるべきだと思いますが、これに固執するあまり、かえってユーザーにとって使いにくい、あるいは使えない状況を招いてしまうとしたら本末転倒な気がします。
たとえば二重課金を防止すべくサブミットボタンの二度押しをさせないように (一度押されたら) ボタンを無効化する、というフールプルーフはあるでしょうが、多くのフォームでは、なにもデフォルトではサブミットボタンを無効化しなくても済むのでは？という観点で検討してみてもよいと思います。
<label> 要素内に出力する。
これはいわば「フェイルセーフ (fail-safe)」の考えかたになりますが、シンプルで馴染みのある UI によって、ユーザーがつまずくことなくスムーズに利用できることを最優先しつつ、もし問題が発生したら、インクルーシブな形でメッセージを伝達し、それによって適切にリカバリーできるようにする、という具合です。なんの変哲もない UI ではありますが、多くのフォームでは、このような形で十分なのでは、と思います。