Skip to main content
Booking must work for everyone, even without a mouse, without a screen and without form-filling experience. That is why accessibility at anny is not a retrofit add-on but part of the components your booking page is built from. Every improvement to an input field, a calendar or a selection menu automatically takes effect on all booking pages. The anny booking page meets WCAG 2.2 Level AA. This page describes what is implemented in detail and also serves as our conformance statement: we tested the booking page against the success criteria of WCAG 2.2 AA and EN 301 549 ourselves, as the BFSG requires.

​
Standards we follow

If you operate a booking page for consumers, you may fall under the BFSG yourself. The section What this means for you as an operator below summarizes what anny provides and what you need to contribute yourself.

​
Keyboard operation

The entire booking flow, selecting a resource, choosing a date and time, configuring options and add-ons, filling in the form, paying, is operable without a mouse. No step requires a click, a hover or a drag gesture. Technically we follow the WAI-ARIA Authoring Practices from the W3C:
  • Roving Tabindex for menus, tabs and selection lists: the arrow keys move focus within the component, Tab leads back out. Nobody gets stuck inside a widget.
  • Combobox pattern for searchable selection fields: you can type and simultaneously navigate through results with the arrow keys.
  • Dialog pattern for modals: focus trap inside the dialog, Escape closes it, focus returns to the trigger afterwards.
  • Visible focus indicator on every focusable element: a 2-pixel border in your accent color, set globally and not disableable.

​
Screen reader operation

Tested with VoiceOver (macOS/iOS) and NVDA (Windows). Structure and orientation
  • Semantic HTML as the foundation: real buttons, real links, real form fields, <nav> and <main> regions. ARIA supplements only where HTML is not enough.
  • Consistent heading hierarchy that allows jumping through pages.
  • Icon buttons without visible text always have a meaningful name, such as “Clear input” instead of “Button”.
Focus as announcement mechanism At every step in the booking process, focus moves to the new heading. The screen reader reads it automatically, including progress: “Choose date (step 2 of 4)”. The step indication is intentionally only exposed to screen readers and does not disturb the visual layout. The same applies to the confirmation page after a successful booking. Status messages For changes where focus should not jump, there is a live region: changed calendar month, updated result count, saved changes, expired session. Urgent messages interrupt, everything else waits for a speech pause, so announcements remain helpful and do not become constant noise. Time slots and calendar
  • Every time slot carries a complete name composed of action, resource, booking option and time, such as “Book: Meeting Room North, Meeting, 14 March 2026, 14:00”.
  • Selected slots announce their state, loading slots announce themselves as busy.
  • The date calendar is a real grid following the W3C pattern: weekday columns with full names, month and year as grid label, selected days marked accordingly. When focusing a cell, the screen reader reads day and weekday, without repeating the full date on every cell.
Forms Labels are programmatically associated with their fields. When validation fails, focus jumps to the first invalid field instead of leaving the user to search for the error message.

​
Booking without mouse and without screen

1

Find a resource

Use Tab to reach the search, enter a search term, navigate through results with the arrow keys. The result count is announced.
2

Choose a booking option

Selection lists open with Enter, the arrow keys navigate, Enter confirms. The selected entry is announced as such.
3

Choose date and time

Navigate in the calendar grid with the arrow keys, Page Up and Page Down switch the month. Available time slots appear as buttons with full labels.
4

Add details

Add-ons, quantities and form fields are standard interactive elements with labels. The cart announces changes via the live region.
5

Complete

After payment, focus moves to the confirmation heading: the booking confirmation is read out immediately.

​
Vision, reading, language

  • Focus indicator with clear contrast on all backgrounds.
  • Zoom up to 200% without layout breakage; the booking page is fully responsive.
  • No blinking or auto-moving content that demands attention.
  • Booking page in over 25 languages, including all EU official languages. Language and time zone are freely adjustable for users, dates and times are formatted according to locale.
If you set custom brand colors, check the contrast: WCAG 2.2 AA requires at least 4.5:1 for normal text and 3:1 for large text and interactive elements. A very light accent green on white may look good in the preview but is unreadable for many users.

​
anny AI: booking by voice

Not every barrier can be solved by a better interface. Some people fundamentally struggle with forms, because of a cognitive impairment, motor limitations, lack of routine with digital applications, or simply because they prefer to speak. With anny AI, we offer a full second channel for that: booking in natural language, by phone or chat.
  • Complete booking in conversation: check availability, name the price, ask for form fields, complete the booking.
  • Manage existing bookings: retrieve appointments and cancel them.
  • Without email address and without an account: for phone bookings, the mobile number is enough; confirmation is sent via SMS.
  • Available around the clock, even outside your business hours.
  • Same rules as online: anny AI checks availability, prices and booking rules in real time against your system. No booking can be created that would not also be possible via the booking page.
anny AI does not replace an accessible interface: both must work, and both do. The voice channel is an additional path, not a workaround.

​
How we test

Accessibility decays if you only establish it once. That is why we test on three levels:
Our development environment checks every component automatically against a set of accessibility rules, including: images need alt texts, buttons need an accessible name, ARIA roles and attributes must be valid, tab orders must not be manually overridden, triggers of selection menus must be real buttons. Violations block deployment. This is supplemented by custom rules written specifically for anny’s recurring component patterns.
New and changed interfaces are tested against a fixed checklist: full keyboard-only operation, testing with VoiceOver and NVDA, logical focus order, visible focus, display at 200% zoom, contrast check, behavior in light and dark appearance. The patterns to apply are documented as binding internal guidelines for our developers, describing per component type which ARIA pattern, keyboard mapping and announcements are required.
The BFSG prescribes a self-assessment procedure: providers test and document the accessibility of their offering themselves; there is no external certification requirement. We tested the anny booking page against the success criteria of WCAG 2.2 AA and EN 301 549. Result: the booking page meets WCAG 2.2 AA. On major product changes we re-test and update this page.

​
Scope of this statement

What this conformance statement covers and what it does not:
  • It applies to the booking page and the customer area, i.e. where your end customers interact. This is the scope relevant under the BFSG.
  • Content you provide, resource descriptions, images, PDF attachments, custom form texts, cannot be made accessible by us technically. You are responsible for those.
  • Content from third parties, such as embedded payment forms or map views, is subject to their accessibility.
Have you encountered a barrier? Report it to support@anny.co with a short description, the affected page and, if known, the assistive technology used. We treat barrier reports with priority.

​
What this means for you as an operator

Since 28 June 2025, the BFSG applies to services in electronic commerce aimed at consumers. Exempt are micro-enterprises with fewer than 10 employees and no more than EUR 2 million annual revenue. Whether you are affected depends on your offering: that is a legal question we cannot answer for you.
For your own accessibility statement you can reference this page to document the status of the booking software you use. The statement itself must come from you and cover your overall offering.

​
FAQ

Yes. The complete booking flow is operable via keyboard and screen reader, from resource search to confirmation. Additionally, they can book by phone via anny AI without using the website.
Yes. The booking page is developed to WCAG 2.2 AA and tested by us. This page is the corresponding conformance statement. If you still encounter a barrier, report it to support@anny.co: we treat such reports with priority.
The BFSG prescribes a self-assessment procedure and does not require an external seal. Our testing against WCAG 2.2 AA and EN 301 549 is exactly that self-assessment. If you need a written conformance statement for a tender, contact us at support@anny.co.
Yes: it is the same application with the same components. On your page, make sure the embed has a meaningful label and that keyboard focus can reach it.
The booking interface in Teams is based on the same components as the web booking page. However, the keyboard and screen reader support of the surrounding client is Microsoft’s responsibility.
For the booking software itself: none. It ships this way. Effort arises with your own content, descriptions, images, documents, and with your accessibility statement.