Accessibility (WCAG 2.1)
naturespath.com · Full-site SEO audit · April 16, 2026
Nature’s Path runs an accessiBe overlay widget in addition to the Whisk theme’s baseline accessibility affordances. Overlay widgets are a mitigation, not a fix — courts and advocacy groups now treat them as insufficient on their own, and accessiBe specifically is the subject of multiple ongoing lawsuits in the US for failing to deliver accessibility parity. The audit surfaced four documented WCAG 2.1 failures (three Level A, one Level AA) plus three pattern-level issues that reappear across page types. Accessibility overlaps materially with both Visual / Mobile UX (cookie banner focus trap, collection H1 contrast, touch target sizes) and Performance (accessiBe adds 217KB / 114KB wasted JS and ∼500ms–1s TBT). Addressing theme-native ARIA improvements could retire the overlay entirely and recover both the accessibility gap and the performance cost.
Score Rationale
What this section shows. A weighted breakdown of the 58/100 accessibility score across five dimensions (Perceivable, Operable, Understandable, Robust, Overlay reliance) with evidence for each row.
Weighted scoring separates surface compliance from underlying structure. An overlay widget can make a site feel accessible on demo without fixing anything underneath; the theme-native-vs-overlay dimension is the audit’s way of calling that out explicitly. The composite (58/100) lands in Needs Work rather than Fail because baseline HTML structure and landmarks are present; the gap is ARIA, contrast, and focus behavior.
How to read the table. Weight column sets the point ceiling per dimension; Score column shows the earned points. The Notes column names the specific evidence backing each score so remediation owners can go straight to the offending patterns without reading the full audit.
| Dimension | Weight | Score | Notes |
|---|---|---|---|
| Perceivable (text alternatives, contrast, adaptability) | 30 | 17/30 | SKU-based alt text site-wide; collection H1 contrast fails on mobile |
| Operable (keyboard, navigation, focus, input modality) | 25 | 14/25 | Triple country selector disrupts focus order; touch targets below 48×48 |
| Understandable (readable, predictable, input assistance) | 20 | 14/20 | Consistent navigation; HTML lang attr set; labels mostly present |
| Robust (ARIA, status messages, parsing) | 15 | 9/15 | “Loading…” announced by screen readers; aria-live regions missing |
| Theme-native vs. overlay reliance | 10 | 4/10 | accessiBe overlay active; theme-native improvements would allow retiring it |
| Total | 100 | 58/100 | Needs work; theme-code fixable without legal exposure |
WCAG 2.1 Principle Scores
What this section shows. The four WCAG 2.1 principles (Perceivable, Operable, Understandable, Robust) scored out of 100 each, plus two extra cards for overlay reliance and Level A gap count.
Principle-level scoring pinpoints where remediation work should start. Understandable passes at 70/100 (consistent navigation, lang attribute set, labels present); Perceivable and Operable both sit at 56–57 because of alt-text and focus-order patterns that need a site-wide pass. Three documented Level A gaps mean a baseline WCAG floor has not been reached, which is the minimum bar for ADA-defensibility.
How to read the cards. Each card shows the principle score with a coloured bar. Status lines name the gap type. The Level A card is a raw count of baseline failures — every one of them should close before any AA work is prioritised.
WCAG 2.1 Findings
What this section shows. Four documented WCAG 2.1 failures (three Level A, one Level AA) with the specific criterion, impact on assistive-tech users, and the recommended fix per row.
Level A failures are the legal exposure line. Level A criteria are the minimum viable accessibility bar; failures at this level are the ones ADA complaints are built around. All three of NP’s Level A gaps (SKU alt text, triple country selector, empty cart in DOM) are theme-code fixable without third-party dependencies.
How to read the table. The Level badge flags A vs. AA so the triage order is obvious. Impact column describes what an assistive-tech user experiences; Fix column names the specific Liquid template and ARIA attribute change needed. Each row maps to a checklist task below.
| Issue | WCAG Criterion | Level | Impact | Fix |
|---|---|---|---|---|
| Product images use SKU-based alt text | 1.1.1 Non-text Content | A | Screen-reader users hear Heritage_Flakes_Cereal_058449221012-22101U2 instead of the product name. Equates to blind or low-vision users being unable to identify the product from audio output alone. Also affects image SEO rankings. |
Replace auto-generated alt with human-readable descriptions (“Heritage Flakes Organic Cereal box, front label”). Set Shopify Admin image alt field per product; ensure theme outputs it on both product-media.liquid and collection cards. |
| “Loading…” announced by screen readers | 4.1.3 Status Messages | AA | Placeholder text for the search widget is announced as live content, causing unnecessary screen-reader output. Users with cognitive disabilities also experience confusion when “Loading” persists visibly without context. | Move loading state to an aria-live="polite" region with aria-busy="true" during fetch; clear the region when content arrives. Hide the literal word “Loading…” behind aria-hidden="true" once content has loaded. |
| Country selector rendered 3 times, all keyboard-reachable | 2.4.3 Focus Order | A | Keyboard-only users tab through the country selector three times (header, mobile menu, footer), each with identical options. Creates focus fatigue and disorients assistive-tech users trying to find the primary navigation. | Reduce to 1–2 rendered instances; hide the redundant ones via aria-hidden="true" + tabindex="-1". Use CSS display:none on the viewport where the duplicate would render, not visibility:hidden (the latter keeps focus). |
| Empty cart content persists in DOM when cart is closed | 1.3.1 Info and Relationships | A | “Your bag is empty” content is announced by screen readers even when the cart drawer is not open, creating phantom content. Also adds DOM noise that slows assistive-tech traversal. | Apply aria-hidden="true" to the cart drawer when closed, or conditionally render only when opened. Pairs with the performance task to lazy-render cart drawer (see Performance). |
Common Patterns to Audit Site-Wide
Three pattern-level issues reappear across page types beyond the four documented failures above. These require a site-wide pass rather than individual fixes.
40–49% of product page images lack meaningful alt text (see E-commerce audit). Theme-widget promo images (“Buy 3 save 10%”, “Free shipping”) inherit empty alt; brand logo carousel images on homepage / About page have no alt. Fix strategy: audit per image type (product, promo, brand logo, decorative, hero banner) and apply the right alt pattern per category — descriptive for content images, alt="" for purely decorative. WCAG 1.1.1 applies whether the image is in a PDP or a theme promo block.
Cart drawer updates, Yotpo review-load, Rebuy recommendations, Gorgias chat, and subscription-consent language all change content after first paint with no aria-live announcement. Screen-reader users cannot tell what changed. Pattern fix: wrap each dynamic region in aria-live="polite" (status-like) or aria-live="assertive" (error-like) based on urgency, and pair with role="status" or role="alert". Scope this to theme layer so third-party widgets inherit it.
No visible “Skip to main content” link was observed. Focus order follows DOM order but the announcement bar, sticky header, mobile menu, search, cart, and country-selector all take keyboard focus before the first product appears. Pattern fix: add a visually-hidden-until-focused skip-link as the first tabbable element; ensure main landmark is present on every page; test keyboard-only navigation from landing to checkout on a representative journey (homepage → collection → PDP → cart → checkout). WCAG 2.4.1 Bypass Blocks.
Whisk theme renders lots of <div> nesting where semantic tags would help assistive tech. Collection pages should use <main> + <section> + <nav aria-label="Filters">; product pages should use <article> around the buy-box; blog posts should use <article> with <time datetime="...">. Pattern fix: retrofit the top 5 templates (theme.liquid, sections/main-product.liquid, sections/main-collection-product-grid.liquid, sections/article-template.liquid, snippets/header.liquid) during the schema template refactor (see Schema audit) since both live in the same files.
accessiBe Overlay — Reliance Risk
What this section shows. The legal and technical risk of relying on the accessiBe overlay widget plus the retirement path for replacing it with theme-native accessibility.
Overlay widgets are a liability, not an insurance policy. Courts have rejected the overlay defense in ADA cases; advocacy organisations and the ADA National Network have formally opposed overlay-only compliance. accessiBe is the subject of ongoing US lawsuits. Running an overlay on top of underlying WCAG failures multiplies exposure rather than reducing it.
How to read the callouts. The warning callout names the reliance risk. The info callout names the retirement path: deploy theme-native fixes, re-test with axe-core / Lighthouse / manual screen-reader, then retire the overlay once WCAG 2.1 AA passes on a representative journey. Pairs with the Performance audit since overlay retirement also reclaims 217+114 KB of JS and ∼500ms–1s TBT on product mobile.
Cross-Reference to Other Audits
Several accessibility issues are already captured in other audit dimensions. This section is the canonical accessibility view; the cross-referenced audits handle the work in their respective tracks.
| Issue | Also Appears In | Owning Track |
|---|---|---|
| Collection mobile H1 contrast fails on dark-green hero band | Visual / Mobile — visual-collection-h1-contrast |
Visual |
| Mobile nav touch targets below 48×48 | Visual / Mobile — visual-touch-target-sizes |
Visual |
| Cookie banner blocks keyboard focus / traps screen readers | Visual / Mobile — visual-cookie-banner |
Visual |
| accessiBe overlay load cost | Performance — performance-accessibe-async |
Performance |
| Cart drawer always in DOM | Performance (lazy-render cart drawer) | Performance / Accessibility |
| Product image alt text | E-commerce — ecommerce-image-alt-text |
E-commerce |
Recommended Testing Cadence
What this section shows. A four-tier testing cadence for accessibility: automated every deploy, manual every month, user testing every quarter, and third-party audit every year.
Testing cadence is how accessibility stays accessible. Automated tools catch about a third of WCAG issues; manual keyboard and screen-reader work catches another third; actual assistive-tech users catch the last third. A four-tier cadence covers all three detection modes without turning accessibility into a full-time role.
How to read the list. Each item names the frequency, the tool or participant, and the coverage purpose. The annual third-party audit is the defensibility layer — documentation a certified firm produces is the artifact that holds up in an ADA complaint.
- Automated, every deploy: axe-core or Lighthouse accessibility score on the five key templates (homepage, collection, product, blog, recipe) via CI pipeline. Block deploy on new Level A regressions.
- Manual, monthly: keyboard-only traversal from landing page to checkout on mobile + desktop; screen reader (VoiceOver macOS + NVDA Windows) on the same journey. 30–45 minutes of focused testing catches what automated tools miss.
- User testing, quarterly: paid user testing session with blind or low-vision screen-reader users. Feedback from actual assistive-tech users surfaces ergonomics issues no automated tool detects.
- Third-party audit, annually: formal WCAG 2.1 AA audit by a certified accessibility firm. Provides defensible legal documentation in the event of an ADA complaint.