Responsive Comparison Table: Keep Labels, Values & Updates

Executive Summary

A responsive comparison table is a relationship contract: every value must stay tied to one plan and one feature at every screen width. This report uses a clearly fictional three-plan, twelve-row fixture to compare a desktop table, a scrollable narrow-screen table and a stacked alternative. The fixture is instructional, not a benchmark, and no browser or screen-reader results are reported.

Information belongs in a true table when readers need two axes. Nielsen Norman Group (NN/g) describes the standard form as products in columns and attributes in rows ^[1], while Roselli advises a list when there is only one axis of information ^[2]. W3C says relying on visual cues alone is not sufficient for an accessible table ^[3], so visual grouping must be separated from the header relationships a developer builds. A schema with one record per feature row, a unit, a typed value per plan and a separate qualification field lets every layout read the same facts.

No mobile treatment is free. A scroll region keeps adjacency but hides part of the grid; NN/g notes that only 2 columns may fit legibly on a narrow screen with wordy cells ^[4]. Stacking keeps one plan whole but makes users remember numbers across views ^[4]. WCAG 2.2 Reflow excepts data tables but not individual cells ^[5], and content around the table must still reflow. A scroll region needs keyboard access ^[6], and Chrome's default focusability applies only when the scroller has no focusable children ^[7]. Hiding rows is a content decision, since Google expects mobile content to be equivalent to desktop ^[8].

The fixture arithmetic: 3 plans × 12 rows × 3 layouts = 108 displayed value placements from 36 stored values, with 70 distinct editable facts. Three editor changes touch 14 placements inside the component, plus pages outside it. Context is modest: Pew reports that 91% of U.S. adults own a smartphone ^[9], and Baymard found sparse mobile comparison use on two retail sites ^[10]. No study of three-plan pricing tables was found.

Before a quote, agree the schema, the treatment per width, each requirement's owner (Table 4) and the editor update log (Table 5). A settled single component suits a scoped project; recurring edits suit ongoing capacity.

Introduction and Background

A plan comparison looks like a layout problem until the first edit. Someone renames a plan, raises an allowance or adds a condition to one cell, and the question becomes which views still tell the same story. This report examines what deserves a true table, what each mobile treatment keeps or loses, and what a business, designer and developer should agree before a quote.

The scope is narrow. It does not rank visual styles, which galleries already cover ^[11], and it leaves pricing strategy, wording and analytics with the business owner. It is not a conformance opinion: WCAG conformance cannot be achieved if part of a web page is excluded ^[12].

The distinctive part is a worked fixture. The "Northlight Planner" product, its plans, prices and conditions are fictional and instructional, not market benchmarks. No browser or screen-reader results are reported; the acceptance table leaves its result column empty because results belong to the delivered build.

Evidence comes in two kinds. Standards and vendor documentation establish what is required or supported. User-experience research shows what readers tend to do, but most of it concerns retail and reference comparisons, not subscription pricing. No controlled study of three-plan pricing tables was found, so mobile patterns are framed as tradeoffs, and no conversion effect is claimed. Search demand was not measured. The audience is a software-as-a-service (SaaS) marketing lead, e-commerce operator or agency producer. The publisher, Tapflare, sells a design and website development subscription and is named in this Introduction and discussed in the commissioning section.

What Belongs in a True Table

The comparison task

A comparison table serves a reader who must relate a value to two things at once: which option and which attribute. NN/g notes that static tables suit membership levels and pricing packages ^[1]. Three questions test whether content is tabular:

• Two axes: does a value only make sense against both a plan and a feature?
• Shared rows: do all plans answer the same questions? Different attributes force empty cells.
• Comparable size: GOV.UK notes a desktop screen typically shows 4 or 5 columns and 10 rows without scrolling ^[13].

Table, list or cards

W3C states that accessible tables need markup indicating header cells and data cells ^[3]; GOV.UK warns against tables for cosmetic reasons when normal page structure will do ^[13]. Three marketing cards, each with a heading and bullets, are three lists, however neatly they line up. That is a legitimate design, but it provides no feature-by-plan relationship, and a brief should not call it a table.

Visual grouping is not the relationship

Viewers tend to group items near each other ^[14], and the ManyPixels Gestalt article says elements placed close together are deemed more related ^[15]. Proximity helps the eye but tells software nothing. W3C says relying on visual cues alone is not sufficient ^[3], because screen readers speak one cell at a time and reference the associated header cells ^[3]. The brief should state a visual grouping requirement for the designer and a programmatic relationship requirement for the developer, and test them separately.

The Content Schema Behind the Component

The most useful handoff is a schema, not a mockup: one record per feature row, one value per plan, units and conditions in their own fields. GOV.UK's content reuse team states its aim as a single source of content truth built on modelled content ^[16]. Sanity stores one-to-many relations as an array of references ^[17], and Webflow says that when a referenced item changes the new content updates automatically ^[18]. The rule for editors: a fact lives in one place and every layout reads it.

Table 1 below lists the fields to define. Wording and pricing stay with the business owner; the designer and developer need the structure.

Schema rules follow from the sources:

• Real numbers: write limits as numbers, since a tick can imply unlimited ^[11].
• One format: keep one number format across a sequence ^[19] and do calculations for the reader ^[13].
• Units: record a house rule; NIST says a space is left between the numerical value and the unit symbol ^[20].
• Consistency: keep surrounding text and table in agreement (Source: www.stylemanual.gov.au).

Qualifications get their own field because they travel. The U.S. Federal Trade Commission (FTC) says a disclosure is more effective placed near the claim it qualifies ^[21], and that there is no set formula for a clear and conspicuous disclosure ^[21]. This is general advertising guidance, not legal advice; a business with a doubtful condition should consult a qualified adviser. If the same facts feed structured data, Google requires it to match the values shown to the user ^[22].

{
  "row_id": "R04", "group": "Capacity",
  "label_display": "Additional seat",
  "label_full": "Additional seat price per user",
  "unit": "USD per user per month",
  "values": {
    "P1": {"type": "not_available", "display": "Not available"},
    "P2": {"type": "number", "number": 6, "display": "6"},
    "P3": {"type": "number", "number": 5, "display": "5", "qualification": "Q2"}
  },
  "qualifications": {"Q2": "Price applies on annual billing."},
  "source_owner": "Pricing owner", "status": "published"
}

The block can be saved as a file such as comparison-row.json and repeated for all twelve rows. It separates the fact (the 5), what explains it (the unit) and what limits it (Q2); every layout below renders the same records.

The Fictional Fixture on Desktop (Hypothetical Example)

The fixture has three plans and twelve rows, with the awkward cases real content produces: a feature name repeated in two groups (Storage), a long label (R11), units in their own field, "Unlimited" values, absent features and seven qualified values. Table 2 below shows the content as a desktop table; the header prices ($12, $39 and $119 per month) are invented.

The fictional qualifications are: Q1 fair-use cap of 500 active projects; Q2 price applies on annual billing; Q3 soft limit, usage above the allowance reviewed before any charge; Q4 annual contracts only; Q5 backups kept 30 days; Q6 business days only, priority queue; Q7 remedy is service credits, exclusions in the terms.

The grid holds 3 × 12 = 36 value cells: 7 carry a qualification, 6 state absence ("Not available", "Not included", "None" or "No") and 2 say "Unlimited". Two rows share the label "Storage" but measure different things, so the group name is part of the label's meaning.

Annotating the desktop version

      (1) column headers: scope="col"
                  v           v          v
+-----------------+------------+----------+------------------+
|                 | Starter    | Team     | Scale            |
+=================+============+==========+==================+
| CAPACITY  (2) group header: scope="rowgroup"               |
+-----------------+------------+----------+------------------+
| Projects        | 3          | 25       | Unlimited (Q1)   |
| ^ (3) row header: scope="row"   (5) marker: (Q1)           |
| (4) a value is read with its row AND column header         |
+-----------------+------------+----------+------------------+
| DATA PROTECTION                                            |
+-----------------+------------+----------+------------------+
| Storage         | Not incl.  | 50 (Q5)  | 500              |
| ^ (6) same label as in Capacity; only the group            |
|     header tells the two Storage rows apart                |
+-----------------+------------+----------+------------------+

• (1) Column headers relate each value to a plan. MDN says the column value means the header relates to all cells of the column it belongs to ^[23].
• (2) Group headers are where visual grouping and semantics can diverge. The WHATWG row group state applies the header to all remaining cells in the row group ^[24]. Merged group cells sit awkwardly with GOV.UK guidance for no split or merged cells ^[13], so the choice is recorded, not assumed.
• (3) Row headers relate each value to a feature.
• (4) The pair is what a reader needs: the relationship of each cell to its row and column header must be programmatically determined or available in text ^[25].
• (5) Qualifier markers are visual symbols; the text must also be reachable, and color must not be the only means of conveying information ^[26].
• (6) Repeated labels test whether group context survives. The schema carries group for this reason.

A specification sketch of the markup (not a tested implementation):

<table>
  <caption id="plans-caption">Northlight Planner plans (fictional)</caption>
  <thead><tr><td></td><th scope="col">Starter</th>
    <th scope="col">Team</th><th scope="col">Scale</th></tr></thead>
  <tbody>
    <tr><th scope="rowgroup" colspan="4">Capacity</th></tr>
    <tr><th scope="row">Projects</th><td>3</td><td>25</td>
      <td>Unlimited <a href="#q1">(Q1)</a></td></tr>
  </tbody>
</table>

MDN says a missing scope leaves browsers to select cells automatically ^[23], and stating it may help where assistive technologies infer incorrectly ^[23]. A caption must be the first child of its table ^[27]. W3C failure documentation is specific: data tables without header elements fail ^[28].

A highlighted "recommended" plan is a visual layer; badge words belong in the header cell's text. Row separation matters: Baymard observed users losing their place in rows without horizontal lines or alternate colors ^[29].

Narrow-Screen Treatments Compared

The same twelve rows must now fit a phone. Smashing Magazine states there is no universal, silver-bullet solution for responsive tables ^[30], and Dave Rupert's survey of options includes freezing the left header column with swipeable cells ^[31]. Below, three treatments of identical content are compared, plus a deliberately broken one.

Treatment A: a local scroll region with a pinned label column

The table keeps its structure inside its own scrolling container. W3C's Reflow guidance notes that a table in its own scrollable container lets other content reflow ^[5], and the U.S. Web Design System (USWDS) calls its scrollable variant ideal for dense data ^[32].

 |<------ 320 CSS px viewport (illustrative) ------>|
 | Feature (pinned) | Starter | Team   | Sca|
 | Projects         | 3       | 25     | Unl|  <- cut-off Scale column
 | Storage          | 5 GB    | 100 GB | 1,0|     signals more to the right
 scroll region: focusable, named by the caption

• Preserves: every row-to-plan relationship and per-row comparison for the visible columns.
• Weakens: simultaneous comparison; Starter against Scale needs a scroll and a memory of the first view.

NN/g recommends locking row headers in place ^[4] and says arrows or cut-off elements best convey hidden columns ^[4]. Smashing notes touch devices hide scrollbars, so readers may think a table is not scrollable ^[30].

Keyboard operation is the easily missed build requirement. The Deque axe rule asks that a keyboard-only user can focus the scrollable region itself ^[6], and Roselli's pattern uses a tabindex for this ^[33]. Chrome documents that from version 130 scrollers are keyboard focusable by default if they have no focusable children ^[7], but only in that case ^[7]. A W3C test rule expects scrollable elements or their descendants to be reachable by sequential focus navigation ^[34]. This research found no normative W3C sentence prescribing an attribute, so the brief should name the behavior to demonstrate (focus, arrow-key scrolling, visible focus). Sticky parts add checks: a focused component must not be entirely hidden by author-created content ^[12], and Roselli found a sticky caption disappears in a left-to-right scroll ^[35].

Treatment B: stacked sections with repeated labels

 STARTER (USD 12 per month, fictional)
   Capacity:      Projects 3 | Storage 5 GB
   Data protection: Storage (backups) Not included
 TEAM (USD 39 per month, fictional)
   Capacity:      Projects 25 | Storage 100 GB
   Data protection: Storage (backups) 50 GB (Q5: kept 30 days)
 SCALE ...

• Preserves: reading one plan completely, with long labels on a full line and qualifiers beside values.
• Loses: adjacent comparison.

NN/g found that converting to tabs or lists does not support compensatory decision making as well ^[1], and that a one-item-at-a-time view makes users remember numbers across views ^[4]. Rupert says stacking becomes an unpassable experience with many rows or columns ^[31], and Smashing notes it might significantly increase page height ^[30].

Implementation differs, and three cautions apply:

• Label source: USWDS stacks by moving column headers into the cell content in each row ^[32].
• Generated text: MDN cautions that CSS-generated content is not included in the accessibility tree like real text ^[36].
• ARIA patches: Roselli warns that applying ARIA (Accessible Rich Internet Applications) roles to retain table semantics can be problematic for responsive tables ^[37], and that when a table is turned into blocks screen readers stop calling it a table ^[38].

A stacked alternative is safest as real headings and lists, or a separate rendering, not a table forced into block display.

Treatment C: selected plans, priority rows and accordions

Other patterns reduce what is shown: priority rows, accordions, or a two-column view that, per Foolproof, only compares contiguous columns ^[39]. These change the contract: Google says the mobile layout may differ as long as the content is equivalent to the desktop site ^[8], so hiding row R12 on phones needs the business owner's sign-off.

A deliberately broken example

• Truncated labels: "Onboarding session for new workspace admini..." loses "up to 45 minutes each".
• Icon-only values: a check mark with no text, where color alone separates "No" from "Yes".
• Hidden rows: R09 to R12 removed on phones, so a mobile reader cannot learn Starter has no uptime commitment.
• Display override without repair: table elements switched to block display, leaving cells tied to no header ^[28].

What each treatment keeps and loses

Table 3 below compares the treatments on the fixture; the right-hand columns say what to test.

No preserved relationship is free: a treatment that keeps adjacency (A) asks for scrolling, and one that removes scrolling (B) removes adjacency. Choosing is a decision about the reader's task.

The reflow exception, applied carefully

WCAG 2.2 Reflow excepts parts of the content requiring two-dimensional layout for usage or meaning ^[5]. W3C lists data tables, not individual cells, and says individual cells would still need to meet Reflow ^[5]; related content such as a preceding heading is not covered ^[5]. The reference width is 320 CSS pixels, equal to a 1280 pixel starting viewport at 400% zoom ^[5].

Whether a three-plan, twelve-row comparison depends on two-dimensional layout for meaning is a reviewer's judgment, not settled here. A stacked view avoids the question for that view, and the exception never excuses the heading, call-to-action buttons or footnotes around the table.

The Design and Build Boundary

Before a quote, agree who owns each requirement and what evidence closes it. Ownership divides four ways:

• Designer: mockup states (desktop, narrow, zoomed, long-label, qualified-value).
• Developer: semantics, the scroll container and keyboard behavior in the built page.
• Business owner: the content in the schema.
• Editor: the update workflow.

A conformance statement, if wanted, needs a qualified auditor; neither a design subscription nor this report supplies certification.

• Mockups include states, not just the happy path: the scroll state with its cut-off cue, the stacked state with repeated group names, and R11 at the narrowest width.
• Semantics are built, not painted: the mockup cannot show header associations, so the developer demonstrates them in the build.
• Zoom and text spacing are tested on the built component: WCAG text spacing asks for line height of at least 1.5 times the font size ^[40].
• Long labels wrap rather than clip: MDN notes that overflow-wrap: anywhere counts break opportunities toward min-content sizing ^[41], while hyphenation needs a language attribute and dictionary ^[42]. The acceptance test is that R11 stays readable.

Container queries let a component respond to its container width instead of the viewport, and MDN reports container-type as widely available since February 2023 ^[43]. The switch point between table and stacked layouts should come from testing the real content, not from a universal column count.

Content systems shape editing, and as of November 2026 their documentation varies. The WordPress Table block says its final appearance may vary depending on the theme ^[44] and offers a header section toggle ^[44]. Contentful added rich-text tables with a header row toggle ^[45]. Sanity's built-in table editing is available from Studio v6.6.0 and disabled by default ^[46]. Webflow's rich text documentation says tables can be created with custom code in HTML ^[47]. A Wix help article documents a table app with a scroll mode ^[48]. These are documentation statements, not tests; ask the developer to demonstrate the real editor on the real site.

Table 4 below is the requirement, owner, evidence and test sheet. The Result column is intentionally empty: it is filled on the delivered build, with browser and assistive-technology versions recorded.

The sheet assigns ownership, not effort; A09 can be a full pass or a sample, and the quote should say which. It does not replace the site's general accessibility responsibilities or release approval process, which the brief should link instead of recreating.

Data Analysis and Evidence

Context figures

Three context figures frame the mobile question:

• Worldwide traffic: StatCounter's October 2026 table lists mobile at 59.9% and desktop at 38.51% ^[49].
• United States traffic: desktop at 52.4% and mobile at 45.43% ^[50]. These are one provider's traffic shares, not any site's audience.
• Smartphone ownership: Pew Research Center reports that about nine-in-ten (91%) U.S. adults own a smartphone ^[9].

Accessibility context comes from surveys. WebAIM's 2026 analysis found an average of 56.1 errors per home page ^[51], and the HTTP Archive Web Almanac 2025 reports roughly 1.6% of desktop sites include table captions ^[52]. In WebAIM's Screen Reader User Survey #11 (1780 valid responses ^[53]), respondents with disabilities (93.4%) are much more likely to use a mobile screen reader ^[53]. None of this says how many comparison tables are usable.

Comparison behavior evidence

Baymard found that on spec-driven sites 67% of participants used comparison features ^[10], yet of 38 mobile participants who visited the two sites with comparison features, three used the feature at one site and none at the other ^[10]. It noted that in portrait mode only one full column would be visible at once ^[10]. NN/g takes a different view: try to support some level of comparison on mobile ^[1]. Both concern retail and reference comparisons, not three-plan pricing tables, so the inference is limited: if a visitor compares plans on a phone, the treatment decides what they can compare; how many do is for the site's analytics to show.

Fixture arithmetic

These are instructional counts, not hours, costs or a statistical sample.

• Value placements: 3 plans × 12 rows × 3 reviewed layouts = 108.
• Distinct editable facts: 3 plan names + 12 labels + 12 units + 36 values + 7 qualification texts = 70. Shared data means 108 placements come from 36 stored values.
• Label placements: 12 desktop + 12 scroll + 36 stacked (each label repeated per plan) = 60, so a relabeled row appears 5 times.
• Qualifier placements: 7 qualified values × 3 layouts = 21 markers needing matching text.

With shared data each fact is stored once; with hand-built layouts one edit can mean 3 value edits or 5 label edits. That is why the schema comes before the quote.

The Editor Update Exercise

The exercise tests whether the person who will maintain the component can do so. In the real CMS, without developer help, the editor makes three changes and lists every affected view: (1) rename "Team" to "Studio"; (2) raise R02 Storage for that plan from 100 GB to 250 GB; (3) remove Q4 ("annual contracts only") from R07 Single sign-on for Scale.

Table 5 below is the update log. Counts are fixture assumptions: three layouts, a call-to-action button carrying the plan name in each, one introductory sentence naming plans, and one shared list of qualification notes.

Three lessons emerge: a plan name is the most widely distributed fact; an allowance can create derived statements no one remembers writing; and a removed qualification can leave an orphaned marker, so marker and note text should come from the same record. The exercise passes when the editor produces this log unaided and a reviewer's spot checks match it.

Commissioning: Scoped Project or Ongoing Capacity

A buyer of a small isolated component should compare a scoped web project with ongoing development capacity. Public procurement guidance gives logic, not a verdict. The U.S. Federal Acquisition Regulation says fixed-price arrangements suit work where risk is minimal or can be predicted with acceptable certainty ^[54], and that the likelihood of changes makes costs difficult to estimate in advance ^[54]. A Project Management Institute paper notes that traditional statements of work have a narrow, but fixed scope for a single price ^[55].

A comparison table with a settled schema and three treatments is a bounded deliverable; one whose plans and conditions change quarterly is a stream of small edits. Table 6 below compares route types. It is editorial, not sourced pricing, and the Tapflare row describes the publisher's own model.

For one component with stable content, a scoped project is the more natural fit and a subscription is not. If the table is one of many recurring requests, capacity may suit better, with the acceptance sheet attached to each. The business owner supplies the schema and wording either way. The publisher of this article, Tapflare, offers a subscription service of this kind.

Implications and Future Directions

The comparison table is shifting from a visual component to a maintained dataset. A schema feeding the table, plan cards and structured data reduces drift; the GOV.UK aim of a single source of content truth ^[16] is the same idea at larger scale. The responsive toolbox also keeps growing: MDN's page for the scroll() function in scroll-driven animations shows a Baseline 2026 "newly available" label and says the feature works across the latest devices and browser versions since October 2026 ^[56], which may eventually allow scroll-edge cues without script, though support should be rechecked before a build relies on it.

Standards guidance is still developing. W3C lists reflowing simple data tables only as a potential future technique ^[5]. The test sheet, not the pattern, is the durable part. Open questions remain: whether pricing-plan tables show the same mobile behavior as retail comparisons, which treatment leads to fewer misreadings, and how assistive technologies treat each in current versions. A buyer wanting evidence should run the acceptance sheet on the built component.

Frequently Asked Questions (FAQs)

What is a responsive comparison table?

A table of options (columns) against attributes (rows) whose layout adapts to width while each value stays tied to its option and attribute ^[1].

How to make a comparison table responsive on mobile

Choose by task: a scroll region with pinned labels preserves adjacency, stacked sections preserve one plan, a selection pattern compares two plans. USWDS recommends scrolling for numerical data across many columns ^[32]. Table 3 shows what each loses.

What are responsive table design best practices?

Real header cells, a caption, visible row separation, a focusable scroll region, an overflow cue and identical content in every layout. GOV.UK says a caption helps users find, navigate and understand tables ^[57].

What does a responsive HTML table need in CSS?

A wrapper that becomes a scroll container only when content overflows ^[58], plus rules for long labels. Avoid display overrides that remove table semantics unless tested with assistive technology.

What are comparison table UX best practices?

Put the information most people look for first ^[13], group rows into categories ^[29], and keep column headers visible, since users otherwise look back to see which product a spec applies to ^[29].

How should a responsive pricing comparison table show conditions?

Beside the value. The FTC says to place a disclosure hyperlink as close as possible to the information it qualifies ^[21].

What are good mobile comparison table examples?

One public gallery lists a horizontally scrolling table with the feature column pinned ^[11]. Judge any example with the acceptance sheet, not appearance.

Is a comparison table web design service worth buying for one component?

It depends on scope and frequency; see the commissioning table above.

Conclusion

A responsive comparison table is a relationship contract before it is a layout. The business decides what is compared and which conditions apply; the designer decides how each width presents the same records; the developer proves relationships, keyboard operation and zoom; the editor proves the content can change. In the fictional fixture, 36 stored values appear in 108 placements, 70 facts feed them, and three small edits touch 14 placements inside the component plus a longer list outside it.

No mobile pattern wins outright. A scroll region keeps adjacency and costs scrolling; stacking keeps one plan whole and costs comparison; selection keeps two plans side by side and hides the rest. The evidence supports tradeoffs and test criteria, not a universal rule, and it concerns retail and reference comparison more than pricing pages. Before approving a quote, agree the schema, the treatment per width, the owner of each requirement and the retest triggers, then keep the acceptance table with the delivered build.