Info and Relationships — semantic tables
Tabular data must use semantic table markup (`<table>`, `<thead>`, `<tbody>`, `<th scope>`, `<td>`) so screen readers can navigate the data with row/column header context.
What it requires
A focused subsection of WCAG 1.3.1 covering tabular data specifically. Visual users see a grid; screen-reader users navigate by cell with each cell announced as "row 3, column 2, [header label], [cell value]". This requires real `<table>` markup with `<th scope="col">` and `<th scope="row">`.
Common failure: `<div class="grid">` styled to look like a table but rendering with no row/column header context to assistive technology. Browsers + screen readers cannot recover the table semantics from the visual styling.
Common Shopify failure
Nutrition-facts panel on food merchant's product page rendered as styled `<div>` grid. Spec table on electronics merchant's product page rendered as flexbox layout. Comparison-matrix block from a page-builder app rendered as nested divs.
How to fix it
Use semantic table markup and associate headers with data cells according to the table's actual structure. Complex tables and grid-like layouts need human review before markup is restructured.
Merchant QA checklist
- Scan the storefront page where this pattern appears: product pages, collection pages, cart drawer, customer-account pages, and any landing page built with theme sections.
- Confirm the issue is fixed in the rendered browser output, not only in the Liquid file. Shopify section settings, app blocks, and third-party scripts can reintroduce the same 1.3.1 (tables) failure after a theme edit.
- Re-test the affected component with keyboard navigation and a screen-reader accessibility tree before publishing the theme, especially when the fix changes markup or ARIA attributes.
How AccessComply handles it
AccessComply uses automated rules to check supported patterns in the pages reached during a scan. Some WCAG requirements need human judgment, assistive-technology testing, or access to third-party content and cannot be established by an automated scan. This criterion is generally treated as a guided or hands-on fix pattern. If the app can safely match the issue to supported source code, the merchant must review and approve the suggested change before anything is written, and the result is checked afterward. Otherwise the merchant should use the guidance above and independent hands-on testing. The label is not a guarantee of detection, a fix, WCAG conformance, or legal compliance.
Primary source: W3C — WCAG 2.0 Understanding 1.3.1 (tables)