Marking Missing, Unverified, and Inapplicable Specifications in a Product Comparison Table

When building a product comparison table, you may encounter cells where data is absent, not yet confirmed, or simply does not apply to the item. This guide outlines practical methods for representing these states clearly within standard HTML tables, ensuring that assistive technologies can interpret the context correctly without relying on visual cues alone.

Setting Up Your Comparison Table Structure

This is an illustrative scenario rather than an actual catalog. A desk-lamp comparison table has three product rows and specs such as shade diameter, dimmable range, color temperature, and bulb wattage. The author sketches columns first: Product, Shade diameter, Dimming range, Color temperature, Bulb wattage. Two columns become the problem: dimming range is only meaningful for the dimmable model, and bulb wattage may be unknown until a supplier reply arrives. A third column for color temperature is fixed for two lamps but open for the third.

Three column-title candidates show the relationship. Candidate A uses “Dimming range” and puts an en dash in the non-dimmable row. Candidate B titles it “Dimming (if applicable)” and leaves the cell empty. Candidate C splits the column into “Dimming type” and “Dimming range.” Candidate A treats inapplicability like missing data; Candidate B signals it in the header but leaves the reader guessing at the cell; Candidate C separates the question of whether dimming exists from the numeric range, at the cost of another column and denser rows. Nothing here resolves which choice fits a reader who scans values rather than reads headers.

For missing data, the author drafts “pending supplier” in the bulb-wattage cell for one row, then wonders whether that phrase is too wordy to repeat across several rows. A compact marker plus a legend entry could be cleaner, but the legend would have to define both the marker and the label without suggesting an expected value. The author also drafts a footnote reading “n/a: feature not offered on this model” and checks whether it would apply to the dimming column only or to other columns later.

The unresolved tradeoff is that a shared dash cannot distinguish “no such feature” from “could not confirm,” while separate markers require the reader to look up meanings. The author leaves the column-title choice and the marker scheme open, and also notes that the color-temperature cell for the third lamp still needs a value or a pending label before the table can be called internally consistent.

Marking Missing Data with Empty Cells

MDN documents the table element and its data cells, in which a cell is a td element or a th element inside a row. Its worked examples present a non-dimmable-style case by placing the text n/a in the Canceled cell for members without a cancellation date; the other rows hold a time element with an actual date. The reference also notes that a missing cell is rendered as if an anonymous table-cell box occupied that place, and that user agents trim cells to fit the available rows and columns.¹

For accessibility, MDN advises that scope on th header cells is redundant in simple contexts because scope is inferred, though specifying it may improve assistive-technology behavior. In complicated tables it suggests breaking content into smaller related tables, or otherwise using id and headers to associate each cell with its headers.¹

You can take a table with an empty shade-diameter cell and decide what belongs there before typing anything. Start from your source list: if the spec is simply absent from the item, the cell can stay empty with a short note in a legend; if you have not confirmed it yet, consider a distinct marker such as a question mark rather than a blank.

For a demonstration, draft a three-row lamp table where one row has no dimming feature, one row lacks a confirmed bulb wattage, and one row has a confirmed shade size. Try filling the first non-dimming cell with “n/a,” the wattage cell with “to confirm,” and leaving the shade cell as “30 cm.” Then revise: you might shorten “to confirm” to a symbol and explain it once in a note below the table. This keeps the non-dimmable and unconfirmed cases visibly separate while reducing repeated wording across many rows.

You can also choose to leave a genuinely absent spec blank and reserve one marker only for unverified data. The choice depends on how many rows you have and whether readers need to tell the two cases apart at a glance. Record that choice beside your draft so later edits stay consistent.

Indicating Unverified Specifications

You can take one row of your own comparison table where a specification such as bulb wattage is not confirmed and decide what the cell should show. Consider drafting the cell as “unverified” plus the reason in short form, such as “unverified — supplier spec not received,” rather than leaving a blank that a reader might read as absence. This makes the cell tell the reader both what is unknown and why, which a bare dash cannot do.

For an illustrative pass, suppose a three-row lamp table has a row with no dimming feature, a row with an unconfirmed bulb wattage, and a row with a confirmed shade diameter. You might write “not applicable — non-dimmable model” in the dimming cell, “unverified — spec not received” in the wattage cell, and the confirmed measurement in the third. Then read the column aloud as a reader would: the two markers should not look interchangeable, and the confirmed value should stand out as the only settled one. If the wording feels heavy, consider a shorter “unverified” with a footnote keyed to the row; the choice depends on how many cells carry the marker.

You can also weigh whether an empty cell is acceptable when the spec genuinely does not exist for an item. Leaving it blank can work if your table has a key or a short note explaining that blanks mean not applicable, but that meaning depends on the reader noticing the key. If your table has only a few rows, a written marker in the cell may be clearer; with many rows, a single consistent phrase repeated across the column may be easier to scan.

Before settling the wording, note your own candidate phrases and why each one fits or fails. A phrase that names the reason, such as “not received” versus “not published,” helps a reader judge whether the gap is temporary. Mark these cells as your working choices, not as verified facts, and revisit them when a source arrives.

Handling Inapplicable Attributes

For an inapplicable attribute, you can treat the cell as a small writing decision rather than a gap to fill with anything. Suppose one row of a lamp table has no dimming feature at all. Two candidate cells might be “Dimming: none” and “Dimming: not supported.” Reading them side by side in the table, the first is shorter but could be mistaken for a missing entry, while the second is longer but states the relationship clearly. You might prefer the second for a single inapplicable row and the first where several rows share the same absence.

You can also decide whether the column title carries part of the meaning. If the column is titled “Dimming range,” a cell reading “Not applicable” repeats the idea awkwardly; if the title is just “Dimming,” a cell reading “None” reads naturally. Draft both title-and-cell pairs, then read the full column aloud. Choose the pair where a reader scanning only that column still understands that the feature is absent by design, not merely unreported.

A useful check is to write one sentence outside the table describing what the cell is meant to convey, then shorten it into the cell. For example, “this model has no dimming control” might become “No dimming control,” which is clearer than a lone dash. If the sentence you write describes missing evidence instead, that cell belongs with your unverified wording rather than your inapplicable wording. You can keep a short personal note recording which phrasing you chose for inapplicable rows and why, so later rows stay consistent.

Using Scope Attributes for Clarity

For tables with a simple row header and a simple column header, W3C guidance calls for the table header element to identify header cells and the scope attribute to declare each header's direction. Setting scope to row means the header applies to the entire row; setting scope to col means it applies to the entire column.²

In the guidance's example, a delivery-slots table places header cells in the top row and first column. Header cells in the top row use the col value, associating each with the data cells in its column, and header cells in the first column use the row value, associating each with its row. The source notes that without this information some users would not easily understand the relationship between header and data cells.²

You can turn scope into clear wording by naming the condition in the cell itself, not leaving the reader to guess from a dash. Consider a lamp table where one row has no dimming feature: instead of a bare dash, draft “Not applicable — no dimmer fitted” and keep it short. For a spec you simply have not confirmed, use a separate phrase such as “Not verified” so the two reasons stay distinct.

You might also let the column title carry part of the meaning. If the header already says “Dimming range,” the cell can read “No dimmer” rather than repeating “Not applicable”; a wording like “Unconfirmed” then marks only the genuinely open item. Read both versions aloud and choose the one that needs fewer words before the reader understands why the cell is not filled.

Before settling, you can write one sentence outside the table stating what the cell should convey, then shorten it into the cell. For example, “This model has no dimming control” can become “No dimmer,” while “We have not received the wattage” can become “Not verified.” Recording those two markers in the table’s own key keeps your choices consistent across rows.

Adding Captions and Summaries for Context

A caption identifies the overall topic of a table and is useful in most situations. A summary, by contrast, provides orientation or navigation hints in complex tables. Both are discussed alongside the structural markup that indicates header and data cells and defines their relationship, so assistive technologies can supply context to users.³

The same page notes that header cells must be marked up as th elements and data cells as td elements, and that more complex tables may need explicit associations through the scope, id, and headers attributes. It gives row-or-column headers, two-header tables, irregular headers, and multi-level headers as the cases it covers, and states that the tutorial does not apply to tables used for layout.³

You can take a marked-up draft table and add a short caption beneath it that explains what your markers mean before comparing rows. Suppose one row carries “not confirmed” for bulb wattage and another carries “not applicable” for dimming range; draft a caption such as “Dashes mean the feature does not exist; ‘pending’ means the value was not confirmed at the time of writing.” Compare it with a version that places the same explanation in a notes column, then keep whichever reduces repeated wording across rows.

You might also append a two-sentence summary after the table stating how complete the comparison is, for example how many cells remain unverified and which specifications were checked against a dated source. This is a writing choice, so consider whether your readers scan the summary before the rows or only reach it afterward.

For context, test one caption against a blank-cell version of the same table and note which one leaves fewer questions about whether a gap means absence or uncertainty. Keep the caption only if it clarifies more than it repeats the markers already in the cells.

Frequently asked questions

How can I draft a three-row lamp table for a demonstration that shows no dimming, unconfirmed wattage, and a confirmed shade size?

For a demonstration, draft a three-row lamp table where one row has no dimming feature, one row lacks a confirmed bulb wattage, and one row has a confirmed shade size. Try filling the first non-dimming cell with “n/a,” the wattage cell with “to confirm,” and leaving the shade cell as “30 cm.”

How should I draft the cell in one row of my own comparison table when a specification like bulb wattage is not confirmed?

You can take one row of your own comparison table where a specification such as bulb wattage is not confirmed and decide what the cell should show. Consider drafting the cell as “unverified” plus the reason in short form, such as “unverified — supplier spec not received,” rather than leaving a blank that a reader might read as absence.

How can I add a short caption beneath my marked-up draft table to explain what my markers mean before comparing rows?

You can take a marked-up draft table and add a short caption beneath it that explains what your markers mean before comparing rows. Suppose one row carries “not confirmed” for bulb wattage and another carries “not applicable” for dimming range; draft a caption such as “Dashes mean the feature does not exist; ‘pending’ means the value was not confirmed at the time of writing.”