Last updated: January 2026
Estimating is detailed work often done under time pressure, sometimes on site, sometimes on a small screen in poor light. Accessibility is not a compliance exercise here; it is what makes the tool usable in the conditions it is actually used in.
ConstrCalc targets WCAG 2.1 Level AA. That covers colour contrast, keyboard operability, focus visibility, text alternatives, and behaviour at high zoom levels.
We treat AA as a working minimum rather than a certificate. Where a control can be made clearer than the standard strictly requires, we make it clearer.
Text and interface colours are verified against their actual rendered backgrounds in both light and dark themes. Where a brand colour failed the threshold — the platform gold is close to invisible as text on a light background — a darker variant is substituted for text while the original is retained for fills.
Colour is never the only carrier of meaning. Category icons are colour-differentiated to aid scanning, but every one is accompanied by a text label, so nothing is lost if colours are indistinguishable to you.
The calculator, navigation, tabs, share controls and export functions are operable by keyboard. Focus indicators are visible rather than suppressed, and a skip link is provided so keyboard users can bypass the header on every page.
Tab order follows the visual order of the page. Interactive elements are real buttons and links rather than styled divs, so they behave as assistive technology expects.
Decorative icons carry aria-hidden so they are not announced as noise. Controls that are icon-only carry descriptive labels. Headings follow a logical hierarchy without skipped levels, which allows navigation by heading.
Live regions announce results where a value updates without a page change, so a screen-reader user is told that a total has recalculated.
Interactive controls meet a minimum touch target of 44 by 44 pixels, and the calculator navigation buttons exceed it. Spacing between adjacent controls is sized to reduce mis-taps on small screens.
Nothing in the platform requires a drag, a precise gesture, or a timed interaction to complete a task.
Interface animation is limited to short transitions on hover and focus. The platform honours prefers-reduced-motion, disabling transform-based movement for users who have asked their system to reduce animation.
Layouts are verified from 320 pixels wide upward. Content reflows rather than requiring horizontal scrolling, and wide data tables scroll within their own container so they never force the whole page sideways.
The calculator is dense by nature: six tabs, many numeric fields, and a summary that updates as you type. On a very small screen this remains demanding regardless of markup quality, and we continue to work on it.
Exported PDF documents are generated by a third-party library and their internal tagging is outside our direct control. If you need an accessible export, the Excel and JSON formats preserve structure more reliably.
If you encounter something you cannot use, tell us at info@constrcalc.com. Describe what you were trying to do and what assistive technology you were using, and we will investigate. Reports of this kind are treated as defects, not as feature requests.
Accessibility is verified by measurement rather than inspection. Contrast ratios are computed against the actual rendered background of each element, in both themes, rather than assumed from the stylesheet — a distinction that matters, because a value defined in CSS can be overridden by a later rule and appear correct in source while failing on screen.
Layouts are checked at 320, 360, 390, 768, 1440 and 1920 pixels. Keyboard operation, focus visibility, heading structure, image alternatives and icon labelling are checked on every page rather than sampled.
There is a practical link between accessibility and correctness in a tool like this. A field whose label is not programmatically associated with its input is a field somebody can fill in wrongly. A result that updates silently is a result a screen-reader user may never learn changed.
Treating those as accuracy defects rather than compliance items is why they are addressed here rather than deferred.
Accessibility work is never finished, because the platform changes and new interface patterns introduce new barriers. Each release is re-checked against the measures described above rather than assumed to have preserved earlier compliance.
Where a change would improve visual design but degrade contrast, keyboard access or screen-reader behaviour, the accessibility consideration takes precedence and the design is reworked.
The Web Content Accessibility Guidelines are published by the World Wide Web Consortium and are the reference this platform works to. Where a regional regulation imposes additional obligations — such as the European Accessibility Act or equivalent national legislation — those apply alongside rather than instead of the guidelines described here.
