# Accessible ticketing (WCAG AA) — MijnEvent Built to WCAG 2.1 AA # Accessible for everyone We believe everyone deserves access to events. That's why WCAG AA accessibility is not an afterthought but a core value of MijnEvent. Short answer ## Is MijnEvent accessible under WCAG? MijnEvent is a Dutch ticketing platform built to WCAG 2.1 level AA. That standard covers the whole platform, not just this website: the public event pages, the checkout, the visitor account, the organiser's management panel and the inspector's check-in app. In practice that means: the entire checkout is operable with a keyboard alone, every interactive element has a visible focus indicator, text meets at least 4.5:1 contrast and interface elements 3:1, every form field has a visible label, error messages sit next to the field with an explanation and a fix, and status messages reach screen readers through ARIA live regions. We also check the contrast of the brand colours an organiser picks. What we do not claim: no external audit has been carried out and no certification has been issued. The status below is a self-assessment against eleven WCAG success criteria, which we link to the W3C row by row so you can check them yourself. Standards ## What we do We build every screen, every button and every form to the WCAG 2.1 AA guidelines. ## Keyboard navigation The entire checkout process is operable with just a keyboard. Logical tab order, visible focus indicators and a skip link to the main content in every part of the platform. ## Color contrast All text meets a minimum 4.5:1 contrast ratio. UI elements and focus indicators meet at least 3:1. We also calculate the contrast of the brand colours organisers pick themselves. ## Screen reader support Semantic HTML, ARIA labels and live regions for error messages and status updates. Designed for screen readers and keyboard navigation, assessed through our own self-assessment against WCAG 2.1 AA — no external audit has been carried out. ## Form labels Every input field has a visible label, descriptive error messages and hint text. Never just a placeholder as a label. ## Touch targets All clickable elements are at least 44x44 pixels. Extra large in the check-in app for field use. ## Error handling Errors appear inline next to the field with clear explanations. Focus automatically moves to the first error field on submission. Against the standard ## Our practice against the standard What we do WCAG 2.1 success criterion Status Full operation with the keyboard alone [2.1.1 Keyboard (level A)](https://www.w3.org/WAI/WCAG22/Understanding/keyboard.html) Visible focus indicator on every interactive element [2.4.7 Focus Visible (level AA)](https://www.w3.org/WAI/WCAG22/Understanding/focus-visible.html) Skip link to the main content, in every part of the platform [2.4.1 Bypass Blocks (level A)](https://www.w3.org/WAI/WCAG22/Understanding/bypass-blocks.html) Semantic HTML and ARIA, so a screen reader gets name, role and value [1.3.1 Info and Relationships (level A)](https://www.w3.org/WAI/WCAG22/Understanding/info-and-relationships.html) · [4.1.2 Name, Role, Value (level A)](https://www.w3.org/WAI/WCAG22/Understanding/name-role-value.html) A visible label on every form field, never just a placeholder [3.3.2 Labels or Instructions (level A)](https://www.w3.org/WAI/WCAG22/Understanding/labels-or-instructions.html) Text contrast of at least 4.5:1, and 3:1 for UI elements [1.4.3 Contrast (Minimum) (level AA)](https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html) · [1.4.11 Non-text Contrast (level AA)](https://www.w3.org/WAI/WCAG22/Understanding/non-text-contrast.html) Error message next to the field, with an explanation and a fix [3.3.1 Error Identification (level A)](https://www.w3.org/WAI/WCAG22/Understanding/error-identification.html) · [3.3.3 Error Suggestion (level AA)](https://www.w3.org/WAI/WCAG22/Understanding/error-suggestion.html) Status messages through ARIA live regions [4.1.3 Status Messages (level AA)](https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html) The success criteria come from the W3C's WCAG 2.1; each one links to the official W3C explanation, which the W3C maintains in the WCAG 2.2 set. "Applied" means: applied according to our own assessment — a self-assessment, not an external audit and not a certification. Last reviewed: July 2026. For comparison, from our own competitor research covering 50 Dutch and international ticketing platforms (reviewed July 2026): 4 platforms publish something about WCAG AA accessibility themselves, 10 confirmed to us on request that they do not meet it, and for the remaining 36 we found nothing about it. That last group only means they publish nothing about it — not that their ticket shop is inaccessible. [See the sources per platform](https://mijnevent.app/en/alternatives). > "Accessibility is not a feature you can toggle on or off. It's a right." — The MijnEvent team Our checklist ## Our WCAG AA checklist - Semantic HTML structure (h1-h6) - Alt text on all images - Visible focus ring on interactive elements - Logical tab order without tabindex > 0 - Labels linked to every form field - Error messages at the field, not just at the top - role="alert" on dynamic error messages - aria-live="polite" on status updates - Buttons for actions, links for navigation - Skip link to main content - Minimum 44x44px touch targets - A focus trap in every dialog, guarded by a test that fails the moment one is added without it Legislation ## What the European Accessibility Act means for you The European Accessibility Act (Directive (EU) 2019/882) has applied since 28 June 2025. It sets accessibility requirements for e-commerce and consumer services, and online ticket sales is such a service. No harmonised standard has been published in the EU Official Journal under the EAA yet, so you demonstrate conformity directly against Annex I of the directive. In practice, WCAG level AA is the benchmark, via EN 301 549. Microenterprises providing a service — fewer than 10 employees and an annual turnover or balance-sheet total of no more than 2 million euro — are exempt under Article 4(5). Above that threshold, the directive reaches your ticket sales too. If you sell through MijnEvent, the ticket shop your visitor buys in is built to WCAG 2.1 AA; what you add yourself, such as your own copy, images and brand colours, remains your own responsibility. [ Read the full explanation of the EAA and ticket sales → ](https://mijnevent.app/en/blog/european-accessibility-act-accessible-ticketing) This is an explanation, not legal advice. What the EAA means for your organisation depends on your size and what you offer. Frequently asked questions ## Questions about accessibility ## Which accessibility level does MijnEvent meet? MijnEvent is built to WCAG 2.1 level AA. That level covers the whole platform: the public event pages and the checkout, the visitor account, the organiser's management panel and the inspector's check-in app. ## Has that WCAG AA conformance been externally audited? No. What you read on this page is a self-assessment against the WCAG 2.1 AA success criteria. No external audit has been carried out and no certification has been issued. We say so explicitly, because a claim without an audit would promise more than we can back up. ## Can I sell tickets for a parade, village fair or festival with MijnEvent? Yes. MijnEvent is built for Dutch organisers of parades, village fairs, festivals and theatre performances, among others. You get your own subdomain, set your own ticket types and prices, and sell through the same accessible ticket shop as every other organiser on the platform. ## Do I still have to do anything about accessibility as an organiser? The platform provides the accessible foundation: keyboard operation, focus indicators, labels, error handling and status messages. What you add is up to you. Write clear event descriptions, give images a meaningful description and pick brand colours with enough contrast — we check that last one for you automatically. ## Does the ticket shop work with a screen reader and without a mouse? That is what it is designed for. The checkout is fully operable with the keyboard, every interactive element has a visible focus indicator, and form labels, error messages and status messages are conveyed to assistive technology semantically and through ARIA live regions. ## I have run into an accessibility problem. What now? Report it through our contact page, telling us which page you hit it on and what you were using. We take such reports seriously and fix what is broken. The accessibility statement also explains how to file a formal complaint. Formal statement ## Our accessibility statement This page shows how we put accessibility into practice. If you want to read the formal, legal statement — covering the WCAG 2.1 AA standard we apply, our compliance status, known limitations and how to file a complaint — see our full accessibility statement. [ Read the accessibility statement ](https://mijnevent.app/en/accessibility-statement) # Together we make events more accessible Have feedback about MijnEvent's accessibility? Let us know. [Contact us](https://mijnevent.app/en/contact) [View features](https://mijnevent.app/en/features)