Healthcare App Cost

Accessibility Statement

Last updated 11 August 2026. We aim to meet WCAG 2.2 level AA across this site. An interactive cost calculator is exactly the kind of component that is easy to build badly, so this page sets out what we actually did, what we test, and where we know we fall short.

Target standard

Web Content Accessibility Guidelines (WCAG) 2.2, level AA. This is a statement of intent and current status, not a formal third-party audit or certification.

What we built for it

  • Real form controls. The scope, platform, design and location selectors are genuine radio inputs grouped in fieldset/legend elements with role="radiogroup". The feature, compliance and integration selectors are genuine checkboxes. The styled pills and cards sit on top of those inputs rather than replacing them, so arrow keys and Space behave the way the platform intends.
  • Keyboard operable throughout. Every control, link, FAQ disclosure and call to action is reachable and operable by keyboard alone. A skip link to the main content is the first tab stop.
  • Visible focus. A 3px :focus-visible outline is applied sitewide, including on the custom pill and checkbox controls, where focus styling is most often lost.
  • Announced updates. The estimate panel carries aria-live="polite", so screen reader users hear the total rather than having to hunt for it.
  • A navigable wizard. Each calculator runs as a series of steps. Progress is exposed as a role="progressbar" with the current and total step counts, the current step is marked aria-current="step", and moving between steps sends focus to the new step’s panel so keyboard and screen reader users land where the content changed instead of at the top of the page.
  • Errors tied to their fields. On the final step every input has a persistent visible label, and a field that fails validation gets aria-invalid plus an aria-describedby pointing at the error message, so the reason is announced with the field rather than only shown in colour.
  • Semantic structure. One h1 per page, ordered headings, landmark regions, breadcrumb navigation in a labelled nav, and captions on data tables.
  • Reduced motion respected. prefers-reduced-motion disables transitions, hover transforms and smooth scrolling.
  • Responsive down to 380px with no horizontal page scrolling, and text that reflows rather than being clipped. Wide data tables scroll inside their own container instead of forcing the page sideways.
  • Native disclosures. FAQs use details/summary, which are keyboard and screen reader accessible without custom scripting.

How we test

Alongside manual keyboard passes, we run an automated browser suite against the built site before release. It asserts, among other things, that focus is visible on the custom controls, that arrow keys move through the scope radiogroup and recalculate the estimate, that Space toggles a feature checkbox, that the estimate panel keeps its live region, and that no page overflows horizontally at 380px.

Known limitations

We would rather name these than let you discover them:

  • Gradient headline text. Part of the homepage headline is rendered with a gradient clipped to the text. In forced-colours or high-contrast modes this can render less predictably than plain text. The same words are present as real text, so content is never lost.
  • Wide tables need horizontal scrolling. On narrow screens the pricing and multiplier tables scroll inside their container. The scroll container is keyboard scrollable, but a multi-column table remains harder to consume on a small screen than on a large one.
  • No formal audit yet. We have not commissioned an independent WCAG audit or assistive-technology user testing programme. Our testing is internal, automated plus manual.
  • Estimates are not persisted. Reloading resets the calculator to its defaults. This is a deliberate privacy decision, but it does mean re-entering selections if a page is reloaded.

Compatibility

The site is built with standard HTML, CSS and JavaScript and is intended to work with current versions of Chrome, Edge, Firefox and Safari on desktop and mobile, together with the screen readers commonly paired with them. JavaScript is required for the calculators to compute; all page content, FAQs and pricing tables remain readable without it.

Reporting a barrier

If something on this site is difficult or impossible for you to use, we want to hear about it — that is more useful to us than a passing grade. Email info@tactionsoft.com and include the page, what you were trying to do, and the browser and assistive technology you were using. We treat accessibility defects as ordinary bugs and fix them on the same basis.