The short answer: accessibility is confirmed before mockups, not after launch. Waiting until the end of a redesign costs more and can harm your forms, documents, and donation journey.
Ask the right question first: Is your nonprofit facing a specific requirement, a contract clause, or an expectation from your audiences?
Framing Web accessibility in Quebec requires three steps: qualifying your obligation, describing verifiable criteria, and planning tests and governance.
A benchmark to understand the issue: according to the 2022 Canadian Survey on Disability, 21.0% of Quebecers aged 15 and over had at least one disability that limited their daily activities. This figure does not imply any legal obligation, but it highlights the scale of usage obstacles to prevent.
Is Web accessibility a requirement for your nonprofit in Quebec?
SGQRI 008 3.0: Start with your organization's status and your contracts
First mistake to avoid: believing that a government standard automatically applies to all types of organizations.
SGQRI 008 3.0 — the Standard on the Accessibility of Quebec Government Websites — came into force on April 29, 2024. It targets public bodies designated by the Act respecting the governance and management of the information resources of public bodies and government enterprises, not all non-profits. It applies to new content from the design phase and to significant modifications of a digital publication.
For an independent nonprofit, four verifications are necessary before making a decision:
- your legal status and any potential link with a public organization;
- clauses in a current contract or call for proposals;
- requirements from a partner ministry or funder;
- commitments already made to your users.
Note: the Canadian Accessibility Act applies to organizations under federal jurisdiction. Being a Quebec non-profit alone does not determine whether it applies. Check if your structure falls under federal jurisdiction or if a contract imposes specific requirements.
Accessibility affects your donations, your services, and your audiences' trust
An accessible website is often perceived as a matter of appearance. The obstacles are elsewhere:
- navigation that is impossible with a keyboard;
- text that is too faint or too dense to read;
- a form whose fields are not clear;
- a video without subtitles;
- a PDF document that is unreadable with a screen reader.
Your "Make a Donation" or "Get Help" page is a gateway to your mission. If it blocks access, you lose a donation or service request. The 21.0% rate mentioned above justifies more inclusive design from the start.
What should be included in a Web accessibility specification for Quebec?
Transform vague intentions into verifiable requirements
The statement "The website must be accessible" means nothing in a submission. It is impossible to compare two providers on that basis.
A good specifications document clarifies five elements: the framework, scope, deliverables, tests, and governance. Prefer verifiable verbs: target, document, test, correct, validate.
Framework: specify the applicable standard. For a public body subject to SGQRI 008 3.0, the Standard is based on WCAG 2.1 and certain WCAG 2.2 criteria — the Web Content Accessibility Guidelines published by the W3C — with a general target of level AA. For a non-profit with a contractual obligation to meet WCAG 2.2 AA, combine the level with a test scope and clear acceptance criteria.
- Scope: pages, forms, member area, PDF documents, videos, donation module, third-party content.
- Deliverables: component inventory, gap list, test report, fixes and, when SGQRI applies, elements needed for the "Accessibility" page and the planned support offer.
- Tests: automated validation, keyboard navigation, manual verification, and where appropriate, Web accessibility audit by a specialist.
- Governance: person responsible, team training, publication criteria, budget for fixes after launch.
Distinguishing roles is important: the agency designs and integrates the agreed-upon components, your nonprofit validates its obligation, provides content and organizes continuity.
Do not forget documents, forms, and integrations added after launch
The Standard also covers downloadable documents and multimedia. A well-designed mockup can miss an obstacle if these elements are not anticipated.
In a redesign, inventory what creates the most risk after delivery:
- PDF files and other downloadable files;
- registration forms and their email confirmations;
- videos and audio content;
- donation and payment modules;
- appointment booking tools;
- digital publications from third-party providers.
Take the example of a donation form: clear fields, understandable error messages, keyboard-testable journey, third-party service behavior verified before launch. A page added six months later can compromise these settings.
The table below translates your accessibility requirements into concrete questions to ask before submission:
| Element | Question to ask in the specifications | Evidence expected before going live |
|---|---|---|
| Framework | What standard or level are you aiming for, and why? | Test plan, documented hypotheses and exclusions. |
| Design and components | How do you verify contrasts, headings, focus states and reusable components? | Component library and test screenshots. |
| Content | Who provides alt text, captions and accessible PDFs? | Publishing guide and corrected sample. |
| Forms and donations | Which critical user journeys are tested with keyboard and screen reader? | Test scenarios for registration, donation, and contact. |
| Validation | What independent audit is planned when obligation or risk justifies it? | Gap report, corrective actions, and go-live decision. |
How to integrate accessibility into a Webflow redesign without making false promises?
What Webflow makes easier, what it cannot certify
An accessible Webflow redesign requires reliable tools, properly used. Webflow provides you with:
- semantic HTML elements — code that gives meaning to a page's structure — to be used properly;
- management of alternative text for images;
- ARIA settings — indications added to the code to help assistive technologies like screen readers;
- an audit panel that identifies notably images without alt text, poorly descriptive link titles, breaks in heading hierarchy, and missing form labels;
- a visual preview that simulates certain situations: forms of colorblindness, blur, text enlargement.
These features are aids, not an audit or certificate of compliance. Real accessibility depends on the structure chosen, content, custom interactions, third-party integrations, and tests performed. For a public body covered by SGQRI, the responsible party must ensure compliance and necessary audits.
Plan a verification before and after launch
A solid control program protects your budget and credibility. Plan for:
- an initial audit before mockups;
- testing during integration;
- a verification of critical journeys before publication;
- update rules after launch.
Automated tools speed up the detection of common errors. They do not replace manual testing: keyboard navigation, error messages, content meaning, real-world scenarios. The W3C — the organization that publishes the WCAG — designs these rules to be verified by a combination of tools and human evaluation.
For a donation journey, registration, or access to an important service, plan testing with people who use keyboard-only navigation or a screen reader. When scope, risk, or contract justifies it, independent validation by a Web accessibility specialist, with documented methodology and results, is the best protection.
Note: We share here best practices for design and integration on Webflow. If your organization is subject to strict accessibility obligations, it is better to have everything validated by a certified expert.
An accessible redesign defends itself before it corrects itself
The process requires three steps: qualify, document, verify.
A specification does not guarantee compliance on its own. However, it makes your submissions comparable, protects your budget, and prevents post-delivery updates from compromising best practices. This is where Web accessibility in Quebec is concretely played out.
Are you planning a redesign or a submission?Validate accessibility priorities first to integrate into your specification. You will be able to clearly define what falls under design, content, integrations, and independent validation.
FAQ
Does SGQRI 008 3.0 apply to all non-profits in Quebec?
No. The Standard applies to public organizations designated in its scope. A non-profit must first verify its legal status, contracts, calls for tender, and requirements from its funders before validating an obligation.
Is WCAG 2.2 AA mandatory for a Webflow site?
The level to specify depends on the applicable framework. For Quebec public organizations concerned, SGQRI sets an AA target based on WCAG 2.1 and certain WCAG 2.2 criteria. Webflow is not a compliance certificate: the organization remains responsible for validating its obligations.
Is an automated tool sufficient to audit a website's accessibility?
No. An automated tool detects certain errors, but it does not replace manual testing, keyboard navigation, form evaluation, or, in some cases, specialized validation.
What should you ask a Webflow agency in a submission?
Ask for the scope covered, criteria targeted, planned tests, content owner, handling of third-party integrations, gap report, potential fixes, and training for the team that will publish after launch.
Are PDFs and videos part of Web accessibility?
Yes. The Quebec Standard covers Web content, downloadable documents, and multimedia. Even if your nonprofit is not subject to it, plan for these formats in your redesign to avoid costly fixes after launch.
