This is the working guide to how we design and build accessible software at IFS. It sets out the standards we hold ourselves to and the process behind them.
Start here if you’re new: read the accessibility statement for our organisation-wide commitment, then the page for your discipline below. Every page ends with something specific and checkable you can act on.
This guidance covers work built on both of our design systems: Granite, our established system across the IFS product offering, and Helix, our newer system for next-generation applications, built with accessibility as a starting requirement rather than a later pass. Where a page draws a distinction between the two, it says so directly.
Foundations
Accessibility in design
Colour, type, motion, content, and interaction patterns that hold up under WCAG 2.2 AA — and why AA is a floor, not a target.
Accessibility in engineering
Semantic structure, focus management, ARIA used correctly and sparingly, and how we test with real assistive technology.
Accessibility in our process
Where accessibility sits in discovery, design, build, and release — with a Definition of Done and named owners at each stage.
Global standards reference
WCAG, EN 301 549, Section 508, the ADA, and the European Accessibility Act — what each one requires and who it applies to.