web-dev-qa-db-ja.com

テーブルはナビゲーションに適していますか?

私のオフィスでは、すべての行がクリック可能であり、ナビゲーションに使用されるテーブルを持つことについて話し合っています。それは良い考えですか?

コンテキストは次のとおりです。「ユーザー」は「プロジェクト」に関与し、「プロジェクト」には複数の「キャンペーン」が含まれ、「キャンペーン」には複数の「ポイント」が含まれます。

さまざまなキャンペーンに関する情報を含むテーブルを含むタブ「キャンペーン」についてどう思いますか。各行をクリックすると、ポイントのテーブルに直接ジャンプできます。その場合、キャンペーンの名前をリンクとして配置するなど、クリック可能であることを明確にするために、いくつかのスタイルを追加できます。

ナビゲートするためにテーブルの行をクリックすることが直感的であるかどうかを具体的に説明します。テーブルとインターフェース全体の外観の画像を添付します。

how the page currently looks like

もう1つの提案は、「特定のキャンペーンに関連付けられているポイントを確認したい場合は、タブpointsをクリックします(「Campañas 「キャンペーンのスペイン語です」

1
BernardoSub

これはユーザーの期待に反します。ユーザーは、特定のアイテムが特定の場所につながるように(使用したWebサイトによって)トレーニングされています。

今、言われていること。ユーザーはこれがどのように機能するかをすぐに学びます。マウスオーバーやカーソルの変更によってフィードバックが返されるだけでなく、ボタンの1つをクリックしたときに、ランディングページがすべての選択肢をカバーしていることがわかります。

これが本当に付加価値のある命題である場合は、必ずそうしてください。しかし、これが単に「ちょっと、このようにしましょう」の場合は、反対することを強くお勧めします。

1
Mayo

ユースケースだけでなく、どのような構造にも適切な引数がある可能性があります。セマンティックマークアップの必要性により、メニューのテーブル(目次とは異なる)の実装の有効性がオーバーライドされると思います。

私は提案します:

  • CSSを利用する場合、ul要素とtable要素の違いは最小限です。どちらも子を持つコンテナ要素です。他ではできないことの1つでできることは多くないと思います(ほとんどの違いは、ブラウザによって適用されるUIのみです)。
  • 特定のDOM要素が特定のタグ名を使用することを期待するテクノロジーがあります。
  • ウェブ全体の均一性。
  • アクティブなトレイルクラス、キーボードナビゲーション、ロール属性などは、おそらくCMSまたは別のシステムによってすでに実装されています。これをテーブルに適用するには、かなりの作業が必要になるでしょうか?これらは貴重な属性です。
  • Tables 自体は、集計の表示に使用されます。表は通常、関連するデータを示しています。サイト メニュー は、異なるデータの関係に従います。

それは良い考えですか?メニューが何でできているかは、ほとんどのユーザーが気にしないと思います。ただし、メニューは常に「リンクのリスト」として記述されます。

支援技術の1つを使用して、上記のメニューでサイトをナビゲートしてみてください。また、SEOデータの分析にも重点を置きます。

https://usability.yale.edu/web-accessibility/articles/navigation

これがメインのサイトメニューではない場合、個人的にはそれほど心配する必要はありません。ユーザー向けのツールと見なすことができます。

これがメインメニューの場合は、セマンティックマークアップを使用します。 ulにスタイルを設定することで、目的のレイアウトを取得できますか?

1
Prestosaurus