WCAG for Ecommerce
WCAG 1.3.1 Info and Relationships — Semantic HTML
The structure users see visually—headings, lists, labels, groups, and tables—must also exist in the code so assistive technologies can understand it.
For D2C teams, this is not just a standards question. It is a revenue-path question. When a WCAG criterion fails on a product page, filter interface, or checkout form, it creates both customer friction and legal exposure.
What this means in plain English
The structure users see visually—headings, lists, labels, groups, and tables—must also exist in the code so assistive technologies can understand it.
On ecommerce sites, this criterion matters because shoppers are rarely reading one clean article. They are evaluating products, interacting with filters, switching variants, reviewing shipping promises, and moving through forms under time pressure. When the underlying accessibility rule breaks, the buying journey breaks with it.
Why it matters for ecommerce
Size charts
product specifications
FAQ accordions
checkout step labels
ADA complaints against online stores usually do not focus on abstract theory. They focus on failed tasks: a user cannot understand a product image, cannot interpret a discount, cannot complete a form, or cannot recover from an error. That is why even one overlooked success criterion can create outsized legal and commercial risk.
How to check if you comply
Manual test
Inspect headings with a screen reader rotor or browser accessibility tree. Check whether sections, lists, tables, and form groups still make sense without CSS.
Automated test
Use browser accessibility inspectors and axe to spot missing labels or incorrect heading order, then manually confirm relationships on dynamic components.
How to fix violations
Use native headings, fieldsets, legends, lists, and tables instead of styling generic divs to look structured.
<fieldset>
<legend>Choose your size</legend>
<label><input type="radio" name="size" /> Small</label>
<label><input type="radio" name="size" /> Medium</label>
</fieldset>
The best fix is usually at the component level. If the problem lives in a reusable product card, accordion, swatch selector, or form field, repair the shared component once instead of chasing the same violation page by page.
Common mistakes stores make
- Skipping heading levels for design
- Using divs instead of fieldsets for grouped options
- Building fake tables with paragraphs
- Breaking label-to-input relationships with custom components
These mistakes recur because ecommerce teams optimize for speed, visual merchandising, and third-party integrations. Accessibility gets treated as cleanup work instead of release quality, so the same defect reappears with every new campaign or theme update.
Why this matters legally
In 2025, 8,667 ADA lawsuits were filed across federal and state courts. Plaintiff firms do not need every WCAG failure to build pressure. They only need enough reproducible barriers to show that disabled shoppers cannot access the same buying journey. That makes criteria like WCAG 1.3.1 Info and Relationships — Semantic HTML commercially and legally material, not academic.
Related reading
FAQs
Why does semantic HTML matter for ecommerce?
Because shoppers need to understand product details, options, and checkout instructions in a reliable structure, not just a pretty layout.
Can ARIA replace semantic HTML?
Not usually. Native HTML is the safest first choice, and ARIA should supplement—not replace—good structure.
What breaks this criterion most often?
Page builders, overly custom design systems, and option selectors that were built visually first and semantically second.