私はこれについて多くのことを調査しましたが、SO とすべての Web で相反する答えを得ているようです。第 508 条では、コンプライアンスがアクセシビリティと同等ではないことを理解しています。
最大の問題は、UI/UX デザイナーが、ドロップダウン メニューのキーボード ショートカットに 508 準拠のキーボード ショートカットが必要であると言われていることです。Windowsフォームアプリケーションにはこれがありますが、Web開発では「準拠」することが必須ではないと思います
回答された私の他の質問はここにあります: MVC 4 サイト 508 準拠
私はthiniceに部分的に同意しますが、残されたコメントの最初の2文には同意します。
私が言及している文は次のとおりです。
それらは508のキーボードで-到達可能-である必要があります。私はショートカットと到達可能の違いを強調し続けています
クリクススは言った：
最大のことは、UI / UXデザイナーが、ドロップダウンメニューのキーボードショートカットには508準拠のキーボードショートカットが必要であると言われていることです。
これを明確にする必要があります。ナビゲーションメニューのシンプルなものです<select>か、それともドロップダウンですか？Thiniceがコメントで述べたように、セクション508は、到達可能である必要があると述べています。質問は次のようになります。
アプリケーションにショートカットキーをどのように追加していますか？accesskeys属性を介してそれらを追加していますか、それともGmail / Yahoo Mailがショートカットキーを追加する方法ですか？
AccessKeysについて答えたと思いましたが、見つかりません。本質的にアクセスキーは素晴らしいことのように聞こえますが、ブラウザまたは支援技術のキーのいずれにも干渉しない、使用が許可されているキーを見ると、かなり制限されています。Gez Lemonは、AccessKeysとその問題の概要を説明しました。Yahoo！Mailのアプローチを実行したい場合は、もう少し作業を行う必要があります。Todd KlootsがARIAについてプレゼンテーションを行いましたが、これは役立つかもしれません。それは私を第二部に導きます。サイトでJavaScriptを多用して作業を行っている場合、ユーザーは1194.21（ソフトウェアアプリケーション/ OS）と1194.22（Web）の両方の標準を使用してサイトを評価します。サイトがJSを使用してnavmenuを作成する場合（YUIメニューの例）、ドロップダウン動作はキーボードで到達可能である必要があります。私はこれが当てはまると思います：
§1194.21ソフトウェアアプリケーションとオペレーティングシステム。
（a）ソフトウェアがキーボードを備えたシステムで実行されるように設計されている場合、製品機能は、機能自体または機能の実行結果をテキストで識別できるキーボードから実行可能でなければなりません。
と
（c）入力フォーカスが変化すると、インタラクティブなインターフェース要素間を移動する、現在のフォーカスの明確に定義された画面上の表示が提供されるものとします。支援技術が焦点と焦点の変化を追跡できるように、焦点はプログラムで公開されなければならない。
（a）キーボードを介してナビゲーション領域に入ることができなければならないと言っているので、両方の標準が使用されていると言います。（c）一部のメニューはtabすべての親アイテムに使用できますが、マウスがないとドロップダウン部分に入ることができないため、機能します。tabサブメニュー項目に移動できるメニューを見たことがありますが、メニューが表示されません。したがって、JAWSを使用するのではなく、キーボード（モビリティの障害）を使用するだけでは、自分がどこにいるかわかりません。
Windowsフォームアプリケーションにこれがあるのはわかりますが、Web開発では、「準拠」する必要はないと思います。
WordやOutlookなどの実際のアプリケーションは、頻繁に使用されるコマンドへのショートカットを提供していると思います。Webアプリケーションでこれを行う場合は、いくつ行うかを考えます。これは、準拠するための必須の部分ではありません。ナビゲーションバーのように作成している場合は、ベストプラクティスとして、特に親要素でARIAロールを使用することをお勧めします。role="navigation"
一部の基準 (および多くの法律) の問題は、それらが解釈の余地があることです...
キーボードの使用について言及している508規格で私が見つけることができる唯一の言及はこれです（逐語的に）：
サブパート B -- 技術基準
§ 1194.21 ソフトウェア アプリケーションおよびオペレーティング システム。
(a) ソフトウェアがキーボードを備えたシステムで実行するように設計されている場合、製品の機能は、機能自体または機能の実行結果をテキストで識別できるキーボードから実行できるものとします。
これに関する私の意見は次のとおりです。
スペクトルのもう 1 つの端は WCAG であり、これは 508 準拠とほとんど結びついており、私の本ではより明確に定義されています。
一言で言えば、重要な機能のカスタム キーボード ショートカットを用意することは、UX にとって良い習慣です。しかし、それ自体は 508 準拠には関係ありません。(例外として、その機能はキーボードでアクセスできる必要があります-何らかの方法で-)。
政府のプロジェクトについて話している場合、508のコンプライアンスのレベルがあります。一部の部門は開発者に508のスコアを割り当て、それは将来の契約のスコアに考慮されます。508コンプライアンスでは、すべてがキーボードで到達可能である必要があるだけです。これは、ある意味で通常は当てはまります。スクリーンリーダーは非表示になっていないものをすべて読み取り、タブキーはリンクを介してユーザーを誘導します。しかし、良いスコアが必要な場合は、法律の条文だけでなく、意図に対処する必要があります。
編集：スクリーンリーダーはいくつかの隠された要素を読み上げます。1つの方法は、アイテムを画面の真上に負の上部位置で絶対に配置することです。もう1つは、clipプロパティを使用することです。 http://adaptivethemes.com/using-css-clip-as-an-accessible-method-of-hiding-content/ ただし、display：none、heights of zero、javascriptトグルを使用している場合、多くのスクリーンリーダーはこれらの項目を話さないでください。
ドロップダウンの場合、スクリーンリーダーなどから要素を積極的に非表示にしているため、ほとんどのリーダーはdisplay：noneで物事を聞くことができないため、修正する必要があります。
キーボードナビゲーションに関する明確なドキュメントはありません。誰も正確に何をすべきかを指定しない理由は、ブラウザやOSなどとの潜在的な競合が非常に多いためです。Ariaは進歩していますが、標準もありません： http ://www.w3.org / TR / wai-aria-practices /＃keyboard
それがあなたの意図するものであるならば、私はメニューにaccessKeysを置きません。
代わりに、http ：//www.w3.org/TR/wai-aria-practices/#aria_ex_widgetを参照してください。
「検索」や「ホーム」などの主要なものの実際のaccessKeysを保存します。あなたがすべてのためのaccessKeyを持っていたならば、あなたのサイトに学習曲線を追加することは原因を助けません。たとえば、「AboutUs」accessKey= Aと入力し、文字に20個のaccessKeyを割り当てた場合、それは悪いことです。
私は長い間508のサイトを運営してきましたが、個人的にはドロップダウンを使用していません。サブページメニューを追加する方がはるかに簡単です。そして、私は個人的にドロップダウンをクリックするのが嫌いです。ドロップダウンにはクリックの精度が必要ですが、これは私を苛立たせ、アクセシビリティには役立ちません。アクセシビリティには、クリックがあまりうまくいかない人も含まれることを忘れないでください。さらに、ドロップダウンは、技術的にではなく、UXの観点から、持つことができるレベルの数に制限があります。
私が使用するもの：
特に問題は、情報の並べ替えにあります。リンクの長いリストをどれだけ速くスキャンするかを考えてから、そこに座って、リンクが読み取られるのを待つことを想像してください。おそらく、コンテンツを消化可能な部分に整理し、検索ボックスにスキャンを任せます。内容によって異なります。
ラック。:)