Skip to main content
accessibility

Accessibility at Domora

Last modified: October 2026

We are working toward the Web Content Accessibility Guidelines (WCAG) 2.1 at Level AA. We do not claim that Domora meets them yet. This page says what we have checked, what we know is not right yet, and how to tell us about a barrier.

Where this stands

Our target is WCAG 2.1 Level AA. We are working toward it, and we do not claim conformance with it today.

In October 2026 our own team audited the site against WCAG 2.1 Level AA and fixed most of what it found; what it did not fix is listed under “What we know is not right yet”. The audit used automated scans with axe-core of the public pages and the signed-in pages, at desktop and phone sizes, in both the light and the dark theme. We also checked keyboard use, colour contrast, zoom to 200% and reflow at a 320-pixel width. This was not an independent audit: no outside firm has reviewed Domora.

We have not yet tested with screen readers or other assistive technology in a structured way. That is the biggest thing we have not done.

What follows is the real state of the product: what we have built and checked, and the gaps we already know about.

What we have built and measure

We checked each of these in a browser in October 2026. Most are also held by tests that run every time the code changes, so a change that breaks one fails the build. Where that is not so, we say so.

  • Colour contrast. Body text, status colours, the text on filled buttons, count badges and the edges of form fields are checked against the WCAG AA contrast minimums in both the light and the dark theme. The check computes the real ratio from the stylesheet rather than trusting a note, and colours in the product were changed where they failed it.
  • Keyboard focus is visible. Every link, button, tab, form field and disclosure control shows where focus is when you reach it with the keyboard: a two-pixel outline in most places, or a ring or rule drawn on the box around a field. It is a shape, not a change of colour, so it does not depend on telling colours apart. A test fails if an outline is removed without something else put in its place.
  • A skip link. The first thing the keyboard reaches on every page is a “Skip to main content” link, unless the page starts you in its first field, as the sign-in page does. It appears when it has focus. Following it moves you past the site’s navigation to the start of the page’s main content, so the next Tab lands on the page’s first control.
  • Reduced motion is honoured. If your device is set to reduce motion, the home page animation and the search page’s agent ticker stay still, and the animated indicators and transitions we know about are switched off. If you see something still moving, please tell us.
  • Moving content can be paused. The home page animation has a “Pause motion” button, which also stops the changing example text in the search box. The ticker of agent activity on the search page has a “Pause agent activity” button, which also stops it updating. The ticker also holds still while the pointer is over it or a link in it has keyboard focus. Each choice is remembered in that browser tab until you close it. With reduced motion on, neither moves. The home page’s button is then not shown; the ticker’s still is, because the ticker still updates.
  • Automated accessibility checks. An automated scan with axe-core covers thirteen pages: nine public pages and four signed-in ones (the deals board, a workflow, the comparison page and the inbox), at desktop and phone sizes, in both themes. It fails on any problem axe rates serious or critical. Browser tests alongside it use the keyboard to check the skip link, that focus stays inside every dialog that covers the page and returns when it closes (the Analyst Desk and the panels that open over it, the photo viewer, side panels, menus and pop-up dialogs; while the cookie choices are shown on top of one, Tab reaches them too), that focus outlines are drawn, and that the pause buttons work. We run these browser checks by hand; they do not yet run automatically on every change.
  • Touch targets. On phones and other touch screens, text fields, drop-down lists and the links in the site footer are at least 44 pixels tall. We measured this by hand, and a test fails if a field’s own styling would make it shorter on a phone.
  • This page and the other policy pages are readable without JavaScript. Their text is rendered on the server and is present in the page whether or not scripts run. We have not verified that for every screen in the product, so we are claiming it only for the ones we checked, and by hand.

What we know is not right yet

  • We have not tested with screen readers in any structured way. Parts of the product are dense, interactive and data-heavy, and we expect problems there that we have not found.
  • The pins on the search map can only be selected with a mouse or by touch. Every home on the map is also in the grid and list views, which work with a keyboard.
  • The charts in our calculators each come with a table of the same numbers, which screen readers read instead. The charts in the Analyst Desk do not: some have a one-line description and some have none.
  • Listing photos are described by the address and their place in the set, such as “photo 3”, not by what they show.
  • When you send a question from the Ask button in Ask Domora, the button turns itself off while it works and keyboard focus falls back to the page. The next Tab brings you back into the panel, but you lose your place.
  • The internal operations area requires JavaScript to render. It is a staff-only surface and this is a deliberate trade, but it is a real limitation and we are not going to leave it off the list.
  • Some documents we generate, including the underwriting pack PDF, have not been checked for accessible tagging.

Reporting a barrier

If any part of Domora is not usable for you, please tell us. Describe the page and what happened, and include the assistive technology and browser you were using if you can. Both reach the same people:

  • Email: info@domora.ai
  • Post: Domora AI, LLC, 215 S Olive Ave, West Palm Beach, FL 33401

A person reads these. We will reply within five business days.

In that reply we will confirm that we have your report and tell you what happens next. After that we will tell you what we find, and be straight with you about what we can fix quickly and what will take longer. If you need information from a page that is not working for you, ask and we will send it to you another way.

How this page changes

We update this statement when the facts change rather than on a schedule, and the date at the top is when the facts below were last true. The October 2026 audit described above was our own. If an outside firm audits Domora, this page will say who did it and what it found, including the parts that failed.