Accessibility.

Standard we follow

We aim for WCAG 2.1, Level AA. That covers things like text contrast, keyboard reachability, clear labels, predictable focus order, and respecting people who've asked the operating system for less motion.

What we've checked

• Color contrast. Body text (ink on cream) clears AAA. Muted hint copy clears AA. The deed's small typography sits on a paper-toned background that meets AA.
• Keyboard navigation. Every link, button, dropdown, file picker, and form field on the site is reachable with Tab. The order matches the visual order on the page.
• Visible focus. Keyboard focus gets a halo-yellow outline. Mouse clicks don't show it, so the design stays clean for pointer users.
• Skip-to-content. The first tab on any page lands on a “Skip to content” link, so people using assistive tech can jump past the nav.
• Reduced motion. If your system has prefers-reduced-motion turned on, the hero video is hidden and the static gradient backdrop takes over. Page transitions and CSS animations are stripped to near-zero duration.
• Form labels and errors. Every form input has a visible label. Validation errors are announced to screen readers as soon as they appear.
• Semantic landmarks. Each page has one <header>, one <main>, and one <footer>, plus a <nav> inside the header, so screen reader landmark navigation works.
• Decorative imagery. Backdrop SVGs (paw prints, halo rings, corner flourishes, hero halo arcs) are marked as decorative so screen readers skip them.
• The deed itself. The on-screen deed is a styled document. It carries an aria-labeldescribing the recipient and parcel, so a screen reader hears “Deed certificate for [name], registered to [parcel name]” instead of trying to read every visual element.

What we know is still imperfect

• PDF accessibility. The deed PDF is rendered by @react-pdf/renderer, which does not currently emit fully tagged accessible PDF structure. A screen reader can read the PDF's text but not its logical structure (sections, semantic roles). We track this and will tag the PDF properly when the library supports it, or move to a renderer that does.
• Hint and metadata copy. The smallest helper text under form labels uses a muted ink tone. It passes AA for normal text against cream, but a few cases sit closer to the AA floor than we'd like. We plan to bump these by a half-shade in the next visual pass.
• Hero video poster. The hero video is still wired to a placeholder. When real footage lands, we'll add audio description for any voiceover and a captioned alternative if the video has speech.
• Automated testing. We rely on manual review against WCAG 2.1 AA and the jsx-a11y lint rules. We have not yet added an automated end-to-end accessibility scan (axe, Lighthouse CI) to the deploy pipeline. That's on the roadmap.

Browsers and assistive tech we test against

• Recent Chrome, Safari, Firefox, and Edge on desktop.
• Mobile Safari (iOS) and Chrome (Android).
• VoiceOver on macOS and iOS. NVDA on Windows when we can. JAWS is on the to-test list but not yet covered.
• Keyboard-only navigation in every supported browser.

How to report a barrier

If anything on the site keeps you from using it, please tell us through the contact form. The more detail the better: which page, what you were trying to do, what device and assistive technology you use, and what happened. We aim to respond within two business days and to ship a fix as soon as we can.

Changes to this page

We update this page whenever we ship an accessibility fix or run a fresh audit. The “Last updated” date at the top reflects the most recent change. Material updates will be flagged on the homepage when we have a banner in place.