Accessibility

Designed to WCAG 2.1 AA.

Proposal Forge is used to write bids for Canadian public-sector buyers, and those bids are written by mixed teams on mixed equipment. This page states plainly what we have done, what we know is still wrong, and how to tell us about a barrier we have missed.

Our commitment

We design and build Proposal Forge to meet WCAG 2.1 Level AA. That is a target we hold ourselves to, not a certification: no independent audit has been carried out, and the gaps listed below are real. We would rather tell you where the product falls short than claim a compliance status we cannot evidence.

Accessibility work is treated the same as any other defect class — it is tracked, prioritised and fixed, and the automated checks below run on every build so fixed problems stay fixed.

What has been done

Keyboard operation: Menus, filters, comboboxes and dialogs are built on Radix primitives, so they open and close with Enter and Escape, move with the arrow keys, trap focus while open and return focus to the control that opened them. Drag-and-drop in the asset library and on the pipeline board has a keyboard equivalent — arrow keys to move a card, or a "Move to…" menu.
Visible focus: Every interactive element shows a 2px focus ring when reached by keyboard, including a global fallback so a component that forgets its own ring still shows one. Rings are solid rather than tinted, so the indicator itself meets the 3:1 minimum.
Colour contrast: Body-size text on light surfaces meets 4.5:1 and larger text meets 3:1. The copper accent was darkened for text and for the gradient behind white button labels, which previously measured as low as 2.6:1.
Form labelling: Text inputs require an accessible name at build time. Validation messages are linked to their field with aria-describedby, marked with aria-invalid, and announced when they appear.
Structure and navigation: A "Skip to main content" link is the first thing keyboard focus reaches. Landmarks are named, the current page is marked with aria-current, tables declare column headers, and each screen in the app sets its own page title.
Language and motion: French pages declare French as the document language. Animation, including background shimmer and hover effects, is suppressed for anyone whose system asks for reduced motion.
Automated checks: axe-core runs against the public pages on every build and fails it on any serious or critical finding.

Known gaps

These are the accessibility problems we currently know about. They are open items on our remediation plan, not accepted limitations.

Automated coverage stops at the sign-in wall: The automated sweep covers public pages only. Screens inside the application are reviewed manually, which means regressions there are caught later than on the public site.
Data tables and charts: Large procurement tables scroll horizontally and are not yet paired with a summary alternative. Chart data is available as figures in the surrounding text but is not exposed as a table on every page.
Screen-reader testing: Testing to date has been with keyboard navigation and automated tooling. Systematic testing with NVDA, JAWS and VoiceOver has not been completed, and no independent accessibility audit has been carried out.
Exported documents: Word and PDF exports carry heading structure but are not yet tagged to PDF/UA. If you need a tagged export, please ask us.

Tell us about a barrier

If any part of Proposal Forge stops you doing your work, tell us and we will treat it as a defect. Please include the page you were on, what you were trying to do, and the assistive technology and browser you were using — it makes the problem far quicker to reproduce.

Email contact@proposalforge.io or use the contact form. We aim to acknowledge accessibility reports within two business days.

If you need information that is currently only available in an inaccessible format — an export, a chart, a large table — ask us and we will supply an alternative.

Last reviewed: 2 September 2026