The European Accessibility Act (EAA) took effect on June 28, 2025. If your Shopify store sells to customers in the European Union, your product pages now need to meet accessibility standards. This is not optional. It is law, and penalties can reach up to 4% of annual revenue or fines up to EUR 100,000 depending on the member state.
The EAA applies to any e-commerce business serving EU customers, regardless of where the business is physically located. If a customer in Germany can buy from your store, the EAA applies to you.
For product pages specifically, this means your variant selectors, color swatches, image galleries, and add-to-cart flows need to work for people using keyboards, screen readers, and assistive technology. Most Shopify swatch apps fail these requirements. Here is what the EAA requires and what you need to check.
In this post
- What the EAA actually requires
- What this means for product pages
- Touch targets: the 44px rule
- ARIA labels for variant selectors
- Keyboard navigation
- Color contrast requirements
- Screen reader support
- Why accessibility overlays do not work
- How Rubik handles accessibility
- Your product page accessibility checklist
- Frequently asked questions
- Related reading
What the EAA actually requires
The European Accessibility Act (Directive 2019/882) sets accessibility requirements for products and services sold in the EU. For e-commerce, it references the EN 301 549 standard, which maps closely to WCAG 2.1 Level AA. If your site meets WCAG 2.1 AA, you are largely covered.
The directive covers the entire purchase journey. Product browsing, product pages, the cart, checkout, and account management. Every interactive element in this flow needs to be accessible.
Enforcement varies by EU member state. Some countries have designated supervisory authorities. Others integrate enforcement into existing consumer protection agencies. The penalties also vary, but the directive requires that they be “effective, proportionate, and dissuasive.” In practice, this means fines that scale with business size.
What this means for product pages
Product pages are where variant selectors live. Color pickers, size selectors, material options. These interactive components are exactly the kind of elements the EAA targets. A sighted customer with a mouse clicks a color swatch and moves on. But a customer navigating by keyboard, or using a screen reader, needs those same swatches to be operable through their assistive technology.
The problem is that most Shopify swatch apps are built entirely for mouse interaction. They render swatches as div elements with click handlers. No keyboard support. No ARIA labels. No focus indicators. They work fine visually but are invisible to assistive technology. Our detailed guide covers every WCAG requirement for Shopify color swatches.
Touch targets: the 44px rule
WCAG 2.5.5 (AAA) recommends interactive elements be at least 44×44 CSS pixels. WCAG 2.5.8 (AA, the standard the EAA references) requires at least 24×24 pixels with adequate spacing. Many swatch apps render tiny 16-20px circles with no padding between them.
Small touch targets are a problem for everyone on mobile, not just users with motor impairments. Fat-finger taps on a 16px swatch frequently hit the wrong color. For jewelry stores showing 8 metal options or fashion stores with 12 colors, cramped swatches create real usability friction.
The fix is straightforward: make swatches at least 24px (ideally 44px) with at least 8px of spacing between them. This gives customers room to tap the right option and satisfies the WCAG requirement. Any swatch app you install should give you control over swatch dimensions.
ARIA labels for variant selectors
A color swatch that shows a blue circle with no text is meaningless to a screen reader. The screen reader sees an unnamed element. The user hears nothing, or worse, hears “button” with no description.
WCAG 1.1.1 requires text alternatives for non-text content. For swatches, this means each swatch element needs an ARIA label like “Select color: Navy Blue” or similar text that a screen reader can announce. The label should include both the option type (Color) and the value (Navy Blue) so the user has full context.
This also applies to image swatches. A swatch showing a product thumbnail still needs a text label. The screen reader cannot describe the image content, so the ARIA label provides the information instead.
Keyboard navigation
WCAG 2.1.1 requires all interactive elements to be operable via keyboard. For variant selectors, this means a customer should be able to Tab to the swatch group, use arrow keys to move between swatches, and press Enter or Space to make a selection.
Most swatch apps fail this completely. They render swatches as div or span elements with no tabindex and no keyboard event listeners. A keyboard user literally cannot interact with them. The variant selector is invisible to keyboard navigation.
WCAG 2.4.7 adds another requirement: a visible focus indicator. When a user tabs to a swatch, there must be a visible outline or ring showing which element has keyboard focus. Many apps suppress the browser’s default focus outline for aesthetic reasons, which breaks this requirement.
Color contrast requirements
WCAG 1.4.11 requires non-text UI components to have at least a 3:1 contrast ratio against adjacent colors. For swatches, this means borders and selection indicators need sufficient contrast against the background. A light gray border on a white background fails.
WCAG 1.4.1 adds a separate requirement: color must not be the only visual means of conveying information. If you show the selected swatch using only a colored border (blue ring around the active swatch), users with color blindness may not see the difference. The selected state needs a non-color indicator too. A checkmark, a thicker border, a different shape, or a text label.
This is particularly relevant for swatch-based selectors versus dropdowns. Dropdowns are naturally accessible (they are native HTML elements). Swatches need extra work to match that accessibility level.
Screen reader support
Screen readers need to understand the structure and state of your variant selector. The swatch group should be announced as a group with a label (“Color options” or “Select color”). Each swatch should announce its value (“Navy Blue”) and its state (“selected” or “not selected”).
When a customer selects a swatch, the screen reader should announce the change. “Navy Blue, selected.” If the gallery updates to show different images, the screen reader should indicate that content has changed, though the gallery update itself is less important than the variant selection announcement.
Proper ARIA roles make this work. The swatch group should have role=”radiogroup” with an aria-label. Each swatch should have role=”radio” with aria-checked indicating the selected state. This follows the WAI-ARIA radio group pattern that screen readers already understand.
Why accessibility overlays do not work
Some store owners install accessibility overlay widgets (like accessiBe or UserWay) and assume the problem is solved. It is not. In April 2025, the US Federal Trade Commission fined accessiBe $1 million for false advertising claims about their overlay’s ability to make sites compliant.
Overlays cannot fix broken HTML structure. If a swatch app renders swatches as div elements with no ARIA labels, no tabindex, and no keyboard handlers, an overlay widget cannot retroactively add those features. The underlying code needs to be accessible. Overlays just add a surface layer that does not address the root issues.
25% of ADA lawsuits in 2024 specifically cited overlay widgets as barriers rather than solutions. For EAA compliance, overlays create a false sense of security. The directive requires the actual product or service to be accessible, not a bolt-on tool that claims to make it accessible.
How Rubik handles accessibility
Rubik Variant Images builds accessibility into the swatch component from the ground up. Here is what is included:
- ARIA labels on every swatch. Each swatch element has an aria-label that includes the option name and value (e.g., “Select color: Navy Blue”). Screen readers announce the full context.
- Keyboard navigation. Customers can Tab to swatch groups and use arrow keys to navigate between options. Enter and Space select a swatch. The full keyboard interaction pattern follows WAI-ARIA guidelines.
- Visible focus indicators. When a swatch receives keyboard focus, a visible ring appears around it. This is not the browser’s default outline, which some themes suppress. Rubik renders its own focus indicator that is always visible.
- Shadow DOM isolation. Rubik renders swatches inside Shadow DOM. This means the swatch styles are isolated from your theme’s CSS. Your theme cannot accidentally break the swatch layout, the focus indicators, or the contrast ratios. The swatches look and behave the same regardless of theme.
- Selected state indicators. The selected swatch uses both color (border) and non-color (checkmark or border weight change) indicators. This satisfies WCAG 1.4.1 for users with color blindness.
- Configurable swatch size. You can set swatch dimensions to meet the 44px touch target recommendation. No coding needed.
- Metafield-based loading. All variant data loads with the page. No external API calls that could delay the variant selector from being interactive. The swatches are available to assistive technology as soon as the page loads.
Most swatch apps treat accessibility as an afterthought or ignore it entirely. Rubik treats it as a core feature. This matters for EAA compliance and it matters for your customers who rely on assistive technology.
Your product page accessibility checklist
Here is a quick audit you can do right now on your product pages:
- Keyboard test. Open your product page and put your mouse away. Can you Tab to each variant selector? Can you select a color using Enter or Space? Can you see which element has focus at all times?
- Screen reader test. Turn on VoiceOver (Mac) or NVDA (Windows). Navigate to your variant selector. Does the screen reader announce each swatch option? Does it announce which one is selected?
- Touch target test. On your phone, try tapping each swatch. Can you hit the right one consistently? Are the swatches large enough that you do not accidentally tap the wrong color?
- Contrast test. Look at your swatch borders and selection indicators. Can you tell which swatch is selected without relying on color alone? Is there a checkmark, border weight change, or other non-color indicator?
- Zoom test. Zoom your browser to 200%. Do the swatches still work? Do they reflow properly? Can you still interact with all variant selectors?
If any of these tests fail, your product pages have accessibility gaps that the EAA could flag. The Rubik Variant Images FAQ covers more technical details about the app’s accessibility implementation.
Watch it in action
See how accessible variant selectors and swatches work on Shopify:
Frequently asked questions
Does the EAA apply to Shopify stores outside the EU?
Yes, if you sell to EU customers. The EAA applies to any e-commerce service available to consumers in the EU, regardless of where the business is headquartered. If a customer in France can place an order on your store, you are expected to meet the accessibility requirements.
What are the penalties for EAA non-compliance?
Penalties vary by EU member state. The directive requires penalties that are “effective, proportionate, and dissuasive.” In practice, fines can reach EUR 100,000 or up to 4% of annual revenue depending on the country. Some member states also allow product removal from the market or service suspension.
Do accessibility overlay widgets make my store EAA compliant?
No. Overlays add a surface layer but cannot fix broken HTML, missing ARIA labels, or absent keyboard handlers. The FTC fined accessiBe $1 million in 2025 for false compliance claims. 25% of ADA lawsuits in 2024 cited overlay widgets as barriers. The EAA requires the underlying product to be accessible, not a bolt-on tool.
Are Shopify’s default variant selectors accessible?
Shopify’s default dropdowns are native HTML select elements, which are inherently accessible. But most merchants replace them with third-party swatch apps that use custom elements without proper accessibility support. If you replaced your dropdowns with a swatch app, check whether that app supports keyboard navigation, ARIA labels, and visible focus indicators.
How does Rubik Variant Images handle EAA accessibility?
Rubik builds accessibility into its swatches: ARIA labels on every swatch, keyboard navigation with arrow keys, visible focus indicators, configurable touch target sizes, non-color selection indicators, and Shadow DOM isolation that prevents theme CSS from breaking accessibility features. It is designed to meet WCAG 2.1 AA requirements out of the box.
