Since January 2026, the German federal states’ market surveillance authority has been actively checking whether digital services comply with the requirements of the German Accessibility Strengthening Act (Barrierefreiheitsstärkungsgesetz, BFSG). The law has been in effect since June 28, 2025, and implements the European Accessibility Act into German law. Fines can reach up to €100,000, while competition-law warnings and claims are also possible.
For event teams, the real message is not the fine, but the scope of application. The decisive factor is not the event itself, but the digital conclusion of a contract. As soon as a ticket is sold or paid participation is booked via a website or app, the process falls under electronic commerce – regardless of how accessible the venue itself is.
This shifts the issue into a different department. In many organizations, accessibility used to be a question for facility management or the venue. It is now a question for the team responsible for the registration journey, event website and attendee communication. And in most cases, that question has never been addressed systematically.
The scope: What actually triggers the requirement
Three points clarify most of the questions that arise in an event context.
The trigger is the conclusion of a contract, not the provision of information. A purely informational website without a booking or sales function does not fall under the law. Once the website is designed to prepare or conclude a consumer contract, the situation changes. For event teams, this means that the registration journey, ticketing, payment page and confirmation documents are the relevant areas.
The exemption for micro-enterprises is narrower than many assume. It applies to services if a company has fewer than ten employees and no more than €2 million in annual turnover or balance sheet total. Both conditions must be met. Companies offering products are affected regardless of their size. And what matters is the company concluding the contract, not the event department within it.
The benchmark is WCAG 2.1 at Level AA. This is not a design guideline, but a testable set of criteria: sufficient color contrast, complete keyboard accessibility, meaningful labels for form fields, text alternatives for images, understandable error messages and no information communicated through color alone.
One point that often settles the discussion: B2B events rarely fall cleanly outside the regulation. As soon as individuals can register privately or pay for participation themselves, there is a consumer connection. Checking whether an exemption applies usually takes more time than implementing the most important accessibility criteria.
Five points in the event process where accessibility regularly fails
What stands out is how similar the findings are across different organizations. The same five areas come up again and again.
The registration form. Required fields that are marked as incorrect only by a red border. Date selectors that cannot be operated without a mouse. Placeholder text instead of proper labels that disappears as soon as someone starts typing. A time limit for purchasing a ticket that cannot be extended. These four issues account for a significant share of accessibility problems and can all be addressed when building the form.
Confirmation email and ticket document. HTML emails without a text alternative, tickets provided as image files without readable content, QR codes without a plain-text code displayed alongside them. If someone cannot read the ticket, they cannot verify whether they received the correct one.
Event website and agenda. Program overviews built as tables without proper structure for screen readers. Session titles assigned to tracks exclusively through color. Speaker images without alternative text. Embedded videos without captions.
On-site communication and check-in. Signage with insufficient contrast, check-in terminals positioned at a height that cannot be reached while seated, announcements without a visual equivalent. This point may not fall under the law itself, but it directly affects the experience of the same attendees.
Post-event content. Recordings without captions, presentations provided as scanned PDFs, summaries available only as graphics. The part of the event that remains online the longest is often the least accessible.
How to ask about accessibility needs without making it awkward
The most common wording in registration forms is essentially: “Do you have a disability?” It is legally sensitive, practically unhelpful and uncomfortable for many people to answer.
A better approach is to ask about needs rather than diagnoses. An optional free-text field such as “What do you need to participate comfortably? (e.g. seating close to the stage, captions, a quiet room, dietary requirements)” provides useful answers and is less problematic from a data protection perspective because it does not directly ask for health information.
Three things make the difference between a token question and a functioning process:
- A named person who sees and responds to the requests, with a promised response time of 48 hours.
- Information about what is already available. Writing “Step-free access, induction loop in Hall 1, captions in the livestream, quiet room on the second floor” on the event website anticipates questions and signals that accessibility requirements are being taken seriously.
- A response that is specific. “We have reserved a seat for you in row 2 and informed the admissions team” is an answer. “We’ll take care of it” is not.
Experience from event projects shows that the share of attendees who complete such a field is almost always higher than the team expects – and the vast majority of requests can be solved through organizational measures rather than additional budget.
Where AI reduces the workload in the accessibility process
The value of AI here is not in making the final assessment, but in handling volume. Four applications are particularly useful in day-to-day work.
Alternative text for existing content. An event website with two hundred speaker images, sponsor logos and session graphics can receive draft alt texts in a single run, which are then reviewed and corrected. The workload drops from days to hours. Human review remains necessary because a model does not know which visual information is relevant in the specific context.
Captions and transcripts. Live captions for streams and automated transcripts for recordings are now available at a quality that is sufficient for many formats. Accuracy decreases significantly with specialist terminology, proper names and strong accents or dialects, so a review step should be included before recordings remain permanently available online.
Simplifying language. Creating a shorter and clearer version of an existing event description is a task language models handle well. This does not constitute certified Easy Language, but it can noticeably improve the accessibility of directions, program descriptions and participation terms.
Automated preliminary checks. Contrast ratios, missing form labels, heading hierarchy and missing alt text can be detected automatically. Depending on the tool, such a scan will identify some of the actual issues – but keyboard usability, the clarity of error messages and whether a screen reader can navigate the registration process meaningfully still need to be tested manually.
What AI cannot do: provide legal classification, replace sign language interpretation or decide what level of accessibility a particular event format requires. Drawing that line clearly prevents more problems than adding another layer of automation.
A self-check you can complete in 90 minutes
Before commissioning an audit, it is worth running through a basic check that any event team can complete without specialist knowledge.
- Complete your entire registration journey using only the keyboard. Use Tab, Shift-Tab, Enter and the space bar. If you cannot reach a step, you have identified an issue.
- Set the browser zoom to 200 percent and repeat the process. If elements overlap or a button disappears, you have identified an issue.
- Intentionally leave a required field empty and submit the form. Does an error message appear as text next to the field, or is the error indicated only by color?
- Open the confirmation email in plain-text view. Are the date, location and ticket code readable?
- Listen to the program page using your operating system’s screen-reading function. Does the structure make sense, or do you hear an incomprehensible sequence of numbers and text?
- Check three random images: Is alt text available, and does it meaningfully describe the relevant content?
Anyone who documents these six points will have a solid priority list and a much clearer idea of whether an external audit is necessary or whether internal corrections are sufficient.
Where eventpage.ai comes in
A large share of the problems described above are not caused by a lack of awareness, but by tool fragmentation. Registration in one form tool, the website in a CMS, confirmation emails in an email system and tickets from a fourth provider: every source has its own templates, meaning accessibility has to be implemented and subsequently verified separately in each one.
eventpage.ai brings the event website, registration, ticketing, agenda and attendee communication together in one system. For accessibility, this primarily means that form fields, confirmation documents and program displays follow the same template logic, while accessibility requirements submitted during registration are connected to the same attendee data used for check-in and seating. AI functions can also support the areas where volume becomes an issue: text drafts, alternative text and summaries for post-event content and recordings.
One system does not replace accessibility testing. But it reduces the number of places where the same checks have to be repeated.
Next step: Build accessibility into invitation management
Accessible events do not begin at the entrance. They begin with the first invitation and continue through the event website, registration, confirmation and attendee communication. Treating these steps as one connected process makes it easier to consider accessibility from the start instead of fixing individual touchpoints later.
This is where centralized invitation management becomes relevant: Accessibility information can be communicated before registration, individual requirements can be collected directly in the registration form and then managed alongside the rest of the attendee data. This helps prevent important information from getting lost across separate forms, emails and spreadsheets.
With eventpage.ai, invitations, event pages, registration and attendee communication can be brought together in one system. This does not replace accessibility testing, but it creates a more consistent foundation for an accessible event journey.
Want to see how registration and attendee communication can be managed in one place? Try eventpage.ai for free: https://app.eventpage.ai/sign-up
