Start with the customer decision
A table is useful when a reader must compare the same attributes across several items. Imagine a Hong Kong repair company publishing service slots by district, weekday and service type. A customer may need to find the evening slot for Kowloon, then compare it with a daytime slot on Hong Kong Island. If the page is only a picture of a grid, a reader who enlarges text or uses a screen reader cannot reliably keep the row and column meanings attached to each value. Start by writing down the question each cell answers: which service, in which district, on which day, with what availability? If the answer needs only a short list, use a list instead. A table earns its place when the relationships between cells are themselves essential. This is an editorial choice as much as a markup choice: remove columns that do not help the customer decide, and put definitions of unfamiliar terms beside the table before asking anyone to interpret figures.
Give every value its context
W3C’s Web Accessibility Initiative explains that data tables need actual header cells and data cells, with programmatic relationships between them. A bold first row is a visual treatment; it does not by itself say which cells are headings. In a simple table, use header cells for the top row and data cells for the values. When the first column names each service or location, mark those cells as row headers. Explicit column and row scope can remove doubt in a table with both directions of headings. Do not turn a layout grid into a data table merely to align prices and buttons. Conversely, do not replace a real table with a collection of visually aligned cards while silently dropping the relationships. A person moving cell by cell should hear or otherwise obtain enough context to know whether “available” describes the Friday repair slot or the Saturday consultation. Test that exact distinction, because a table can look tidy while conveying the wrong answer.
Name the table and explain units
A short caption helps a reader identify the subject of a table before entering its cells. “October repair appointment availability” is more useful than “Table 1”, and a nearby sentence can explain whether the times are local Hong Kong time and whether availability is live or a dated snapshot. W3C says captions are particularly helpful for users who navigate among tables, while a separate summary can explain an unusual structure. The caption need not repeat the entire paragraph above the table. Label units in the column header, not in only the first data row; a fee column marked “HKD per visit” prevents later values from being mistaken for hourly charges. If the table compares products, distinguish current stock, estimated dispatch and a promised delivery date. Those are different claims, and the heading must not compress them into the ambiguous word “status”. When a value is unavailable, say what the dash or blank means instead of forcing customers to guess.
Simplify before adding complex markup
A merged header may seem to save space, but it can make a table harder to maintain and harder to understand. W3C’s tutorial describes grouped rows and columns for irregular headers, and explicit identifiers for truly multilevel headings. The practical first move is often to split one large table into two small tables, each with a direct caption and simple headings. Consider a catalogue that lists two regions, three delivery methods and several fee conditions under merged cells. A customer may only need a table for local delivery and another for collection. The team can then state exceptions in text rather than stacking another heading level. If a complex table remains necessary, document what every spanning heading covers and verify the associations after content edits. A new delivery option can shift a merged cell without any obvious visual error. A content editor should not have to infer hidden header relationships from cell colours alone.
Work through a real comparison
Suppose the company offers appliance inspection in two districts on three days. Draft a small table with a caption naming the service and period, district as the row heading, and each day as a column heading. Each data cell can say “morning”, “afternoon” or “no appointment”, rather than a bare tick. Put a note beside the table explaining that selecting a time opens a booking flow and that availability is confirmed only after submission. Now ask one colleague to find a Kowloon Saturday appointment using keyboard navigation and a screen reader, and another to find it with text magnified on a narrow mobile view. Compare the answers they report with the actual booking system. If a day disappears horizontally, a heading is lost when the table is restyled, or the booking control lacks a distinguishable name, fix the presentation before publishing. This example is a test design, not a claim that any particular business has available slots.
Test content and navigation together
An automated checker can find some missing table semantics, but it cannot decide whether the headings actually answer the customer’s question. Review a rendered page with keyboard only, at increased text size, and with at least one screen reader used by your audience. Move to a middle cell and confirm that its row and column context is available; do not test only the first row. Check a cell with a long bilingual label, one with no value, and one with an action such as booking or viewing details. A horizontally scrollable container must still let the customer reach every column and understand which heading applies. If the table updates after a filter, verify that the displayed caption, column set and status match the new result. Keep a short record of the test input, expected answer, observed answer and any correction. The release decision should be based on whether the reader can reach the same business conclusion, not on whether the grid looks balanced in a screenshot.
Make updates safe for the next editor
Tables often become inaccessible during routine content updates rather than initial development. A merchant may add a fourth price tier, rename a location or paste rows from a spreadsheet without checking the underlying cell types. Give the editor a short content rule: every new row needs the same columns in the same order, each row heading must identify the item, and a changed unit requires the header to change too. If the price is before tax or valid only on selected days, put that condition where it applies and link it to the exact value; a note several screens away can be missed. When an option expires, remove or explain it rather than leaving a blank cell that could mean either zero availability or missing data. Keep the source of the figures and their last verification date in the editorial working record. Before publishing an update, compare one old and one new row using the same assistive-technology path. This small maintenance test protects customers from a technically valid but commercially misleading table.
Know when a table is the wrong interface
A customer should not have to scan twenty columns to answer a yes-or-no service question. If there are many categories but only one relevant result after the user selects a district, a labelled filter followed by a plain result list may be clearer. If the information is a process, such as how to book, use ordered steps. A table is strongest for simultaneous comparison; it is weaker when every row contains long prose or conditional exceptions. On mobile, do not solve narrow width by shrinking text until it is unreadable. Consider a smaller table per service, an accessible scroll area with a visible cue, or a separate details view that repeats essential context. Whatever presentation is chosen, test the same customer task in English and Traditional Chinese. Chinese labels can have different widths, and a bilingual column heading may wrap into multiple lines. Check that a wrapping heading does not visually appear to belong to the neighbouring column. The useful result is a customer who can answer the question accurately without remembering a heading from several screens earlier.
Before you proceed
- The table has a specific caption and stated units.
- Every data cell retains correct row and column context.
- Keyboard, magnification and screen-reader checks produce the same decision.
