Accessibility Statement

Last reviewed: April 26, 2026 Effective date: April 26, 2026

Our commitment

Reservly is committed to making its platform usable by the widest possible audience, including people who rely on assistive technology such as screen readers, keyboard-only navigation, voice input, switch access, screen magnifiers, or high-contrast display modes.

We target WCAG 2.1 Level AA as our conformance standard. We have not yet undergone an independent third-party audit; our claim is substantial conformance with ongoing improvement — we do not claim full WCAG 2.1 AA conformance. We are working to close the gaps listed below.

What Reservly covers in this statement

This statement covers:

• Reservly's marketing site — reservly.io (landing page, pricing, docs, legal pages)
• Reservly's business dashboard — the management interface used by businesses who subscribe to Reservly
• Customer-facing public booking pages — the pages hosted at reservly.io/{business-name} that end customers use to make reservations
• Transactional emails — booking confirmations, reminders, and notifications sent by Reservly on behalf of businesses

Business-controlled content: Businesses using Reservly upload their own service descriptions, images, logos, and PDF documents. Reservly provides tools and encourages accessible content, but we cannot guarantee the accessibility of third-party content uploaded by businesses. If you encounter an inaccessible image or document on a business's booking page, please contact us and we will relay the issue to the business.

Standards we target

We monitor WCAG 2.2, which was published in October 2023 and adds nine new success criteria. We are progressively addressing the WCAG 2.2 AA criteria and will update our conformance claim when they are met.

Accessibility features we provide

• Semantic HTML. Pages use proper HTML elements — headings (h1→h2→h3), landmark regions (<main>, <nav>, <header>, <footer>), lists, and form labels — so assistive technology can navigate the page structure.
• Keyboard navigation. Interactive elements in our forms, dialogs, menus, dropdowns, calendars, and date pickers are reachable and operable with the keyboard alone.
• Focus indicators. A visible focus ring appears on every focused interactive element when using keyboard navigation. We use CSS focus-visible so the ring appears for keyboard users but not mouse users, avoiding visual clutter.
• Screen-reader support. We use Radix UI accessible component primitives, which provide ARIA roles, keyboard management, and focus trapping for dialogs, dropdowns, and other complex widgets.
• Form labels. All form fields have associated labels. Required fields are marked both visually and programmatically (aria-required).
• Error identification. Errors in booking and authentication flows are announced to screen reader users via ARIA live regions.
• Decorative images. Icons and decorative images are hidden from assistive technology (aria-hidden="true") so they do not create noise for screen reader users.
• Responsive layout. All public pages work at 320 px wide without horizontal scrolling.
• Language. The page language is declared in the HTML (lang="en") so assistive technology can apply appropriate pronunciation rules.
• Skip to main content. A "Skip to main content" link is present as the first focusable element on every page, allowing keyboard and screen reader users to bypass navigation and jump directly to the main content area.
• Autocomplete attributes. Login, signup, and booking form fields carry autocomplete attributes, enabling password managers and browser autofill to assist users with motor or cognitive disabilities.
• 66-language support. Businesses can offer their booking pages in up to 66 languages. When a different language is selected, content is translated.

Known limitations

We are transparent about the gaps we know exist today:

1. Language attribute on language switch. When a customer selects a non-English language on a booking page, the page content translates but the HTML lang attribute does not update dynamically. Screen readers use this attribute to select the correct voice and pronunciation. We are addressing this.

2. Floor-plan editor drag-and-drop. The floor-plan seating editor in the business dashboard uses drag-and-drop to position tables. A keyboard-accessible alternative for this feature is on our roadmap. This does not affect customer-facing booking pages.

3. Third-party widgets. Paddle Checkout (for Reservly subscriptions) and Stripe/PayPal (for business payment processing) are operated by those providers. We select providers with strong accessibility records but cannot directly control those widgets.

4. User-generated content. Images, service descriptions, and documents uploaded by businesses are outside Reservly's direct control. We provide guidance and tooling to encourage accessible content.

5. Animations. Some landing page animations may not fully respect the prefers-reduced-motion user setting. We are adding CSS media query rules to address this.

6. Toast notification announcements. Reservly uses Sonner for in-app toast notifications (success, error, and informational messages that appear briefly on screen). The accessibility of these toasts for screen reader users depends on Sonner's ARIA live-region implementation. We have not yet independently verified that all Sonner toast variants are reliably announced by NVDA, JAWS, and VoiceOver in all browser combinations we support. We are investigating and will update this Known Limitation when we have confirmed behaviour or have implemented a verified alternative.

Compatibility

Reservly is tested against and designed to work with the following assistive technology and browser combinations:

We cannot guarantee full compatibility with all assistive technology combinations, but we aim to meet the needs of users of the above.

Technical specifications

Reservly is built on:

• Next.js 16 (React 19 — App Router) — server-rendered HTML for speed and SEO, with progressive enhancement
• Radix UI — accessible component primitives (dialogs, menus, checkboxes, radio groups, sliders, tabs)
• shadcn/ui — Tailwind CSS v4 component library built on Radix UI
• Tailwind CSS v4 — CSS framework with semantic color tokens
• ESLint with jsx-a11y plugin — static accessibility linting on every code change

How we test

• Static linting: eslint-plugin-jsx-a11y rules run on every code change and catch common violations (missing alt text, missing label associations, non-interactive elements with event handlers).
• Build-time type checking: TypeScript strict mode prevents entire categories of runtime errors.
• Manual review: New features that affect user-facing UI are reviewed against WCAG 2.1 AA criteria before shipping.
• Planned: We are integrating @axe-core/playwright into our end-to-end test suite so automated accessibility scans run against every production build. We commit to completing this integration within the next 90 days.
• Third-party audit: We plan to commission an independent WCAG 2.1 AA audit within 12 months of general availability or upon reaching 200 business customers, whichever comes first.

Accessibility feedback

If you encounter an accessibility barrier on Reservly, or if you need content in an alternative format, please contact us:

Email: accessibility@reservly.io (with subject line "Accessibility")

Please include in your message:

• What you were trying to do
• What happened instead
• The page URL (if applicable)
• The assistive technology, browser, and operating system you were using (if known)

You do not need to provide all of this — any information helps.

Our response commitments:

• Acknowledgement within 5 business days
• Assessment (severity + initial remediation plan) within 20 business days
• Resolution on a best-effort basis, prioritised by severity. Issues that block completion of a core task (signing up, making a booking, cancelling a booking, checking in) are treated as critical and addressed as soon as reasonably practicable.

If our response does not resolve your issue, you may escalate by replying to our response email and requesting escalation to the Privacy Officer.

Regulatory escalation contacts

EU residents: Each EU member state has designated a national authority responsible for EAA enforcement. The European Commission maintains a list of national bodies at ec.europa.eu/social/main.jsp?catId=1202. You may file a complaint with the authority in your member state if our response does not satisfy you.

UK residents: You may contact the Equality and Human Rights Commission (EHRC) or the Equality Advisory and Support Service (EASS) if our response does not satisfy you.

UK Equality Act 2010 — Section 20 Reasonable Adjustment Duty: Under the Equality Act 2010 Section 20, Reservly has a duty to make reasonable adjustments where a provision, criterion, or practice (or a physical feature, or the absence of an auxiliary aid or service) puts a disabled person at a substantial disadvantage compared to a non-disabled person. This duty applies to Reservly as a private-sector service provider; there is no micro-enterprise exemption for the UK private sector (unlike the European Accessibility Act, which provides a micro-enterprise carve-out). If you are a disabled user and require a reasonable adjustment to use Reservly's services — for example, receiving information in an alternative format, or assistance completing a booking — please contact accessibility@reservly.io with subject line "Reasonable Adjustment Request".

US residents: The Department of Justice Civil Rights Division accepts ADA-related complaints at https://www.ada.gov/filing-a-complaint/.

We commit to cooperating in good faith with any complaint or inquiry from these bodies.

European Accessibility Act (EAA)

The European Accessibility Act (Directive 2019/882) became enforceable on June 28, 2025. Reservly launched after this date and does not rely on transitional provisions.

Reservly currently qualifies as a micro-enterprise under the EAA's size threshold (fewer than 10 employees and annual turnover or balance-sheet total not exceeding €2 million). Under Art 4(5), micro-enterprises providing services are exempt from certain EAA service requirements. Reservly relies on this exemption where applicable but voluntarily targets WCAG 2.1 AA conformance regardless, because accessible design is the right standard to build to and because this exemption may not apply indefinitely.

The technical standard for EAA compliance is EN 301 549 V3.2.1, which incorporates WCAG 2.1 AA. Reservly's WCAG 2.1 AA target satisfies this technical requirement.

ADA (United States)

Reservly's public booking pages serve as the online booking interface for businesses that operate physical locations — salons, wellness studios, clinics, and similar places of public accommodation under ADA Title III. Reservly takes its obligation to provide accessible booking pages for these businesses seriously and targets WCAG 2.1 AA as the benchmark referenced by the Department of Justice.

Changes to this statement

This statement will be updated when:

• We resolve a known limitation listed above
• We introduce a new accessibility feature
• Our conformance status materially changes
• Our regulatory posture changes (e.g., if the EAA micro-enterprise exemption no longer applies)

The Last reviewed date at the top reflects the most recent revision.

Contact

Accessibility enquiries: accessibility@reservly.io (subject line: "Accessibility") General enquiries: support@reservly.io

Reservly c/o Northwestern Registered Agent Services 30 N Gould St Ste R Sheridan, WY 82801 United States

This Accessibility Statement is incorporated into the Reservly Terms of Service and Privacy Policy.