OXID eShop is neither accessible nor inaccessible on its own. OXID states that its APEX theme is accessible at WCAG level AA, and that is a good start – but your customers see your child theme, the markup your modules add, your product data and your checkout. This page separates what OXID gives you from what stays your job, and names the places to test first.
Does the BFSG apply to your OXID shop?
If you sell to consumers through OXID eShop, 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; details are on our page on the micro-enterprise exemption.
OXID is often used for business customers. A purely B2B shop that only sells to businesses is not a service to consumers. If the same installation also lets consumers buy – a second shop, a public price list with checkout, a B2C sub-shop – treat that side as covered. Scope, market surveillance and the information you have to publish are explained in BFSG for online shops. Comparing platforms? See Shopware and JTL-Shop.
What the platform gives you, and what it does not
You get:
- Twig templates. OXID eShop 7.0 supports the Twig template engine natively, and 7.1 dropped support for Smarty [3]. Every OXID 7 theme is written in Twig.
- APEX as the standard theme. APEX is installed by default [4]. OXID describes it as a Bootstrap 5 based theme for Twig, and each APEX line belongs to a range of OXID compilations – APEX 3.0.x to 7.4.x, for example [5].
- A vendor statement on accessibility. In the release notes for OXID eShop 7.1.0 (April 2024), OXID says it has ensured that APEX is accessible according to WCAG level AA, naming increased contrast, better alt attributes, frames with readable names and screen-reader compatibility [6]. The notes do not say which WCAG version was used.
- Child themes. A child theme inherits from one parent – APEX in OXID's own example – and overrides only the templates you copy into it. There is one layer of inheritance only [7].
You do not get:
- A statement for your theme. The claim covers APEX as shipped. A child theme, a theme from an agency or a theme from the OXID 6 era is not covered.
- Updates to templates you copied. Once a template sits in your child theme, it is loaded from there. When APEX fixes that template, your copy stays as it was [7].
- Accessible modules. Modules extend theme blocks through Twig; OXID's own tutorial adds a button to the mini basket that way [8]. Every module with frontend output brings its own markup.
- A fix from a display toolbar. The 7.1 release notes also present a third-party module that adds an icon for customers to change font size and contrast [6]. A toolbar like that changes the presentation for some users; it does not repair the markup your templates render.
- Useful alt text. Alt text comes from your product data, your ERP or your import. A theme cannot invent it.
What we find on OXID shops
Child themes frozen on an old APEX
A child theme copies the templates it changes – the header, the product box, the basket. From then on those files no longer follow APEX [7]. A shop built on an early APEX version keeps the old header, menu and focus styles wherever they were overridden, however often the parent is updated.
Shops that have not moved to OXID 7
Shops still on OXID 6 run Smarty themes, and those themes were never part of the APEX statement. The move to OXID 7 means rewriting templates in Twig anyway [3]. That is the cheapest moment to fix structure, labels and focus handling.
Modules writing into theme blocks
Modules hook into named Twig blocks. A module that calls parent() keeps the original content and adds its own; one that does not replaces it [8]. That is how a correctly labelled button in APEX gets swapped for an icon without a name.
Variant selection and list filters
Variant selectors that are restyled into tiles are often not reachable with the keyboard and show the selected state only by colour. Filters on category pages reload the list without announcing the number of results, and focus lands at the top of the page or disappears.
Consent banner and floating widgets
The consent tool, chat buttons and assistance toolbars sit on every page. One defect there – focus that does not move into the dialog, a "Reject" link in low contrast, an icon without a name – counts on every URL. Floating buttons can also cover the element that currently has focus.
Checkout, payment modules and business features
Payment providers embed card fields and express buttons as iframes or redirect to their own pages. Iframes without a title, errors listed only at the top of the form and fields without autocomplete are the usual findings. Business features such as login before prices, customer-group checkouts or a CAPTCHA at registration add hurdles that a consumer journey has to pass as well.
Where to look first
| Criterion | Why on OXID | Automation |
|---|---|---|
| 2.1.1 Keyboard (A) | Variant tiles, menus in child themes | Partly automated |
| 2.4.3 Focus Order (A) | Mini basket, filters, consent dialog | Partly automated |
| 2.4.7 Focus Visible (AA) | Focus styles in older child themes | Partly automated |
| 2.4.11 Focus Not Obscured (Minimum) (AA) | Sticky header, floating widgets | Manual only |
| 4.1.2 Name, Role, Value (A) | Module buttons, icon links, toggles | Partly automated |
| 4.1.3 Status Messages (AA) | Add to basket, filter results | Manual only |
| 3.3.1 Error Identification (A) | Checkout and registration errors | Manual only |
| 1.3.5 Identify Input Purpose (AA) | Address and payment fields | Partly automated |
| 1.1.1 Non-text Content (A) | Product images from ERP or import | Partly automated |
| 1.4.3 Contrast (Minimum) (AA) | Brand colours in the child theme, badges | 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
- Write down what you run. OXID compilation, APEX version, child theme or own theme, Twig or still Smarty. That list tells you which vendor statement applies at all.
- Diff the child theme against APEX. List every template your child theme overrides and compare it with the current APEX version. Then scan a staging copy once with plain APEX: whatever disappears came from your overrides.
- Walk the purchase journey with a keyboard. Home → category → filter → product → variant → basket → checkout → payment in test mode, in every shop or language that sells to consumers.
- Inventory modules by block. For each module with frontend output, note which blocks it extends and whether it keeps the original content. Patch, replace or document it as a known limitation, and ask vendors for test evidence rather than a badge.
- Fix product data at the source. Alt texts and variant names belong in the article data, the ERP or the import, not in templates.
- Re-test after every compilation or APEX update. New APEX lines follow new compilations; a scheduled crawl catches regressions before customers report them.
What Reviseberg checks on OXID – and what you still test yourself
Reviseberg crawls your shop, including category and product 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 defect in one overridden template 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, a product 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, sign in 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.
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 OXID module and no connector: nothing is applied to your shop automatically, and we never inject an overlay script.
Written to be useful, not as legal advice. As of 27 September 2026.