Skip to content
remodelmath

Legal

Accessibility Statement

The site is built to be usable by everyone — keyboard navigation, screen readers, mobile devices, slow connections, reduced-motion preferences. Here's what we've implemented, what we know about, and how to tell us if something isn't working for you.

Published Updated 3 min read

Conformance standard

We target WCAG 2.1 Level AA conformance across the site. This is the standard that most US web-accessibility regulations (including ADA Title III case law) reference. We aim for substantial conformance and treat any failure to meet a Level AA criterion as a real bug to fix.

What we've implemented

Concrete patterns implemented sitewide:

  • Semantic HTML5 — every page uses appropriate <header>, <nav>, <main>, <article>, <section>, <footer> elements. Form fields use <label> / <fieldset> / <legend> per accessibility best practice.
  • Keyboard navigation — every interactive element is reachable via Tab. Focus order follows visual order. The escape key closes the mobile menu. The mobile menu opens on Tab + Enter on the hamburger button. The calculator's stepper buttons, dropdowns, radios, and switch toggle all support keyboard interaction.
  • Skip-to-content link — first focusable element on every page. Becomes a high-contrast pill at the top-left when focused via Tab, letting keyboard users jump past the navigation.
  • Visible focus indicators — sitewide terracotta ring on every focusable element when navigated by keyboard (using :focus-visible so the indicator doesn't appear for mouse interaction, where it would be visual noise).
  • Screen-reader announcements — the cost calculator's output panel uses an ARIA live region so screen-reader users hear the new estimate announced whenever they change an input ("Estimated total for California: $8,400 – $12,200, range based on 8 windows, medium confidence. Estimates may vary depending on project conditions, project scale, and regional contractor pricing.").
  • ARIA where needed — disclosure widgets carry aria-expanded, dialog elements carry role="dialog" aria-modal, navigation regions carry aria-label, breadcrumbs use the standard breadcrumb pattern with aria-current="page" on the current item.
  • Color contrast — body text and UI elements meet WCAG AA contrast (4.5:1 for body text, 3:1 for UI components). Status indicators (Energy Star eligible / Permit required / Lead-paint disclosure) use both color tone AND icon AND label text — never color alone.
  • Mobile-first responsive design — layouts work at viewports from 320px upward. Touch targets are at least 48×48 pixels (per WCAG 2.5.5). Body text is at least 16px on mobile.
  • Reduced-motion support — animations respect prefers-reduced-motion: reduce. The mobile-menu transition and the back-to-top button transition are disabled or instant when the user's OS-level motion preference is set to reduce.
  • Descriptive link text — links describe their destination. No "click here" or "read more" patterns.

Known limitations

Things we know about and plan to address:

  • Calculator output table on very narrow viewports. The data-sources table on the methodology page scrolls horizontally on screens narrower than ~480px. A future revision will restructure narrow-viewport rendering to avoid horizontal scroll.
  • OS-native dropdowns. The calculator's State, Window Type, Material, Glass Type, and Home Age dropdowns use the native HTML <select> element — which means the dropdown rendering depends on your operating system and browser. This is a deliberate accessibility choice (native controls have the best screen-reader support) but means visual styling of the open dropdown is OS-controlled, not site-controlled.
  • JavaScript requirement for calculator interactivity. The cost calculator requires JavaScript to compute results. The form is rendered statically and the page is fully readable without JS, but calculations don't run. We're considering a no-JS fallback (server-side computed sample for default inputs) for a future revision.

How to report an accessibility issue

If you encounter an accessibility barrier — anything that prevents you from using the site — please tell us. Email contact@remodelmath.com with a description of the issue, the page URL, and (if possible) the assistive technology you were using (screen reader name and version, voice control software, browser zoom level, etc.). We treat accessibility reports as priority bug reports and aim to respond within 5 business days.

Ongoing commitment

Accessibility isn't a one-time pass. We test new pages and features against the same standards as the existing pages, audit periodically with automated tools (Lighthouse, axe), and fix issues as they're surfaced. Accessibility implementation work is documented in our build journey and architectural principles — these aren't bolt-on policy claims, they're how the site is constructed.