Accessibility Statement

DailyBuilt, Inc., a Delaware corporation ("DailyBuilt", "we", "us") wants everyone to be able to use the software we build and the pages we host. This statement explains the standard we build to, what we have done, what we know is not finished, who is responsible for what, and how to reach a person if something does not work for you.

1. Our conformance target

We design and build to the Web Content Accessibility Guidelines (WCAG) 2.1 at Level AA as our target standard.

This is a target, not a claim of conformance. We have not commissioned an independent accessibility audit, we do not publish a Voluntary Product Accessibility Template (VPAT) or Accessibility Conformance Report, and we have not verified every screen against every Level AA success criterion. Parts of our properties conform; parts have known gaps; and parts have not been formally evaluated at all. Section 4 describes what we know today.

WCAG 2.1 Level AA is the standard courts most commonly apply to private businesses. No federal regulation currently prescribes a web accessibility standard for private companies; the Department of Justice's 2024 rule adopting WCAG 2.1 Level AA applies to state and local government entities.

We publish this statement because we would rather tell you where we actually are than claim a conformance level we have not measured.

2. What this statement covers

This statement applies to the properties DailyBuilt builds and controls:

• dailybuilt.co — our marketing website, including this page.
• app.dailybuilt.co — the DailyBuilt application used by our business customers ("Customers").
• The hosted pages we template for Customers and their customers ("End Users") — booking pages at {slug}.dailybuilt.co/book, document signing pages, and invoice payment pages, together with the transactional emails those flows send.

It does not apply to:

• Content a Customer authors or uploads into pages we host. See Section 6.
• Third-party components embedded in our pages, such as the payment form rendered by our payment processor, the bot-protection challenge on public forms, or embedded components from advertising and business-profile providers. We choose vendors partly on accessibility, but we do not control their markup and cannot warrant it.
• Customers' own websites, systems, and documents, including websites we may host for a Customer under a separate arrangement.
• Documents a Customer or End User uploads to the Service, and PDFs generated from Customer-authored content. See Section 4.

3. What we have done

Accessibility work we have already built into the product:

• Accessible component foundations. The shared interface library used across the application and our hosted pages is built on accessible headless primitives (Radix UI) that implement the WAI-ARIA authoring practices for interactive patterns — dialogs, menus, comboboxes, tabs, checkboxes, radio groups, and similar — including keyboard interaction, focus management, and the ARIA roles, states, and properties those patterns require.
• Keyboard operation. Interactive controls are reachable and operable by keyboard, with visible focus indicators.
• Semantic structure. Pages use semantic HTML landmarks and heading order, form controls are associated with labels, and images that carry meaning are given text alternatives.
• Reduced motion. Our marketing site and the application honor the operating system prefers-reduced-motion setting: animation-heavy scroll effects, transitions, and decorative motion are suppressed or replaced with a static presentation when that preference is set.
• Color and contrast. Our design tokens define text and interface colors intended to meet WCAG AA contrast ratios in both light and dark presentation, and we do not rely on color alone to convey status.
• Zoom and reflow. Layouts use relative units and responsive layout so content reflows rather than requiring horizontal scrolling at increased zoom or on small screens.
• Accessible defaults for Customer pages. The booking, signing, and payment templates ship with accessible structure and labeling by default, so a Customer gets that behavior without having to build it.

4. Known limitations

We know of the following gaps. This list is not exhaustive, because we have not completed a full evaluation.

• Motion-rich marketing pages. Some pages on dailybuilt.co use scroll-driven animation and canvas- or WebGL-based visual effects. Reduced-motion preferences are honored, but the underlying decorative graphics may not expose meaningful text alternatives, and reading order in heavily animated sections has not been fully verified with assistive technology.
• Dense interactive surfaces in the application. The calendar and availability editor, the document editor and signature-field placement canvas, data tables with inline editing, and the analytics charts are complex interactive widgets. Some of these have not been fully verified for screen-reader announcement, keyboard-only operation of drag interactions, or accessible names on every control.
• Generated PDFs. Sealed documents, certificates of completion, invoices, and superbills are generated as PDFs. These are not currently produced as tagged, fully accessible PDF/UA documents. If you need the contents of a document in an accessible format, contact us and we will provide one.
• Embedded third-party components. The payment form, the bot-protection challenge, and embedded provider components are rendered by third parties. Their accessibility is determined by those vendors.
• Emails. Transactional and marketing emails follow accessible email practice (semantic structure, text alternatives, adequate contrast, a plain-text alternative), but rendering varies by email client and we cannot control every client.
• No formal evaluation record. We have not completed a documented, criterion-by-criterion evaluation of any property, and no assistive-technology compatibility matrix has been published.

If you encounter a barrier that is not on this list, please tell us (Section 7). Reports from people who actually use assistive technology are the most useful input we get.

5. Compatibility

We build to current web standards and test in current versions of major browsers (Chrome, Safari, Firefox, and Edge) on desktop and mobile. The product is intended to work with the assistive technology those platforms provide, including screen readers, screen magnification, speech input, and operating-system contrast and motion settings.

We have not completed formal compatibility testing against specific screen reader and browser combinations, and we therefore do not publish a supported-combination matrix. Very old browsers that no longer receive security updates are not supported.

6. Content our Customers author

DailyBuilt is a platform. Our business customers create their own content inside it: the text and images on their booking pages, the questions on their intake forms, the wording and layout of the documents they send for signature, the descriptions on their invoices, the copy in their email and text messages, and their brand colors and logo.

We provide accessible templates and defaults. The business is responsible for the content it puts into them. A Customer can, for example, upload an image without a text alternative, write a form question that is not understandable, choose a brand color combination that fails contrast, or upload a scanned PDF that a screen reader cannot read. Those choices are the Customer's, and the Customer is responsible for its own obligations under the Americans with Disabilities Act, Section 504 and Section 508 where applicable, and any state or local accessibility law that applies to it.

Where we can help Customers make good choices, we try to: accessible defaults, contrast-aware brand tokens, prompts for image text alternatives, and guidance in the product. We will continue adding those. If you are a Customer and you want help reviewing your own pages, contact us.

Public entities and federal contractors. No current DailyBuilt Customer is a state or local government entity or a federal contractor, so the procurement obligations under Section 508 and the Department of Justice's Title II rule do not presently apply to the Service. A Customer subject to those obligations should tell us before it buys, so the requirement can be addressed in its Order Form.

7. Feedback, help, and accommodations

If any part of a DailyBuilt page or a page we host for a business does not work for you, tell us. You do not need to identify a WCAG criterion or use any particular wording.

Email: hello@dailybuilt.co — please put "Accessibility" in the subject line.

It helps if you can include:

• The web address (URL) of the page, or which business's booking, signing, or payment page it was.
• What you were trying to do and what happened.
• The browser, operating system, and any assistive technology you were using.

Our commitment.

• We acknowledge every accessibility report within 5 business days.
• We give you a substantive response — what we found, and either a fix, a timeline, or an alternative way to accomplish what you were doing — within 15 business days, and tell you why if a fix will take longer.
• We prioritize barriers that block someone from completing a task (booking an appointment, signing a document, paying an invoice) over cosmetic issues.
• We either remediate the barrier or provide an equivalent alternative means of completing the task. We do not close a report without doing one or the other.

Accommodations and alternatives. If a hosted page is not usable for you and you need to get something done now, we will find another way. That may mean providing a document in an accessible format, or putting you in touch with the business so a person can book the appointment, take the signature, or take payment directly. Ask us and we will arrange it. We do not charge for accommodations.

If you would like to escalate a report you have already sent, reply to the same thread and say so; it will be routed to a member of our leadership.

8. How we keep improving

• Accessibility is part of our design and code review, not a separate cleanup phase. Components enter the shared library with keyboard and screen-reader behavior expected.
• We review this statement at least annually and whenever we ship a significant change to the application or to our hosted page templates. Prior versions of this document are archived by date and are available on request to hello@dailybuilt.co.
• Commissioning an independent accessibility evaluation and publishing an Accessibility Conformance Report is on our roadmap. We will update this statement, including its date, when that changes.
• Reports we receive under Section 7 feed directly into the work queue.

9. Formal approval and legal note

This statement was prepared by DailyBuilt and reflects our own assessment as of the effective date. It has not been reviewed or approved by an external accessibility auditor.

This statement is informational. It describes our target and our current status; it is not a warranty, a guarantee of conformance, or an amendment to any agreement between DailyBuilt and a Customer. If it conflicts with the Terms of Service or an Order Form, those govern.

10. Contact

DailyBuilt, Inc. c/o Corporation Service Company, 251 Little Falls Drive, Wilmington, DE 19808 hello@dailybuilt.co

Related pages: Terms of Service · Privacy Policy · Security