Payhip Accessibility Checklist 2026 | WCAG 2.1 AA & EAA
Last updated: 2026-06-18
Payhip is a storefront platform for creators selling digital products, online courses, memberships, and coaching, and it appears on the web in two quite different ways that have different accessibility implications. The first is the hosted Payhip storefront and product pages, where Payhip controls most of the markup and you control the content (product descriptions, images, course lessons, pricing). The second is the embedded buy button or product card that creators drop onto their own website, where Payhip's widget renders inside a page you built on another platform. Accessibility responsibility spans both: shoppers complete a purchase through Payhip's checkout regardless of which entry point they used, and a barrier anywhere along that path can stop a sale and create legal exposure for you as the seller.
On the content side, the recurring issues are familiar: product and cover images published without alt text (a particular problem for digital products whose cover image often carries the title and key selling points as baked-in text), heading structure flattened into styled text in long product descriptions and course lessons, and low-contrast accent colors applied to buttons and links through the store's theme settings. On the platform side, the higher-stakes issues are the checkout and account flows and the embedded buy button: form fields that rely on placeholders, error messages that are not announced, a payment step that must be operable by keyboard and screen reader, and an embedded widget whose buttons need an accessible name and whose modal must trap and return focus correctly. For course sellers there is an additional layer: video lessons need captions and downloadable resources need to be accessible documents. This checklist covers the content you control and the platform behavior you should test, maps each issue to its WCAG 2.1 AA success criterion, and gives a fix you can apply in Payhip's settings or, where the fix lives in the platform itself, an accessible fallback you can provide. It is ordered by impact, leading with checkout and form issues because those sit directly on the path to purchase.
Common Accessibility Issues
The Payhip checkout, discount-code entry, and account forms are the direct path to a completed sale. When fields rely on placeholder text instead of persistent visible labels, or when validation errors are shown only in color or are not announced, screen reader users meet unlabeled inputs and unclear errors at the exact moment they are trying to pay, abandoning the purchase.
Test the full checkout with a screen reader and keyboard before relying on it: confirm each field announces a label, that required fields and errors are conveyed in text and not by color alone, and that the payment step can be completed without a mouse. Where Payhip's hosted fields cannot be altered, keep your own surrounding content (product page, instructions) fully labeled and provide a clear, accessible support contact so a blocked buyer can still complete the purchase another way.
<input type="email" placeholder="Email address"><label for="email">Email address</label>
<input type="email" id="email" autocomplete="email">Digital-product covers on Payhip almost always carry the product title, format, and key selling points as text baked into the image. Published without a text alternative, that information is completely invisible to screen reader users, who cannot tell what the product is or what it includes from the cover alone.
Add descriptive alt text to every product image and cover, transcribing any text that appears in the image (title, format, what is included). For galleries of preview screenshots, describe what each preview shows rather than leaving a filename. Make sure the essential product information also appears as real text in the description, not only inside the cover image.
When you embed a Payhip buy button or product card on your own site, the widget's button must expose an accessible name and the checkout modal it opens must manage focus correctly. Common failures are an icon-only or ambiguously named button, a modal that does not move focus to itself when it opens, and focus that is not trapped inside the modal or returned to the trigger on close, leaving keyboard and screen reader users lost.
Ensure the embed's buy button has a clear accessible name (visible text such as Buy now - Product Name, or an aria-label if the visible text is generic). Test that opening the checkout moves focus into the modal, keeps focus within it while open, closes on Escape, and returns focus to the button afterward. If the embedded modal cannot meet this, link to your hosted Payhip product page as an accessible alternative path to checkout.
Payhip's course and digital-product description editors let you size text freely, so long lessons and product pages end up with section titles styled to look like headings but marked up as ordinary paragraphs, or with skipped heading levels. Learners using a screen reader cannot navigate a lesson by heading and lose the structure of the material.
Use real heading levels in lesson and product content: one H1 for the lesson or page title, H2 for sections, H3 for sub-points, in order. Apply the editor's heading styles rather than just enlarging or bolding text. Break long lessons into clearly headed sections so screen reader and keyboard users can move through them efficiently.
Course sellers on Payhip commonly deliver lessons as embedded video and provide downloadable resources (PDF workbooks, slide decks). Videos without captions exclude deaf and hard-of-hearing learners, and downloadable PDFs that are scanned images or untagged exclude screen reader users, breaking the core value of a paid course.
Provide accurate captions for every course video (uploaded or generated and then corrected), and add a transcript where the audio carries information not shown on screen. Make downloadable resources accessible: use tagged PDFs with real text and a logical reading order rather than scanned images, and give documents headings and alt text. Treat captions and accessible downloads as part of the product, since learners have paid for content they can actually use.
Payhip lets you set a store accent color used on buy buttons, links, and highlights. Creators often choose a brand color that looks good but places white button text or colored link text below the 4.5:1 contrast minimum, making the most important calls to action hard to read for low-vision shoppers.
Check your accent color against the text placed on it with a contrast checker and adjust until button text reaches 4.5:1 and link text against its background does too. If a brand color cannot meet contrast as a button background, darken it for the button or use dark text on a lighter tint. Verify hover and focus states of buttons and links, not only the resting color.
Payhip-Specific Tips
- Payhip reaches shoppers two ways - the hosted storefront and the embedded buy button - and you are responsible for accessibility on both paths to checkout.
- Test the full Payhip checkout with a keyboard and screen reader; it sits directly on the path to a sale, so unlabeled fields or unannounced errors cost real revenue.
- Add alt text to every product cover and transcribe the title and selling points baked into the image, and repeat them as real text in the description.
- For embedded buy buttons, confirm the button has a clear accessible name and that the checkout modal moves, traps, and returns focus correctly; otherwise link to the hosted product page.
- If you sell courses, caption every video, provide transcripts, and deliver downloads as tagged, real-text PDFs rather than scanned images.
- Run your store accent color through a contrast checker so buy buttons and links meet 4.5:1.
Recommended Tools
WAVE Browser Extension
Run it on your Payhip storefront and product pages to catch missing alt text, unlabeled fields, low-contrast buttons, and heading problems in one pass.
WebAIM Contrast Checker
Verify your Payhip store accent color and button text against the 4.5:1 and 3:1 minimums before launching.
axe DevTools
Automated WCAG scanning that flags unlabeled checkout inputs, embedded buy buttons without an accessible name, and skipped heading levels in lessons.
Keyboard-only testing (Tab, Enter, Escape)
Walk the whole purchase path - product page, embedded buy button, checkout modal, payment - with only the keyboard; if you cannot complete a purchase, neither can a keyboard-dependent customer.
NVDA + Firefox / VoiceOver + Safari
Screen-reader testing reveals whether checkout fields announce labels, whether the embedded modal manages focus, and what your product covers convey.
Payhip Accessibility At a Glance
| Plugin / Tool | Area | Common Failure | WCAG | Best Fix |
|---|---|---|---|---|
| Checkout hosted forms | Placeholder fields, silent errors | 3.3.2 | Test path; labels; accessible fallback | |
| Product covers digital products | Text baked in, no alt | 1.1.1 | Alt text; repeat as real text | |
| Embedded buy button widget + modal | No name, focus not trapped | 4.1.2 | Name button; manage focus | |
| Course content videos/downloads | No captions, untagged PDF | 1.2.2 | Caption; tagged real-text docs | |
| Accent color buttons/links | Below 4.5:1 | 1.4.3 | Adjust to 4.5:1 / 3:1 |
Frequently Asked Questions
Am I responsible for accessibility if Payhip hosts my checkout?
In practice, yes. Accessibility law and demand letters focus on whether a visitor can complete a task on your store, not on which company's servers render a particular page. Your customers experience your Payhip storefront, embedded buy button, and checkout as your business, so a barrier in any of them is a barrier on your store. The parts you control directly - product descriptions, images and covers, alt text, heading structure, course content, captions, downloadable resources, and your accent color - are squarely your responsibility and are where most fixable issues live. For the hosted checkout itself, your job is to test it with a keyboard and screen reader, report any blocking issue to Payhip, and meanwhile provide an accessible fallback such as a clearly labeled support contact so a blocked buyer can still complete the purchase. Documenting that you tested and provided a fallback also strengthens your position if a complaint arrives.
Do my Payhip course videos and downloads need to be accessible?
Yes, and for a paid course it is central to the value you are selling, not an extra. Deaf and hard-of-hearing learners need accurate captions on every video lesson, and where the audio carries information not visible on screen they also need a transcript. Learners who use screen readers need your downloadable resources - workbooks, slide decks, checklists - to be real, tagged documents with selectable text, headings, and alt text, rather than scanned images or untagged exports that read as a blank or jumbled page. The practical workflow is to caption videos (auto-generate then correct the errors), keep a transcript alongside lessons that rely on spoken detail, and build downloadable PDFs from real text with a logical reading order. Because your customers have paid specifically to consume this content, an inaccessible lesson is both an exclusion and a refund or complaint risk, so treat captions and accessible downloads as part of finishing the product.
Does the European Accessibility Act apply to a Payhip store?
Very likely, if you sell to consumers in the EU. The European Accessibility Act, in force since June 2025, brings e-commerce and many consumer digital services within scope, and an online store selling digital products, courses, or memberships to EU consumers is the kind of service it targets. There is a limited carve-out for microenterprises providing services, but it is narrower than many sellers assume and should not be relied on without checking your situation. In the US, the ADA applies to businesses selling to the public, and stores with the failures common on Payhip - unlabeled checkout fields, uncaptioned course videos, low-contrast buttons - are the kind that draw demand letters. WCAG 2.1 AA is the practical technical target under both frameworks, so bringing the content you control up to that standard and testing the checkout path is the sound approach regardless of which law applies to you. This is general guidance, not legal advice; consult a qualified attorney about your specific situation.
Further Reading
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.