JavaScriptを利用したサブウィンドウをサイトに追加しています。基本的に、UIの一部は、ユーザーがリンクをトリガーするまで画面の左端から離れた位置に配置されます。次に、表示された位置に移動します。私は一連の5つのテストケースを持っていますが、それらを個別にリンクするためのレピュテーションポイントをまだ取得していません。
アクセシビリティの目的で、ドキュメントフラグメントを含むリンクを使用したいので、次のようになります。
<a href="#quicklinks" id="quicklinks-trigger">Quick Links</a>
対応するJavaScriptを使用して（jQueryを使用）：
$("#quicklinks-trigger").click(function(e){
$("#shadow").removeClass("default");
$("#shadow").addClass("active");
});
#quicklinks HREFは、スクリーンリーダーの内部カーソル（別名カレット）を、新しく表示されたUIの先頭にリダイレクトします。[クイックリンク]サブウィンドウに対応するリンクがあり、カーソルをドキュメントの主要部分にリダイレクトします（<a href="#main" id="close-quicklinks"></a>）。これはテストケース1で実際に動作していることがわかります。スクリーンリーダーで聞くと（私はNVDAでテストしています）、スクリーンリーダーは、リンクがトリガーされたときにクイックリンクにスキップし、メインドキュメントに戻ります。クイックリンクの終了リンクがトリガーされたとき。
また、ドキュメントの断片に応じてページを上下にスクロールしますが、これは醜くて煩わしいものです。これは、次を使用して抑制することができます。window.preventDefault()テストケース2を参照してください。これは非常にスムーズに機能し、ドキュメントをスクロールしません。したがって、次のようになります。
$("#quicklinks-trigger").click(function(e){
$("#shadow").removeClass("default");
$("#shadow").addClass("active");
e.preventDefault（）; }）;
残念ながら、preventDefault（）を呼び出すと、ブラウザがカーソルを正しい場所に移動できなくなります。目の不自由なユーザーはそこでリンクをトリガーできます。その後、スクリーンリーダーは、クイックリンクUIではなく、ソースコード順に次のアイテムに進みます。これを修正する最も簡単な方法は、トリガーリンクの直後にクイックリンクサブウィンドウを定義するHTMLを配置することです。しかし、これが目的のCMSは、メニューに挿入されたHTMLの大きなブロックではうまく機能しないため、それはできません。
スクロールをなくすために、他のいくつかのアプローチを試しました。テストケース3は、ウィンドウを手動でスクロールバックします。
$("#quicklinks-trigger").click(function(e){
$("#shadow").removeClass("default");
$("#shadow").addClass("active");
window.setTimeout(function(){ scrollTo(0,0); }, 1);
});
...これは機能しますが、下にスクロールしてから上に戻るため、目に見えてぎくしゃくした効果があります。これは、テストケース1よりも優れています。
テストケース4では、内部カーソルを手動で移動することを期待して、preventDefault（）をfocus（）と組み合わせて使用してみました。
$("#quicklinks-trigger").click(function(e){
$("#shadow").removeClass("default");
$("#shadow").addClass("active");
$("#quicklinks").focus();
e.preventDefault();
});
しかし、＃quicklinksはDIVであり、フォーカス可能な要素ではないため、機能しませんでした。クイックリンクHTMLに非表示のフォーカス可能な要素を追加できると思いますが、それは厄介です。
テストケース5では、ターゲット要素からID属性を削除し、onhashchangeイベントを使用してフラグメント識別子を書き換えてから、IDを復元しようとしました。
function cfl_hash(fragment){
// Get the section the fragment refers to.
var target = $(fragment);
// Save its current ID.
var id = target.attr("id");
// Remove the ID so the browser won't scroll.
target.attr("id","");
// Rewrite the hash to the desired fragment, only if onhashchange event supported.
if("onhashchange" in window){ location.hash = fragment; }
// Put the ID back in place.
target.attr("id", id);
}
$("#quicklinks-trigger").click(function(e){
$("#shadow").removeClass("default");
$("#shadow").addClass("active");
cfl_hash("#quicklinks");
});
これは、スクロールを許可するがカーソルの移動を妨げるという不幸な効果がありました。IDスワップのイベントのシーケンスが間違っていると思います。これはスクロールを抑制するために機能するはずですが、カーソルが移動できるかどうかは疑わしいです。
スクリーンリーダーユーザーのカーソルリダイレクトもキャンセルせずに、目の見えるユーザーのスクロールをキャンセルできないのは本当に迷惑です。
これまでのところ、FirefoxとNVDAでのみテストしました。ブラウザとスクリーンリーダーの他の組み合わせでこれがどのように機能するかはわかりません。
提案？