私は何かを取り除きたいと思っていました。それはWCAGに関するウェブサイトでのJavascriptの使用です。アクセシビリティとjavascriptを使用
JavaScriptの使用は、ユーザーがウェブサイトのコンテンツにアクセスしたり、ウェブサイト上でアクションを達成するのを妨げない限り、正しく使用されます。
たとえば、WebサイトにログインするためにJavascriptが必要な場合、これはWCAGを破ると思われますか？
また、必要なJavascriptを設定するためのオプションを購入するサイトがある場合、WCAGも破損しますか？ AJAXを使用して
は（ARIAを使用することができます）限り、ユーザーがページが更新されていることを警告されるようで結構です
私の仮定はJavascriptが体験を向上させるために使用されなければならないが、そのユーザーに頼ったことがないということですそれなしで目標を達成できますか？
これらの仮定は正しいですか？
WCAG 2は、JavaScriptを使用したり、JavaScriptを使用することを妨げません。
「アクセシビリティがサポートされています」というコンセプトを参照することはできませんが、すべてのメインストリームブラウザ&はJavaScriptをサポートしているため問題ありません。
Matt May（投稿者an excellent book on accessibility）は、「is JavaScript required」という質問に対する明確な回答を書いています。
JavaScriptを使用せずにサイト作業を行うことに焦点を当てて見逃しているのは、ほとんどのアクセスユーザーがJavaScriptを受け取るということでしょう。したがって、JavaScriptバージョンにアクセス可能にする必要があります。
キーボードフォーカス、ARIA、適切なHTML構造などのアスペクト（JavaScriptで作成されていても）。 an accessible Angular.js implementationに焦点を当てる必要があるものについて説明しましたが、ほとんどのJavaScript依存サイトに適用されます。
と言われていますが、プログレッシブエンハンスメントは、障害に関係なく、JavaScript（about 1.1% according to the UK Government site）を受け取っていない人がいるため、有用な方法です。私はそれが単なる例であることは知っていますが、単純なログインフォームにJavaScriptを必要とするのはかなり不自由なようです。
はい、あなたの前提は正しかったです.JSは利便性を高めますが、アクセシビリティは向上させるべきではありません。
古典的な例は、AJAXのオートコンプリート/提案があるフォームのフィールドです：JSなしでは、すべての値を手作業で完了する必要がありますが、まだ使用できます。クライアント側の検証が通常は歓迎されるが、サーバ側の検証は必須である、電子メールアドレスと同じ値をチェックする場合も同じ。 Q & Aをここで確認してください：Javascript and Accessibility
セクション508！= WGAC 2.0。 508は[現在更新中]（http://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh）であり、おそらくWCAG 2.0に似ているだろう。 JavaScriptのアクセシビリティに関するディクテーションは無効になっています。 – steveax
OK、ウェブサイトにログインするなどの私の例を見て、JSにログインするのは大丈夫でしょうか？ – Lee
アクセシビリティ上の問題ではありません（障害に関して）。しかし、ユーザーの約1％がログインすることができませんでした。それが大丈夫かどうかを判断する必要があります。 – AlastairC