Accessibility Trees: Check Your Product Page

A customer selects “Medium,” but the size control does not expose a name. Another opens a size chart, but its measurements exist only in an image. Both problems deserve attention even when the product page looks complete.

An accessibility-tree inspection gives you a way to examine what a browser exposes about those elements. It is useful for accessibility and for browser tools that consume that representation. It does not show everything every AI system knows about your store, and it is not a test of Google indexing.

Here is a focused product-page review you can run with a developer, using a clearly labeled apparel example and a record of what you actually observe.

What the accessibility tree represents

A browser derives an accessibility tree from a page’s structure and semantics. It can expose roles, names, and states: for example, a heading with the product name, a labeled size selector, or a button that is disabled. This representation supports assistive technologies. Chrome’s documentation shows how to inspect it alongside the page’s DOM.

Some agent tools use this structure too. Microsoft’s Playwright MCP project describes browser interaction through accessibility snapshots. That is evidence about a particular tool’s interface. It does not establish that every browsing agent uses only this representation or that all AI search answers come from it.

Keep a browser interaction test separate from a search test. Google’s JavaScript SEO guidance describes crawling, rendering, and indexing as separate steps. A page’s presence in an accessibility snapshot does not prove Google has indexed it; JavaScript content is not automatically invisible to Google either.

What the 95.9% statistic actually measured

The 2026 WebAIM Million study found automatically detected WCAG failures on 95.9% of the homepages it examined. This is an accessibility finding about that sample. It is not the percentage of product pages that AI agents cannot read, nor a measurement of lost citations or sales.

Use that research as a reason to test your own pages. Do not convert its headline percentage into an “AI readability score” for your catalog. Your inspection needs to establish which element is defective and which customer task it affects.

Define a task before opening developer tools

For this illustrative example, imagine a navy pocket T-shirt available in several sizes. The review task is: “Find the garment chest measurement, select navy in Medium, and determine whether that variant is available.” These are example product details, not observations from a real store.

Write down what a successful review should establish:

• The product heading identifies the garment.
• The color and size controls have understandable names.
• Their current selections can be determined.
• The size-chart control can be found and operated.
• The chart distinguishes garment measurements from body measurements.
• Availability and purchase controls agree with the selected variant.

This task gives the reviewer a boundary. They can report a missing size-selector name or an inaccessible chart without claiming to have certified the entire storefront.

Inspect the controls and their state changes

Open the product page in Chrome, open DevTools, and select the Elements panel. Select a control in the DOM, then open Accessibility to inspect its computed properties. Chrome also provides a full accessibility-tree view. Record the browser version and selected variant so another reviewer can repeat the check.

W3C’s form-labeling guidance calls for labels that identify a control’s purpose and are associated with that control. For a size selector, a visible “Size” label should correspond to the actual input. Placeholder text or nearby styling is not sufficient evidence that the browser computed a useful name.

Ask the developer to record the following before and after selecting Medium: control role, computed name, current value or selected state, and whether the control is disabled. The exact representation depends on the widget. A dropdown and a group of radio buttons need not produce identical trees.

An illustrative issue report might read: “The visible label says Size, but the inspected control has no computed name. Associate the label with the input and repeat the Medium selection.” This describes a proposed repair and verification step; it is not a measurement from our sample store.

Test the size chart as a complete interaction

Use the keyboard to reach and activate the size-chart control. Check where focus moves, whether you can read the measurements, and how you return to the product options. Then repeat with a screen reader or an accessibility reviewer where possible.

For the illustrative tee, a useful chart entry would say “Size M — garment chest width, measured flat: 52 cm,” if that is the verified specification. “Medium fits everyone” provides no measurement. “Chest: 52” leaves the unit and measurement method unresolved.

If the chart is an image, a short alt description may explain its purpose while still failing to communicate every measurement. Provide the actual size data in accessible text or a suitable table. Do not squeeze a whole measurement grid into a promotional image description.

Also test a variant that is unavailable. Record whether the page communicates that state and whether the purchase action behaves accordingly. Stop before placing an order. A normal-stock check does not cover the unavailable-size path.

Separate missing product facts from interface defects

These two findings need different owners:

• Missing fact: the merchant has not supplied a garment measurement. The content owner needs a verified value and measurement method.
• Interface defect: the measurement exists, but the chart cannot be operated or understood through the tested interface. The theme developer needs to repair the presentation or behavior.

For a hosted marketplace listing, document the fields you can edit and the interface behavior the platform controls. Improve your own product facts and report reproducible platform defects with steps and evidence.

For an owned storefront, repeat the task after theme updates or changes to variant apps. Keep the product-image review alongside this check so image descriptions and visible options describe the same item.

Save evidence rather than a blanket pass score

Use a small review log: URL; date; browser; task; selected options; element; observed name or state; expected behavior; correction; retest result. Include a screenshot or accessibility snapshot when it explains the defect.

Write conclusions at the scope you tested. “The Medium selector exposes a label and the selected state in this browser” is a useful result. “All AI agents can now buy from this store” is not established by that test.

How FirstShelf can help

FirstShelf can help review submitted listing facts and image evidence for ambiguity. Use that to identify unanswered product questions, then use browser and accessibility testing to check how the storefront exposes the answers. A FirstShelf listing assessment does not certify WCAG conformance or guarantee AI placement. See our methodology for the assessment boundary.

Editorial update, September 27, 2026: corrected the interpretation of the WebAIM statistic and separated accessibility inspection, browser-agent behavior, and search indexing.