The rating everyone sees and nobody hears

Star ratings are among the most influential elements on a product page, and among the least accessible. To a sighted shopper, four and a half gold stars communicate instantly. To a screen-reader user, the same widget is often announced as "image" or as a bare number with no context, or skipped entirely. The shopper who most needs review information to compensate for not seeing the product is the one least likely to get it.

This is not an edge case. Review widgets are usually third-party embeds, which means the merchant never built them and may not realize they are broken. But accessibility responsibility does not follow the code's authorship. If it renders on your product page, it is your compliance surface.

What the accessible pattern looks like

The baseline fix is text equivalence. Every visual rating needs a text alternative that states the rating and the scale: "Rated 4.2 out of 5 stars, based on 318 reviews." That single sentence, properly exposed to assistive technology, does more than most widget rebuilds. It belongs in the widget's accessible name or in adjacent text the screen reader encounters in a sensible order.

The star graphics themselves should be hidden from assistive technology once the text equivalent exists. Five separate star images, each announced individually, turn a rating into a confusing recitation. One summary, announced once, is the correct granularity.

The review list below the summary

The summary is only the entry point. The review list underneath carries its own traps. Star ratings per review repeat the same announcement problem at scale. Review text is usually fine, but the metadata around it, dates, verified-purchase badges, helpful-vote counts, is often structured as a visual layout with no programmatic relationships. A screen-reader user hears a stream of fragments: "Verified. Helpful, 12. October 3rd."

The fix is semantic structure: each review as an article or list item, the rating as text, the metadata grouped so the relationships are announced. "Review by Jordan, verified purchase, rated 5 out of 5, posted October 3rd" is the same information, made navigable.

Sorting, filtering, and pagination

Review widgets usually offer sorting and filtering: by rating, by recency, with photos only. These controls are frequently the least accessible part of the widget. Custom dropdowns that are not real select elements, star-filter buttons with no labels, and pagination that reloads content without moving focus or announcing the change.

Test the widget the way a keyboard-only user experiences it. Can you reach the sort control by keyboard? Does activating a filter announce the result count? When you move to page two, does focus go somewhere sensible, or does it stay on a button that no longer describes the visible content? These are the failures that turn a readable review list into an unusable one.

What to ask your review app vendor

Because the widget is third-party, the practical path is vendor pressure plus defensive markup. Ask the vendor for their VPAT or accessibility statement, and specifically whether the rating summary exposes text equivalents and whether all controls are keyboard operable. If the answers are vague, add your own text summary adjacent to the widget and make sure it is the first thing assistive technology encounters.

Document the gap either way. In an accessibility complaint or lawsuit, the question is not whether the third-party widget was perfect. It is whether you knew about the barrier and did nothing. A text summary you added yourself is evidence of the opposite.

Testing with real assistive technology

Automated checkers will not catch most of these failures, because a widget can pass color contrast and labeling checks while remaining unusable in practice. The meaningful test is a screen reader pass: NVDA or VoiceOver, keyboard only, attempting to answer the questions a shopper actually asks. What is the rating? How many reviews? What do the recent ones say? Sort by lowest rating and read two. If any of those tasks is confusing or impossible, the widget fails regardless of what the scanner reported. Fifteen minutes with a screen reader finds what no audit tool will.