In short and in plain language
Many people buy tickets for concerts and plays on the internet. A ticket shop should then be easy for everyone to use. A law says so.
Often the shop shows a plan of the hall. It has many small dots for the seats. People who do not see well can hardly use this plan. So the shop also needs a list. The list shows each seat with its row and number.
Some people need a space for their wheelchair. Some come with a helper. People should be able to book these seats in the shop. They should not have to call.
Often there is only a short time to finish buying. So the shop should ask for the name and the way to pay first. Just before the time runs out, it should warn you. Then you should be able to get more time.
At the end, you get the ticket. All important details should be on it as text: day, time, row and seat. Then a reading program can read them out loud.
A hypothetical example: a concertgoer who shops online with a screen reader wants two tickets for the New Year's concert: one for herself and one for her companion, because her German disability ID card carries the mark B. The ticket shop's seat map is a single graphic, and her screen reader announces "graphic" and nothing else. The companion ticket can only be ordered by phone, and the hotline is closed in the evening. When she finally gets two seats through the automatic seat selection, the reservation expires while she is typing her address. And the e-ticket that eventually arrives by email is an image with a code and no readable text. Concert, theater and New Year's Eve tickets are being bought right now, and the route there often runs online: 31.6 percent of people aged 16 to 74 in Germany bought tickets for events online in the three months before the survey in 2025 (Eurostat). This article shows how a ticket shop solves the critical points: a seat map with an equivalent seat list, bookable wheelchair and companion seats, discounts and proof in the order flow, a fair time window and an e-ticket that can be read.
Key takeaways
- Selling concert or theater tickets online to consumers is a service in electronic commerce; since June 28, 2025 the BFSG applies to it, with microenterprises exempt (BFSG, § 1 para. 3 no. 5).
- A seat map drawn as a graphic needs an equivalent seat list with row, seat, category and feature; every selectable seat carries a name that describes its purpose (W3C, Understanding SC 1.1.1).
- Seat symbols smaller than 24 × 24 CSS pixels are acceptable when a different control on the same page offers the same function at sufficient size, such as the seat list (W3C, Understanding SC 2.5.8).
- Wheelchair space and companion seat belong in the shop as a bookable pair; the mark B proves the entitlement to bring a companion (SchwbAwV, § 3 para. 2), and checking it at the door keeps data to a minimum.
- A two-minute reservation window can be essential; name and payment method then belong before the time window, as the W3C describes for a ticket shop (W3C, Understanding SC 2.2.1).
- The e-ticket states event, date, entry time, row and seat as text, the entry code gets alternative text that names its purpose, and the PDF is tagged.
Why the ticket shop falls under the BFSG
Section 1(3) of the BFSG lists the services it covers when they are provided to consumers after June 28, 2025. Number 5 is services in electronic commerce (BFSG, § 1 para. 3 no. 5). These are digital services offered via websites and apps and provided electronically at the individual request of a consumer with a view to concluding a consumer contract (BFSG, § 2 no. 26). A ticket shop in which private customers choose seats and pay usually meets these criteria, whether a concert promoter, a private theater or a cultural association runs it. An overview of all obligations is on the page about BFSG requirements.
Microenterprises that offer or provide services are exempt (BFSG, § 3 para. 3). A microenterprise employs fewer than ten people and has either an annual turnover of no more than 2 million euros or an annual balance sheet total of no more than 2 million euros (BFSG, § 2 no. 17). A small stage with its own box office can fall under this, a concert agency with ten or more employees cannot. The details, including groups and associations, are in the article on the microenterprise exemption.
One distinction matters for travel tickets. Electronic tickets and ticketing services in air, bus, rail and waterborne transport are a separate case in the law (BFSG, § 1 para. 3 no. 2), and for these passenger transport services the ordinance additionally requires, among other things, information on smart ticketing such as electronic reservation and booking of tickets (BFSGV, § 15). What applies there in detail is explained in the article on information duties in passenger transport. Concert, theater, sports and cinema tickets remain electronic commerce.
For electronic commerce, the ordinance sets additional requirements, two of which are central for a ticket shop. Information on the accessibility of the products and services offered must be provided insofar as the responsible economic operator makes it available (BFSGV, § 19). And identification, authentication, security and payment functions must be perceivable, operable, understandable and robust (BFSGV, § 19). For a ticket shop it is reasonable to read the first requirement as covering the organizer's details on wheelchair spaces, step-free access or hearing systems. The second concerns login and checkout, even when they come from a different provider than the seat map.
The seat map needs an equivalent seat list
The seat map is the heart of the ticket shop and at the same time its biggest barrier. It usually consists of a graphic or a canvas with hundreds of small symbols whose meaning depends only on color and position. People who cannot see find nothing in it without a text alternative. People with limited fine motor control can barely hit the tiny targets. And people who have trouble telling colors apart see a pattern without meaning.
WebAIM's tenth screen reader survey shows that such patterns get in the way: among twelve problem areas, screen reader users rank lack of keyboard accessibility fifth and missing or improper image descriptions sixth (WebAIM Screen Reader User Survey #10). The survey ran in December 2023 and January 2024 with 1,539 valid responses; the sample was not controlled and does not represent all screen reader users (WebAIM Screen Reader User Survey #10). Missing alternative text is still widespread: 53.1 percent of the home pages of the top one million websites had images without alternative text (WebAIM Million 2026).
Every seat needs a name
In its Understanding document for success criterion 1.1.1, the W3C describes a related case: an image of a building floor plan is interactive, and the user selects a room to reach a page with information about it (W3C, Understanding SC 1.1.1). The short text alternative there describes the image and its interactive purpose. For controls the criterion states: if non-text content is a control or accepts user input, it has a name that describes its purpose (W3C, Understanding SC 1.1.1). Applied to the seat map, this means the map as a whole gets a description such as "Seat map, main hall, orchestra and balcony, choose seats", and every selectable seat a name such as "Orchestra left, row 7, seat 12, category 2, available".
In a large hall, names alone are not enough. Anyone who steps through hundreds of seats one by one with a screen reader loses track. That is why an equivalent seat list belongs next to the map: a table with section, row, seat, category, price and features such as "wheelchair space", "companion seat", "restricted view" or "aisle", filterable by number of seats, price and feature. The list is not a fallback but often the faster route for everyone who searches by price or access rather than by location. Its table structure has to exist in the code, not just visually: information, structure and relationships conveyed through presentation must be programmatically determinable or available in text (W3C, Understanding SC 1.3.1). Column headers are real header cells, so the screen reader names the column for every value.
A third route complements both: automatic seat selection. Anyone who asks for "two seats, category 2, side by side" and accepts the suggestion does not need the map at all. What matters is that the suggestion then names the seats in plain text and can be changed, instead of only lighting up on the map. The same principle works for store locators, where the result list is the real text alternative to the map.
A ticket shop should not rely on the exemption for online maps. It only applies insofar as essential information for maps intended for navigation is provided in an accessible digital form (BFSG, § 1 para. 4 no. 3). A seat map is used to choose what is being bought, not to navigate, and even under the wording of the exemption the road leads back to an accessible list of the essential information.
Color, contrast and size of seat symbols
Some seat maps distinguish category and availability by color alone: purple for category 1, light blue for category 2, gray for taken. But color must not be the only visual means of conveying information or distinguishing a visual element (W3C, Understanding SC 1.4.1). Shape and markers solve this: taken seats crossed out, selected seats filled with a check mark, wheelchair spaces with their own marker and a legend that explains every marking in words. The W3C gives the example of a graphic in which color and number together identify an element; anyone who cannot tell the colors apart understands the image through the numbers (W3C, Understanding SC 1.4.1).
Symbols and their states need a contrast ratio of at least 3:1 against adjacent colors (W3C, Understanding SC 1.4.11). A pale gray taken seat on a white background quickly falls short, and the difference between "available" and "selected" must not lie in a shade that is barely darker than the background.
When it comes to size, the exceptions in success criterion 2.5.8 help. Pointer targets must be at least 24 × 24 CSS pixels (W3C, Understanding SC 2.5.8). In a dense seat map, seat symbols are often smaller. The criterion allows this when the same function can be achieved through a different control on the same page that meets the size (W3C, Understanding SC 2.5.8). For maps with densely placed markers, the W3C also names the "essential" exception and, for that case, strongly encourages offering the function through alternative means as far as practical (W3C, Understanding SC 2.5.8). Both lead to the same result: the seat list with sufficiently large selection controls is how the seat map meets the requirement.
Keyboard, zoom and panning
All functionality must be operable through a keyboard (W3C, Understanding SC 2.1.1). For a seat map, the grid pattern described in the ARIA Authoring Practices is a good fit: a container in which users move with the arrow keys, Home and End (W3C, ARIA Authoring Practices Guide). Instead of jumping through hundreds of tab stops, focus enters the map with one Tab and moves from seat to seat with the arrow keys; the space bar selects. Every selection is announced as a status message without moving focus, for example "Row 7, seat 12 selected, 2 of 2 seats" (W3C, Understanding SC 4.1.3). The W3C illustrates this kind of message with a shopping cart next to whose icon the text "5 items" appears after an item is added and is announced (W3C, Understanding SC 4.1.3).
If a map can only be panned by dragging, it needs an alternative. Functionality that uses a dragging movement must also be achievable with a single pointer without dragging; the W3C gives the example of a map that can be dragged and also has buttons to move the view up, down, left and right (W3C, Understanding SC 2.5.7). When zooming in, content must be presentable at a width of 320 CSS pixels without loss and without scrolling in two dimensions (W3C, Understanding SC 1.4.10). Maps and diagrams are exempt because they need a two-dimensional layout (W3C, Understanding SC 1.4.10). The map itself may therefore scroll sideways; the W3C names the same exception for data tables as a whole, though not for individual cells (W3C, Understanding SC 1.4.10). The filters, cart and notes next to it, on the other hand, have to reflow, and a seat list with a few short columns stays readable on a narrow screen without sideways scrolling.
The following overview maps the typical errors in seat maps to the WCAG 2.2 success criteria, each with its conformance level (W3C).
| Element | Typical error | Criterion | Solution |
|---|---|---|---|
| Map as a whole | graphic without description | 1.1.1 (A) | short description with purpose, seat list next to it |
| Single seat | no name, color only | 1.1.1 (A) | name with section, row, seat, category and status |
| Seat list | table only in the visual layout | 1.3.1 (A) | real column headers and rows |
| Category and status | only color tells them apart | 1.4.1 (A) | shape, markers and a legend in words |
| Seat symbol | pale gray on white | 1.4.11 (AA) | at least 3:1 against adjacent colors |
| Seat symbol | smaller than 24 × 24 CSS pixels | 2.5.8 (AA) | equivalent seat list with large targets |
| Operation | mouse only | 2.1.1 (A) | grid with arrow keys, space bar selects |
| Panning | dragging only | 2.5.7 (AA) | buttons for panning and zooming |
| Selection | change without announcement | 4.1.3 (AA) | status message with row, seat and count |
Wheelchair space and companion seat as a bookable pair
Wheelchair spaces sit in fixed places in the hall, and there are only a limited number of them. If they cannot be booked in the ticket shop and are only available through a form or a hotline, a second, slower route is created for exactly the people to whom the law is meant to give easier access. Services are accessible when people with disabilities can find, access and use them in the usual way, without particular difficulty and in principle without outside help (BFSG, § 3 para. 1). A hotline as the only route also excludes deaf and hard of hearing people if there is no written channel. What applies to hotline, chat and contact channels is described in the article on accessible customer service.
A bookable pair works better. The wheelchair space appears in the map and the list as its own type with text, and the seat next to it is labeled as a companion seat that is suggested, but not forced, when the wheelchair space is chosen. Not every wheelchair user comes with a companion. For the mark B, the law even states explicitly that the finding does not mean the severely disabled person is a danger to themselves or others when not accompanied (SGB IX, § 229 para. 2). A shop should therefore not sell wheelchair spaces only as a bundle with a companion ticket, and conversely should not tie companion tickets to wheelchair spaces.
Seat selection needs the details that make a decision possible in the first place: step-free route to the seating area, location of elevator and accessible restroom, view from this seat, hearing system or induction loop, admission of an assistance dog. If the organizer supplies such details, § 19 BFSGV speaks for providing them in the shop (BFSGV, § 19). They help most where the decision is made: at the seat in the map and the list, not in a PDF in the footer.
Wheelchair space
Its own seat type in the map and the list, with text instead of a symbol only, bookable online like any other seat and with details on access, elevator and view.
Companion seat
Right next to it, suggested when the wheelchair space is chosen but not forced. Ticket type and condition appear as text at the seat.
Second channel
Phone, email or chat for questions still make sense, but as an addition to online booking, not as the only route to the wheelchair space.
Discounts and the mark B in the order flow
The mark B appears on the front of the German disability ID card together with the sentence "The entitlement to bring a companion has been proven" (SchwbAwV, § 3 para. 2). Entitled are severely disabled people who, as a result of their disability, regularly need help when using public transport (SGB IX, § 229 para. 2). By law, the mark is linked to free carriage of the companion on public transport (SGB IX, § 228 para. 6). For concert and theater tickets, neither the BFSG nor the SchwbAwV contains a rule on companion tickets. Whether there is one, at what price and with what proof, is set by the organizer in its terms.
If an organizer offers a companion ticket or a discount for severely disabled people, it belongs in the normal order flow and not in a footnote with a phone number. In practice this means: the discount is its own ticket type with a visible label, the condition sits next to it as text, for example "Proof: disability ID card with mark B, shown at the door", and selection fields for ticket type and quantity have programmatically associated labels. If an entry is missing, the error message names the field and how to fix it. How fields, required entries and error messages are built accessibly is covered in the article on accessible forms.
When it comes to proof, restraint pays off. Data concerning health is personal data related to the physical or mental health of a person that reveals information about their health status (GDPR, Art. 4 no. 15). An uploaded photo of the disability ID card with degree of disability and marks will generally fall under this definition, and processing health data is prohibited in principle unless one of the exceptions applies (GDPR, Art. 9 para. 1). On top of that comes the principle of data minimization: data must be limited to what is necessary for the purposes of processing (GDPR, Art. 5 para. 1 lit. c). Showing the card at the door serves the same purpose without the shop storing a copy. Anyone who still wants to check online should clarify this with their data protection advisor before launch.
Ticket type instead of ID upload
The time window: details before the reservation
As soon as seats are in the cart, the shop holds them for a limited time. That is a time limit within the meaning of success criterion 2.2.1. The W3C even uses the ticket shop as an example in its Understanding document: a website gives two minutes to confirm the purchase before the seats are returned to the general pool (W3C, Understanding SC 2.2.1). Because tickets can sell out quickly and holding them longer may change the nature of the offer, the time limit counts as essential in this example (W3C, Understanding SC 2.2.1).
The next sentence of the example is the remarkable one: the website moves as much as possible out of the time-critical phase and lets users provide their name and payment method, for instance, before that phase begins (W3C, Understanding SC 2.2.1). For the order flow this means login or guest details, billing address, payment method and ticket type come before the reservation, and only confirming the seats remains inside the time window. How the warning before expiry, focus and announcement of the extension are built when the time limit is not essential is covered in the article on countdowns, timers and cart reservations.
People with disabilities such as blindness, low vision, dexterity impairments or cognitive limitations may need more time to read content or fill out forms (W3C, Understanding SC 2.2.1). In a ticket shop this applies especially to choosing seats. The clock should therefore start only once the seats are fixed, not when the map opens. How such flows can be simplified further for people with cognitive disabilities is shown in the article on cognitive accessibility beyond WCAG.
The e-ticket as text, not as an image
At the end of the purchase comes the ticket, and that is where accessibility ends abruptly in some shops. If the ticket PDF consists only of an image with logo, event photo, code and rasterized details, a screen reader reads nothing aloud, zooming makes the type blurry, and anyone who wants to show the ticket at the entrance cannot find out which day it is valid for.
An accessible e-ticket separates what people read from what machines read. Event, date, time, entry time, venue, section, row, seat, ticket type and ticket number appear as real text, with a heading and in a sensible order. The entry code is non-text content, and all non-text content needs a text alternative that serves the equivalent purpose (W3C, Understanding SC 1.1.1). For the code this means alternative text such as "Entry code for row 5, seat 1, scanned at the entrance". The ticket number as text lets staff check the ticket by hand if necessary.
The notes around the ticket belong in text form as well. For information about how a service works, the ordinance requires, among other things, that it be provided via more than one sensory channel (BFSGV, § 12 no. 2) and that an alternative presentation be offered where non-text content is included (BFSGV, § 12 no. 2). A sentence such as "Print the ticket or show it on your phone, entry from 5:15 pm via the north entrance" therefore appears as text in the email and on the ticket, not only as a pictogram.
Suitable formats are an HTML version in the customer account or the confirmation email and a tagged PDF with reading order, document language and alternative text. How a PDF has to be structured for this is explained in the article on accessible PDFs. If the ticket is also issued in an app or as a pass for the phone's wallet app, the requirements for mobile applications apply to the app; the article on accessible apps summarizes them.
- Event, date, time and entry time as text with a heading
- Venue, section, row and seat in the order needed at the entrance
- Ticket type with its condition, for example "companion ticket, proof at the door"
- Entry code with alternative text that names its purpose
- Ticket number as text for checking by hand
- Tagged PDF with document language, plus an HTML version in the email or customer account
Test procedure for the ticket shop
Automated tests find only part of the problems in a ticket shop. All automated tools have limitations, and not all conformance failures can be detected automatically (WebAIM Million 2026). Whether a seat map works by keyboard, whether the selection is announced and whether the warning before expiry comes in time can only be shown by a manual run. These eight steps cover the order flow:
- To the seat without a mouse: Tab into the seat map, move through rows and seats with the arrow keys, select with the space bar. Every stop must have visible focus.
- To the seat with a screen reader: listen to the names of map and seat, go through the seat list with table navigation and check whether the selection is announced.
- Without color: view the map in grayscale. Category, status and wheelchair space must be recognizable without color, and the legend explains them in words.
- Zoomed in: zoom the browser to 400 percent, which at a window width of 1,280 CSS pixels equals a width of 320 CSS pixels (W3C, Understanding SC 1.4.10). Filters, cart and notes must not scroll sideways; the exceptions are the map and, at most, the seat list as a data table.
- Wheelchair and companion seat: book a wheelchair space with a companion seat, without phone and without a form outside the shop.
- Discount: choose the ticket type for the companion, read the condition, trigger an error message and have it read aloud.
- Time window: check whether name and payment method are requested before the reservation, then wait for the warning. The warning must be announced, and extending must work with one action.
- E-ticket: open the PDF and the email with a screen reader. Date, entry time, row and seat must be read aloud, and the code has alternative text.
The test question for every ticket shop
Before the season, a WCAG audit of the entire order flow and a screen reader test make sense, ideally with a real event in the test system and all ticket types that will later be sold.
Embedded ticketing systems and the information duty
If an organizer does not run the ticket shop itself but embeds a ticketing provider's system, nothing changes for visitors: they click "Buy tickets" and land on the seat map, regardless of whose server it is on. That is why the embedded system belongs in every test of the order flow, just like a hotel's booking tool. Who bears which obligation depends on who offers the consumer contract. That belongs in the contract with the provider, together with a commitment on accessibility, access to test reports and deadlines for fixes.
Then there is the information duty. The service provider may only offer its service if it has prepared the information under Annex 3 and made it available to the public in an accessible form (BFSG, § 14 para. 1). Under Annex 3, it states in its general terms and conditions or in another clearly perceptible way how the service meets the accessibility requirements, naming among other things the competent market surveillance authority (BFSG, Annex 3). For the ticket shop this means describing how seat map, seat list and time window can be operated, how wheelchair and companion seats are booked and in which formats the e-ticket is delivered. How such a statement is documented and kept up to date is shown on the page about the accessibility statement.
An accessible ticket shop is therefore not a special build but an order flow with three equivalent routes to a seat, clearly labeled ticket types, a time window that only starts once the seats are fixed, and a ticket that can be read aloud. Once these building blocks are in place, they serve every season that follows.
Sources
Related Articles
Select Menus Without Surprises: WCAG 3.2.2 On Input
WCAG 3.2.2 in online stores: why sort, language and variant menus must not reload on the first arrow key, and how an Apply button and a keyboard test fix that.
BFSG Self-Check: What Site Owners Can Test Without Tools
Eight browser checks with no extra software: keyboard, zoom, images, title, headings, contrast, forms and video, plus where a self-check reaches its limit.
Accessible Promo Banners: Keep Text Out of the Image
Promo banners with discount text baked into the image fail WCAG 1.4.5. How shops build banners as HTML text, apply the exceptions and test before Black Week.