Accessibility Statement

What we did in the calculator

A sixteen-step wizard full of card-style options is exactly the kind of interface that usually breaks for keyboard and screen reader users. The measures below are the ones that matter most here.

• Real form controls. Every selection tile wraps a genuine <input type="radio"> or <input type="checkbox">. The input is visually hidden but present and focusable, so arrow-key navigation within a radio group, Space to toggle, and screen reader announcements all work the way the platform intends. Nothing here reimplements a control the browser already ships.
• Selection is never colour alone. A selected tile gains a tick mark and a heavier border as well as a filled ground, satisfying SC 1.4.1.
• Grouped questions are fieldsets. Each question is a <fieldset> with a legend, and each grid carries an explicit radiogroup or group role with a label.
• Progress is announced. The step bar is a real progressbar with aria-valuenow, aria-valuemin and aria-valuemax. The step rail marks the current step with aria-current="step", and steps you have not reached are genuinely disabled rather than merely greyed.
• Focus moves deliberately. Advancing a step moves focus to the new panel, so keyboard users are not silently returned to the top of the document. Focus is never moved on first paint.
• Live regions where counts change. The app-library result count and the feature-selection count are role="status", so a filtered list is announced rather than silently changing.
• Errors are linked and announced. Form errors use aria-invalid, aria-describedby and role="alert", and are described in text rather than by a red outline.
• The chart has a text equivalent. The cost composition bar carries a role="img" with an aria-label listing every segment and its percentage, and the same figures appear in the table beneath it.

Site-wide

• Semantic landmarks, one h1 per page, no skipped heading levels.
• A skip link as the first focusable element on every page.
• Visible focus rings on every interactive element, never removed without a stronger replacement.
• Body text meets 4.5:1 contrast and large text 3:1 against its background.
• Layouts reflow to 320px without horizontal scrolling; wide tables scroll inside their own container rather than the page.
• Touch targets on the wizard are at least 44×44px.
• No animation beyond short transitions, and prefers-reduced-motion is respected.
• The site works at 200% zoom and with text spacing overrides applied.

Known limitations

• The calculator requires JavaScript. There is no non-JavaScript fallback, because the estimate is computed in the browser — which is also what keeps your answers private. Every reference app page carries a fully server-rendered cost breakdown, timeline and FAQ that does not need JavaScript to read.
• The step rail scrolls horizontally on narrow screens. It is keyboard navigable and scrolls the focused item into view, but it is a compromise.
• We test with keyboard navigation, VoiceOver and NVDA, and with automated checks. We have not commissioned an independent third-party audit.

Tell us if something blocks you

If any part of this site is difficult or impossible to use, email info@tactionsoft.com with the page and what happened. We treat accessibility defects as bugs, not feature requests, and we will reply with a fix or a timeline. If you cannot use the calculator at all, send us your requirements in the email and we will run it for you and send the result back.