無効なボタンをより包括的にします-CSSチュートリアル-php.cn

無効なボタンをより包括的にします

無効なボタンについて話しましょう。具体的には、なぜそれらを使用するのか、HTMLの従来の無効化された属性（

無効化されたボタンが非常に理にかなっている場合、多くのユースケースがあり、すぐにそれらの理由に到達します。しかし、この記事を通して、ショッピングカートに多くのチケットを追加できるフォームを検討します。

「カートに追加」ボタンを無効にするための明確な状況があるため、これは良いベースラインの例です。カートに追加するチケットがない場合です。

しかし、最初に、なぜ無効になったボタン？

人々が無効または利用できないアクションを実行するのを防ぐことは、障害のあるボタンに到達する可能性のある最も一般的な理由です。以下のデモでは、カートに追加されているチケットの数がゼロより大きい場合にのみチケットを追加できます。試してみてください：

このデモでコードの説明をスキップして、重要なことに注意を向けることを許可してください：「カートに追加」ボタン。

 <button type="submit" disabled>
  カートに追加
</button>

ログイン後にコピー

このボタンは、無効な属性によって無効になっています。（これはブール属性であることに注意してください。つまり、無効または無効にされる= "無効"として記述できることを意味します。）

すべてが順調に思えます…それで、何が問題なのですか？

正直に言うと、私はここで記事を終了することができます。障害のあるボタンは吸うので、障害のあるボタンを使用しないようにし、代わりにより良いパターンを使用します。しかし、現実的にしましょう。ボタンを無効にすることが最も理にかなっているソリューションです。

そうは言っても、このデモの目的のために、「カートに追加」ボタンを無効にすることが最良のソリューションであるとふりかけます（ネタバレアラート：そうではありません）。それを使用して、それがどのように機能するかを学び、途中でその使いやすさを向上させることができます。

相互作用の種類

障害のあるボタンが使用できることの意味を明確にしたいと思います。ボタンが無効になっている場合、それは使用できないはずです。だから…キャッチは何ですか？私と一緒に耐えなさい。

ウェブ上には、ページと対話する方法が複数あります。マウスを使用することは最も一般的なものの1つですが、運動障害のためにキーボードを使用してナビゲートする目撃者のような他の人がいます。

Tabキーのみを使用して上記のデモをナビゲートして、前進し、タブシフトして後方に移動してみてください。無効化ボタンがどのようにスキップされているかに気付くでしょう。焦点は、チケット入力から「ダミー用語」リンクに直接送られます。

一瞬一時停止して、最初にボタンを無効にすることと、実際に達成したことに対してボタンを無効にする理由を要約しましょう。

「相互作用」を「クリック」と関連付けることは一般的ですが、それらは2つの異なる概念です。はい、 C Lickは相互作用の一種ですが、ホバーやフォーカスのような1つだけです。

言い換えると…

すべてのクリックは相互作用ですが、すべてのインタラクションがクリックではありません。

私たちの目標はクリックを防ぐことですが、無効化することにより、クリックだけでなく焦点も防止しています。確かに、この動作は無害に見えるかもしれませんが、混乱を引き起こします。認知障害のある人は、ボタンに焦点を合わない理由を理解するのに苦労するかもしれません。

次のデモでは、レイアウトを少し調整しました。マウスを使用し、送信ボタンの上にホバリングすると、ボタンが無効になっている理由を説明するツールチップが表示されます。それは素晴らしいことです！

ただし、キーボードのみを使用する場合、ボタンを無効にすることができないため、そのツールチップを見る方法はありません。同じことがタッチデバイスでも起こります。痛い！

コードの説明をもう一度スキップさせてください。 Haydon Pickeringによる「Inclusive Tooltips」と、Sarah Higleyの「WCAG 2.1の時代のツールチップ」を読んで、ツールチップパターンを完全に理解することを強くお勧めします。

救助へのアリア

無効属性は、ARIA-Disabled = "true"と相関します。キーボードのみを使用して、次のデモを試してみてください。マークされた無効ではあるが、ボタンがフォーカスによってアクセスできる方法に注意して、ツールチップをトリガーしていることに注意してください！

かっこいいね？大きな改善のためにこのような小さな微調整！

しかし、私たちはまだ完了していません。ここでの警告は、JavaScriptを使用して、プログラムでクリックを防ぐ必要があることです。

 elform.addeventlistener（ 'submit'、function（event）{
  event.preventdefault（）; / *ネイティブフォームの送信を防ぐ */

  const isdisabled = elbuttonsubmit.getAttribute（ 'aria-disabled'）=== 'true';

  if（isdisabled || submitting）{
    //チケットが追加されないように早めに戻ります
    戻る;
  }

  Issubmitting = true;
  // ...カートに追加するコード...
  Issubmitting = false;
}）

ログイン後にコピー

ダブルクリックがフォームを2回送信するのを防ぐ方法として、このパターンに精通しているかもしれません。その理由で無効属性を使用していた場合、フォームが提出されている間にキーボードフォーカスが一時的に損失するため、私はそれを行わないことを望みます。

障害者とARIA障害の違い

あなたは尋ねるかもしれません：ARIA-Disabledがデフォルトでクリックを妨げない場合、それを使用するポイントは何ですか？それに答えるには、両方の属性間の違いを理解する必要があります。

2つの間の唯一のオーバーラップはセマンティクスです。どちらの属性も、ボタンが実際に無効になっていることを発表し、それは良いことです。

障害者属性とは反対に、Aria-Disabledはすべてセマンティクスに関するものです。 ARIA属性は、デフォルトでアプリケーションの動作やスタイルを変更することはありません。彼らの唯一の目的は、支援技術（スクリーンリーダーなど）がより意味のある堅牢な方法でページコンテンツを発表するのを支援することです。

これまでのところ、私たちは2種類の人々、クリックする人とタブをする人について話しました。次に、別のタイプについて話しましょう。スクリーンリーダーを使用してWebをナビゲートする視覚障害（失明、低視力など）について話しましょう。

スクリーンリーダーを使用する人は、多くの場合、 TABキーを使用してフォームフィールドをナビゲートすることを好みます。次に、MacOSのボイスオーバーが無効なボタンを完全にスキップする方法を見てください。

繰り返しますが、これは非常に最小限の形です。長い間、すぐにそこにない送信ボタンを探すことは迷惑になる可能性があります。送信ボタンが隠されており、フォームに完全に記入したときにのみ表示されるフォームを想像してください。それは、障害者属性が使用されるときに一部の人々がどのように感じるかです。

幸いなことに、無効化されたボタンは、スクリーンリーダーが完全に到達できないわけではありません。各要素を個別に1つずつナビゲートすることができ、最終的にはボタンが見つかります。

可能ですが、これは迷惑な経験です。一方、ARIAが障害を抱えていると、スクリーンリーダーは正常にボタンに焦点を合わせ、そのステータスを適切に発表します。アナウンスは、スクリーンリーダー間でわずかに異なることに注意してください。たとえば、NVDAとJWASは「ボタン、利用できない」と言いますが、ボイスオーバーには「ボタン、薄暗い」と書かれています。

両方の属性が、使用したツールに基づいて、さまざまなユーザーエクスペリエンスをどのように作成するかをマッピングしました。

したがって、両方の属性の主な違いは次のとおりです。

Tabキーを使用すると、ボタンをスキップして混乱につながる可能性があります。
Aria-Disabledは引き続きボタンに焦点を合わせ、存在することを発表しますが、まだ有効になっていないことを発表します。同じ方法で、視覚的に知覚するかもしれません。

これは、アクセシビリティと使いやすさの微妙な違いを認めることが重要な場合です。アクセシビリティは、誰かが何かを使用できることの尺度です。使いやすさは、何かを使いやすい尺度です。

それを考えると、無効にアクセスできますか？はい。それは良い使いやすさを持っていますか？私はそうは思わない。

もっと良くできますか？

私たちのチケットフォームの例の本当の包括的なソリューションをあなたに見せずにこの記事を終えたなら、私は自分自身に気分が悪いでしょう。可能な限り、無効なボタンを使用しないでください。いつでもクリックして、必要に応じてフィードバックとしてエラーメッセージを表示します。このアプローチは、他の問題も解決します。

認知摩擦の少ない：いつでも人々がフォームを提出できるようにします。これにより、そもそもボタンが無効になっているかどうかの不確実性が削除されます。
色のコントラスト：無効なボタンはWCAG 1.4.3の色のコントラストを満たす必要はありませんが、その状態に関係なく、要素が常に適切に表示されることを保証すべきだと思います。しかし、それはボタンがもう無効にされていないので、今心配する必要はありません。

最終的な考え

正直に言うと、障害者属性はアクセシビリティの問題とはまったく見られません。私に関係するのは、よりユーザビリティの問題です。障害者属性をAria Disabledと交換することで、誰かの経験をより楽しくすることができます。

これは、Webアクセシビリティでの私の旅へのもう1つのステップです。長年にわたり、私はアクセシビリティがWeb標準に準拠している以上のものであることを発見しました。ユーザーエクスペリエンスに対処することは難しく、ほとんどの状況では、ソリューションへのアプローチ方法にトレードオフや妥協を行う必要があります。完璧なアクセシビリティのための銀の弾丸はありません。

Webクリエイターとしての私たちの義務は、利用可能なさまざまなソリューションを探して理解することです。そうして初めて、可能な限り最良の選択をすることができます。問題のふりをすることには意味がありません。

一日の終わりには、あなたがウェブをより包括的な場所にすることを妨げるものは何もないことを忘れないでください。

ボーナス

まだそこに？私が価値があると思うこのデモについての最後の2つのことを言及させてください：

1.ライブ地域では、動的なコンテンツを発表します

デモでは、コンテンツの2つの部分が動的に変更されました。フォームの送信ボタンと成功確認（「[X]チケットを追加！」）。

ただし、これらの変更は、スクリーンリーダーを使用して視力障害のある人にとっては視覚的に認識されていますが、それは現実ではありません。それを解決するには、これらのメッセージをライブ地域に変える必要があります。これらにより、支援技術は変更を聞き、更新されたメッセージが発生したときに発表することができます。

デモには.SRのみのクラスがあり、ロードメッセージを含むを隠していますが、スクリーンリーダーによって発表されることができます。この場合、aria-live = "assertive"がに適用され、フォームが送信された後に意味のあるメッセージを保持し、ロードの過程にあります。このようにして、フォームが機能していることをユーザーに発表し、ロード中に忍耐強くなることができます。さらに、フォームフィードバック要素に対して同じことを行います。

 <button type="submit" aria-disabled="true">
  カートに追加
  <span aria-live="assertive">
     
  </span>
</button>

<p aria-live="assertive">
  
</p>

ログイン後にコピー

要素がまだメッセージを保持していなくても、ARIA-Live属性は最初からDOMに存在する必要があることに注意してください。そうしないと、支援技術は適切に機能しない場合があります。

この小さなaria-live属性とそれが行う大きなことについてあなたに話すことがたくさんあります。ゴッチャもあります。たとえば、誤って適用されている場合、属性は善よりも害を及ぼす可能性があります。 IRE AderinokunとAdrian Roselliの「ロードスケルトン」による「Aria-Liveの使用」を読んで、それがどのように機能し、どのように使用するかをよりよく理解する価値があります。