アクセシビリティの目的で、無効化された要素をフォーカス可能にする必要がありますか？
たとえば、3つのステップを含むセットアップウィザードがあり、ユーザーがステップ1を使用している場合、ユーザーは、コントロールが無効になっているかどうかに関係なく、コントロールに集中して次のステップに進むことができる必要があります。 ？コントロールの状態（有効または無効）は、ユーザーが現在のステップ（この場合はステップ1）で要件を完了したかどうかによって異なります。物事をより複雑で混乱させないために、無効化された要素はフォーカス可能であるべきだと思います。
私は、視覚障害のあるスクリーンリーダーユーザー向けの専門的なウェブアプリで作業しています。
私たちはユーザーテストを定期的に行っていますが、これはユーザーテストセッション中に何度も発生しており、ステップ/フローを完了するために必要な無効化された要素（または一般に重要すぎて見逃すことはできない）は、Tabキーでフォーカスできるはずです。
無効化されたボタンがTABでフォーカスできない場合、ユーザーはボタンが存在することを時々見逃してしまい、ボタンを見つけることができません。
これはブロッキングの問題です
さらに、@ Andrew Martinが言ったように、ボタンのツールチップに障害の理由を書いた場合（これは良い習慣ではないかもしれませんが、それでも起こる可能性があります）、JAWSのようなスクリーンリーダーでは決して読まれない可能性があります。説明/ツールチップは、TABフォーカスに関する説明のみを読み取るためです。
だから私は間違いなくあなたのユースケースではあなたはそれのために完全に行くかもしれないと言います。
これは少しトリッキーです。
通常、通常のフォーム要素では、やり取りできない、または役に立たないものはすべて完全に削除するのが最善です。
ただし、あなたが話しているその特定のボタン（「次のステップ」ボタン）は、完了レベルのガイドとして機能することもできます。つまり、フォームに十分なデータが含まれるまで、次のステップに進むことができません。
この場合、無効状態は、必要なデータをすべて入力していないことをユーザーに示します。
フォーカスの問題に関しては、一般的に、目に見えない無効な要素がフォーカスを取得できるようにすることはお勧めできません。フォーカスは相互作用の可能性を意味します。インタラクションを暗示することにより、ユーザーはボタンを無効にするのではなく、欠陥があると考える可能性があります。 可能性フォーカスを追加したい唯一の状況は、ボタンに無効化された理由を示すメッセージがボタンに含まれている場合です-しかし、それ自体は悪いデザインです。マナー。
[〜＃〜]修正[〜＃〜]
ここでエラーを指摘してくれたSteveDに感謝します。
（OPによって提示される場合のように）進行状況インジケーターとしても使用される無効化された要素へのフォーカスを防止すると、スクリーンリーダーソフトウェアによる読み取りも防止されます。ただし、これはHTMLで修正できます。
HTMLがdisabled属性を使用している限り、これはフィールドが無効であることをユーザーエージェントに通知しますが、フィールドがキーボードフォーカスを取得できる場合のみです。
詳細については、以下のコメントを参照してください。
スクリーンリーダーを使用すると、@ Lethsのわずかな対置として、無効化されているかどうかにかかわらず、aria-hidden=trueを使用してスクリーンリーダーから明示的に非表示にしない限り、ページ上のeveryオブジェクトにアクセスできます。これは@Lethsの投稿にコメントとして追加したくありませんでした。これは、メインの質問に関連する重要なポイントだからです。つまり、無効にされたオブジェクトにフォーカスを移動できるようにnotを決定した場合でも、スクリーンリーダーのユーザーはそれらのオブジェクトにアクセスできます。 JAWS（PCで最も人気のあるスクリーンリーダー）を使用すると、仮想PCカーソルまたはJAWSアクセサリダイアログ（Ctrl + Ins + Bなど）の1つを使用して、ボタンのリストを取得できます。 'ボタン名に追加されます）。
さて、そうは言っても、スクリーンリーダーのユーザーはページをタブ移動してそこにあるもののイメージをつかむことがよくあり、タブ移動はデフォルトで無効なボタンをスキップします。ユーザーがそのような傾向がある場合、仮想PCカーソルを使用してDOM全体をナビゲートしたり、すべてのボタン、チェックボックス、ラジオボタンなどのダイアログを表示したりすることができますが、それだけで、ページ。理想的には、スクリーンリーダーのユーザーは、無効にされたオブジェクトにタブで移動できる必要があります。目の見えるキーボードユーザーには理想的ではないかもしれませんが、それは彼らにとってもひどい害ではありません。
編集：ロジックは、要素がイベントに応答する場合にのみ、フォーカスできるということです。しかし、@ Lethsが彼の経験からコメントしているので、これは場合によっては有害になる可能性があります。したがって、ユーザーが期待することと、ユーザーにとって最も有益なことを実行するのが最善の方法だと思います。
いいえ、ユーザーが要素を操作できない場合は、（フォーカス）のヒントを与えないでください
：focus疑似クラスは、要素にフォーカスがあるときに適用されます（キーボードまたはマウスのイベント、またはその他の入力形式を受け入れます）。
出典： W
マウスの場合、カーソルの変化は、ユーザーが要素を操作できることを示します。たとえば、ポインタは、要素を操作できることをユーザーに通知します。
キーボードでは、focusプロパティは、ユーザーが要素を操作できることを示します。
あなたが持っている状態の要素はユーザーからの相互作用を許可していないので、利用可能な相互作用があるというヒントを与えません 。
ここに例があります フォーカスできない無効な入力のW3から。
これは私がウィザードに期待する振る舞いの例です。この場合、それはアンインストールダイアログです（私が試してみた最初のプログラムです）。これは私が覚えている限りずっとそうでした。閉じて詳細を表示するだけが利用可能なオプションで、2つのタブの切り替えが行われます。
質問に答えるために、私は慣れ親しんでいる慣習に従い、ウィンドウと同じように、操作できないボタンを完全に無効にします。ただし、他のユーザー（およびおそらく非Windowsユーザー）はこれに同意しない場合があります。
はい。無効なボタンはフォーカス可能でなければなりません。アクセシビリティのためだけでなく、それが無効になっている理由をアラートで説明するためにも。
私の経験則は、コマンドの関連性です。一部のボタンは、フェーズまたはコンテキストが外れていると非表示になります。クリックすると無効になる理由をいくつか示して説明します。
たとえば、プロセスの詳細の表示はマネージャーのみが有効です。従業員はコマンドが無効になっているのを見ます。アラートをクリックすると、機能とは何か、必要に応じてマネージャーに尋ねる必要があることを説明します。これにより、「プロセスの詳細を表示するオプションを用意しておくとよいでしょう」という提案を従業員が記入して「上司に尋ねる」という回答を回避できます。