Since the end of June 2025, the Accessibility Strengthening Act (BFSG) has applied to electronic commerce with consumers. The technical benchmark is EN 301 549, which references WCAG 2.1 Level AA. Currently, most "modified" shops meet neither the technical requirements nor the documentation obligations—and the accessibility statement, which is itself a mandatory element, is missing from almost all of them.
This module addresses exactly these issues.
1. Check. At the push of a button, the shop retrieves its own pages and checks them against 26 automated rules: missing alt text, form fields without labels, interactive elements without accessible names, heading hierarchy, landmarks, language attributes, duplicate IDs, table headers, removed focus indicators, color contrast (based on the WCAG formula), and more. Each finding includes a severity level, the relevant WCAG criterion, the location, a context snippet, the resolution status, and a notes field. Additionally, there is an 18-point manual checklist covering aspects that software cannot evaluate. A CSV export serves as the audit log.
The check accesses the shopping cart and checkout via a recording mode: you open the shop once using a time-limited token and click through the ordering process; the module then checks the pages actually served during that session. No test purchases, no simulated shopping carts.
2. Repair. 14 individually toggleable fixes for errors systematically found in standard templates: skip links and landmarks; language attributes; hidden labels for search, newsletter, login, and quantity fields; accessible names for icon buttons; restored focus indicators; keyboard-navigable main menu (arrow keys and Esc); checkout error messages programmatically linked to their respective fields; shopping cart tables with headers; mandatory field indicators; and duplicate IDs.
Each fix has its own toggle—because eventually, a custom modification will conflict with a fix, and you need to be able to disable just that specific one rather than the entire module. Pure JavaScript; no jQuery required. By default, only those fixes that do not alter the shop's visual appearance are enabled.
3. Documentation. A generator for the accessibility statement—including all mandatory BFSGV components—that publishes the statement as a content page in the relevant language at the click of a button. The real trick: outstanding issues identified during the audit are automatically incorporated into the "Non-accessible content" section. This is why the audit tool and the statement generator belong in a single module rather than two separate ones.
It also includes the feedback form required by the regulation, complete with a submission log and deadline tracking—serving as proof of compliance in itself. Spam protection consists of an invisible honeypot field and a time delay; image-based CAPTCHAs were deliberately avoided, as a CAPTCHA on the very form intended for use by people with disabilities would constitute a violation itself.
Additionally, it includes a self-assessment tool for micro-enterprises, complete with a dated result.
What the module explicitly does not do
It does not automatically make the site accessible. A large portion of the requirements relates to content: meaningful alt text, descriptive link text, subtitles, clear language, and the contrast ratios of the custom design. These are decisions that must be made by a human. These are precisely the points covered in the manual checklist—the module tells you exactly what you need to verify yourself.
It is not an overlay widget. There is no pop-up toolbar with contrast or text-to-speech buttons. Such widgets are rejected by disability advocacy groups and are proven not to ensure compliance; in fact, online stores using overlays face lawsuits more frequently in the US than those that do not. A button would be an easier sell—but it wouldn't be honest.
It doesn't sugarcoat the results. The audit reads the HTML source code without executing JavaScript, whereas most fixes operate within the browser. Consequently, the report displays two separate figures: "Open errors" and "Issues mitigated by the module." A mitigated issue hasn't vanished completely; if the fix is disabled, the issue returns. An issue is only permanently resolved when fixed within the template itself. Other providers quietly exclude such issues from their counts, but this module clearly distinguishes between the two.
Technical details, for those interested:
A system module for modified eCommerce, developed and tested against version 3.3.0-r16825; the hook folders and helper functions used also exist in version 2.x. No core files are modified—installation is via FTP followed by a single click in the System Modules section, and the module automatically creates the necessary database schema. It includes fallback selector chains for `tpl_modified_nova`, `nova_server`, `tpl_modified`, `tpl_modified_responsive`, `xtc5`, `bootstrap4`, and `Karl Bootstrap 5`, along with generic entries for unknown child themes.
The audit runs exclusively on your own server and only accesses URLs within your own shop. There are no external services involved and no data leakage.
Uninstalling the module deletes only the configuration settings. The audit history, checklist, explanations, and submitted feedback remain intact—serving as your proof of compliance.
Deutsch
English