Accessibility

Our commitment

Alinity is used by regulators to deliver services to the public and to registrants, including people with disabilities. Accessibility is therefore a functional requirement of the product, not an optional enhancement. We are committed to making both this website and the Alinity platform usable by the widest practicable range of people, and to removing barriers as we identify them.

How we approach accessibility

We design and build with recognized accessibility practices in mind, and we treat a reported barrier as a defect to be fixed rather than a request to be considered. We do not claim conformance with a specific accessibility standard, and we would rather say that plainly than overstate where we are.

Accessibility obligations vary by jurisdiction and by organization. Where a client has requirements under legislation such as the Accessible Canada Act or comparable provincial legislation, we work through with that client what the platform supports today and what we are actively improving.

What this means in practice

Semantic structure and correct heading order so screen reader users can navigate by landmark and heading. Keyboard operability with a visible focus indicator and no keyboard traps. Deliberate attention to text contrast throughout the interface palette.

Form fields with programmatically associated labels, clear error identification and instructions that do not rely on colour alone. Text alternatives for meaningful images and icons. Content that reflows on zoom, time limits that can be extended, and no content that flashes in a way likely to cause seizures.

Documents and generated output

Where the platform generates documents such as certificates, invoices, letters and reports, we work toward tagged, readable output. Documents authored by a client organization and uploaded into its environment remain that organization's responsibility, and we provide guidance on producing accessible templates.

Testing and assurance

Accessibility is assessed during design review and before release using a combination of automated tooling, manual keyboard-only testing, and screen reader testing with current versions of NVDA, JAWS and VoiceOver in supported browsers.

Accessibility defects are triaged alongside other defects, with barriers that block a task treated as high priority. We are glad to walk a client or prospective client through our current state, our known gaps and what we are working on.

Known limitations

Some complex data tables and configuration screens intended for administrative users continue to be improved for screen reader efficiency. Certain third-party embedded components, such as scheduling and payment widgets, are governed by their vendors' own accessibility work; we monitor these and raise issues with the vendors.

We publish and maintain a current list of known limitations for clients, with target remediation timelines.

Feedback and alternate formats

We welcome feedback, and it is the most reliable way we learn about barriers. On request we will provide information from this website in an alternate format, including large print, plain text or accessible PDF, at no cost.

We review this statement at least annually and after any significant change to the website or platform.