You click “Price,” and the list changes. Are the cheapest items first, or did the click reverse an order that was already active? A sort control should answer that question without making the visitor compare several rows.
Name the order in ordinary language
For a product list, “Price: low to high” is clearer than an unexplained arrow. For dates, “Newest first” may be easier to understand than “Descending.” Choose wording that matches the values and the audience’s task.
Distinguish the current state from the action available next. If a column heading toggles direction, its visual indicator and accessible information should make the change understandable. The W3C sortable-table example demonstrates buttons in sortable headers and an aria-sort state on the sorted column. Use the pattern appropriately and test it with keyboard and assistive technology users.
Decide what happens to awkward values
Real lists include equal prices, missing dates and names with punctuation. Define a stable secondary order so identical values do not appear to shuffle unpredictably between visits. Decide where missing values belong and label them honestly rather than pretending they are zero.
For example, a service with no published price should not automatically be presented as the cheapest option. “Price on request” is information about availability, not a numeric amount.
Test the task, not only the click
Prepare a small test list containing low, high, equal and missing values. Check each direction, the state after filtering, and what happens when returning from an item page. Verify that the announced order matches the visible result.
On a phone, make sure the control remains reachable and its label does not lose the direction through truncation. If sorting triggers loading, communicate that state without leaving the user unsure whether the action worked.
A useful sort control lets someone predict the result before using it and recognise the result afterwards. The arrow is only one part of that explanation.