What a default WooCommerce shop looks like to accessibility checks

We built a clean shop, added everything the normal way, broke nothing on purpose, and ran the checks. The shop's own content produced nothing at all. The theme and WooCommerce templates produced forty-six items.

The shop

A fictional bakery, Rye & Crumb. WordPress 7.1, the default Twenty Twenty-Five theme, WooCommerce 11.1 with its default settings. Six products, four content pages plus WooCommerce's own shop, cart, checkout and account pages, and two blog posts. Everything added through the block editor the way an owner would add it.

Nothing was made inaccessible on purpose. The images were simple drawings rather than photographs, which matters for one of the findings below.

The content scan found nothing

Twenty-eight items were read: posts, pages, products and every image in the library. Zero findings.

That result is more interesting than it sounds, and it is not a clean bill of health.

When somebody adds an image in the block editor and does not type any alt text, the editor saves alt="". In HTML that is not missing alt text — it is a positive statement that the image is decorative and that a screen reader should skip it. No automated check can call that a failure, because the markup says the author decided. WooCommerce separately falls back to the product name for product images, so those are never empty either.

So an image that shows the product, uploaded by somebody who simply did not think about alt text, is indistinguishable from an image that was deliberately marked decorative. Blog and page images need a person to look at them. A scan of any kind will keep saying nothing is wrong.

The browser check found forty-six

The browser check loads real pages and runs axe-core 4.13 on them, plus the plugin's own probes. It covered fourteen of fifteen pages and raised forty-six items. Every one of them came from the theme or from WooCommerce's templates. None came from anything the shop owner typed.

The two marked needs review are not called failures and are not counted as any. Contrast over an image depends on which part of the image sits behind which letter, and a machine measuring one sample point cannot settle it. The aria-controls case may be harmless if the element is created later by script. Both need a person, and the report says so rather than inflating the number.

One page could not be checked at all: the checkout, because an empty cart redirects to the cart page. That is WooCommerce working as designed. Version 0.1.2 now names pages it could not reach rather than quietly leaving them out of the count, which is the difference between fourteen of fifteen and an unexplained fourteen.

One finding was wrong, and that is worth saying

Version 0.1.1 also reported WooCommerce's inactive product tabs as unreachable by keyboard. That was a false alarm: the arrow keys do reach them, which is how a tab list is supposed to work. It is fixed in 0.1.2.

It is mentioned here because a tool that reports a problem you cannot find is worse than one that reports nothing, and because any checker that never admits a mistake is either new or not being read carefully.

What this means if you run a shop

A careful owner, doing everything the normal way, still inherits a list they cannot fix from the editor. Navigation markup, a cart drawer and a gallery button are not content. They are the theme and the platform, and the fixes are a theme change or a report to whoever maintains the theme or WooCommerce.

That is the useful shape of the result. The work in front of a shop owner is not mostly their own typing. It is partly a conversation with somebody else's code, and knowing which is which is what stops an afternoon being wasted in the wrong place.

See for yourself

Try it in your browser What the plugin does

A temporary WordPress site with the plugin installed, nothing to sign up for. The free plugin is on WordPress.org, or search for Lumadro Accessibility Ledger under Plugins, Add New in your own admin.