What does £240 belong to?

A number needs its neighbours

A reader reaches £240 in a support-plan table. With the whole grid in view, it is obvious that the price belongs to Growth and is monthly. After magnification or horizontal scrolling, those labels may be elsewhere. Cell-by-cell navigation needs the relationship too. The design has to carry that meaning with the value, rather than depend on the arrangement visible in the first screenshot.

“£240” is not much of an answer on its own. “Growth, monthly price, £240” is a useful statement. A data table needs to preserve that relationship when read through assistive technology, magnified, scrolled on a narrow screen or exported. Readability is partly the appearance of each cell and partly the availability of the context that makes the cell interpretable.

Consider a fictional comparison of three business-support plans. Each row names a plan; columns show monthly price, included support hours and response arrangement. The figures are invented for this example. A sighted reader may understand that £240 belongs to the Growth plan. The markup should make the row and column relationship explicit rather than leaving another reader to reconstruct it from position.

W3C’s tables tutorial explains row and column headers, scope and captions. They let the markup express the relationships the comparison relies on. First check whether that comparison is understandable enough to use. A large grid with several overlapping header groups can need a simpler presentation before more associations are added. The reader is trying to choose support, not solve the designer’s layout while keeping a price in memory.

Build the simplest truthful table

For the support plans, use a caption that identifies the comparison and any important unit or period. Mark the plan names as row headers and the attributes as column headers. In a simple table, scope=row and scope=col establish the direction of those headers. Keep the price period explicit: a caption saying “monthly prices” may help, while a cell or accessible label can carry context where necessary.

Growth, monthly price, £240 names the relationship we want the reader to retain. It is a proposed result to test, not a transcript from a screen reader we have run. Different browser and navigation modes may present it differently. Supply the semantic association so those tools can use it, then check whether a person can complete the intended comparison in the supported combinations instead of assuming one exact announcement will occur everywhere.

Avoid adding merged headers merely to make the design look more sophisticated. A two-tier comparison with separate regions or billing periods may need grouped headers. W3C describes additional associations for those cases. Sometimes two smaller tables, each with a clear caption, make the information easier to maintain and understand than one larger table with several levels of header association.

Qualifying notes need an association too. If £240 excludes an optional service, place the qualification where someone inspecting that price can find it. A superscript symbol explained far below the comparison may be visually conventional yet difficult to follow when reading one cell at a time. Sometimes a short phrase in the heading or cell is the clearer solution.

Define the meaning of a dash before using it as a cell value. Zero included hours, an unavailable service, an inapplicable attribute and information still to be confirmed lead to different comparisons. An explicit phrase such as Not included can resolve that ambiguity for visual and nonvisual readers alike. The table's data contract needs to distinguish those states even when the initial sample happens to contain none of them.

<table>
  <caption>Illustrative support plans — monthly prices</caption>
  <tr><td></td><th scope="col">Monthly price</th></tr>
  <tr><th scope="row">Growth</th><td>£240</td></tr>
</table>

Decide what happens when the grid is wider than the screen

The support comparison may need horizontal space to preserve relationships between plans and attributes. A labelled, discoverable scroll region can retain that grid while the surrounding prose reflows within the viewport. Its operation needs testing with keyboard and enlarged text as well as a pointer. Keeping the wide content within that boundary avoids requiring sideways movement merely to continue reading the article around it.

Another option is a plan-by-plan presentation that repeats attribute labels. That can work well when the main task is understanding one plan. It can make cross-plan comparison harder because corresponding values no longer align. The responsive design should follow the reading task rather than a rule that every table must become cards at a certain width.

Inspect the rendered semantics when changing the layout. A CSS-generated label may look convincing without providing the relationship the assistive tool needs. Maintaining a desktop table and a separate mobile card set can also leave repeated or inconsistent content if hiding and updates go wrong. Keep one trustworthy data source and test both presentations. Changing where £240 appears should not change which plan it describes or the qualifications needed to interpret it.

WCAG’s reflow guidance recognises that some content requires a two-dimensional layout, including certain data tables. That does not mean every surrounding control or paragraph may ignore narrow screens. A useful implementation preserves the necessary table relationship while keeping navigation, explanation and actions usable in the available space.

The table is also a small interface

If the table contains a “Choose” button in each row, its name needs enough context to distinguish the plan. Three identical names can be inconvenient in a list of controls, even if their visual position is obvious. “Choose Growth” communicates the action and target more directly. Check that any additional accessible name remains consistent with the visible wording.

Sorting changes the visual order without changing which plan owns a value or action. The heading needs to convey its actionable role and current sort, while row headers and button targets remain attached to the same records. A reordered Growth row must still choose Growth. Reviewing those relationships tests the table's behaviour beyond whether the newly sorted prices appear numerically plausible.

Orientation without an accidental spreadsheet

Sticky headers and frozen first columns can aid orientation, especially in wide tables. They can also obscure focused controls or take most of a small viewport. Test movement to a button near an edge, enlarged text and a long plan name. The useful question is whether the reader can retain context while reaching the action, not whether the header remains visible under every conceivable circumstance.

These support plans need comparison and selection, which ordinary table markup and controls can usually provide. An editable spreadsheet would introduce another keyboard model for readers to discover and for the team to maintain. Use it when people actually need those editing operations. Rows and columns are not, by themselves, a reason to give a read-only pricing comparison the operating demands of a spreadsheet.

Review relationships in more than one direction

A practical review script can ask for four tasks: find Growth’s monthly price, compare included hours across plans, locate the response arrangement for Starter and choose the intended plan. Try them by visual inspection, keyboard navigation and the supported screen-reader table controls. Record the actual relationships announced and any point where context is lost.

Then change the data. Give one plan a long name, insert a “To be agreed” response arrangement and add a price with a qualifying note. These variations reveal whether the design depends on short, uniform content. A fixture with three tidy rows may hide the very case that will make a real comparison difficult to understand.

Inspect the export too if the product offers one. A CSV may preserve raw rows while losing the caption, units or meaning of a blank value. Include explicit column names and a documented treatment of exclusions. Someone should not need to return to the webpage to discover that a price was monthly or that a zero was actually an unavailable service.

Follow Growth’s £240 monthly price through scrolling, sorting and export, then check that its selection control still chooses Growth. The caption, headers, labels and units should keep the same relationship understandable at each stage. A CSV cannot rely on the original webpage to explain a blank or billing period. Leaving that context in the exported data gives the next reader the same comparison, even after the visual grid and surrounding prose have gone.