アクセシビリティとこれらすべてのJavaScriptフレームワーク
私はしばらくの間、Backbone.jsやBatman.jsなどのJavaScriptフレームワークのいくつかを調査してきましたが、私はそれらが本当に好きなのですが、私は何度も何度も戻ってきます。その問題はアクセシビリティです。
私はWeb開発者として、特にプログレッシブ拡張のアイデアを使用して、アクセシビリティを念頭に置いて自分のWebサイトとアプリケーションを作成しようと常に努めてきました。
明らかに、これらの新しいJSフレームワークは正常に機能しません。そのため、この問題に対する他の開発者の考えや、それについて何をしているのかと思いました。結局のところ、ウェブサイト/アプリのアクセシビリティは、多くの国で法律の一部であるため、実際にはオプションではありません。
たぶん私はこの問題に熱心に取り組んでいるだけで、アクセシビリティの観点から物事がどれほど進んでいるかについては理解していません。
私は最新のサイトでjs-framework（私の場合はspine.js）を使用しています。それでも私は非JavaScriptブラウザー（確かに熱狂的ではない：SEOだと思う）が私のサイトをナビゲートし、コンテンツを消化できることを確認します。
例として、製品が表示されている検索ページを使用します。製品は、ページング、フィルタリング、ソートできます。もちろん、これは一般化されたアイデアの例です。
PREREQ：サーバー側とクライアント側の両方をレンダリングできるテンプレートエンジンを使用します。 （口ひげを使用）。これにより、jsなしでサーバー側のテンプレートを介してモデルをレンダリングしたり、jsを使用してクライアント側のテンプレートを介してモデルをレンダリングしたりできるようになります。
最初に、サーバー側のmoustache-templateを使用して製品をレンダリングします。また、JSON形式の同じ製品を含む「bootstrapJSON」オブジェクトも含めます。
最初は、すべてのリンク（製品詳細ページ、ページング、ソート、フィルタリング）は、実際のサーバー側のURL（ハッシュバングURLなし）です
最終結果は、JSを使用せずにページング、並べ替え、フィルタリングで100％ナビゲートできるページです。
すべてのページング、ソート、フィルタリングのURLはサーバーへのリクエストにつながり、その結果、一連の新しい製品がレンダリングされます。ここで特別なことはありません。
JS対応-domload時：
- bootstrapJSONをフェッチして、そこから製品モデルを作成します（これを行うには、jsフレームワーク機能を使用します）。
- その後、同じmoustache-templateを使用して製品を再レンダリングしますが、クライアント側で実行します。 （jsフレームワークを再度使用）。
- 視覚的には何も変化しないはずです（すべてのサーバー側とクライアント側のレンダリングが同じモデルで同じテンプレートで行われた後）、少なくともクライアント側のモデルとビューの間にはバインディングがあります。
- uRLをhashbang-urlsに変換します。 （例：/ products /＃sort-price-asc）、jsフレームワーク機能を使用してイベントをワイヤリングします。
これで、すべての（フィルタリング、ページング、ソート）のURLがクライアント側の状態変化となり、おそらくjs-frameworkがサーバーにajax-requestを実行して新しい製品（JSON形式）を返すことになります。これをクライアントで再度レンダリングすると、ビューが更新されます。
6.でajax-requestを処理するコードのロジック部分は、サーバー側で、4。で使用したコードと100％同一です。ajax-callと通常のリクエストを区別し、JSONまたはhtmlで製品を吐き出します。 （口ひげのサーバー側を使用して）それぞれ。
編集：2013年1月に更新この質問/回答は合理的な牽引力を得ているので、昨年の密接に関連したいくつかのahaの瞬間を共有したいと思いました：
JSONを吐き出して、選択したクライアント側のmvc（上記の手順6.および7.）を使用してクライアント側にレンダリングすると、CPUのコストがかなり高くなる可能性があります。もちろん、これは特にモバイルデバイスで顕著です。
上記の私の回答で提案されているようにクライアント側で同じことをする代わりに、（サーバー側のmoustache-templateレンダリングを使用して）ajaxでhtmlスニペットを返すためにいくつかのテストを行いました。クライアントデバイスによっては、最大で10倍高速になる可能性があります（1000ミリ秒-> 100ミリ秒）。もちろん、距離は異なる場合があります。 （ステップ7以降は両方とも実行できるため、実際にはコードを変更する必要はありません）
もちろん、JSONが返されない場合、クライアント側MVCがモデルを構築したり、イベントを管理したりする方法はありません。それでは、なぜクライアント側MVCを維持するのでしょうか。正直に言うと、非常に複雑な検索ページでさえ、後から考えると、クライアント側のMVCをあまり使用しません。私にとっての唯一の真の利点は、クライアントのロジックを明確に分離するのに役立つということですが、あなたはすでに自分自身でそれをしているはずです。したがって、クライアント側のMVCを取り除くことは、ToDoにあります。
そうそう、私は Hogan を使ってMoustacheを交換しました（同じ構文、もう少し機能が多いですが、何よりもパフォーマンスが非常に優れています！）バックエンドをJavaからNode.js（imhoをロックします）
私は視覚障害者のユーザーおよびWeb開発者なので、ここで呼びかけます。
私の経験では、これらのフレームワークは、アクセシビリティに関して適切な手順が取られていれば問題ではありませんでした。
多くのスクリーンリーダーはJavaScriptを理解しており、開発者はHTML5のaria-live属性などを使用してエクスペリエンスを改善し、スクリーンリーダーに状況の変化を警告したり、role属性を使用してスクリーンリーダーに追加のヒントを提供したりできます。
ただし、JavaScriptを使用したWeb開発の基本的な原則は、JavaScriptを使用せずに最初に基礎となるサイトを開発し、次に、その機能的でテスト済みの基盤を使用してより優れた機能を提供することです。 JSの使用は、製品の購入、サービスの提供、または情報の取得に必要ではありません。また、スクリーンリーダーの動作を妨げるJavaScriptを無効にしているユーザーもいます。
アクセシビリティを考慮せずに完全なBackbone.jsまたはKnockoutサイトをゼロから実行すると、「新しいTwitter」のようなものになり、多くのスクリーンリーダーでは非常に失敗します。しかし、Twitterには強固な基盤があるため、他の手段を使用してプラットフォームにアクセスできます。巧妙に作成されたAPIを備えた既存のサイトにバックボーンを移植することは非常に可能であり、非常に多くの楽しみも持っています。
したがって、基本的に、これらのフレームワーク自体はjQUery自体と同じようにアクセシビリティの問題ではありません。開発者は、誰にとっても機能するユーザーエクスペリエンスを作成する必要があります。
コンテンツを取得するためにJavaScriptがJavaScriptを必要とするWebページは、アクセシビリティ関連の課題に直面する可能性があります。 JavaScriptフレームワークのアクセシビリティは間違いなく競合の問題ですが、実際には、どのWebアプリケーションでも、使用するフレームワークに関係なく、コンテンツが動的に提供されると欠点が生じます。
サイトにアクセスできるようにするための特効薬はありません。また、すべてのJavaScriptフレームワークを説明することはできません。 JavaScriptを使用しているときにサイトに完全にアクセスできないようにする方法について、いくつか考えてみましょう。
Uki.js などのjavascriptや、 Jo 。静的（-ish）、セマンティックHTMLコンテンツを使いこなせるようになればなるほど、うまくいくでしょう。
ARIAロール （
role="application"およびaria-live動的なページの領域を示す属性。時間が経つにつれて、ますます多くのariaロールが支援デバイスによってサポートされるようになるため、これらのaria属性を使用することは、アプリに適切に追加できる場合に意味があります。JSライブラリの観点から、それらのソースを確認し、それらがariaロールを出力するかどうかを確認します。完全にアクセスできるわけではないかもしれませんが、支援機器を検討していることを示しています。
可能な限り、JavaScriptを必要ではなく拡張として扱います。動的なページ更新を必要としない重要な情報にアクセスするための代替方法またはワークフローを提供するようにしてください。
ユーザーとアプリをテストして検証します。支援機器を使用している人や、Webソフトウェアを使用して他の問題を抱えている人と、いくつかのユーザーテストセッションを行います。実際の人々がサイトを使用するのを見ることほど、サイトがアクセス可能であることを証明するのに役立つものはありません。
最後のポイントが最も重要ですが、多くの人はそれを回避しようとします。テクノロジーに関係なく、人々が使用するアプリケーションを開発しているという事実は変わりません。どのマシンも理論もアプリケーションが使用可能であることを完全に検証することはできませんが、とにかくそれをマシン用に構築するわけではありません。正しい？ :)
Chris Blouch（AOL）とHans Hillen（TPG）は、アクセシビリティのレビューで行った作業を含め、jQueryに関してこれについて良いプレゼンテーションを行いました。 JQueryを介してリッチインターネットアプリケーションにアクセスできるようにする それと、HTML5およびリッチインターネットアプリケーションのアクセシビリティに関するその他の関連プレゼンテーション（ http://www.paciellogroup.com/training/CSUN2012/ ）興味があるはずです。
私のお金は最もアクセスしやすいフレームワークを選択することにあります。jQueryは、アクセシビリティに全体的にかなり焦点を当てるだけでなく、かなりの優雅なデグラデーションまたはプログレッシブ拡張フォールバックを提供します。また、間接的に、jQuery（DrupalパブリックおよびイントラネットWebサイト）を利用するいくつかのシステムのテストとレビューを支援し、アクセシビリティに関する欠陥が発見され、修正のためにプロジェクトに戻されるようにしています。