Why an accessibility overlay does not fix this
An overlay is a script that loads on your storefront and rewrites the page in the browser. It is the fastest thing to buy and the least likely thing to work. Here is what actually happens.
What an overlay does
It injects a widget, guesses at missing labels and alternative text, and offers the visitor a panel of toggles: bigger text, higher contrast, a reading mask. The page underneath does not change.
Why the people it claims to help reject it
Assistive technology already does what the toggle panel offers, and does it better, because it is configured once for every site rather than re-discovered on each one. An overlay that inserts its own controls into the tab order adds work for a keyboard user rather than removing it.
Guessed labels are worse than missing ones. A missing label announces as an unnamed field, which is a problem the user recognises. A wrong guessed label announces confidently as the wrong thing, and the user has no way to tell.
Why it does not survive scrutiny
- The barrier is still in your theme. Turn the script off and it is exactly as it was.
- A person testing your site will test it as their own tools present it, not as your widget presents it.
- An overlay leaves no record of anything being fixed, because nothing was.
What has to change instead
The label element in the checkout template. The button that is a div. The swatch that has no keyboard handler. The contrast token in the child theme. These are small edits, and they are permanent.
That is the whole difference between the two approaches: one paints over the page for the duration of a script, the other changes what the page is.
What we do instead
We report the barrier with the element it lives on, ship the change to make, and re-test after you make it. Nothing of ours runs in front of your buyer. Our companion plugin adds no JavaScript and no CSS to your storefront at all.