一覧の並び替えでは、矢印の向きより先に、何を基準に、どの範囲を並べるかを決めます。「期限が近い順」を選んでも、表示中の20件だけが並び替わるなら、利用者が期待する結果とずれることがあります。
この記事は一覧画面を設計・実装する人向けです。架空の社内依頼一覧を使い、並び順の仕様と確認方法を整理します。文言とデータは作例で、作業時間の短縮を実測したものではありません。
「昇順」を利用者の言葉へ置き換える
この一覧で利用者がしたいのは、次に着手する依頼を探すことです。初期表示は「期限が近い順」とし、必要に応じて新着順へ変えられる案にします。
| 選択肢 | 並べる値 | 同じ値だった場合 |
|---|---|---|
| 期限が近い順 | 期限の早いものから | 受付日時の古いものから、その後は依頼IDの昇順 |
| 新着順 | 受付日時の新しいものから | 依頼IDの降順 |
| 更新が新しい順 | 最終更新日時の新しいものから | 依頼IDの降順 |
「新着」が受付日時か公開日時かは、サービスによって異なります。この例では受付日時と定義し、更新しただけの古い依頼は新着の先頭へ移しません。順位の基準を変える場合は、ラベルも見直します。
期限のない依頼は末尾へ置き、「期限なし」と表示します。期限切れは早い日付として先頭側に含めます。これはこの記事の案です。「期限切れを別枠にする」「期限未設定を先に整理する」運用なら、別の初期順が適します。
ページではなく、対象全体を並べる
100件のうち20件ずつ表示する一覧なら、先に絞り込み、その全件を並べ、最後にページを切り出す順番を仕様にします。100件という数は説明用です。
手元にある20件だけをブラウザで並べ替えると、次ページにもっと早い期限が残る可能性があります。全データを取得していない実装では、並び順もサーバーへ渡す必要があるか開発者と確認します。同順位の決め方を固定するのは、同じ条件で読んだ際の順序を明確にするためです。ただし、新しい依頼が追加される状況までページ間の重複や抜けを防げるわけではありません。
この作例では、並び順を変えたら1ページ目へ戻し、検索語と絞り込みは維持します。詳細画面から戻る場合は、元の順序とページへ戻す案にします。ページ番号だけでなく、条件一式を戻す設計です。
列見出しで並べ替える場合
Carbonのデータテーブルは、列見出しから昇順・降順へ変更する操作を扱っています。Data table
列が多い画面でも、すべての列を並べ替え可能にする必要はありません。この例では「期限」「受付日時」「最終更新日時」を対象にし、自由記述の依頼内容には付けません。
W3Cの並び替え可能な表の作例では、操作できる見出しにボタンを置き、現在の並び替え対象の見出しへ aria-sort を設定しています。アイコンだけを付ける実装では、操作可能な列や現在の順序が伝わるかを確認します。Sortable Table Example
この作例は実装の参考であり、導入しただけで自分の画面のアクセシビリティが保証されるものではありません。キーボード操作、フォーカスの見え方、読み上げを実際の一覧で確認します。
日付の文字列をそのまま比較しない
「9月2日」「10月1日」の表示文字列や、「1,000」のような区切り付き数値を、そのまま並べる案は避けます。この例では元の日付・数値を比較し、表示形式は別に扱います。日時の基準となるタイムゾーンも揃えます。
数値の空欄を0として扱うか、未設定として末尾へ置くかも仕様です。利用者が入力していない値を、実在する0と同じ意味にしないようにします。
確認用の小さなデータを作る
期限が同じ依頼、期限なし、期限切れ、表示ページの外に最も早い期限がある依頼を用意します。順序を変えても件数が変わらないか、同順位の規則が働くか、詳細から戻って元の場所を確認できるかを試します。これらを仕様の例に残せば、見た目だけでは分からないずれを議論できます。
条件の保持は検索の絞り込みと解除、一覧の形式そのものは表とカードの選び方も参考になります。