Does a room booking really fall under the German Accessibility Act?

As a rule, yes. The act covers services in electronic commerce provided to consumers after 28 June 2025 (BFSG). The definition requires a digital service via website or app, provided electronically, at individual request and with a view to concluding a consumer contract (BFSG). A booking form on your own website typically meets those criteria. A purely descriptive page without a booking option is a different case — although it can enter the scope through other routes.

Does the microenterprise exemption apply to a hotel as well?

It applies to services when the business employs fewer than ten people and reaches at most 2 million euros in annual turnover or at most 2 million euros in balance sheet total (BFSG). Both figures have to be calculated rather than estimated, and they change with the headcount. Anyone close to the line should document the current state. Regardless of the duty, describing the building remains a selling point that works without a legal obligation.

We use an embedded booking tool. Who is responsible?

The business remains the service provider, even when the form comes from outside. Section 14 (1) BFSG permits offering only if the requirements are met and the prescribed information has been made publicly available (BFSG). In practice that means: request test results from the provider of the tool, test your own part of the page yourself, and settle responsibility in the contract before the integration goes live.

Is the note “accessible rooms on request” enough?

Typically not. The standard in the act asks for findability and usability without particular difficulty and in principle without external assistance (BFSG), and the regulation asks for information on the accessibility of the service offered, insofar as it exists (BFSGV). Pointing to an enquiry shifts both onto the guest. Measurements on the room page cost time once and answer the question for every future enquiry as well.

Do the room facts have to be written in easy language?

The act asks for understandable language for services, not necessarily for easy language as a separate version. In practice, an additional plainly worded version of the arrival and room description still pays off, because it helps guests with limited German and older guests too. The effort stays small when the facts already exist as short sentences and numbers rather than as advertising copy.

What belongs in the accessibility statement of a hotel?

An account of how the service meets the requirements, and a route for feedback; the act requires the information under Annex 3 no. 1 to be produced and made publicly available (BFSG). It also helps to add the date of the last test, the known limitations with a planned remedy, and a contact option that is actually answered. The statement does not replace the room facts; it sits alongside them.

Accessible Hospitality: Hotel Booking Without Barriers

A guest who uses a wheelchair is looking for a double room with a level-access shower for a weekend in November. The hotel has exactly that room. On the website, a chain of obstacles begins anyway: the calendar only responds to a pointer, the room selection consists of image tiles without names, and under the amenities sits the sentence “accessible rooms on request”. What follows is a phone call on the next working day — or no booking at all. Two things go wrong here, and they belong to two different duties: one concerns the path to the booking, the other concerns what is said about the building. The German Accessibility Act and its implementing regulation treat them separately. Businesses that mix them up typically meet neither.

Key takeaways

The booking flow on your own website is a service in electronic commerce and therefore falls under the German Accessibility Act, which applies to services provided after 28 June 2025 (BFSG).
Next to it stands a second, separate requirement: provide information on the accessibility of the services offered (BFSGV). That is the description of the building, not of the website.
Microenterprises with fewer than ten employees and at most 2 million euros in annual turnover or balance sheet total are exempt from the requirements for services (BFSG).
On 51 percent of the home pages analysed in 2026, form input labels were missing (WebAIM Million) — exactly the component a booking form is built from.
At the end of 2025, a good 7.8 million people with a severe disability lived in Germany; 45 percent of them were aged between 55 and 74 (Destatis) — the age group with time and budget for travel.
An embedded booking tool does not shift the role: the business remains the service provider, and the service may only be offered if the requirements are met (BFSG).

Two duties that hotels regularly confuse

Section 1 (3) of the German Accessibility Act lists the services it covers. Number 5 names services in electronic commerce, and the scope is tied to a date: the act applies to services provided to consumers after 28 June 2025 (BFSG). What counts as such a service is defined in Section 2 no. 26: digital services offered via websites and via applications on mobile devices, provided electronically and at the individual request of a consumer with a view to concluding a consumer contract (BFSG). A room booking that starts on the hotel's own website, settles dates, room type and price there and ends with a confirmation fits that description without detours. Whether payment happens immediately or only at the reception desk typically changes nothing — what matters is the conclusion of the contract, not the moment of payment.

The second duty is not in the act but in the regulation that implements it. Section 19 no. 1 of the implementing regulation requires, for services in electronic commerce, that information on the accessibility of the products offered for sale and of the services provided is made available, insofar as that information is supplied by the responsible economic operator (BFSGV). For a hotel this means: the form has to be operable, and the offer itself has to be described. How wide is the room door, how high is the threshold to the bathroom, how does a guest get from the car park to the lift. These facts are not a marketing question. They are the part of the booking flow that decides the purchase, and the regulation lists them as a requirement of their own alongside operability.

Two levels, one sentence

The first duty concerns the path to the booking, the second concerns its content. A fully operable form that says nothing about steps, door widths and showers meets one and misses the other. A detailed room description that only exists in a document a screen reader cannot read reverses the mistake.

Who is covered: company size and the exemption

Before the technology comes the question of the business itself. Section 3 (1) BFSG sets the standard: products and services are accessible when people with disabilities can find, access and use them in the usual manner, without particular difficulty and in principle without external assistance (BFSG). Subsection 3 exempts microenterprises that offer or provide services from that standard (BFSG). Who counts as a microenterprise is defined in Section 2 no. 17: fewer than ten people employed and either at most 2 million euros in annual turnover or at most 2 million euros in annual balance sheet total (BFSG). A guest house with six rooms and three employees stays below that line, a hotel with forty rooms and fifteen employees does not. The threshold is arithmetic, not judgement — and it is recalculated with every additional seasonal worker. Where the exemption applies and where it ends is described in detail in the article BFSG exemption for microenterprises.

The audience is larger than internal discussions tend to assume. At the end of 2025, a good 7.8 million people with a severe disability lived in Germany, which was 9.4 percent of the population (Destatis). For hospitality, the age distribution is the more interesting part: 45 percent of that group, around 3.5 million people, belonged to the 55 to 74 age bracket, and another 34 percent were 75 or older (Destatis). This is the group with time, with a travel budget and with practice in researching ahead. They rarely book spontaneously; they check first. If the threshold height is missing, the enquiry moves to the next hotel that provides it — and the rejection does not arrive as a complaint in the inbox, it appears as a missing booking in the occupancy list.

Source	What it says	What follows from it
BFSG, Section 1 (3) no. 5	Services in electronic commerce are covered when they are provided to consumers after 28 June 2025	The booking flow on your own website falls under the act
BFSG, Section 2 no. 26	Digital services via websites and apps, electronic, at individual request, with a view to a consumer contract	Enquiry and reservation flows count too when they lead to a contract
BFSG, Section 2 no. 17	Microenterprise: fewer than ten people and at most 2 million euros in turnover or balance sheet total	The headcount decides, not the number of stars
BFSG, Section 3 (1)	Findable, accessible and usable without particular difficulty and in principle without external assistance	„On request“ is the opposite of that standard
BFSG, Section 3 (3)	The standard does not apply to microenterprises that offer or provide services	Small houses stay exempt as long as they remain below the threshold
BFSG, Section 14 (1)	Offering is allowed only if the requirements are met and the information under Annex 3 no. 1 is publicly available	The statement belongs on the website, not in a folder at reception
BFSGV, Section 12 no. 3	Websites and mobile applications must be perceivable, operable, understandable and robust	The standard for the booking form itself
BFSGV, Section 19 no. 1	Provide information on the accessibility of the services offered, insofar as it exists	Describing the building is a requirement in its own right

The table also explains why responsibility inside the business often stays unclear. The two levels sit with different people: the operability of the form belongs to the website and therefore usually to an agency, while the facts about the building belong to reception and facility management. Other sectors know the same split with their own follow-on rules, for example digital health applications whose requirements additionally follow from the German social code — covered in the article Accessible digital health apps. For hotels planning both levels together, the overview accessible tourism collects the typical test points.

The booking flow: where it breaks in practice

A room booking is a form with four peculiarities that set it apart from an ordinary contact form. First, two date fields depend on each other: departure has to be after arrival, and occupancy decides which combination is selectable at all. Second, the price changes while the guest is still typing. Third, a payment step follows with its own fields and its own error patterns. Fourth, the process ends with a confirmation that reports a change of state without the page reloading. Each of these peculiarities has a well-known pattern that goes wrong. The calendar is the most frequent case; the construction matches that of an appointment picker and is walked through with keyboard operation and announcements in the article Accessible appointment booking.

Arrival and departure

A calendar that only responds to pointer clicks shuts out keyboard and screen reader users. The shortest route is a labelled text field with a clear format next to the calendar. The calendar stays as the convenience; it is not the only way in.

Room type and features

Rooms are often chosen through image tiles. Without text inside the control, the choice becomes a row of identical-sounding buttons for a screen reader. Name, size and features belong in the accessible name, not only in the photo.

Guest count and occupancy

A stepper made of two unlabelled icon buttons is tedious with a keyboard and silent for a screen reader. A labelled number field does the same job; the buttons may stay next to it.

Payment and payment errors

Payment fields inherit the error patterns of online retail: errors marked by colour alone, messages far from the field, focus left at the top. The step matches a shop checkout and is tested against the same criteria.

Confirmation and status

The booking confirmation frequently appears without a page change. If it is not exposed as a status message, a screen reader user is left unsure whether the booking went through. Focus belongs on the confirmation.

Hold time and time pressure

Many flows hold the room for only a few minutes. If the timer runs out without warning, the person who types more slowly loses the selection. Extending the time on request is the usual route the guidelines foresee.

That these patterns are the rule rather than the exception is shown by the annual analysis of one million home pages: 95.9 percent of the pages analysed in 2026 had automatically detectable WCAG failures, an average of 56.1 errors per page (WebAIM Million, 2026). Two of the most common error types hit a booking form directly: 51 percent of pages were missing form input labels, and 30.6 percent carried buttons with no content at all (WebAIM Million, 2026). A booking flow consists almost entirely of form fields and icon buttons. The likelihood that your own form carries one of those two patterns is correspondingly high — and both belong to the findings that disappear with manageable effort.

Every field has a visible label that is programmatically tied to the field. Placeholder text does not replace it, because it disappears as soon as typing starts — the patterns are in the article Accessible forms.
Error messages sit in plain words next to the field, name the cause and the remedy, and focus moves to the first field that was rejected.
The payment step follows the same rules as a checkout in online retail; the article Accessible checkout walks through the steps one by one.
Icon buttons carry an accessible name. A plus sign on its own does not say what it increases.
The confirmation is exposed as a status message and receives focus, so that the screen reader reaches the result.
The whole flow is operable by keyboard to the end, without focus getting stuck inside an overlay.

The embedded booking tool is part of it

Few hotels build their own booking form. The common setup is a tool embedded into the page by frame or script that handles availability, prices and payment. From the guest's point of view this is a single process on the hotel's website. Embedding changes nothing about the role: the business remains the service provider. Section 14 (1) BFSG turns that into a prohibition on offering — the service may only be offered if it meets the requirements and if the information under Annex 3 no. 1 has been produced and made publicly available in an accessible form (BFSG). How to test an embedded tool without owning its source code is described in the article Third-party widgets.

Testing belongs in the contract

A tool that is only tested after it has been embedded is expensive to replace. Setting out the test standard, the acceptance procedure and the rights in case of defects in writing beforehand changes the negotiating position. The article Accessibility in the contract shows which clauses make acceptance testable and what applies when a defect only surfaces in live operation.

Describing the building: measurements instead of adjectives

The second duty is worked on less often in hospitality, although it is cheaper to fulfil. Section 19 no. 1 BFSGV ties it to a condition: the information has to be provided insofar as it is supplied by the responsible economic operator (BFSGV). For a hotel, the responsible economic operator is the business itself; whatever is known about the building therefore belongs on the page. The practical core lies in the form. “Accessible room available” is not information, it is an invitation to ask a question. A guest using a wheelchair needs numbers: the clear door width, the height of the threshold, the turning space in the bathroom, the height of the bed. A guest with low vision needs different facts: lighting, contrast in the corridor, tactile labelling at the lift. Someone hard of hearing asks about the doorbell, about the fire alarm and about subtitles in the television programme.

The effort is a one-off and amounts to a few hours per room category: measure, write down, publish. What matters is where the facts sit. They belong on the room page and inside the booking flow, not in a document that has to be downloaded first. Putting them into an image file makes them unreadable for a screen reader. Putting them into a document moves the problem into a file that then has to be tested in turn. As text on the page, the same facts are searchable, translatable, zoomable and visible to search engines — duty and sales point in the same direction for once.

Clear door width of entrance, room and bathroom in centimetres
Height of the thresholds on the way from the entrance to the bed
Dimensions of the shower, type of seat, side of the grab rails
Height of the bed and the sides from which it can be approached
Dimensions of the lift car, height of the control panel, tactile labelling
Route from the car park or the bus stop: length, surface, gradient, door opener
Equipment for guests with hearing or vision impairments: signalling system, contrast, lighting

Three neighbouring topics on the same page

The room description benefits from plain language, because it carries many technical terms — see the article Plain language on the web. The room photos need alternative texts that describe the room rather than the mood, see Accessible images and alt text. And the location map typically becomes the last dead end on the page when it is expected to work without a text alternative; the article Accessible maps shows the ways out.

Statement, feedback and evidence

Section 14 (1) BFSG links offering the service to two conditions: the requirements have to be met, and the information under Annex 3 no. 1 has to be produced and made available to the public in an accessible form (BFSG). What is meant is the accessibility statement, which is frequently missing in hospitality because it gets confused with the description of the building. It is something else: an account of how the service meets the requirements, combined with a route for feedback. Structure, mandatory content and the question of how to run the feedback route day to day are covered in the article Accessibility statement and feedback mechanism. For a hotel with a staffed reception, feedback is usually the easiest part — it only has to reach someone who passes it on.

booking-dates.html

<fieldset>
  <legend>Travel dates</legend>

  <label for="arrival">Arrival (DD.MM.YYYY)</label>
  <input id="arrival" name="arrival" type="text" inputmode="numeric"
         autocomplete="off" aria-describedby="arrival-hint">
  <p id="arrival-hint">Example: 21.11.2026</p>

  <label for="departure">Departure (DD.MM.YYYY)</label>
  <input id="departure" name="departure" type="text" inputmode="numeric"
         autocomplete="off" aria-describedby="departure-hint">
  <p id="departure-hint">Must be after the arrival date</p>

  <!-- The calendar is the convenience, not the only way in -->
  <button type="button" aria-expanded="false" aria-controls="calendar">
    Open calendar
  </button>
  <div id="calendar" hidden>...</div>
</fieldset>

The excerpt shows the point where most booking flows fail. Both date fields are ordinary text fields with a visible label; the format sits in the label and again in a hint tied to the field through aria-describedby. That makes entry work with a keyboard, with speech input and with a screen reader before any script has loaded. The calendar remains, but as an additional route behind a button whose state is reported through aria-expanded. The dependency between the two fields belongs in the error message, not in a silent lock: someone who enters a departure date before the arrival date needs a sentence that says what to change.

room-accessibility.html

<h3 id="room-12-access">Accessibility: room 12</h3>

<dl aria-labelledby="room-12-access">
  <dt>Clear door width, room</dt>
  <dd>92 cm</dd>

  <dt>Threshold to the bathroom</dt>
  <dd>none, level-access shower 120 x 120 cm</dd>

  <dt>Bed</dt>
  <dd>height 48 cm, reachable from both long sides</dd>

  <dt>Lift</dt>
  <dd>car 110 x 140 cm, control panel at 105 cm, tactile labelling</dd>

  <dt>Route from the car park</dt>
  <dd>step-free, 18 m, entrance door with automatic opener</dd>
</dl>

The second excerpt is Section 19 no. 1 implemented in HTML: a description list whose terms and values stay together even when the page is read aloud without styling or magnified heavily. The values in the example stand for the format, not for a particular hotel; every business fills in its own measurements. What matters is that the row is complete: a single figure for the door width helps little when the threshold to the bathroom goes unmentioned. And the list belongs on the room page, not in an appendix — it is part of the decision the guest makes before booking.

Testing instead of assuming

The evidence does not come out of a scanner. Automated checks reliably find the missing field label and the insufficient contrast; whether the occupancy logic is operable by keyboard and whether the confirmation is announced is decided by a manual run. For a single hotel, a morning is usually enough once the route is fixed. Which requirements have to be checked in detail is collected on the page BFSG requirements; the following order has proven itself for booking flows.

Complete one booking entirely by keyboard, from the date selection to the confirmation, without touching the pointer.
Walk the same route with a screen reader and note at which point it stays unclear what to do next.
Magnify the page to twice its size and check whether calendar, price summary and buttons remain fully visible and operable.
Trigger an error on purpose: invalid date, too many guests, incomplete payment. Watch where focus goes and what is announced.
Let the hold time expire and check whether a warning appears and whether the time can be extended.
Separate what sits in your own source code from what sits in the embedded tool; keep both parts apart in the report.
Check the room page for measurements: is every fact on the page as text, or only in an image and a document?
Record the result per component, including the runs without findings, and date the report along with the test environment.

A hotel that leaves out the threshold height sells the guest uncertainty along with the room. The booking that then fails to arrive shows up in no statistic — it is simply one line fewer in the occupancy list.

Test practice in booking flows

The order that pays off

Anyone starting before the winter season takes the booking flow first, because bookings are lost there every week, and the room facts second, because they are collected once and then only maintained. Together the two match the scope of a WCAG audit for a mid-sized hotel — with the difference that the second part consists of a folding rule and half an hour per room category.

Sources and studies

This article is based on data from: the German Accessibility Act (BFSG) with Sections 1, 2, 3 and 14 and the implementing regulation (BFSGV) with Sections 12 and 19, in the versions published on gesetze-im-internet.de (German Federal Ministry of Justice); the severe disability statistics of the Federal Statistical Office as of the end of 2025 according to press release no. 246 of 13 July 2026 (Destatis); the WebAIM Million 2026 analysis of the accessibility of one million home pages (WebAIM).