Sellfy Accessibility Checklist 2026 | WCAG 2.2 AA & EAA Compliance
Last updated: 2026-06-11
Sellfy is an all-in-one ecommerce platform built for creators, letting you sell digital downloads, subscriptions, print-on-demand merchandise, and physical products from a hosted storefront with your own domain, or by embedding buy buttons and product widgets on a site you built elsewhere. Because the storefront is template-driven and the checkout is provided by Sellfy, you control less of the markup than on a fully custom store - which is good and bad for accessibility. The good part is that the core checkout flow is maintained by Sellfy, so you are not hand-coding a payment form. The bad part is that the parts you do control - the theme colors, the product copy, the images you upload, and any embedded buttons on your own site - are exactly where the common failures live, and the template gives you no accessibility warnings. Creators routinely pick brand colors that fail contrast, upload product images and cover art with no alt text, and use 'Buy now' on every product so screen reader users cannot tell the buttons apart. The embedded buy button and the cart and checkout that open over your page raise focus-management and labelling questions, product galleries and variant pickers (size, format, color) are often operable by mouse only, and any custom signup or contact form you add tends to lean on placeholder labels. With the European Accessibility Act now enforceable for businesses selling to EU consumers, and ADA Title III claims targeting online stores in the United States, an inaccessible Sellfy storefront is a real legal and revenue risk - customers who cannot complete checkout simply leave. This checklist covers the issues we see most often on Sellfy stores and the specific settings and content practices that fix each one. None of this is legal advice; consult a qualified attorney for your jurisdiction.
Common Accessibility Issues
Sellfy storefront themes let you set brand colors for text, buttons, links, and backgrounds with no contrast feedback. Creators pick colors that look on-brand against the chosen background, so pale body text, low-contrast 'Buy now' buttons, and muted price and label text routinely ship below the 4.5:1 minimum. On a store, low-contrast buttons and prices directly cost sales as well as failing WCAG.
Check every text, link, button, and price color against its background with a contrast checker and correct any below 4.5:1 for normal text or 3:1 for large text and UI components. Pay special attention to the primary buy button, sale and discount badges, and any text placed over banner images. Re-check hover and focus states. Choose theme colors that pass before you launch rather than discovering failures in an audit.
/* Pale button text on a light brand fill - about 2:1, fails */
.buy-button { color: #ffffff; background: #ffd24d; }/* High-contrast button - about 8:1, passes */
.buy-button { color: #ffffff; background: #1f6b3a; }Product thumbnails, gallery images, and digital-product cover art are central to a Sellfy store, but they are frequently uploaded with no alt text, so the theme renders empty or filename-based alt. Screen reader users browsing the storefront hear nothing meaningful about the product, and images that carry text (a course cover, an ebook title graphic, a merch design) convey none of that information.
Provide descriptive alt text for every product image that conveys what the product is - for cover art that contains a title, reproduce that title in the alt. Where the platform does not expose an alt field for a given image slot, ensure the product name appears as real text near the image so the information is not image-only. Mark purely decorative storefront graphics so they render alt="".
<img src="cover_final_v2.png" alt=""> <!-- ebook cover, empty alt --><img src="cover_final_v2.png" alt="Ebook cover: The Freelance Pricing Playbook">On a product grid or a page of embedded buy buttons, every button often reads 'Buy now' or 'Add to cart' with no product context. Screen reader users listing the buttons or links on the page hear the same phrase repeated with no way to tell which product each one buys, failing WCAG 2.4.4 Link Purpose. Icon-only cart buttons sometimes have no accessible name at all.
Make each buy or add-to-cart control distinguishable by its accessible name. Where the visible label must stay short, add an aria-label that includes the product name (for example aria-label="Add The Pricing Playbook to cart"), or ensure the button is programmatically associated with the product heading so assistive tech announces both. For icon-only cart and wishlist buttons, always provide an accessible name.
<button>Buy now</button>
<button>Buy now</button>
<button><svg></svg></button> <!-- cart icon, no name --><button aria-label="Buy The Pricing Playbook">Buy now</button>
<button aria-label="Buy The Freelance Toolkit">Buy now</button>
<button aria-label="View cart"><svg aria-hidden="true"></svg></button>When you embed a Sellfy buy button on your own site, clicking it opens a cart or checkout overlay (often in a modal or iframe) on top of your page. If focus is not moved into that overlay when it opens and returned to the trigger when it closes, keyboard users are left behind the overlay and screen reader users may not be told the checkout opened, so they cannot complete a purchase by keyboard.
Verify that opening the embedded cart or checkout moves keyboard focus into the overlay, traps it there while open, and returns it to the buy button on close, and that Escape closes the overlay. Ensure the overlay container is announced as a dialog with an accessible name. If the embedded widget cannot manage focus correctly, link out to the full hosted Sellfy checkout page instead, where the flow is a normal page navigation.
<!-- Embedded checkout opens in a div with no role, focus left on page -->
<button onclick="openCheckout()">Buy now</button>
<div id="checkout-overlay">...</div><button onclick="openCheckout()">Buy now</button>
<div id="checkout-overlay" role="dialog" aria-modal="true" aria-label="Checkout">...</div>
<!-- JS: move focus in on open, trap it, Escape closes, focus returns to button -->Product image galleries (thumbnail to main-image swapping) and variant pickers for size, format, or color in Sellfy product pages are often built as clickable images or styled divs that respond to mouse clicks but cannot be reached or operated with the keyboard, and color swatches frequently rely on color alone with no text label. Keyboard users cannot change the image or select a variant, and the selected state is not announced.
Ensure gallery thumbnails and variant options are real buttons or inputs that receive keyboard focus and respond to Enter or Space, with a clear visible focus indicator. Give each variant option a text label (not just a color swatch) and convey the selected state to assistive tech (for example with aria-pressed or a checked radio). Test selecting a variant and changing the gallery image using only the keyboard.
<div class="swatch" style="background:#c00" onclick="pick('red')"></div> <!-- color only, no keyboard --><button class="swatch" aria-pressed="false" onclick="pick('red')">
<span class="chip" style="background:#c00" aria-hidden="true"></span> Red
</button>Email-capture, discount-code, and any custom contact forms on a Sellfy storefront commonly render the field name as placeholder text rather than a persistent, associated label, and show validation as a single generic message. The placeholder vanishes on typing, is announced inconsistently, and often fails contrast itself, while an unassociated error leaves screen reader users unsure which field to fix.
Give every field a visible, persistent label associated via for/id rather than a placeholder. Indicate required fields in text, not color alone. Tie each error message to its field with aria-describedby, set aria-invalid on failed fields, and move focus to the first error on a failed submit. For the discount-code field at checkout, make sure its label and any 'invalid code' message are announced to screen readers.
<input type="email" placeholder="Your email" /> <!-- placeholder as label --><label for="sf-email">Your email <abbr title="required">*</abbr></label>
<input id="sf-email" type="email" required aria-required="true" aria-describedby="sf-email-err" />
<span id="sf-email-err" role="alert"></span>Sellfy stores commonly mark sale items, sold-out products, or low-stock warnings with color alone - a red badge, a green 'available' dot - with no text or shape to back it up. Users who are colorblind or who use a screen reader get no equivalent signal, so they miss the discount or do not realise an item is unavailable.
Pair every color-coded status with a text label or icon with an accessible name: 'Sale - 20% off', 'Sold out', 'Only 2 left'. Ensure the badge text itself meets contrast against its background. This keeps the information available to colorblind users and screen reader users and is a low-effort fix that also makes the storefront clearer for everyone.
<span class="badge-red"></span> <!-- red dot meaning 'on sale', no text --><span class="badge">Sale – 20% off</span>Sellfy-Specific Tips
- Check theme colors - especially the buy button, price text, and sale badges - against 4.5:1 and 3:1 before launch; the theme editor gives no contrast warning.
- Add descriptive alt text to every product image and cover-art graphic; for covers with a title baked in, reproduce that title in the alt.
- Give each buy / add-to-cart button an accessible name that includes the product, so screen reader users can tell repeated 'Buy now' buttons apart.
- If you embed buy buttons on your own site, verify the cart/checkout overlay moves focus in on open, traps it, returns it on close, and supports Escape - or link out to the hosted checkout page.
- Make gallery thumbnails and variant pickers real keyboard-operable buttons with text labels and an announced selected state, not mouse-only swatches.
- Back up every color-coded status (sale, sold out, low stock) with text so colorblind and screen reader users get the same information.
Recommended Tools
axe DevTools
Browser extension for automated WCAG testing. Run it on your live Sellfy storefront and product pages to catch low contrast, missing image alt, unlabelled buy buttons, and form-label problems.
WebAIM Contrast Checker
Check your theme's text, button, price, and badge colors against the 4.5:1 and 3:1 minimums, since the Sellfy theme editor offers no contrast feedback of its own.
NVDA + Firefox / VoiceOver + Safari
Screen-reader testing confirms that product names, buy buttons, variant selections, and checkout overlays are announced correctly - especially the embedded cart flow, which automated tools cannot fully judge.
Keyboard-only testing (Tab, Enter, Escape)
Operate the whole purchase flow with the keyboard - browse products, change the gallery image, pick a variant, open the cart, and complete checkout - to expose mouse-only galleries and focus-leaking overlays.
Lighthouse (Chrome DevTools)
Built-in Chrome audit that flags contrast, alt-text, and accessible-name issues on a published Sellfy page. Use it as a first pass, then confirm with manual keyboard and screen-reader testing of the checkout.
Sellfy Accessibility At a Glance
| Plugin / Tool | Area | Common Failure | WCAG | Best Fix |
|---|---|---|---|---|
| Theme Colors buttons, prices | Brand colors below 4.5:1 | 1.4.3 | Pick contrast-safe theme colors | |
| Product Images thumbs, cover art | No alt text on products | 1.1.1 | Descriptive alt; reproduce cover titles | |
| Buy Buttons grid / embeds | Repeated 'Buy now', icon-only | 2.4.4 | Unique accessible name per product | |
| Checkout Overlay embedded buy button | Focus not moved or returned | 2.4.3 | Manage focus or use hosted checkout | |
| Variant Picker size/color/format | Mouse-only; color-only swatches | 2.1.1 | Keyboard buttons with text labels |
Frequently Asked Questions
Is the Sellfy checkout accessible, or is that my responsibility?
The core checkout flow is provided and maintained by Sellfy, so you are not hand-coding the payment form, and the parts Sellfy controls are more likely to be kept reasonable than a custom build. But you are still responsible for the parts you control and for verifying the whole flow works. That means your theme colors (including the buy button and price text), your product images and alt text, your button labels, and - importantly - the behaviour of any buy button you embed on your own site, where the cart and checkout open as an overlay whose focus management you should test. The safest approach is to treat the entire purchase journey as in scope: test browsing, variant selection, adding to cart, and completing checkout with only the keyboard and with a screen reader. If an embedded overlay traps or leaks focus, link customers to the full hosted Sellfy checkout page instead, where it is a normal page navigation.
How do I make repeated 'Buy now' buttons accessible on a Sellfy store?
The problem is that a product grid or a page of embedded buttons gives every button the same visible text - 'Buy now' or 'Add to cart' - so a screen reader user listing the page's buttons hears the same phrase over and over with no way to tell which product each one buys. The fix is to make each button's accessible name unique. Keep the short visible label if you like, but add an aria-label that names the product, such as aria-label="Buy The Pricing Playbook", or make sure the button is programmatically tied to the product's heading so assistive tech announces both together. Do the same for icon-only cart, wishlist, or quick-view buttons, which often have no accessible name at all. This is WCAG 2.4.4 Link Purpose, and it directly affects whether a screen reader user can confidently buy the right product.
Can an inaccessible Sellfy store create legal risk under the EAA or ADA?
Yes. The European Accessibility Act is enforceable for businesses selling to EU consumers, and in the United States ADA Title III claims regularly target online stores whose checkout or product pages are not usable with assistive technology. A Sellfy storefront with low-contrast buttons, unlabelled product images, repeated 'Buy now' buttons, mouse-only variant pickers, or a checkout overlay that keyboard users cannot operate is the kind of barrier these claims and audits focus on - and it also costs you sales, because a customer who cannot complete checkout leaves. The practical defence is the same as the practical fix: meet WCAG 2.2 AA by correcting contrast, adding alt text, giving buttons unique accessible names, making galleries and variant pickers keyboard-operable, using real form labels, and verifying the checkout works by keyboard and screen reader. This is general guidance, not legal advice; consult a qualified attorney about your obligations.
Further Reading
- Accessible Ecommerce Checkout Guide
- Product Variant Swatches Screen Reader Accessibility
- Color Contrast Guide
Other CMS Checklists
Get our free accessibility toolkit
We're building a simple accessibility checker for non-developers. Join the waitlist for early access and a free EAA compliance checklist.
No spam. Unsubscribe anytime.