Skip to content

Legal

Accessibility

What we have done to make a dense, dark, data-heavy interface usable with a keyboard, a screen reader, magnification or reduced motion — and what still needs work.

Last updated: August 2026

Our target

We aim to meet WCAG 2.2 Level AA. We have not commissioned a third-party audit, so this is a statement of intent and implementation rather than a certified conformance claim. If you hit a barrier we want to hear about it.

What is implemented

  • Keyboard operation. Every control in the calculator — the platform toggles, the industry and app-type dropdowns, the scope and scale radio groups and the breakdown that expands under the estimate — is a real button, select or details element, reachable and operable by keyboard in a logical order.
  • Visible focus. A single high-contrast indigo focus ring is applied site-wide with an offset, so it stays visible against every surface. We never remove focus outlines.
  • Skip link. A skip-to-content link is the first focusable element on every page.
  • Semantic structure. One h1 per page, ordered headings, real lists and tables with header cells, landmark regions, and fieldset grouping for each question.
  • Screen-reader state. Selections expose aria-checked or aria-pressed. Radio and checkbox groups are labelled. The live estimate is an aria-live region, so the figure is announced when it changes.
  • Reduced motion. Every animation is decorative. With prefers-reduced-motion: reduce, animations and transitions are disabled and the cost figure snaps to its new value instead of counting.
  • Contrast on a dark interface. Body and interface text meets the 4.5:1 minimum against its background. Dark themes make it easy to ship text that is too dim; the muted greys here are chosen to clear the threshold rather than to look subtle.
  • Colour is never the only signal. The homepage matrix marks common pairings with a filled glyph as well as a colour, and every cell carries a screen-reader label naming the platform and industry. Warnings pair colour with an icon and text.
  • Reflow. The layout works down to 320px without horizontal scrolling. Wide tables scroll inside their own container rather than forcing the page sideways.
  • No timing traps. Nothing auto-advances, times out or disappears while you read it.

Known limitations

  • Range sliders are native inputs, which are keyboard-accessible but fiddly. Every slider is paired with either a visible numeric readout or a directly editable number field, so no value is reachable only by dragging.
  • The homepage matrix is a large table. It is navigable and labelled, but a screen-reader pass through 128 cells is slow — the platform and industry hub pages provide the same links in shorter lists, and are the better route.
  • The calculator requires JavaScript. The estimate is computed in the browser, so there is no server-rendered fallback for it. All editorial content — platform guides, industry guides, combination pages, the method page and FAQs — is server-rendered and readable without JavaScript.
  • We have not yet tested against every combination of screen reader and browser. Reports of specific failures are the most useful thing you can send us.

Accessibility as a cost line

Worth noting, since this is a cost estimator: accessibility appears in the model as a real, priced line rather than an afterthought. WCAG 2.2 AA is available as a feature, as a QA discipline, and as ADA and Section 508 compliance programmes. Retrofitting it costs several times what building with it costs, which is the honest reason to include it from the start.

Feedback

If any part of this site is difficult or impossible for you to use, email [email protected] with what you were trying to do, the page, and your browser and assistive technology if you know them. We treat accessibility defects as defects, not feature requests.

App Development Cost is published by Taction Software Solutions (Taction Software LLC), United States. Questions about this page: [email protected].