The accessibility code that was already there and doing nothing

We spent a week on accessibility on a client’s store, working from automated scans and by hand, page type by page type. The measured scores moved a long way: home 44 to 68, contact 53 to 80, cart 47 to 80, and a product page 47 to 62. Worth saying plainly, because a lot of accessibility marketing does not, an automated scan covers roughly a third of the standard. Those numbers are real progress and they are not a pass.

What we found

The two faults that mattered most were on the contact form, and no scanner we ran flagged either of them.

The first: the email field carried the attribute that ties an input to its error message, and the id it pointed at existed nowhere on the page. Correctly written, correctly spelled, connected to nothing. A customer using a screen reader hears the field and never hears why it was rejected.

The second: the message shown after submitting had autofocus on it, sitting on a <span>. A span cannot take focus unless it has been explicitly made focusable, so when the form posted and the page re-rendered, focus stayed where it was. Someone using a screen reader submitted the form and got no confirmation of any kind. Both of these read as care. Neither did anything.

What we did

Fixed both along with seven other items, and then went looking for the same shape elsewhere, because a theme that has one dead reference usually has more. Where a fix would have meant editing rich text inside template settings, we did it once in JavaScript against the rendered page instead, so it also covers copy the client writes later. What is left on those pages is now either a decision for the client, a third-party app’s own code, or Shopify’s.

What to take from it

If your store has had accessibility work done at some point, do not assume the attributes that exist are attributes that work. They accumulate over years, across themes, apps and hands, and nothing checks them. The cheap version of this audit is to take every reference in your markup that names another element and confirm the thing it names is actually there. And be careful with the tooling: a checker with a narrow idea of what “hidden” means will report a working fix as broken, and re-running it is not the same as verifying it.