How do you indicate sort state accessibly in a data table?
Communicating sort state without relying on color alone.
Use shape-differentiated icons, annotate aria-sort on the active header, and maximize the button click target.
What's really being asked
This question tests whether you understand inclusive design for complex interactive components, specifically how to encode state visually and programmatically. Interviewers want to see that you treat accessibility as a design systems problem, not a post-development fix. You must show knowledge of WCAG perceivability and operability principles by addressing color independence, screen-reader semantics, and target sizing in a single coherent pattern.
The full answer
A strong answer walks through four decisions in order. First, visual indicators must differ by shape, not just color; for example, use a diamond or hollow icon for unsorted columns and upward or downward pointing triangles for ascending and descending. Second, the active sorted column must carry the aria-sort attribute with values ascending or descending so assistive technologies announce the state. Third, the header text should be wrapped in a button element to create a native interactive control with built-in keyboard support. Fourth, the button should fill the entire header cell via CSS to maximize the click target for users with motor impairments.
The mistakes people make
Red flags include proposing color-only indicators such as green for ascending and red for descending, which fails for color-blind users and offers no shape distinction. Another mistake is relying on CSS-generated icons without ARIA annotations, leaving screen-reader users unaware of which column is sorted or in what direction. Suggesting custom div-based controls instead of native buttons also signals a gap in understanding keyboard accessibility and semantic HTML.
What usually comes next
An interviewer might ask how you would handle sorting multiple columns simultaneously, where you would need to clarify whether aria-sort supports multiple headers or if an alternative pattern like a visually hidden description is required. They may also ask how you would annotate this in Figma; the correct approach is to document the aria-sort state on the component variant and include accessibility notes in the design spec rather than relying on redlines alone.
A concrete example
In the W3C APG sortable table example, the Favorite Number column is sorted ascending. The header contains a button that spans the full cell, the active th has aria-sort set to ascending, and the icon is a character entity triangle. Unsortable columns like Address omit the button entirely, while sortable but inactive columns display a diamond icon to signal capability without implying current state.
Interview question
When building a sortable data table, which combination of techniques best serves users with color blindness, screen readers, and motor impairments?
- a.Use color-coded arrow icons to show sort direction, implement each header as a clickable div with a custom keydown handler, and rely on CSS-generated icons without ARIA annotations.
- b.Wrap header text in a button filling the full cell, use shape-differentiated icons such as diamonds and triangles, and place aria-sort only on the currently sorted header.Correct
- c.Apply aria-sort to every sortable header, use triangle icons that differ only by color, and keep buttons sized to the text width.
- d.Rely on CSS-generated arrows that rotate to indicate direction, use span elements with tabindex="0", and add visually hidden text instead of aria-sort.
Why? this is the answer
Option B is correct because it addresses all three accessibility requirements: full-cell buttons for motor impairments, shape-differentiated icons for color independence, and aria-sort on only the active header for screen readers. Option C is a common distractor because it includes aria-sort and native buttons, yet misapplies the attribute to all headers and relies on color alone, failing both color-blind users and proper state semantics.
Just read this? Test yourself on what you have been reading.
Read the original → w3.org
- #accessibility
- #ui design
- #figma
- #aria
- #data tables
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on accessibility — each one lists the topics its interview covers.
See open roles