WCAGなどのアクセシビリティ標準の主要な要件の1つは、WebサイトまたはアプリケーションがJavaScriptを使用せずに表示されるか、JS以外の代替手段を提供することです。私はいくつかの初期調査を行いましたが、WebSocketに関してこれに関する多くの情報を見つけることができませんでした。WebSocketはAJAXと同様に扱われると想定する必要がありますか？
質問する
148 次
2 に答える
4
Websocketは有用なことを行うためにJavaScriptを必要とするため、JavaScript以外の代替手段を提供する必要がある標準がある場合は、Websocketを使用しないJavaScript以外の代替手段を提供する必要があります。はい、WebsocketはAJAXと同じです。これらは、AJAXが提供する1回限りの要求/応答ではなく、永続的な双方向接続を作成するための単なる方法です。AJAXと同じように扱う必要があります。
WCAG 1.0ではJavaScriptに代わるものを提供する必要がありますが、WCAG2.0はテクノロジーに中立です。JavaScriptに代わるものを必要とする代わりに、クライアント側のスクリプトを含むWebページをよりアクセスしやすくするための一連の手法を提供します。すべてのユーザーがJavaScriptを有効にしているわけではないことに注意してください。完全に無効にするか、デフォルトで参照することを好むユーザーがまだいます。しかし、今日のアクセシビリティテクノロジーは、JavaScriptの特定の使用法に対応できるため、JavaScript以外のフォールバックがない場合でも、アクセシブルなサイトを作成できます。
于 2012-11-12T17:53:46.950 に答える
1
ブライアンの答えは良いですが、私はいくつかの洞察を追加すると思いました。
ここには、テクノロジーとコンプライアンスという2つの問題があります。
コンプライアンスに関する限り、何らかの理由でWCAG 1.0が必要な場合は、JS以外のバージョンが必要です。WCAG1.0がそう言っているからです。以前は、スクリーンリーダーに問題が発生したために一部のスクリーンリーダーユーザーがJSを無効にする場合がありましたが、それは数世代前のテクノロジーです。Web上のスクリーンリーダーユーザーの最近の調査では、Javascriptを有効にした状態で98.6％が示されました。
テクノロジーに関する限り、Javascriptとアクセシビリティの問題は、実際にはJavascript自体とは関係ありません。アクセシビリティの問題は、何か（通常はJavascript）がDOMを介してUIを操作しているという事実と関係があります。アクセシビリティで問題となっているのは、UIの操作です。結果のDOMにアクセスできるように注意し、スクリーンリーダーが変更を適切に処理するように注意する必要があります。たとえば、ARIAライブ領域を使用して、適切な場合にスクリーンリーダーが新しいコンテンツを読み上げるようにしたり、キーボードのフォーカスが消えないようにしたりします。予期しない場所に行き着きます。
定義上、UIをほとんど変更しないJavaScript自体には、アクセシビリティの問題はありません。したがって、Webソケット、Webワーカー、ローカルストレージなどには、アクセシビリティの問題はありません。重要なのは、後でDOMを更新するかどうかといつ更新するかです。
于 2012-11-15T12:13:43.477 に答える