Make a service-package table understandable on mobile and without vision

Choose the comparison the customer actually needs

Ask which decision the table should support. Is the customer choosing a maintenance frequency, a service scope or an assessment option? Remove rows that do not help that decision. Then check whether a cell's meaning is clear without seeing its position: 'included' is useless if the user cannot identify the relevant package and task.

Preserve row and column header relationships

W3C's Two Headers tutorial addresses tables whose values need both a row and a column label. Ask the maintainer to verify those associations in the actual published component. The service owner still needs to approve every inclusion; markup cannot make an inaccurate scope value correct.

A genuinely two-dimensional table may use a supported horizontal scrolling region. That exception does not cover individual cells: their content and surrounding instructions or controls still need usable reflow without lost information. Test a long cell as well as the whole table.

Source checks: W3C WAI: Tables with Two Headers · W3C: Understanding Reflow

Test one feature across packages

Use a short verified comparison before building a complicated matrix. Label the service feature in each row and package in each column. State included, not included or assessment needed in text where appropriate. Test the same question through desktop, mobile and an appropriate assistive-technology review rather than judging only the table's visual appearance.

• Define the two or three package differences that affect the customer's next decision.
• Verify each inclusion or condition with the service owner.
• Use clear row and column headers and ask the maintainer to check their semantic associations.
• Test a narrow layout and ensure any necessary scrolling is discoverable and operable.
• Ask a reviewer to identify one feature's status in each package without relying only on color or visual position.

Avoid shrinking or flattening the table into an image

A screenshot loses table semantics and can become unreadable when enlarged. Colored ticks without accessible meaning may hide whether work is included. Shrinking every cell to fit a phone can make text unusable. Card layouts also need their feature and package relationships preserved; a responsive design change does not automatically solve the comparison task.

Record whether comparison questions can be answered

Record whether readers can answer specific questions, such as which package includes a defined visit or which needs assessment. Note where headings or conditions are missing. These observations improve the table's usefulness. They do not prove that comparison tables always sell more services or that the page meets every accessibility requirement.

Keep package facts and table structure maintained together

Keep the verified package scope and table structure in the maintenance note. When an inclusion changes, update its cell, explanatory text and any linked quote selection together. Retest the same comparison question after redesigning the layout. Staff should use the same package names so the customer's selection can be recognized during review.

Worked example: an illustrative two-header garden-care table

For example, a garden-care business compares a recurring visit and a one-time tidy-up. Feature names are row headers and package names are column headers. The sample values explicitly distinguish included work, excluded work and assessment needed; they are fictional service boundaries, not actual business offers.

A customer asks whether hedge work belongs to the one-time option. The narrow-screen and assistive-technology review must preserve both headers for that cell. The table may need horizontal scrolling, while its cell text still wraps usefully without lost information. This tests scope interpretation, not real pricing or the suitability of every hedge job.

Questions about this task