A red or green dot is a compact way to mark a product feature. It is also an incomplete answer if the meaning depends entirely on distinguishing the colours. A comparison should remain understandable when colour is unavailable, when a screen reader reads it, and when someone navigates its controls with a keyboard.
Consider a table comparing caption or audio-description availability across editions of a television box set. The data is illustrative, but the design problem is common: how do we make every status and its context understandable?
Start with explicit status text
Write the meaning beside any coloured marker. “Confirmed,” “Not included” and “Not confirmed” communicate different states. A green dot cannot express those distinctions on its own, and a dash can mean almost anything without explanation.
Use colour as an additional cue rather than the only one. Icons can help scanning, but they also need understandable meaning. Avoid making a user decode an unexplained symbol or repeatedly return to a distant legend.
W3C's guidance on use of colour says that colour must not be the sole visual means of conveying information. Explicit labels are a practical way to support that principle in a comparison.
Distinguish missing information from a negative result
A feature that has not been verified is not the same as a feature confirmed to be absent. Keep those states separate in both the data and its presentation.
For example, “English SDH: Not confirmed” should not become “No English SDH” just because a spreadsheet cell was empty. The comparison table should preserve uncertainty rather than hiding it behind a red cross.
If a viewer depends on a feature, include a clear next step for an unknown result, such as checking the edition details or contacting support. Do not imply compatibility that the evidence does not establish.
Give each value its row and column context
A visible table layout helps sighted readers connect a feature to a product. Assistive technology also needs those relationships to be represented in the structure.
For a conventional data table, use actual table elements, an informative caption where helpful, and appropriate header cells. In a simple comparison, product names may be column headers and feature names row headers. W3C's tables tutorial explains how header associations help users interpret data cells.
A table that looks orderly because of CSS positioning is not necessarily understandable to a screen reader. Inspect the semantics rather than assuming the visual grid establishes the relationships.
Keep the first version structurally simple
A small number of clearly named columns is easier to compare than a grid with several layers of merged headings. If complex headers are necessary, their associations need deliberate treatment and testing.
Use meaningful product or edition names. “Option 1” and “Option 2” may be convenient internally, but they become ambiguous when someone reaches the table from another part of a page.
Do not replace a semantic table with an interactive grid solely to make it look modern. A static comparison and an editable spreadsheet have different interaction requirements. Choose the structure that matches the task.
Design narrow-screen behaviour without losing meaning
On a small screen, a table can overflow. Decide how people will reach its contents and how they will keep track of the current product and feature.
A scrollable table can work when the scrolling area is discoverable and usable. An alternative card layout can also work if every value retains an explicit feature label and edition name. Avoid dropping the labels simply because the design has switched from columns to cards.
Test zoom and narrower layouts with long product names and longer status text. “Not confirmed for all episodes” may reveal problems that a one-character tick will not.
Make controls work without a pointer
The comparison itself may be static, but sorting controls, product selectors and “remove from comparison” buttons are interactive. Use suitable native controls, provide clear names, and make the current focus visible.
Check the order in which focus moves through the page. A keyboard user should be able to change the comparison and continue reading without becoming trapped or losing their place unexpectedly.
If changing a control updates results, decide how users will learn what changed. Do not rely exclusively on a brief colour flash or a message visible only on hover.
Test meaning as well as appearance
Begin by asking whether each cell makes sense without its colour. Then check a screen reader's presentation of the row and column headers, and navigate every interactive control with a keyboard.
Try browser zoom, a narrow viewport and longer labels. Include confirmed, absent and unknown values in the sample data. Check that the full feature name and relevant edition remain available in every layout.
Automated checks can catch some problems, but they do not establish that a comparison is understandable or usable. Manual review of the actual decisions and interactions remains valuable.
Make the promise match the evidence
A clear table lets users compare facts without decoding colours or guessing what a blank cell means. It should also make the limits of those facts visible.
For an accessibility-related product feature, clarity is particularly consequential: a mistaken status can affect whether someone can use the product at all. Start with accurate states, preserve their context, and make every control reachable.
References: W3C, Tables Tutorial: https://www.w3.org/WAI/tutorials/tables/
W3C, Understanding Use of Color: https://www.w3.org/WAI/WCAG22/Understanding/use-of-color.html
Editorial disclosure: Generated with AI for the DVDWholesaleShop account. Examples and the accompanying comparison graphic are illustrative, not specifications for actual products. This article does not claim a deployed implementation or certify WCAG conformance.
Top comments (0)