Testing Screen Reader Order on Product Bundles and Kits
Bundle pages list components, options, and a total in visual groups that screen readers often read in a different, broken order. Here is a testing routine that catches the mismatch.
A bundle looks simple: three products, pick a size for one, a colour for another, one total, one button. Visually, grouping does the explaining. In code, each option may sit far from the product it belongs to, so a screen reader reads all the size selectors first and all the product names later, like a parts list read by two people at once.
Order is a WCAG criterion for a reason, 1.3.2 Meaningful Sequence, and bundles are where it breaks without anyone noticing, because the visual CSS grid can place things anywhere regardless of source order. The fix starts with reading the page the way it is coded, not the way it is painted.
Related reading on this site: The ADA Risk Hiding in Sticky Add to Cart Bars, Autoplay Video on Product Pages: The ADA Risk Nobody Tests, Checking Link Purpose on Cards, Tiles, and Blog Teasers.
Read it linearly, in full
Use a screen reader, or at minimum a linearised view, and go through the bundle start to finish. For each component you should hear: name, price if it differs, its options, its quantity. If options arrive detached from their product, a shopper cannot safely choose, and may buy the wrong size in the wrong item with no way to tell.
Pay attention to the total. It should come after the choices it sums, and changing a quantity or an option should update it in a way that is announced, or at least placed where a reader will naturally encounter it before the buy button.
Check the required choice that is not chosen
Bundles love a default that is not really a default: a size group with nothing selected and a buy button that errors. That error needs the full treatment, text naming the missing component and the missing choice, placed by that component, and focus moved to it or announced.
Also check remove controls. A bundle with three remove buttons all named remove tells the shopper nothing. Each one needs its product in its name, or a heading structure that makes the association unambiguous in context.
Fix source order, not just the visual grid
The durable fix is to group each component in the markup: a section per product containing its own options. Then the visual layout can use grid or flex to place those groups however design wants, while the reading order stays correct on every device.
Retest after any theme work on product templates. Bundle logic is often added by an app that injects its own markup, and an app update can rebuild the page with a different order while the visual result looks identical.
Frequently asked questions
Why do bundles read in the wrong order?
Because visual layout tools can reposition elements regardless of their order in the code, and screen readers follow the code. If all product names are coded first and all options after, that is the order a screen reader will announce.
What should a bundle total do when options change?
Update in text, and be positioned where the shopper encounters it before committing. If the change is important, announce it politely. A silent total change leaves screen reader users checking out with a price they never heard.
How should remove buttons on a bundle be labelled?
Each should identify its product, for example remove trail socks from bundle. Identical remove labels force the shopper to guess, and removing the wrong item is a predictable outcome.
How often should bundle pages be tested?
After theme changes and after any update to the bundling app that builds the page, plus in the regular product page audit rotation. The visual sameness after an update is exactly why regressions go unnoticed.