Why should an agency sell accessibility monitoring?

Because clients get sued whether or not the agency built the store recently, and the first call goes to whoever runs the site. A monitoring retainer turns that liability call into a service line: continuous coverage, monthly reporting, and a fix queue your team bills against, all documented per client.

What does the monthly client report contain?

Scan history, score trend, issues opened and closed with dates, current template status, and recommended priorities. It is formatted to be forwarded inside the client's company without explanation. Agencies typically attach it to their standard monthly reporting, where it anchors the accessibility line item.

Can the reports carry our agency's branding?

Yes. Reports are generated per client store with your agency as the presenting party. The underlying evidence is identical either way; the difference is that your client sees your name on the compliance program, which is the point of running a retained accessibility service.

How does pricing work across many stores?

Every portfolio starts with a free accessibility audit of one client store, delivered client-branded exactly as your client would receive it monthly. Ongoing monitoring is quoted per store after that, with volume tiers as the portfolio grows. Most agencies resell monitoring inside their maintenance retainers.

What happens when a client receives a demand letter?

Their store's evidence file is already built: months of scans, dated fixes, and current status. You hand the client a defense-ready pack and, if needed, an accelerated remediation plan. The agency looks prepared because it is prepared. A11yShieldHQ provides documentation, not legal advice.

Does A11yShieldHQ fix the issues itself?

No. The monitor finds, attributes, and verifies; the fixes belong to your developers or the client's team. That separation keeps the evidence credible, because the party reporting conformance is not the party billing for remediation. Verification rescans confirm every closed issue with a date.

Accessible Promo Code Entry at Checkout

October 29, 2026

Promo code fields fail on hidden labels, error messages that only turn the box red, and apply buttons that do nothing a screen reader can hear. Here is how to make discount entry work for everyone.

The promo field is small, and stores treat it as decoration. It is often a collapsed link that expands with animation, an input with no label, and an apply button that answers a bad code by shaking the box. For a shopper using a screen reader, nothing happened. For a shopper with low vision, a red outline is the whole message.

That matters for money, not just compliance. A valid code that will not apply, with no readable reason, reads as dishonesty. People abandon, or they pay full price and file the kind of complaint that accessibility practitioners see in Title III demand letters: a named workflow, a date, and a barrier a keyboard could not finish.

Label it and keep it visible

A collapsed promo link is fine if the control that opens it has a clear name and the expanded field keeps a visible label: discount code, not just code. Connect the label in code. Placeholder text is not a label, and it vanishes at the exact moment the shopper starts typing and needs to check which field they are in.

Keep the field in the tab order where sighted shoppers see it, next to the order total it changes. Moving it later in the DOM than the pay button creates a different checkout for keyboard users, one where the discount effectively comes after payment.

Say what happened, in text

A rejected code needs a reason in words: expired, does not apply to items in this order, minimum spend not met. That text belongs next to the field, linked to the input with aria describedby, and it should be announced when it appears. Colour and an icon alone fail 1.4.1 Use of Color outright.

A accepted code needs the same treatment. Update the total, name the saving, and announce it. If the total changes silently, a screen reader user has no way to know the code worked except checking out and hoping.

Do not punish pasting or typos

Many codes arrive by copy and paste from an email. Blocking paste, forcing uppercase, or clearing the field after an error all punish the shoppers most likely to struggle. Leave what they typed in place, select it if you must, and let them edit one character.

Also check the mobile version with the on screen keyboard open. A sticky pay bar that covers the apply button, or covers the error text, is a barrier you will only find by testing at real size with zoom at 200 percent, which WCAG 1.4.10 Reflow requires you to support.

Frequently asked questions

Is a placeholder enough as a promo field label?

No. A placeholder disappears while typing and many screen readers do not treat it as a label. Use a visible label connected to the input, and keep any format hint as separate descriptive text.

How should an invalid code error read?

State the specific reason in text next to the field, link it to the input for assistive technology, and announce it when it appears. Red borders or shaking animations alone do not count as an error message.

Should promo entry be hidden behind a link?

It can be collapsed if the toggle is properly named and keyboard operable, and the expanded field is fully labelled. Test that opening it does not move focus somewhere unrelated.

What total should update when a code applies?

The item total, the discount line with the code name, and the amount due. All three should be readable as text, not only shown as a changed number a screen reader never announces.