We target WCAG 2.2 Level AA and are partially conformant. This page lists what we have implemented, what is still failing, when we expect to fix it, and how to reach a human if something blocks you today.
Engineering is a field many people enter and remain in with disabilities, and a platform that gates access to professional work has no excuse for being difficult to use. We publish our failures alongside our commitments because a statement that only lists achievements is not useful to the person who is currently stuck.
This statement covers the public platform, the client and engineer dashboards, the technical workroom and the help centre. It does not cover documents uploaded by other users, which we do not produce, or the output of third-party engineering tools linked from the platform.
Every interactive control is reachable and operable by keyboard alone, in a logical order, with a visible focus indicator that meets the 3:1 contrast requirement against adjacent colours. No control depends on hover or on a pointing device. A skip link reaches the main content from the first tab stop on every page.
Testing covers NVDA with Firefox, JAWS with Chrome, VoiceOver with Safari on macOS and iOS, and TalkBack with Chrome on Android. Automated checks run in continuous integration, but they are treated as a floor rather than as evidence: every new interactive pattern is tested manually with at least two screen readers before release.
Content reflows to a 320 CSS pixel viewport width without horizontal scrolling or loss of function, supports 200% zoom without content loss, and tolerates the WCAG text-spacing overrides. Data tables that genuinely require two dimensions scroll horizontally within a focusable, labelled region rather than forcing the whole page to scroll.
Body text meets at least 4.5:1 and large text at least 3:1 against its background. Interface components and meaningful graphical objects meet 3:1. Colour is never the only way information is conveyed: status, availability, validity and verification state all carry a text label or an icon alongside any colour treatment.
Animation is decorative, brief and suppressed entirely under the reduced-motion preference. There is no auto-playing media, no parallax, no content that flashes, and no session timeout that removes work without warning and an extension option.
Every input has a persistent visible label programmatically associated with it, not a placeholder standing in for one. Errors are identified in text, describe how to correct the problem, are announced to assistive technology, and never rely on colour alone. Required fields are marked in text as well as visually.
Each item states the barrier, the workaround available now, and when we expect to address it. If something here is blocking you, contact us and we will provide an alternative directly rather than waiting for the fix.
Drawing sets, 3D models and CAD previews are rendered visually and are not meaningfully available to screen reader users. A drawing conveys geometry, dimensions and annotation that no short text alternative can substitute for.
Every preview offers download of the source file, which can be opened in the user's own tooling with its own accessibility settings. Attached documents carry a descriptive title, discipline, revision and stated purpose in text. On request we will provide a structured text summary of a drawing's key parameters within two business days.
The proposal comparison table and some fee tables exceed the width of a 320 pixel viewport and must be scrolled horizontally. While the scroll region is focusable, labelled and keyboard-operable, comparing values across a wide table remains harder with a screen magnifier.
A stacked single-column view is available on proposal comparison from the view toggle, and every table has a text summary of its key conclusions above it.
Analytics charts in Engineer Pro and Enterprise reporting currently provide a text summary and an accessible data table, but the interactive tooltips on hover and focus do not announce consistently in JAWS.
Every chart has a linked accessible data table containing the same values, and all analytics views support CSV export.
Documents uploaded by clients and engineers — specifications, reports, scanned drawings — are frequently inaccessible PDFs, including scans without a text layer. We do not control their production.
Uploaders are prompted to provide accessible source formats where they exist. Where you receive an inaccessible document on a live engagement, contact support and we will work with the uploader to obtain an accessible version.
Product walkthrough videos in the help centre have accurate captions and a full transcript, but audio description is not yet provided for the sequences that are primarily visual demonstration.
Each video has a step-by-step text article covering the same content, and those articles are the canonical version of the guidance.
Community posts created before August 2025 may contain images without alternative text and heading levels that skip, because the original editor did not enforce either.
The current editor requires alternative text on images and enforces heading structure. Historical content is being remediated by view volume, highest first.
A partially conformant claim means parts of the content do not fully conform. Those parts are the known limitations above.
| Item | Detail |
|---|---|
| Target standard | WCAG 2.2 Level AA |
| Conformance claim | Partially conformant — see known limitations |
| Additional criteria met | Several Level AAA criteria, including 2.4.13 Focus Appearance and 1.4.8 Visual Presentation on body content |
| Also assessed against | EN 301 549 v3.2.1 and Section 508 |
| Last full audit | 12 August 2026, by an external accessibility consultancy |
| Audit method | Manual expert evaluation, assistive technology testing, and testing with disabled participants |
| Next scheduled audit | February 2027 |
| Statement last reviewed | 25 September 2026 |
We would rather hear about a barrier than have you work around it silently. Reports about accessibility go to the engineering team directly, not into a general queue.
If something on the platform prevents you from doing your work, contact us and describe what you were trying to do, the page you were on, and the assistive technology, browser and operating system you are using if you know them. Any of those details is helpful; none of them is required.
We aim to acknowledge accessibility reports within two business days and to give a substantive response, including either a fix date or a workaround, within five business days. Where a barrier blocks live work, we will provide the information or document in an alternative format in the meantime — plain text, structured data, a tagged PDF, or a direct conversation with someone who can read the material to you.
If you are not satisfied with our response, ask for it to be escalated to the accessibility lead, who will review it independently. Where you have a right to complain to a national enforcement body under local accessibility law, that route remains open to you and we will not ask you to exhaust our process first.
Statement last reviewed 25 September 2026. This site is a product demonstration; conformance details, audit dates and contact addresses are illustrative.
