The target

We aim for this site to conform to WCAG 2.1 Level AA. That is a commitment, not a certification: it means we test against it, we treat failures as bugs, and we fix them rather than documenting them as known issues.

What gets tested, and how

  • Automated. npm run a11y runs axe-core against every route at desktop and mobile widths and fails the build on any serious or critical violation. It runs in CI on every push.
  • Keyboard. Every interactive element, including navigation dropdowns, the mobile menu, accordions and the quote carousel, both forms, is reachable and operable with a keyboard alone, with a visible focus ring and Escape closing anything that opens.
  • Motion. Animation is decoration. Visitors with prefers-reduced-motion set see content in its final state immediately, and nothing auto-advances.
  • Zoom. Pinch-zoom is never disabled. Text scales to 200% without loss of content, which is why you will not find user-scalable=no in our markup.

Where we know we fall short

Automated tools catch roughly a third of accessibility problems. We have not yet run this site past assistive-technology users, and until we have, that is an honest gap rather than a solved problem. Where placeholder content still sits on the site, it is marked as placeholder rather than dressed up as real.

Reporting a problem

If something here is hard or impossible to use, email treeinapool@gmail.com with the page and what happened. We reply within one business day and treat access barriers as higher priority than feature work.

The same standard on client work

Accessibility and performance budgets are part of every build scope, not an upsell. The QA pass before launch covers both, and the numbers go in the handover document.