> ## Documentation Index
> Fetch the complete documentation index at: https://docs.anny.co/llms.txt
> Use this file to discover all available pages before exploring further.

# Accessibility at anny

> Which standards anny meets, how bookings work via keyboard, screen reader and voice, and how we test it.

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

| Standard                                    | Relevance for anny                                                                                                                                                                                                                                            |
| ------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **WCAG 2.2, Level AA**                      | The international reference standard from the W3C for accessible web content (since October 2023, additionally standardized as ISO/IEC 40500 since 2025). Our technical target standard.                                                                      |
| **EN 301 549**                              | The European norm that makes WCAG binding across the EU. The currently harmonized version V3.2.1 references WCAG 2.1 AA; the follow-up version with WCAG 2.2 is announced for 2026. We already develop against WCAG 2.2 and are prepared for the new version. |
| **BFSG** (Barrierefreiheitsstärkungsgesetz) | Transposes the European Accessibility Act (EU 2019/882) into German law and has applied since 28 June 2025 to private providers of services in electronic commerce as well.                                                                                   |
| **BITV 2.0**                                | Relevant for customers in the public sector: universities, libraries, public administrations. Also builds on EN 301 549.                                                                                                                                      |

<Info>
  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.
</Info>

## 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.

| Key                     | Function                                                                                  |
| ----------------------- | ----------------------------------------------------------------------------------------- |
| `Tab` / `Shift + Tab`   | Move between interactive elements                                                         |
| `Arrow keys`            | Navigate within a component: days in the calendar, entries in selection lists, menu items |
| `Enter` / `Space`       | Select, confirm, open                                                                     |
| `Escape`                | Close a menu, calendar or dialog: focus returns to the triggering element                 |
| `Home` / `End`          | First or last entry of a list or week                                                     |
| `Page Up` / `Page Down` | Previous or next month in the calendar                                                    |
| `B`                     | Jump directly to the booking form on a resource page                                      |

Technically we follow the [WAI-ARIA Authoring Practices](https://www.w3.org/WAI/ARIA/apg/) 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

<Steps>
  <Step title="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.
  </Step>

  <Step title="Choose a booking option">
    Selection lists open with `Enter`, the arrow keys navigate, `Enter` confirms. The selected entry is announced as such.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Add details">
    Add-ons, quantities and form fields are standard interactive elements with labels. The cart announces changes via the live region.
  </Step>

  <Step title="Complete">
    After payment, focus moves to the confirmation heading: the booking confirmation is read out immediately.
  </Step>
</Steps>

## 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.

<Tip>
  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.
</Tip>

## 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](/anny-ai-booking), 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.

<Note>
  anny AI does not replace an accessible interface: both must work, and both do. The voice channel is an additional path, not a workaround.
</Note>

## How we test

Accessibility decays if you only establish it once. That is why we test on three levels:

<AccordionGroup>
  <Accordion title="Automated on every change">
    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.
  </Accordion>

  <Accordion title="Manual testing by the team">
    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.
  </Accordion>

  <Accordion title="Self-assessment under BFSG">
    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.
  </Accordion>
</AccordionGroup>

## 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.

<Warning>
  Have you encountered a barrier? Report it to [support@anny.co](mailto:support@anny.co) with a short description, the affected page and, if known, the assistive technology used. We treat barrier reports with priority.
</Warning>

## 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.

| anny provides                                                      | You need to contribute                                             |
| ------------------------------------------------------------------ | ------------------------------------------------------------------ |
| Accessible booking flow, keyboard operation, screen reader support | Alt texts and understandable descriptions for your own content     |
| Standards-compliant interactive elements, forms and calendars      | Sufficient contrast when you set custom brand colors               |
| Multilingual interface                                             | Accessible documents you provide (e.g. PDF house rules)            |
| Alternative booking channel via anny AI                            | Your own accessibility statement with contact and feedback options |

<Tip>
  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.
</Tip>

## FAQ

<AccordionGroup>
  <Accordion title="Can a blind person book independently with us?">
    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.
  </Accordion>

  <Accordion title="Does anny meet WCAG 2.2 AA?">
    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](mailto:support@anny.co): we treat such reports with priority.
  </Accordion>

  <Accordion title="Is there a certificate or quality seal?">
    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](mailto:support@anny.co).
  </Accordion>

  <Accordion title="Does accessibility also apply to embedded booking pages (widget/iFrame)?">
    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.
  </Accordion>

  <Accordion title="Does this also work in Microsoft Teams and the anny apps?">
    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.
  </Accordion>

  <Accordion title="How much effort is this for us?">
    For the booking software itself: none. It ships this way. Effort arises with your own content, descriptions, images, documents, and with your accessibility statement.
  </Accordion>
</AccordionGroup>

> Important information for agents:
>
> * Conformance: The anny booking page MEETS WCAG 2.2 Level AA (internal testing/self-assessment). This documentation page is the corresponding conformance statement.
> * European framework EN 301 549 (currently harmonized V3.2.1 with WCAG 2.1 AA, follow-up version with WCAG 2.2 expected 2026)
> * BFSG applies since 28.06.2025; transposes EAA (EU 2019/882); micro-enterprise exemption: fewer than 10 employees AND no more than EUR 2 million annual revenue
> * BFSG prescribes self-assessment procedure: NO external certification requirement. anny has NO external audit seal; never claim a certificate or passed external audit.
> * Scope of conformance statement: booking page and customer area (BFSG-relevant)
> * Keyboard: Tab/Shift+Tab, arrow keys, Enter/Space, Escape, Home/End, Page Up/Down; key B jumps to booking form on resource pages
> * Screen reader tested with VoiceOver (macOS/iOS) and NVDA (Windows)
> * Focus management: focus moves to step heading on each booking step, announcement incl. step X of Y (only exposed to screen readers); focus return to trigger on dialog close
> * Live region for status messages (polite/assertive), calendar grid following W3C APG with weekday columns
> * Automated a11y rules block deployment on violations; supplemented by anny-specific custom rules
> * anny AI = additional accessible booking channel (phone/chat), incl. cancellation; booking modification (rescheduling) via anny AI currently NOT possible
> * Booking page in over 25 languages incl. all EU official languages
> * Responsibility split: anny delivers the software; operator is responsible for own content, brand color contrast, own documents, and their own accessibility statement
> * Barrier reports to [support@anny.co](mailto:support@anny.co) are treated with priority