Most accessibility "audits" are an automated scan with a logo on it. A scanner can only detect roughly a third of WCAG failures — it cannot tell you whether a focus order makes sense, whether a button's name describes what it does, or whether a cart drawer is usable without a mouse.
This page documents the full process behind every AccessoraX audit, in the order we run it. It exists so you can see what you're paying for, compare us honestly against other providers, and hold us to it.
- Principles we work to
- Phase 1 — Scoping and page selection
- Phase 2 — Automated testing
- Phase 3 — Keyboard-only testing
- Phase 4 — Screen reader testing
- Phase 5 — Visual and zoom testing
- Phase 6 — Component-level testing
- Phase 7 — Third-party apps
- Phase 8 — WCAG mapping and severity
- Phase 9 — Reporting
- Phase 10 — Retesting
- What this method does not cover
Principles We Work To
Manual first
Automated tools run first because they are fast, not because they are authoritative. Every finding a scanner reports is confirmed by hand before it reaches your report.
Test the journey, not the page
A page can pass in isolation and still block a purchase. We test complete paths: find a product, choose a variant, add to cart, check out.
Reproducible
Every finding includes the page, the element, the steps to reproduce it and the assistive technology used. You should be able to see it yourself.
Honest about limits
No audit finds 100% of issues, and no vendor can promise you won't be sued. We tell you what we tested and what we didn't.
Phase 1 — Scoping and Page Selection
Testing every URL on a 400-product store is neither possible nor useful, because most product pages are the same template rendered with different data. We test templates and journeys.
A standard scope covers:
- Homepage
- Collection or category template
- Product template, including one product with variants and one without
- Cart page and cart drawer
- Checkout, through to the payment step
- Search and search results
- Account pages: login, register, order history
- Content pages: about, contact, policy pages
- Any page with a form, modal, carousel or filter
- 404 page
We ask for one thing before starting: your best-selling product and your highest-traffic collection. Those get tested first, because a barrier there costs you the most.
Phase 2 — Automated Testing
Automated scanning is the first pass. It is good at finding machine-detectable failures at volume: missing alt attributes, empty links, contrast ratios, duplicate IDs, missing form labels.
| Tool | What it contributes |
|---|---|
| axe DevTools | Rule-based WCAG checks with low false-positive rate |
| WAVE | Visual overlay showing where issues sit on the page |
| Lighthouse | Baseline score and performance context |
| HTML validator | Malformed markup that breaks assistive technology |
| Contrast analysers | Precise ratio measurement, including text over images |
What automation cannot do. It cannot judge whether alt text is accurate, only whether it exists. It cannot tell you a focus order is illogical, only that elements are focusable. It cannot detect a keyboard trap that requires three interactions to reach. Roughly 30–40% of WCAG 2.1 AA criteria are machine-testable. The rest is the work below.
Phase 3 — Keyboard-Only Testing
The mouse is put away. Every task a customer needs to complete is attempted using only Tab, Shift+Tab, Enter, Space, Escape and the arrow keys.
What we check on every interactive element
- Reachable — can it be focused at all?
- Operable — does it respond to Enter or Space as expected?
- Visible — is there a focus indicator, and is it visible against its background?
- Not obscured — is the focused element hidden behind a sticky header, cookie banner or chat widget? (WCAG 2.2, 2.4.11)
- Escapable — can focus always move onward, or does it trap?
- Logical order — does focus follow the visual reading order?
Journeys tested by keyboard alone
Browse and buy
- Navigate from homepage to a product via the menu
- Apply and clear a collection filter
- Select size and colour variants
- Add to cart and reach checkout
Recover and correct
- Change a quantity, then remove an item
- Apply an invalid discount code
- Submit a form with a deliberate error
- Dismiss every modal and overlay
Phase 4 — Screen Reader Testing
Keyboard testing proves a control can be reached. Screen reader testing proves it makes sense when announced. A button you can Tab to that says "button, blank" is still unusable.
| Screen reader | Browser | Why this pairing |
|---|---|---|
| NVDA | Chrome and Firefox on Windows | Most widely used free screen reader; the common desktop baseline |
| VoiceOver | Safari on macOS | Behaves differently from NVDA, particularly with ARIA and tables |
| VoiceOver | Safari on iOS | Touch gestures differ entirely from desktop navigation |
We test with more than one because they disagree. A pattern that announces correctly in NVDA can be silent in VoiceOver, and vice versa. Testing one and declaring compliance is a common shortcut we don't take.
What we listen for
- Does every control have a name that describes its purpose?
- Are product name, price, variant and availability announced together, in a sensible order?
- Do headings form a navigable outline? (We navigate by heading, as real users do.)
- Do landmarks let a user skip to main content, navigation and footer?
- Are images described, or correctly marked decorative?
- Are state changes announced — item added, filter applied, error raised?
- Is anything announced that shouldn't be, such as hidden carousel slides?
We record the actual announcement text for key controls and include it in the report. Reading "Add to cart, button" versus "clickable" is more persuasive to a stakeholder than any severity rating.
Phase 5 — Visual, Zoom and Reflow Testing
Colour contrast
Measured, not eyeballed. Body text must reach 4.5:1, large text 3:1, and interface components and focus indicators 3:1 against adjacent colours. We check the states people forget: hover, focus, disabled, placeholder text, text over hero images, and text on brand-coloured buttons.
Use of colour
Colour must never be the only way information is conveyed. Sale prices, stock status, required fields, form errors and selected variants are all checked for a non-colour cue.
Zoom and reflow
Text spacing (1.4.12)
Line height, letter and word spacing increased. Nothing may clip or overlap.
Reflow (1.4.10)
Content at 320px width with no horizontal scrolling, and at 400% browser zoom.
Text resize (1.4.4)
Text scaled to 200% without loss of content or function.
Orientation and targets
Portrait and landscape both usable; touch targets at least 24×24px, with 44×44px recommended.
Motion
Carousels, parallax and animated banners are checked for a pause control and for whether they respect prefers-reduced-motion. Anything that flashes more than three times per second is flagged immediately as a seizure risk.
Phase 6 — Component-Level Testing
This is where most Shopify-specific failures live. Each component is tested as an interactive unit, not just scanned as markup.
Forms
- Every field has a visible, programmatically associated label — a placeholder is not a label
- Required fields indicated by more than colour or an asterisk alone
- Errors identified in text, associated with the field, and announced
- Focus moves to the first error on failed submission
- Autocomplete attributes present on name, address, email and payment fields
- Grouped inputs wrapped in
fieldsetwith alegend
Product cards and collection grids
- Card links have unique, descriptive names — twelve links all reading "Read more" is a failure
- Product images carry meaningful alt text, not filenames
- Price, sale price and availability are all in the accessible name or nearby text
- Rating stars have a text equivalent
- Quick-view and quick-add controls are keyboard operable and return focus correctly
- Lazy-loaded or infinite-scroll content announces that new results have loaded
Filters, sorting and search
- Filter groups use fieldset and legend so the question being answered is clear
- Applied filters are announced and individually removable
- Result counts are announced when they change
- Autocomplete follows the combobox pattern, navigable by arrow keys
- "No results" is communicated to screen readers, not shown visually alone
Cart drawer
The single most common point of failure we find. Tested against four requirements:
- Focus moves into the drawer when it opens
- Focus stays inside while it is open
- Escape closes it
- Focus returns to the trigger on close
We also check that it is marked up as a dialog with an accessible name, that quantity and remove controls identify which product they act on, and that subtotal changes are announced through a live region.
Dynamic content and ARIA
Anything that changes without a page load is checked for whether the change is perceivable non-visually: cart updates, filter results, form validation, live inventory, countdown timers.
How we treat ARIA
ARIA is assessed against the first rule of ARIA: don't use it if native HTML can do the job. A <button> beats a <div role="button"> every time. We flag ARIA that is redundant, contradictory, points at missing IDs, or hides content that should be available. Incorrect ARIA is worse than none — it actively misinforms.
Phase 7 — Third-Party Apps and Checkout Boundaries
Third-party apps account for a large share of the violations we find, and they are the part store owners are least aware of. Each installed app that renders customer-facing markup is tested individually.
Common categories audited: reviews, popups and email capture, live chat, upsell and bundling, filters and search, cookie consent, loyalty widgets, and any accessibility overlay.
Checkout boundaries — what we can and cannot change
Shopify controls the checkout page itself. On plans below Shopify Plus, checkout.liquid cannot be edited, and we will not claim otherwise.
What we can audit and fix: the cart drawer, cart page, express checkout buttons, checkout extensions and apps, and every step leading to checkout. In our experience that is where the failures actually are — customers rarely reach Shopify's checkout because they get stuck before it.
Where a genuine barrier sits inside Shopify's own checkout, we document it, report it to Shopify, and record it in your report as a known limitation outside your control. That documentation matters if you are ever challenged.
Phase 8 — WCAG Mapping and Severity Classification
Every finding is mapped to a specific WCAG 2.1 or 2.2 success criterion by number and level. "This looks wrong" is not a finding. "1.3.1 Info and Relationships (Level A) — the shipping options are not grouped in a fieldset, so the question is not announced" is.
Severity is impact, not tidiness
Severity reflects how much the issue blocks a real person, and how exposed it leaves you legally. It is not a measure of how hard it is to fix.
| Severity | Meaning | Example | Target |
|---|---|---|---|
| Critical | Blocks a core task outright. No workaround exists. | Checkout cannot be completed by keyboard | Immediately |
| High | Blocks a task for a specific group, or a workaround exists but is unreasonable. | Variant swatches have no text labels | Within 2 weeks |
| Medium | Task is possible but significantly harder or slower. | Heading order skips levels | Within 1–3 months |
| Low | Minor friction, or best practice beyond the AA requirement. | Link text could be more descriptive | Next redesign |
Where a single root cause produces many instances — one bad snippet rendering across 300 products — it is reported once, with the instance count. Padding a report with 300 line items makes it look thorough and makes it useless.
Phase 9 — Reporting
Every finding in your report contains:
- Page URL and the specific element
- WCAG criterion, number and conformance level
- Severity, with the reasoning
- Steps to reproduce, including which assistive technology was used
- What a user actually experiences, in plain language
- A recommended fix, with code where applicable
- Instance count if the issue repeats
Reports also include a prioritised remediation order, an estimate of effort, and a plain-English summary for stakeholders who won't read the technical detail.
Phase 10 — Remediation and Retesting
An audit that ends at the report is half a job. After fixes are implemented — by us or by your team — we retest.
- Verify each fix using the same method that found the issue. A keyboard failure is retested by keyboard, not by scanner.
- Regression check the surrounding area. Fixes break things; focus management in one modal often affects others.
- Re-run the full automated pass to catch anything introduced during remediation.
- Re-walk the core journeys end to end, since components pass individually and still fail in sequence.
- Issue a verification record stating what was fixed, when, how it was confirmed, and what remains open.
Accessibility is not a one-time state. Adding products, installing apps and updating themes all introduce new issues. We recommend retesting quarterly, and after any theme change or app installation.
What This Method Does Not Cover
Every vendor should publish this section and almost none do.
- No audit finds every issue. Expert manual review typically surfaces the large majority of barriers, not all of them. Anyone promising 100% is selling something.
- We are not a law firm. We can reduce risk and document your efforts. We cannot guarantee immunity from claims, and no accessibility vendor can.
- We test templates, not every URL. A product page with unusual custom content may behave differently from the template we tested. Tell us about anything unusual and we'll include it.
- Shopify's checkout is outside our control on non-Plus plans, as described above.
- We do not run usability studies with disabled participants. Testing with assistive technology is not the same as testing with people who depend on it daily. For higher assurance, we can help you arrange that separately.
- Compliance is a moving target. WCAG 2.2 added criteria; a store audited against 2.1 may have gaps against 2.2.
Standards We Test Against
- WCAG 2.1 Level AA — the standard courts currently reference in ADA cases
- WCAG 2.2 Level AA — the current W3C recommendation, including focus appearance and target size
- ADA Title III — the legal context in the United States
- EN 301 549 — where a store sells into the EU
For the detail of what these require, see our WCAG 2.1 requirements guide and our Shopify WCAG checklist.
See this methodology applied to your store
We'll run the first stages of this process on your homepage and send back a recorded walkthrough showing exactly where a customer would get stuck. Free, and there's no pitch attached.
Request your free auditWhere This Methodology Applies
This is the process behind every engagement: