3 に答える
ここでの正解は、ARIA、特にaria-checked属性を使用することです。アクセシビリティのために特別に設計されています。
そうは言っても、チェックボックスを削除したいというあなたの願望は間違っていると思います。チェックボックスのように機能するもの、つまり、チェックされた状態とチェックされていない状態があり、ページ上の何かを制御するものは、おそらく実際のチェックボックスである必要があります。これにより、スクリーンリーダーだけでなく、キーボードやマウスのユーザーが期待する動作も非常に優れたものになります。
いつでも。をラップすることができ<a>ます<label>。
問題は、目の見えるユーザーにとってチェックボックスのように見え、チェックボックスのように動作するかどうかです。これらが視覚的にチェックされている/チェックされていない状態を持っているように見え、クリックしてその状態を切り替えることができるアイテムである場合、それらはチェックボックスとして動作しているため、スクリーンリーダーのユーザーにそのように公開する必要があります.
ここで単純なアンカーを使用する際の問題は、スクリーンリーダーがそれらをリンク要素として読み上げるだけであるため、スクリーンリーダーのユーザーは、ページの状態を切り替えるものではなく、ナビゲーションが行われることを期待することです。また、チェックされた状態の情報は読み出されないため、スクリーンリーダーのユーザーは項目がチェックされているかどうかわかりません。
ここでの理想的な状況は、元のコードのように実際のチェックボックスを引き続き使用することです。(空Aのタグをドロップします。キーボード ユーザーはタブで移動できるため、これは問題ですが、画面が存在せず (目の見えるキーボード ユーザーの場合)、コンテンツ テキストがないため、スクリーン リーダーは「リンク」を読み上げるだけで、ユーザーは離れます。何に焦点を合わせているか混乱している。）
ここで実際のinput type=checkboxコントロールを使用する利点は、それらが機能することです。視力のあるマウス ユーザー、視力のあるキーボード ユーザー、およびスクリーン リーダーのユーザーはすべて、優れたエクスペリエンスを得ることができます。マウスとキーボードでアクセスできます。スクリーンリーダーはそれらをチェックボックスとしてアナウンスし、チェックされている/チェックされていない状態を伝えます。(実際の HTML 形式でなくてもかまいません。)
--
価値があるのは、使用しないやむを得ない理由がありinput type=checkbox、代わりにA、チェックボックスのように動作するようにクリックハンドラーと背景画像で変更された を使用する必要がある場合-そして、正当な理由があるとは思わないここにそのルートを行くために！- 次に、WAI-ARIA属性を使用して、追加のセマンティック ヒントでコントロールをマークアップし、スクリーン リーダーが正しい状態のチェックボックスとしてアナウンスするようにすることができます。これには、たとえば、role="checkbox"とを追加する必要があります。aria-checked="true"また、ユーザーはチェックボックスが入力だけでなくスペースバーにも応答することを期待しているため、そのためのキーボード処理も追加する必要があります。実際に機能することを確認するには、スクリーンリーダーでこれをテストする必要があります。何を複製するのは大変な作業ですinputすでにあなたのためにしています！ただし、このアプローチは、メニュー、スライダー、ツリービューなど、HTML で同等の便利な機能がまだ提供されていないカスタム コントロールを実装する場合には意味があります。これらのいくつかは最終的に、またはすでに HTML に組み込まれる予定です。)