アクセシブルで応答性の高いテーブル？
Webアプリ内で大きな複数列のテーブルを作成することを検討しています。ただし、どのソリューションも100％に適合しないという課題を抱えており、十分に優れているため（すべての要件を満たしているわけではない）、ソリューションを1つだけ選択することに警戒しています。
質問：誰もがアクセス可能（セマンティック）かつ応答性のあるテーブルの例に遭遇しましたか？
これは実現可能性の課題をもたらし、レスポンシブテーブルはセマンティックではない傾向があります。そうは言っても、技術的な制限を認識しているので、UXベースの答えを誰かが持っているかどうか疑問に思っています。
私が過去に見てきたいくつかのオプションを示すためだけに：
- Mailchimpの固定列テーブル： http://ux.mailchimp.com/patterns/tables テーブル内のスクロールバーにより、これは大規模なデータセット設定では事実上使用できなくなります。
- CSSTricks： https://css-tricks.com/responsive-data-table-roundup/ したがって、CSSのこの非表示テキスト内のテーブルにより、アクセスできなくなります
注：私たちが到達しようとしているアクセシビリティレベルは、レベルAAです。
うーんこれを見てください： https://github.com/filamentgroup/tablesaw
幅が狭くなると、テーブルがリストに変換されます。行を比較する機能は失われますが、画面サイズが小さい場合でもデータにアクセスできることが保証されます。
大きなマルチカラムテーブルの問題は、より優れたコンテンツと情報アーキテクチャを作成しても解決されないことは興味深いです。なぜなら、テーブルの応答性やアクセス可能性に関係なく、情報がある場合でも、読者は情報を使用できないからです。単に情報が多すぎます。大量の情報を少量の画面領域にどのように収めるかという問題は、常に「それほど多くない」という答えを与えます。質問は「どれだけで十分か」ということです。そして「どれだけ十分に役立つのですか？」
ナイトニングによって提供される答えは、作業可能なスペースの量が異なる場合にさまざまなコンテンツ戦略を立てる必要がある場合の例であり、レスポンシブデザインでも可能性が低いことを覚えておくことも重要です。ユーザーが常に異なるビューポート間を切り替える必要がありますが、情報へのアクセスに使用するチャネルまたはデバイスを変更すると、一貫した論理的なフローまたはリンクが存在します。
UXの観点から見ると、ワイドスクリーンデスクトップアプリケーション用に特別に設計されていない限り、大きな複数列のテーブルはあまり使用できないか、アクセスできません。特に限られたスペースのモバイルデバイスで表示される可能性が高い場合は、Webアプリでこのような大量の情報を表示するケースを検討する必要があると思います。コンテンツ設計の観点から見ると、各テーブルの行と列の関係は線形または1対1ではないため、情報がテーブル構造に適さない場合、特に複数列のテーブルは課題となります。コンテンツを賢明または論理的な方法で段階的に開示または非表示にする場合、必ずしも階層を展開または折りたたむことはできません。
ただし、最小限の情報、またはユーザーにとって意味のある情報のアトミックブロックを作成し、その情報ブロックの複数のユニットに基づいてテーブル階層または構造を構築することで、少し頭痛の種を省くことができます。可能な限りユーザーが責任を持ってアクセスできるようにします。これは、多くのレスポンシブWebサイトがレイアウトとデザインの問題を解決しようとしている数であり、大きなテーブルを含むコンテンツ戦略のすべてのレベルに適用されます。
テーブルはすごい90年代です（30歳になろうとしています）
HTMLテーブルは1993年に提案され、1996年頃に離陸しました。この間、アクセシビリティを考慮したものはほとんどなく、レスポンシブデザインの予測はさらに低かったです。 UXはプロセスで考慮されていません。
このケースは一意ではありません。今日、滑稽に見える他の多くのHTML標準があります-selectsおよびradio groupsすべてにデザインとユーザビリティの欠陥があります。
本当の問題は、（存在の偏りのために）デザイナーが新しい問題に対する使い慣れた解決策を適用し続けることです。テーブルのキラー機能は自動調整機能で、これは実際にはプレゼンテーションビジネスです。それ以外は、代替ソリューションと比較してほとんど提供しません。
複雑なコンポーネント
元の意図とは異なり、今日のWebでテーブルに必要なさまざまな機能は、恐ろしいものにほかなりません。それらの中で：
- 列のサイズ変更
- 列の表示/非表示
- 仕分け
- 粘着性のあるヘッダー/列
- 階層ヘッダー
- インライン編集
- 行編集
- 単一行選択
- 複数選択
- プログレッシブロード
- 集計行
- 迅速なサポート
- アクセシビリティのサポート
ポイントは、HTML標準の一部ではないテーブルには非常に多くの要件があるため、独自のコンポーネントを作成したり、HTMLテーブルに基づいてコンポーネントを作成したりしないことです。
グリッドを入力してください
特にあなたが言及しているのとまったく同じ問題で、テーブルに多くの苦労をしてきたので、これは私がはるかにうまく機能することがわかりました：
- テーブルを使用する代わりに、単純な
<ol><li></li></ol>マークアップ。これでアクセス可能になります。 - CSSを使用してリストプレゼンテーションを削除します。
- グリッドを使用して、テーブルプレゼンテーションを作成します。これによりレスポンシブになります。
これは、ベアバージョンは次のようになります。
これは明らかに非常に限られた要件のセットの下で機能します。つまり、固定（および制約付き）列幅に満足している場合です。利点は、通常のテーブルではほとんど常に壊れる、ページ全体の秩序だった視覚的なフローが得られることです。
そのため、より複雑なテーブルの場合、JavaScriptを組み込む必要があり、本当に複雑なものの場合は、プレゼンテーション全体がJavaScriptベースでした（したがって、CSSグリッドはありません）。
段階的開示
特に大規模なデータセットの場合、覚えておく価値のあるテーブルに関するもう1つのことは、繰り返しになりますが、問題を考慮せずにソリューションを使用します。つまり、すべてをユーザーに投げます。
UXの観点から見ると、ダイジェストできる情報の量は限られています。多くの場合、情報量は限られています本当に必要。
そこで、私たちが解決した方法は、テーブルビューを使用して、ユーザーが関心のあるレコードを簡単に見つけられるようにすることですが、「関心のある場所を見つける」ことができる列のみを表示します。
追加のデータは、ツールヒントとして表示されるか、折りたたまれて表示されます。行をクリックすると、完全なレコードが表示されます（または、モバイルでは実際に詳細ビューに「移動」します）。
この慣行は、「表」の行（例：aria-label）を「概要」として、折りたたまれた領域を「完全な詳細」として、アクセシビリティを促進します。
テーブル（6列のみ）をモバイルユーザー用の320ピクセルバージョンに変換する必要があったとき、私はちょうど夜間と同じことをしました。私が最初に行ったのは、ユーザーが実際には必要としない情報が含まれる列をすべて削除することでした。それはちょうど与えられた、なぜなら…まあ、明らかに。したがって、残りの列は4つだけです。タブレットユーザー以上の場合は列が再び反転しますが、電話の場合はリストになり、問題なく動作します。
ああ、1つの違い：リストではヘッダーを指定していません。このリストの情報は明白なので、説明文は必要ありません。テーブルレイアウトにヘッダー行を含めました。
アクセシビリティに関して、あなたの質問は理解できません。要素の表示/非表示をプログラムで管理し、ARIA、ロール、およびhtml属性を使用して、希望どおりの操作を実行できます。とにかく：
-要素の非表示について、要素はposition：absolute;を使用して非表示にする必要があります。 ATでのみ利用できるようにするためです。それらをATにも非表示にする場合は、ARIA非表示を使用する必要があります。WCAGサイトで詳細を確認できます。
http://www.w3.org/TR/WCAG20-TECHS/H51.html
http://webaim.org/search/?q=tables
-内容について、テーブルにはデータの量（1）とその探索方法（2）の2つの問題があります。スクリーンリーダーを使用しようとすると、フィールド（1）が多すぎると、ユーザーがおそらくテーブルの2行目に迷惑になることがわかります。
彼はおそらくキーボード（2）を使用してセルをシフトし始め、おそらく何か面白いものがあるかどうかを知るためにランダムに停止します。キーボードを使用していてブラインドを使用しているユーザーのスクロールの問題は、プログラムで正しく管理されていれば問題ではないことを理解しています。
不要なデータはなくしたいし、キーボードの操作性を高めたい。アプリケーションとサイト全体のアクセシビリティのコンテキストでUXを理解するために、ユーザーテストも実施するでしょう。しかし、私はあなたの特定のケースを知りません。