Accessibility statement

We want this site, and the platform behind it, to work for everyone, including people using screen readers, keyboard navigation, magnifiers, and reduced-motion settings. Web Content Accessibility Guidelines (WCAG) 2.1 Level AA is our working target, for the public site and the application surfaces alike. This page says what we currently check automatically, and what we already know we don’t meet. It’s a statement of where we are, and it isn’t a claim of full conformance.

What we check every night

An axe-core audit runs nightly against our main branch, using the wcag2a, wcag2aa, wcag21a and wcag21aa rule sets, plus heading-order. Axe classes that one as best practice, outside WCAG, so we have to ask for it by name. It covers every marketing page and every borrower- and staff-facing application route: the borrower journeys in both presentation idioms, the status tracker, verification and signing rooms, the document room, and the loan-officer, processor and production workspaces, at desktop width, and the phone-facing subset again at a 360px viewport. Any violation on a route in that set fails the run and raises an alert. The full audit runs nightly and doesn’t run on every change, so a regression can merge. We catch it the next morning, and nothing blocks it before then.

The audit has two limits. It reaches each route in its entry state, so a defect that only appears after a dialog opens is outside it. And an automated pass is a floor, and it isn’t a conformance finding: axe checks what a machine can check, and that’s a minority of WCAG. We’re continuing deeper per-phase and manual assistive-technology review.

What we do beyond the automated gate

• Semantic structure: every marketing page carries header, navigation, main and footer landmarks, a single h1, and a skip-to-content link. Heading levels increase by one on every audited route, checked every night.
• Keyboard operability: we draw focus indicators and never suppress them, so the segmented controls take a 3px outline at a 2px offset on keyboard focus. We haven’t yet completed a keyboard-only traversal of every surface, so we describe this as what we build toward. It isn’t a measured property of all of them yet.
• Contrast: we hold the tokens carrying secondary and fine-print text to 4.5:1 (success criterion (SC) 1.4.3) in every scope that redefines them, and the tokens carrying control boundaries to 3:1 (SC 1.4.11) against every ground they paint on. Both are tests that fail the build. Neither one just warns.
• Motion & imagery: the site respects prefers-reduced-motion. We hide decorative graphics from assistive technology, and informative images carry text alternatives.

Known gaps

We measured these on August 18, 2026, and we list them because a conformance claim without its exceptions isn’t one:

• Three of the four application routes outside the marketing site carry no footer landmark, /demo, /offline and /voe (/partner has one). They also carry no nav landmark. Both absences are deliberate, and we explain them below instead of closing them.

Why we aren’t “fixing” those two: a landmark is a promise about what a region contains, and these four are single-purpose surfaces: an offline notice, an employment verification form, a demo entry point, a partner’s view of one transaction. None has site navigation, and three have no closing content. Adding an empty nav or footer would retire a line on this page while giving a screen-reader user a region that announces itself and holds nothing, which is worse than leaving it out. WCAG doesn’t require either one. If those routes gain real navigation, they’ll gain the landmark with it.

One note for anyone checking this by hand: two of those four, /demo and /partner, sit behind the demo pass on this deployment, so we redirect an unauthenticated visitor away from them. We audit them every night all the same. /voe and /offline are the two that need no credential.

Closed since the last update

We list these instead of deleting them, because a gap that disappears without a record looks exactly like one nobody ever wrote down. We re-measured each one on the date we closed it: August 17 and August 18, 2026:

• Heading order is level-clean, and now gated. We fixed the seven pages that jumped from h1 to h3, along with one on the borrower status tracker that this page never listed. The audit had been blind to the whole class, because axe files heading order under “best practice”, outside the WCAG rule sets we ran. So we switched the rule on explicitly, and a nightly run fails on a skipped level on any route (SC 1.3.1).
• Every audited route has a page heading and a main landmark. The employment-verification page had no h1 in any of its four states, so a verifier arriving on an expired link met a page with no heading at all, and the offline shell had no header. We fixed both (SC 1.3.1, 2.4.6).
• Skip links now cover every audited route. The four routes outside the marketing site each carry a skip-to-content link targeting their main landmark. A test pins the link to its target, because a skip link whose target is missing is inert while still reading as a fix (SC 2.4.1).
• Marketing form placeholders meet AA. The contact and demo-request inputs read the same themed token as the application inputs: 5.26:1 on our cream background and 6.93:1 in dark, against the 4.5:1 requirement. A test that fails the build holds the token to AA in both schemes (SC 1.4.3).
• The /integrations table is keyboard-scrollable. Its wrapper takes keyboard focus with a visible focus ring and an accessible name, and the marketing pages have joined the 360px audit pass, so the narrow-width states that hid this are now checked every night (SC 2.1.1).

The platform

We hold the Apsis Line product, the borrower journey and the lender workspaces, to the same automated bar as the public site, on the scope and with the limits described above. A borrower-facing mortgage application has to be usable by every borrower, and we treat that as a product requirement. It isn’t a compliance exercise for us.

Accessibility review is part of client evaluation. We’ll hand your accessibility team the audit configuration and the current findings at the start of it, and we welcome results that disagree with ours. An independent instrument is the only kind that can find what ours isn’t looking for.

Found a problem?

If any part of this site is hard to use with assistive technology, tell us at robert@apsisline.com and include the page and the technology you were using. Accessibility reports go to the top of the queue.