☰

アクセシビリティとこれらすべてのJavaScriptフレームワークについて質問する

tag-icon • tag-icon javascript accessibility backbone.js javascript-framework sproutcore
アクセシビリティとこれらすべてのJavaScriptフレームワークについて質問する

私はしばらくの間、Backbone.js や Batman.js などの JavaScript フレームワークをいくつか調査してきましたが、それらは本当に気に入っているものの、何度も繰り返して問題になる 1 つの問題があります。それはアクセシビリティの問題です。

Web 開発者として、私は常にアクセシビリティを念頭に置き、特にプログレッシブ エンハンスメントの考え方を活用して Web サイトやアプリケーションを作成するように努めてきました。

明らかに、これらの新しい JS フレームワークは、そのままでは適切に機能低下しません。そこで、この問題について他の開発者がどう考えているのか、また、それに対してどのような対策を講じているのかを知りたいと思いました。結局のところ、Web サイトやアプリのアクセシビリティは、多くの国で法律の一部となっているため、実際にはオプションではありません。

おそらく私はこの問題について熱心になりすぎていて、アクセシビリティの面で物事がどれだけ進歩したかを認識していないだけなのかもしれません。

ベストアンサー1

最新のサイトでは、js フレームワーク (私の場合は spine.js) を使用しています。それでも、非 js ブラウザー (SEO を考慮して、あまり熱心ではありません) でもサイトをナビゲートしてコンテンツを理解できることを確認しています。

例として、製品が表示される検索ページを作成します。製品はページ分け、フィルタリング、並べ替えが可能です。もちろん、これは一般化されたアイデアの例です。

前提条件: サーバー側とクライアント側の両方でレンダリングできるテンプレート エンジンを使用します (私は Mustache を使用します)。これにより、サーバー側のテンプレートを使用して js なしでモデルをレンダリングし、クライアント側のテンプレートを使用して js を含むモデルをレンダリングできるようになります。

  1. 最初に、サーバー側の Mustache テンプレートを使用して製品をレンダリングします。また、同じ製品を JSON 形式で含む 'bootstrapJSON' オブジェクトも含めます。

  2. 当初: すべてのリンク (製品詳細ページ、ページング、並べ替え、フィルタリング) は実際のサーバー側 URL (ハッシュバン URL ではない) です。

  3. 最終結果は、JS を使用せずにページング、並べ替え、フィルタリングを使用して 100% ナビゲートできるページです。

  4. すべてのページング、並べ替え、フィルタリング URL はサーバーへのリクエストとなり、その結果、新しい製品セットがレンダリングされます。ここでは特別なことは何もありません。

  5. JS 対応 - domload の場合:

    • bootstrapJSON を取得し、そこから製品モデルを作成します (これを行うには、js フレームワークの機能を使用します)。
    • その後、同じ mustache テンプレートを使用して製品を再レンダリングしますが、今度はクライアント側で実行します (ここでも js フレームワークを使用します)。
    • 視覚的には何も変わらないはずです (結局、サーバー側とクライアント側のレンダリングは同じモデル、同じテンプレートで実行されたため)。ただし、少なくともクライアント側のモデルとビューの間にはバインディングが存在します。
    • URL をハッシュバン URL に変換します (例: /products/#sort-price-asc)。そして、js フレームワーク機能を使用してイベントを接続します。

  6. これで、すべての（フィルタリング、ページング、並べ替え）URL によってクライアント側の状態が変更され、おそらく js フレームワークがサーバーに ajax リクエストを実行して新しい製品（JSON 形式）を返すことになります。これをクライアントで再度レンダリングすると、更新されたビューが表示されます。

  7. 6. の ajax リクエストをサーバー側で処理するコードのロジック部分は、4. で使用されているコードと 100% 同一です。ajax 呼び出しと通常のリクエストを区別し、それぞれ JSON または html (Mustache サーバー側を使用) で製品を出力します。

編集: 2013 年 1 月更新この質問/回答がそれなりに注目を集めているので、昨年の関連性のある「なるほど！」と思った瞬間をいくつか共有しようと思います。

  • JSON を吐き出し、選択したクライアント側 MVC を使用してクライアント側でレンダリングすると (上記の手順 6 と 7)、CPU のコストがかなり高くなります。もちろん、これはモバイル デバイスで特に顕著です。

  • 上記の回答で提案されているように、クライアント側で同じことを行う代わりに、Ajax で HTML スニペットを返すテストをいくつか行いました (サーバー側の Mustache テンプレート レンダリングを使用)。クライアント デバイスによっては、最大 10 倍高速化できます (1000 ミリ秒 -> 100 ミリ秒)。もちろん、結果は異なる場合があります。(ステップ 7 ですでに両方を実行できるため、実質的にコードの変更は必要ありません)

  • もちろん、JSON が返されない場合、クライアント側 MVC がモデルを構築したり、イベントを管理したりする方法はありません。では、なぜクライアント側 MVC を保持するのでしょうか。正直に言うと、後から考えてみると、非常に複雑な検索ページであっても、クライアント側 MVC をあまり使用していません。私にとっての唯一の本当の利点は、クライアント上のロジックを明確に分離するのに役立つことですが、これはすでに自分で行っているはずです。したがって、クライアント側 MVC を削除することは、ToDo に含まれています。

  • ああそうだ、私は口ひげをホーガン(同じ構文、少しだけ機能が増えましたが、何よりもパフォーマンスが非常に優れています!) バックエンドを Java から Node.js に切り替えたため、これが可能になりました (個人的には素晴らしいと思います)

おすすめ記事