リッチテキストフィールドからタブ移動するのに意味のあるキーボード入力は何ですか？
私のWindowsアプリケーションには、システム全体のオプションを制御するフォームがあり、ツールバーと同等の機能とコントロールの領域があります。ツールバーには一連のアイコン/ラベルのペアがあります。 1つを選択すると、そのトピックに関連するオプションを設定するためのフィールドがコントロール領域に表示されます。
現在、TabとShift + Tabを使用してコントロールを切り替え、Ctrl + Tabを使用してコントロールとツールバー間でフォーカスを移動しています。ただし、一部のフィールドはリッチテキストをサポートしており、ユーザーがこれらのフィールドにタブ文字を入力できるようにしたいと考えています。
このシナリオを処理するための標準的なアプローチはありますか？そうでない場合は、これらのフィールドからタブで移動する方法を提供しないか、またはタブ文字を入力する方法を提供しない方がよいでしょう（ユーザーはおそらく複数のスペースで間に合わせることができます）？
これはシステム全体のオプション用であるため、フォームは特に頻繁にアクセスされることはなく、アプリケーションの管理者（通常はアプリケーションを使用する他のアクティビティに応じて、パワーユーザーである場合とそうでない場合がある）によってのみアクセスされます。リッチテキストフィールドは、定期的に発生する正式なコミュニケーションでユーザーの顧客に送信されるストックテキストを格納するためのものです。
TabとShift + Tabはアプリケーションの残りの部分で非常に完全にサポートされており、ほとんどのユーザーが気付かない可能性があっても、この領域での期待に反しないようにしたいと思います。
いくつかのアイデアが思い浮かびます。
リッチテキストボックスにタブがありません。
最も簡単な解決策は、リッチテキストボックスへのタブ文字の入力をサポートしないという提案です。タブキーが機能しないことに気付いた場合、ユーザーは4〜5個のスペースを自然に入力すると思います。 MS Wordが著作権記号になるようにMS Wordが「自動修正」する方法（c）のように並べ替えて、4〜5個の一連のスペースをタブ文字に変換することを検討することもできます。ユーザーがめったにタブ文字を入力する必要がなく、ユーザーが一連のスペースを入力する他の理由がない場合は、これで十分でしょう。
Ctrl-tab
標準に最も近いのは、テキストボックスの外にフォーカスを移動するために、Tabの代わりにCtrl-tabを使用することです。たとえば、Ctrl-TabはMDIの内部ウィンドウ間を移動するために使用されているため、多少類似しています。理論的根拠は「ctrl」が「大きくする」ことを意味するため、タブがカーソルを少しだけ移動/フォーカスする場合（リッチテキストボックス内）、ctrl-tabはカーソルを大きく移動/フォーカスする必要があります（テキストボックス外）。 。
問題は、ツールバーのコントロール間を移動するためにすでにCtrl-Tabを使用していることです。ただし、ツールバーは必要ないようですが タブコントロール –同じ領域内の異なるコントロールセットを表示するものです。ツールバーの代わりにタブコントロールを使用する場合（またはツールバーをタブコントロールのように機能させる場合）、ツール/タブのバンクは、（タブキーを使用して）タブを移動するもう1つのコントロールになります。フォーカスがタブコントロールに移動すると、ユーザーは矢印キーを使用してタブコントロール間を移動します。リッチテキストボックスを終了するために、Ctrl-tabを自由に使用できるようになりました。
（実際には、他のアプリとの整合性を高めるために、タブキーの問題の解決方法に関係なく、ツールバーではなくタブコントロールを使用することもできます。）
つまり、これは標準に最も近いものです。ただし、検出しにくいため、アプリをほとんど使用しないユーザーには適さない場合があります。タブキーが常にコントロール間を移動する場合は、内部整合性が向上します。確かにCtrl-Tab（なんでも）の使用をコミットする前に、一部のユーザーでテストして、プロンプトなしで自然に試すかどうかを確認してください。
編集ウィンドウ
ユーザーは、8.5x11ページに相当するようなリッチテキストをたくさん入力しますか？すべてのリッチテキストを一度に表示すると、他のコントロールセットに必要なスペースよりも多くのスペースが必要になりますか？その場合は、リッチテキストボックス自体がウィンドウ内にあるはずです。メインウィンドウで、テキストの最初の部分のみを読み取り専用のテキストボックスに表示します。編集用のボタンを使用すると、フルサイズのサイズ変更可能なウィンドウが開き、テキストを編集およびフォーマットするためのすべてのメニューとツールバーが表示されます。
通常は、その場で編集することをお勧めしますが、ユーザーは一度に多くのテキストを表示できるため、専用のウィンドウの方が適している可能性があります。 、コピー、および貼り付けを、ショートカットキーの専門知識に依存するのではなく、適切なメニュー項目として使用します。また、ユーザーのタスクをより適切にサポートするための多くの可能性を開きます。ユーザーはそのまま保存できます。たぶん、ユーザーはリッチテキストのローカルバージョンを保存して開くことができるので、さまざまな状況で適用する代替のライブラリを管理できます。顧客が見ているとおりにテキストを印刷して確認できます。
副次的な利点として、独立したリッチテキスト編集ウィンドウがタブの問題を解決します。ユーザーはリッチテキストからタブ移動しません。彼らはそれを閉じます。
タブではなくタブの代替
最後に、テキストボックスからタブ移動する代わりに、テキストボックスにタブ文字を挿入する代わりの方法を見つける必要があります。リッチテキストコントロール（太字、斜体など）の中には、タブボタンや、ユーザーにタブのようなインデントを設定するインデントボタンがあります。 Ctrl-Tのようなアクセラレータを指定できます。これで、タブキーにより、リッチテキストボックスからユーザーを取り出すことができます。これの主な利点は、ボタンが表示されることで、1番目と2番目のオプションにはない発見しやすさが提供されることです。
これについてオンラインでa11yの専門家と話し合いました。結論は次のとおりです。
アプリケーションに、その主な機能と考えられる編集可能な領域がある場合は、アプリケーションの他の部分に移動するショートカットを作成することで、これを回避できます。 CTRL + F8を追加して、ツールバーなどに移動します。
アプリケーションに複数の編集可能な領域がある場合、またはこの領域がアプリケーションの主要機能ではない場合（コメントセクションエディターなど）、Escapeを使用してtextareaのフォーカスを外すことにしました。フォーカスはこの領域の外のラッパーに移動し、フォーカスがラッパーから移動するまでtextareaはフォーカスを失います（その時点でラッパーは再びフォーカスを失います）。または、EscapeはTab-as-inputを無効にして、（ユーザーが他の文字を入力するかEscapeキーをもう一度押すまで）Tabを使用してフィールドをエスケープできるというメッセージを表示することもできます。