Info and Relationships
Information, structure, and relationships conveyed visually (headings, lists, tables, grouped form fields) must also be programmatically determinable through HTML semantics or ARIA.
What it requires
Visual users can see at a glance that a piece of text is a heading because it is bigger or bolder; that a group of items is a list because they are bulleted; that a set of inputs is a form section because they are grouped under a visual title. Screen-reader users only know any of this if the underlying HTML semantically marks it up.
A `<div class="big-text">` styled to look like a heading is a 1.3.1 failure — use `<h2>`. A list of items wrapped in `<div>` instead of `<ul>` / `<li>` is a failure. A form section without a `<fieldset>` and `<legend>` (or `aria-labelledby` equivalent) is a failure.
Common Shopify failure
Theme product pages where the variant selector group ("Color", "Size") is just `<div>` containers. Cart drawer where the "Cart subtotal" label is visually styled but not associated with the value via a list or definition.
How to fix it
Replace styled `<div>` headings with `<h2>` / `<h3>`. Use `<fieldset>` + `<legend>` for variant groups. Use `<dl>` / `<dt>` / `<dd>` for cart summary lines.
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 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