What the audit is, and what it is not
An accessibility audit is a test of whether people who use a screen reader, a keyboard alone, magnification, voice control or other assistive tools can use your website or store: find a product, read its details, add it to the basket, pay, create an account, submit a form, read your terms. We test against WCAG 2.1 AA, the technical standard most complaints and requirements refer to, and we tell you criterion by criterion what passes, what fails, and the code change that fixes it.
It is an engineering audit by engineers, which is both the strength and the limit. We find and fix the problems in your markup, styles, scripts and templates. We do not tell you what the law requires of you; a lawyer can tell you that. We do not sign conformance statements or produce VPATs, because those are claims you make, with advice. And we do not install overlay widgets, for the reasons explained below.
Why businesses ask for this now
Three reasons come up, in roughly this order.
A letter arrived. Law firms send demand letters on behalf of people who could not use a site with assistive technology. According to Seyfarth Shaw, 5,006 ADA Title III lawsuits were filed in US federal courts in the first half of 2026, and letters outnumber suits. A lawyer can tell you what a letter means for your business; we can produce the audit and the fixes the lawyer will ask about. See what an ADA website demand letter means.
A buyer asked. Larger customers, public bodies and some marketplaces ask suppliers for evidence of accessibility before they sign.
Someone could not buy. A customer, an employee or a relative told you the store did not work with their screen reader. This is the most direct reason and the easiest to act on.
What the free scan finds
Automated tools check the page as delivered to the browser against the rules that can be checked by a machine. On a typical store or business site the scan surfaces:
- Images without alternative text, and decorative images not marked as such.
- Text contrast below 4.5 to 1 for body text and 3 to 1 for large text.
- Form fields without a programmatic label; required fields not indicated to assistive tools.
- Links and buttons with no accessible name (an icon with no text).
- Missing document language, missing or duplicate page titles, skipped heading levels.
- Elements that cannot receive keyboard focus but respond to a mouse.
- Zoom disabled on mobile, content that cannot reflow at 320 pixels.
We run the scan on each distinct template rather than on every page, group the findings by WCAG criterion, and tell you which findings are template-wide (one fix, every page) and which are content-level (an editor's job). The report says plainly what the scan cannot see.
What needs a human
Most of the criteria need a person testing with the tools people actually use. In the paid audit we test each template with a keyboard alone, with a screen reader on desktop and on a phone, at 200 and 400 percent zoom, and with a contrast and motion check. In particular:
- Keyboard. Can every control be reached and operated with Tab, Enter, Space and the arrow keys? Are there traps, where focus enters a menu or a modal and cannot leave? Can the cookie banner, the search, the variant picker, the quantity field, the checkout and the account pages all be used without a mouse?
- Focus order and visibility. Does focus move in the order a sighted person would read? Is the focused element visibly highlighted, or has the theme removed the outline? When a modal opens, does focus move into it and return afterwards?
- Screen reader semantics. Is the mega-menu announced as a menu with its state? Are product variants and prices read in a sensible order? Are "Add to cart" confirmations, form errors and loading states announced? Are headings, landmarks, lists and tables real elements rather than styled divs? Do custom components (carousels, accordions, tabs, star ratings) carry the right roles, names and states?
- Meaning. Is the alternative text useful, or is it the file name? Is information conveyed only by colour (a red border on an error, a green dot for in stock)? Do link texts make sense out of context?
- Forms and checkout. Are errors identified in text, associated with the field, and specific enough to fix? Do autocomplete attributes exist for name, address and payment fields? Does the time limit, if any, warn and extend?
- Motion and media. Can autoplaying carousels be paused? Do videos have captions?
Every finding in the report has the criterion, where it occurs, how to reproduce it, a screenshot or recording, and the code-level fix.
Platform specifics
Shopify. Most failures live in three places: the theme (focus styles stripped, custom drawers and modals without focus management, heading levels used for size), app-injected widgets (reviews, upsells, chat, countdown timers, each adding its own markup you do not control), and product media (alternative text never filled in). We fix the theme in a duplicate you can preview, audit each app's front-end output, and tell you which apps need configuring, replacing or removing. The checkout on standard Shopify is Shopify's own and is largely out of your hands; on Plus, checkout customisations are in scope.
WooCommerce and WordPress. The theme and child theme carry most of the fixes, and the front-end output of each plug-in is audited separately, since page builders, sliders and mega-menu plug-ins are frequent offenders. Blocks and templates you actually use are fixed; those you do not are listed for removal. Editor guidance covers alternative text and heading use for your content team.
Custom applications on Laravel, Node or .NET are audited in the same way, in your repository, with fixes delivered as reviewed pull requests.
On overlay widgets
An overlay is a script added to the page that shows a toolbar and attempts to modify the page in the visitor's browser: enlarging text, changing contrast, adding labels it guesses at. Vendors sell them as a quick route to compliance. We do not install them, for a plain reason: they do not change the code a screen reader actually reads, so the underlying failures remain for anyone who tests the page; many assistive technology users report that overlays conflict with the tools they already run; and a page that is only usable while a third-party script loads is a page that fails whenever that script does not. Fixing the markup is slower. It is also the thing that works, and it is yours when it is done.
Illustrative record
A US Shopify store, about 1,200 products, custom theme, nine apps rendering on the storefront, prompted by a buyer's accessibility questionnaire. Illustrative of a typical scope, not a client result.
- Scan: 14 templates, contrast failures in the theme palette, 60 percent of product images without alternative text, three app widgets with unlabeled controls. Manual audit: focus outline removed site-wide, cart drawer trapping focus, variant picker announcing nothing, error messages conveyed by colour only, carousel with no pause
+ Sprint: theme palette and focus styles corrected, drawer and modal focus management rebuilt, variant picker and quantity controls given roles and announcements, form errors associated with fields, carousel paused by default, two apps reconfigured and one replaced, alternative text template and editor guide delivered
What it costs
| Work | Includes | Fixed price |
|---|---|---|
| Automated scanThe first step | Automated checks on your main templates, grouped by WCAG criterion, with a note on what the scan cannot see. 2 working days | Free |
| WCAG 2.1 AA auditPriced by template and page count | Automated plus manual testing with keyboard, screen readers and zoom on every distinct template; a dated report by criterion with reproduction steps and code-level fixes. 1 to 3 weeks | $1,200 to $7,500 |
| Fix sprint | Remediation in your theme, templates and code on a staging copy; app and plug-in review; editor guidance; re-test of every finding. 3 to 6 weeks typical | from $4,000 |
| Conformance monitoringOptional, cancel any month | Monthly scan, manual re-test of templates that changed, fixes for regressions, a named engineer | $200 to $900 a month |
What moves the audit price: the number of distinct templates, whether checkout and account flows are in scope, and how many third-party widgets render on the page. What moves the fix sprint: how much of the theme needs rebuilding rather than correcting, and how many apps or plug-ins have to be replaced. The price is written down before work starts. Half at start, half at the re-test.
How it runs
Free scan (2 working days)
You send the site address and, if you like, the pages that matter most. We run the automated tools on your templates and send the findings grouped by criterion, template-wide versus content-level, with what the scan cannot judge.
Audit (1 to 3 weeks)
We agree the templates and flows in scope and the fixed price. Each template is tested with keyboard, screen readers and zoom. You receive a dated report by criterion with evidence and the code-level fix for each finding.
Fix sprint (3 to 6 weeks)
Fixes are made in a staging copy of your theme or a branch of your repository that you can open at any time, with a written log every working day. App and plug-in changes are agreed with you before they are made.
Re-test and hand over
Every finding is re-tested and its status recorded in the report. You get the final report, the editor guidance for alternative text and headings, and a session for your team.
Monitoring (optional)
A monthly scan and a manual re-test of anything that changed, with regressions fixed. Theme updates and new apps are the usual cause. Cancel any month.
Who does the work
RiantSoft has built, upgraded and maintained ecommerce stores and business applications for US and UK clients since 2009, on Shopify, WooCommerce, Magento, Laravel, Node and .NET. Accessibility remediation is theme and application engineering with a test method attached, and the fixes live in your own code and your own accounts when the job is done.
Request a free scan, or email info@riantsoft.com.
Questions people ask
What is WCAG 2.1 AA and why that version?
The Web Content Accessibility Guidelines are the technical standard, published by the W3C, that describe how web content should work for people who use screen readers, keyboards, magnification or other assistive tools. Each guideline has success criteria at three levels, A, AA and AAA. Level AA of version 2.1 is the one most complaints, procurement requirements and regulations refer to, which is why we audit against it. Version 2.2 added a few criteria in 2023 and we check those too, marked separately, so you know where you stand on both.
What is an ADA website demand letter?
A letter from a law firm, on behalf of a person with a disability, stating that your website could not be used with assistive technology and that this breaches the Americans with Disabilities Act, usually with a request for money and for the site to be fixed. According to Seyfarth Shaw, 5,006 ADA Title III lawsuits were filed in US federal courts in the first half of 2026, and demand letters are more numerous than suits. We are not lawyers; a lawyer can tell you what the letter means for you. Our article on what a demand letter means covers the first week in plain terms, and we can run the scan and the audit the lawyer will ask for.
Can a free automated scan tell me if my site is compliant?
No. Automated tools detect only the failures a machine can judge: missing alternative text, contrast below the threshold, form fields without labels, missing document language, duplicate IDs, empty links and buttons. They cannot tell whether the alternative text is meaningful, whether the page can be used entirely from a keyboard, whether focus moves in a sensible order, whether a screen reader announces a custom menu or a product variant picker correctly, or whether an error message is conveyed to someone who cannot see it. Those need a person. The scan is where to start, not where to stop.
Do you install an accessibility overlay or widget?
No. Overlays are scripts that add a toolbar and attempt to patch the page in the visitor's browser. They do not change the underlying code, so the problems a screen reader meets in the markup are still there for anyone who tests it; many assistive technology users say they interfere with the tools they already run; and a page that only works when a third-party script loads is a page that fails whenever that script does not. We fix the code itself, which is slower and is also the thing that works, and it is yours when it is done.
Will you sign a conformance statement or produce a VPAT?
No to both. A conformance statement or a VPAT (Voluntary Product Accessibility Template) is a formal claim about your product's accessibility that you make to buyers or regulators, and it carries legal weight for you. We will give you a detailed, dated audit report that lists each criterion, its status, and the evidence, which is what an accessibility consultant or your lawyer would use to prepare such a document. We are the engineers who make the findings true; the statement should be made by you, with advice.
How does this work on Shopify, WooCommerce or WordPress?
On Shopify we work in your theme code and check the apps you have installed, since app-injected widgets such as reviews, upsells and chat are a common source of failures you cannot fix from the theme; some have to be replaced. On WooCommerce and WordPress we work in the theme and child theme, audit the plug-ins that render on the front end, and fix the templates and blocks you actually use. In every case the work happens in a staging copy you can open, and the fixes live in your own code, not in an injected script.
How long does an audit and fix take?
The free scan comes back within two working days. The audit takes one to three weeks depending on page count: we test every distinct template rather than every page, because a store with 3,000 products has perhaps a dozen templates. The fix sprint typically runs three to six weeks for a store or business site, and ends with a re-test of every finding. If you have a deadline from a letter or a procurement process, tell us at the start and we will write the dates into the scope.