A plentymarkets shop is neither accessible nor inaccessible on its own. plentymarkets – called PlentyONE since November 2024 [3] – is an ERP first, and its web shop is one sales channel among many. What counts is what that shop renders: the storefront, your theme and plugins, and item data often written for marketplaces rather than your own site. This page separates what PlentyONE gives you from what stays your job, and names the places to test first.
Does the BFSG apply to your plentymarkets shop?
If you sell to consumers through your plentymarkets shop, you provide an e-commerce service – in the words of the law, a "Dienstleistung im elektronischen Geschäftsverkehr" (§ 1(3) no. 5 BFSG). In Germany the Barrierefreiheitsstärkungsgesetz has applied to such services since 28 June 2025. It transposes the European Accessibility Act, so shops selling into other EU countries meet equivalent national laws there [1][2].
Micro-enterprises that provide services are exempt: fewer than 10 employees and an annual turnover or balance sheet total of no more than €2 million (§ 2 no. 17, § 3(3) BFSG) [1]. Both conditions must be met. A purely B2B shop that only sells to business customers is not a service to consumers; if you sell to both, treat the consumer side as covered.
This page is about your own shop. Many plentymarkets merchants also sell on marketplaces; what applies there, and how staff are counted, is on our page on the micro-enterprise exemption. Scope, market surveillance and the information you have to publish are explained in BFSG for online shops. Comparing platforms? See JTL-Shop and Shopware.
What the platform gives you, and what it does not
You get:
- Two storefronts to choose from. The current PlentyONE Shop is built with Vue.js 3, Nuxt 4, Tailwind CSS and Storefront UI 2 [4]; its code is published as a boilerplate on GitHub [5]. The older plentyShop LTS, an open-source template plugin built on Twig and Vue.js [8], still runs many shops. The manual recommends moving from it to the successor, though no end of life has been set [6].
- Accessibility guidance in the manual. PlentyONE's manual has a section on the BFSG. It asks for a contrast ratio of at least 4.5:1 for text, 3:1 for large text and graphics, and explains where to publish accessibility information in both shops (Setup » Shop » [client] » Legal) [7].
- A place for alt text per language. For plentyShop LTS, the manual shows where to enter alternative text for item images – per language, in the image translations – and for files in the file manager [6].
- A vendor statement for plentyShop LTS. The same manual page says the shop can be fully operated with a keyboard and uses ARIA labels [6].
You do not get:
- A statement for your shop. The keyboard statement covers plentyShop LTS as shipped, not your theme, plugins or content, and the manual names no WCAG level for either storefront.
- Accessible plugins. Plugins are installed in a plugin set and often hook into the shop through container links [10]. Each one brings its own markup.
- Protection from your theme. A theme plugin's CSS overrides the plentyShop LTS stylesheet, and a theme can replace the templates of Vue components [9]. Contrast, focus styles and labels are then the theme's.
- Alt text that exists. The field is there; item data maintained for marketplaces often leaves it empty.
What we find on plentymarkets shops
Theme plugins that override more than colours
A theme plugin extends plentyShop LTS through a template container and its own stylesheet, which overrides the classes it touches [9]. A theme that removes the focus outline or sets brand colours below 4.5:1 does it on every page. Themes that replace component templates, such as the single item view, take over that markup completely, labels included.
Plugins in containers
Trust badges, cross-selling, payment logos, reviews, chat and consent tools arrive as plugins linked into containers [10]. Each one renders its own HTML into your header, item page or checkout. An icon link without a name in one container shows up on every page that has that container.
Variation selection and item lists
Items with variations let customers choose attributes such as size or colour. When those are styled as tiles instead of native selects, they are often not reachable with a keyboard and show the selection only by colour. Facet filters reload the list without announcing the number of results.
Item data written for marketplaces
Many plenty merchants maintain item data centrally and send it to marketplaces and the shop at once. Image alternative text, which marketplaces rarely ask for, stays empty – and the shop falls back to nothing or to the file name. Shops that serve several languages also need the alternative text in each language [6], and text passages in another language need to be marked as such.
Basket preview, checkout and payment plugins
After "Add to basket", a preview or overlay opens without moving focus and without a status message. In the checkout, payment plugins embed card fields and express buttons as iframes; without a title and a sensible focus order the purchase ends there. Mandatory checkboxes for terms and cancellation policy need a properly associated label and a clear error message.
Moving to the PlentyONE Shop
The new shop is a different codebase, not a new theme: Vue 3 components and server-side rendering with Nuxt [4]. A migration is the best moment to fix structure and labels, but it brings the typical risks of a JavaScript frontend: page changes without a new title or focus reset, and custom components replacing native form controls. Test it as a new shop.
Where to look first
| Criterion | Why on plentymarkets | Automation |
|---|---|---|
| 1.1.1 Non-text Content (A) | Empty alt text in synced item images | Partly automated |
| 1.4.3 Contrast (Minimum) (AA) | Theme colours, badges | Automated |
| 2.4.7 Focus Visible (AA) | Theme CSS overriding the focus outline | Partly automated |
| 2.1.1 Keyboard (A) | Variation tiles, container plugins | Partly automated |
| 2.4.3 Focus Order (A) | Basket preview, facet filters | Partly automated |
| 4.1.2 Name, Role, Value (A) | Icon links from plugins, replaced components | Partly automated |
| 4.1.3 Status Messages (AA) | Add to basket, filter results | Manual only |
| 3.1.2 Language of Parts (AA) | Multilingual item texts | Partly automated |
| 3.3.1 Error Identification (A) | Checkout errors, mandatory checkboxes | Manual only |
| 1.3.5 Identify Input Purpose (AA) | Address fields in checkout | Partly automated |
"Automated" means a rule can decide the criterion on its own; "partly automated" means a rule finds some failures and a person has to judge the rest. The full list is in WCAG 2.2 AA, criterion by criterion.
A sensible order of work
- Know which shop runs on which client. plentyShop LTS or PlentyONE Shop, which theme, which plugin set. The answer decides whose code a finding is in.
- Isolate the theme. Scan a staging copy once with the plain storefront and no theme plugin. Whatever disappears came from your theme.
- Walk the purchase journey with a keyboard. Home → category → filter → item → variation → basket → checkout → payment in test mode.
- Inventory the plugin set. List every plugin with frontend output and the containers it is linked to. Patch, replace or document each as a known limitation, and ask vendors for test evidence rather than a badge.
- Fix item data at the source. Fill alternative text in the item images, per language, once in the ERP – not page by page – so the shop and every other channel get it.
- Re-test after every plugin or shop update. Payment and theme plugins update often. A scheduled crawl catches regressions before customers report them.
What Reviseberg checks on plentymarkets – and what you still test yourself
Reviseberg crawls your shop, including category and item pages, and runs every axe-core rule on every page at a desktop width of 1280 pixels, then repeats the rules that change with the layout – contrast and target size among them – at 360 pixels. Results are mapped to WCAG 2.2 A/AA and EN 301 549. Findings are grouped into issues by rule and ranked by the points you gain by fixing them, so a theme defect shows up as one issue on 400 pages rather than 400 separate entries. From an account, Reviseberg can also crawl a staging shop behind a password.
The keyboard agent opens the pages of a journey you name – a category page, an item page, the basket – and presses Tab, Shift+Tab and Escape through each of them, recording every step. It reports unreachable elements, lost or invisible focus, missing skip links and keyboard traps. It does not fill in forms or place an order, so the checkout steps behind a full basket and the payment iframe are yours to walk by hand. The free report covers up to 100 pages and runs the keyboard agent on one page you choose.
Missing alt text is found automatically, and Reviseberg can suggest alt text for an image; a person decides, and nothing is written back to your item data. You still test some things yourself: whether alt text actually describes the image, whether error messages make sense, and how the shop behaves with a screen reader and zoom. Screen-reader, zoom and voice-control agents are not built yet; for those criteria the platform gives you guided manual tests, and a criterion nobody has tested is reported as untested, never as passed. There is no plentymarkets plugin and no connector, and we never inject an overlay script.
Written to be useful, not as legal advice. As of 27 September 2026.