Accessibility statement

Our commitment

We design and build Appraisal Ally — the marketing website at appraisalally.com and the application at app.appraisalally.com — to conform with the Web Content Accessibility Guidelines (WCAG) 2.2, Level AA. Accessibility is part of every design and engineering review, not a phase that happens at the end.

This statement covers both the marketing website and the authenticated product. If you encounter a barrier we have not listed below, please tell us — we will treat it as a bug.

Conformance status

Appraisal Ally is partially conformant with WCAG 2.2 Level AA. “Partially conformant” means most of the content meets the standard, with a small set of known exceptions listed in the next section.

What we have done

Keyboard navigation

• A “skip to content” link is the first focusable element on every page and becomes visible on focus.
• Focus order matches the visual reading order. No tabindex values greater than zero anywhere in the codebase.
• Every interactive element shows a visible focus ring on :focus-visible with sufficient contrast against any background.
• Modals, sheets, and the mobile menu trap focus while open and return focus to the trigger when dismissed with Esc or a close button.
• Sticky mobile CTA bars sit in the document flow rather than being floated out of it, so they receive focus in the correct order.

Screen readers and ARIA

• Icon-only buttons (menu, play/pause, mute, accordion chevrons, comparison-table tooltips) carry meaningful aria-label values.
• Accordions, tabs, switches, and dialogs use the underlying Radix primitives, which manage aria-expanded, aria-controls, aria-selected, aria-checked, and roving focus correctly.
• The comparison tables on /pricing and /vs/* use semantic <table> markup with <caption> and scope attributes on headers.
• The application's toast region uses aria-live=“polite” so screen readers announce stage changes, save confirmations, and errors without stealing focus.
• Form inputs use the floating-label pattern with a real <label> wrapping the input, so screen readers announce the field name continuously, not just on focus.

Captions and transcripts

• Every video on the marketing site ships with a WebVTT caption track in English, attached via <track kind=“captions”>.
• The hero animations are visual-only — they have no audio narrative — so the captions describe key visual moments (e.g. “Card moves from Pick Comps to After Inspection. Toast appears: Stage updated.”).
• The founder testimonial video ships with full closed captions and a linked plain-text transcript below the video player.

Reduced motion

We respect prefers-reduced-motion: reduce. Hero loops, scroll reveals, and the pricing-toggle micro-interactions are either disabled or replaced with an instant equivalent when reduced motion is requested. This is audited as part of code review — any animation in the codebase must check the user's preference.

Color and contrast

• Body text on white meets WCAG AAA (~7.5:1).
• Footer text on the dark background meets WCAG AA (white at 90 percent opacity).
• Primary call-to-action buttons (white on #2a83ed) meet AA for large text and are only used at a minimum 44 pixel target height with 16 pixel type.
• Focus rings use a 2 pixel ring with a 2 pixel offset so they remain visible against any background.

Zoom and responsive layout

Pages are tested at 200 percent browser zoom and with a 200 percent font-size override. No content is cut off and no horizontal scrolling is introduced. We do not set user-scalable=no in any meta viewport — pinch-to-zoom is always available on mobile.

Known limitations

We are not yet fully conformant in the following areas. Each item has an owner and a target.

• Audio descriptions on hero loops. The hero animations have no audio narrative, so we have not authored a separate audio-description track. Captions describe the visual content. We will revisit if a future loop adds narrated audio.
• Audio descriptions on the founder testimonial video. The v1 founder video has closed captions and a transcript but does not include a separate audio-description track. We are evaluating adding one in a future release.
• Third-party embeds. The booking calendar on /demo is an embedded Cal.com widget. We have verified it is keyboard accessible end-to-end, but we do not control its internal markup. If you experience an issue inside the calendar widget itself, please use the Open in a new tab link below the embed or email us and we will book the slot for you.
• PDF exports. Invoices, statements, and appraisal exports generated by the application are PDF documents. We tag PDFs with a basic document structure but have not yet completed a full PDF/UA conformance review.

Assistive technology we test with

We test new releases on the following combinations. Other combinations should work but are not part of our standard test matrix.

• VoiceOver on macOS with Safari and Chrome.
• VoiceOver on iOS with Safari.
• NVDA on Windows with Firefox and Chrome.
• TalkBack on Android with Chrome.
• Full keyboard-only navigation in Chrome, Firefox, and Safari.

How we work on accessibility

• Accessibility checks are part of every pull-request review, not a separate audit at release time.
• Component primitives (buttons, dialogs, menus, accordions, tabs) are built on top of Radix UI, which gives us correct ARIA semantics and keyboard handling by default.
• We run automated checks with axe-core during CI and resolve any serious or critical findings before merge.
• We treat any reported accessibility barrier as a bug, not a feature request.

Report a barrier

If something on appraisalally.com or inside the app is not accessible to you — a focus trap that breaks, a control that cannot be reached by keyboard, a contrast issue, a missing label, anything — please email us. Include the page or screen, the browser and assistive technology you are using, and what you were trying to do. We will reply within two business days and keep you posted until it is fixed.

Email: support@appraisalally.com

A real person reads every report. We treat accessibility barriers as bugs and keep you posted until they're fixed.

Formal complaints

If you have raised an accessibility concern with us and are not satisfied with the response, you can file a complaint with the relevant authority in your jurisdiction. In the United States, that is typically the U.S. Department of Justice Civil Rights Division.