IFS builds software that runs essential services — energy, defence, aviation, healthcare, manufacturing. The people who operate that software don’t get to choose whether they can see a screen clearly, use a mouse, or read quickly under pressure. If our product excludes them, it has failed. Accessibility is part of the job, the same as performance or security.
We commit to designing and building every IFS product to conform to WCAG 2.2 Level AA as a baseline, to test against that standard with both automated tooling and people who use assistive technology, and to undertake VPAT conformance reporting for every product we ship — rather than a statement of intent that nobody re-checks.
Scope
This statement applies to:
- Every product in the IFS portfolio, including IFS Cloud and its component applications (Aurena web client, mobile clients, and embedded analytics).
- Products in the wider IFS suite, tracked individually by product line.
- Marketing and documentation properties we control, including design.ifs.com.
- Design system components published through Granite, our established component library across the IFS product offering, and Helix, our newer system for next-generation applications, since a conformant component is what makes a conformant product possible at scale.
It doesn’t cover third-party integrations, customer-built extensions, or tailored customer configurations we didn’t design, though we document the accessibility impact of extension points where we can.
Conformance target
| Standard | What it is |
|---|---|
| WCAG 2.2 — Level AA | Our contractual and design floor for all new work. AAA criteria are adopted selectively where they materially help — larger touch targets, sufficient contrast, plain language. |
| EN 301 549 | The European ICT accessibility standard, which incorporates WCAG 2.2 AA by reference. Our default conformance basis for public-sector and EU customers. |
| Section 508 | U.S. federal procurement standard, referencing WCAG. We complete and maintain a Section 508 edition VPAT for federally sold products. |
| European Accessibility Act | In force since 28 June 2025. We treat EAA obligations as a compliance floor for customer-facing digital services sold in the EU, not a ceiling. |
Full detail on each standard, who it binds, and how they relate to one another is on the global standards reference page.
How we get there
Conformance is a result of process, not a final audit. Our approach, detailed under Accessibility in our process, includes:
- Design-time checks — colour contrast, focus order, and content structure are reviewed before a design leaves Figma, using the same criteria engineering will later test against.
- Accessible-by-default components — Granite and Helix components ship with correct semantics, keyboard behaviour, and focus handling built in, so teams inherit conformance rather than re-deriving it. Helix, our system for next-generation applications, was built with accessibility as a starting requirement rather than a retrofit, so new products designed in it inherit a stronger baseline from day one.
- Automated testing in CI — every build is scanned with axe-core; a new violation on a changed page fails the build.
- Manual and assistive technology testing — before release, features are walked through with a keyboard only, then with NVDA, JAWS, and VoiceOver, by someone other than the person who built it.
- Testing with disabled users — for major flows, we test with people who use assistive technology as their primary means of access, not only with internal simulation.
Feedback and requests
If you encounter an accessibility barrier in an IFS product, or need this statement or a related document in an alternative format, contact your IFS account team or the accessibility mailbox referenced in your product documentation. We aim to acknowledge accessibility feedback within 2 business days and to provide a remediation plan or timeline within 10.