Back to Blog
Shopify Dawn Theme Accessibility Issues: Common WCAG Violations and How to Fix Them — featured image

Shopify Dawn Theme Accessibility Issues: Common WCAG Violations and How to Fix Them

Author avatarVijaygopal Balasa
Updated May 3, 2026
8 min read

Test the Actual Dawn-Based Store

Shopify publishes Dawn as an Online Store theme, but a theme name does not determine the accessibility of a live storefront. Version, merchant settings and content, custom Liquid or JavaScript, localization, and app-rendered UI can all change the result. The sections below are patterns to inspect on the actual published store, not a claim that every Dawn installation fails them.

1. Color Contrast Failures (WCAG 1.4.3)

Where to inspect: Configured color schemes, sale or sold-out badges, secondary text, form placeholders, transparent headers, and text over imagery.

The standard: WCAG 1.4.3 requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (18px+ or 14px+ bold).

What to check:

  • Sale price badges (red text on white or light gray)
  • "Sold out" overlays on product cards
  • Secondary navigation links
  • Placeholder text in search and form fields
  • Footer text against dark backgrounds

How to fix it: First check whether the current Theme Editor exposes the relevant foreground and background settings. If not, a scoped CSS-variable or component-style change may be appropriate. Names differ by theme version, so inspect the actual source before editing:

:root {
  --color-foreground: 18, 18, 18;        /* Dark text on light backgrounds */
  --color-secondary-text: 102, 102, 102; /* Ensure 4.5:1 against background */
}

Always verify contrast with a tool like WebAIM's Contrast Checker after making changes.

2. Missing or Unhelpful Alt Text (WCAG 1.1.1)

Where it appears: Product images, collection banners, promotional content blocks, and logo images.

The standard: WCAG 1.1.1 requires all non-decorative images to have text alternatives that convey the same information.

What we commonly find:

  • Product images with alt text like "image1.jpg" or left blank
  • Collection banner images with no alt text or generic descriptions
  • Logo images with alt="logo" instead of the company name
  • Promotional images with text content not reflected in alt text

How to fix it: For product images, add alt text to each image in the Shopify admin product editor. For theme images (banners, promotional blocks), add alt text through the Theme Editor.

For assisted remediation, AccessComply may offer reviewed alt-text candidates for eligible images when the relevant Shopify content path and plan entitlement are supported. A merchant must confirm image purpose and accuracy, and the published theme must be checked to ensure it renders the stored value.

3. Keyboard Navigation Issues (WCAG 2.1.1, 2.1.2)

Where it appears: Cart drawer, mobile navigation hamburger menu, mega menus, and predictive search.

The standard: WCAG 2.1.1 requires all functionality to be operable via keyboard. WCAG 2.1.2 prohibits keyboard traps.

Cart drawer: Test the installed version and any customizations for:

  • Tab focus doesn't move to the cart drawer when it opens
  • Close button isn't the first focusable element after the drawer opens
  • Focus doesn't return to the trigger (cart icon) when the drawer closes

Mobile menu: The hamburger menu needs a logical focus flow:

  • Focus moves into the menu when it opens
  • Tab navigates through all menu items
  • Escape key closes the menu and returns focus to the hamburger button
  • Menu items don't receive focus when the menu is visually hidden

How to fix it: If testing confirms a defect, trace the responsible first-party theme or app code. File names and ownership vary; do not apply a generic focus patch without checking the component's dialog semantics, close behavior, trigger restoration, and mobile states.

4. Icon Buttons Without Accessible Names (WCAG 4.1.2)

Where to inspect: Cart, search, wishlist, social, quantity, and other controls that may be represented only by an icon.

The standard: WCAG 4.1.2 requires all user interface components to have accessible names that can be programmatically determined.

What this looks like:

<!-- Bad: screen reader says "button" -->
<button class="cart-icon-bubble">
  <svg>...</svg>
</button>

<!-- Good: screen reader says "Cart, 2 items" -->
<button class="cart-icon-bubble" aria-label="Cart, 2 items">
  <svg aria-hidden="true">...</svg>
</button>

How to fix it: First inspect the computed accessible name; visible text or aria-labelledby may already provide one. For a truly unnamed icon-only button, an accurate aria-label can be appropriate. For example:

<button aria-label="Decrease quantity for {{ product.title }}">−</button>
<button aria-label="Increase quantity for {{ product.title }}">+</button>

In Liquid templates, you can use the product title variable to make ARIA labels contextually accurate.

5. Form Label Association (WCAG 1.3.1, 3.3.2)

Where it appears: Email capture forms, cart note fields, checkout link fields, product option selectors.

The standard: Form inputs must be programmatically associated with their labels using <label for="..."> and matching id attributes, or using aria-labelledby / aria-label.

Common Dawn pattern (broken):

<!-- These are separate — no association -->
<p class="field__label">Email</p>
<input type="email" class="field__input" placeholder="your@email.com">

Fixed pattern:

<label class="field__label" for="email-input">Email</label>
<input type="email" class="field__input" id="email-input" placeholder="your@email.com">

6. Focus Indicators (WCAG 2.4.7)

Where it appears: Links, buttons, and form fields across the entire theme.

The standard: WCAG 2.4.7 requires keyboard focus to be visible. WCAG 2.4.11 (new in 2.2) requires a minimum focus indicator area.

What to test: Inspect focus visibility against each configured background and in component states. Do not infer a result from the selector or outline thickness alone.

How to fix it: Strengthen focus indicators in assets/base.css:

:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 3px;
  border-radius: 2px;
}

An automated finding may identify a source-mapped focus-style candidate, but the color, area, clipping, and behavior across components still require merchant approval and manual verification.

7. Heading Hierarchy (WCAG 1.3.1)

Where it appears: Blog pages, product pages with rich descriptions, collection pages.

The standard: Heading levels must be used in logical order (H1 → H2 → H3), not skipped for visual styling purposes.

Examples to inspect after content or section customization:

  • Collection page has H1 "Women's Clothing" then jumps to H3 product titles (skipping H2)
  • Blog post sidebar uses H3 headings when H2 would be appropriate
  • Footer sections use H4 or H5 for organization names when H2/H3 is correct

How to fix it: In Liquid templates, change heading tags to the semantically correct level. Use CSS for visual sizing rather than selecting heading tags for their default appearance.

8. Skip Navigation (WCAG 2.4.1)

Where it appears: The very top of the page, only visible on keyboard focus.

The standard: WCAG 2.4.1 requires a mechanism to skip blocks of content that repeat on every page (like navigation).

What to test: Current Dawn releases may include a skip link, but installed versions and customizations differ. Verify that a bypass mechanism is present, becomes visible when appropriate, moves focus to the intended target, and works across representative pages.

How to verify: Tab from the browser address bar to your store. The very first focusable element should be a "Skip to content" link that becomes visible when focused.

How to fix it: Ensure the skip link becomes visible on :focus:

.skip-to-content-link:focus {
  position: fixed;
  top: 10px;
  left: 10px;
  z-index: 9999;
  padding: 0.5rem 1rem;
  background: #000;
  color: #fff;
  text-decoration: none;
}

Running a Scoped Audit on Your Dawn Store

The patterns above are review prompts, and every store's configuration is different. Product catalogs, installed apps, theme customizations, content, and dynamic states all affect the result.

AccessComply's free scanner can report eligible automated findings on public, discoverable pages and states it reaches, with severity and sample locations. Supported, safely source-mapped first-party changes may be offered for merchant approval according to current plan entitlements. Authenticated flows, third-party UI, content meaning, and interaction behavior still require manual or vendor testing; verify current plan details on the pricing page.


Scan your Dawn store now — free, no account required. See automated WCAG-mapped findings and an accessibility score across up to 10 discoverable pages, subject to crawler safety and time limits.

Further Reading

Free scan available

Find the storefront issues holding back growth

Scan SEO, speed, and accessibility by page. Review supported fixes before they run, keep saved originals, and verify the live result afterward.

Vijaygopal Balasa, Founder, AccessComply
Written by

Vijaygopal Balasa

Founder, AccessComply

Founder of AccessComply. Builds tools that find and fix supported Shopify accessibility issues in theme code—not through overlays. Focused on practical WCAG 2.2 AA improvements for merchants.

Keep improving after this fix.

Get concise, practical updates on Shopify SEO, speed, accessibility, and safer storefront changes. No daily noise; unsubscribe anytime.

More on Shopify How-To

See all →