Before approving the launch of a website in English and French, follow a quote request through to the person who will handle it. Open the service page, complete the form, check what the visitor receives, then find the request in your team’s working tool.
This gives you a concrete way to accept the work. A page can look polished while its confirmation, response language or assignment of enquiries still needs attention.
The method below covers one service and its two language versions. Use it for a redesign or a new enquiry path on an existing website. It complements the project’s other checks, including content, redirects from old pages, performance and access permissions.
Define what should happen
Start with a statement that the person responsible for the service and the person building the website can both approve:
Someone interested in our service can describe their project in English or French. The request reaches our tracking tool with the agreed information, and the designated person knows they need to handle it.
Then name the destination. It might be a monitored inbox, a form provider’s submissions dashboard or a CRM you already use. Choose the place where your team actually works. You do not need to buy new software to carry out this check.
Record the next step you are promising the visitor: a review of their request, a qualification call or an invitation to book a meeting. A quote request should not imply that a price, service visit or booking has already been confirmed.
Prepare a test you can recognize
Agree on the test with your team and your website provider. Prefer the project’s test environment, use contact details you control and enter fictional information. Add a reference such as “TEST EN 01” to the message so you can find the request afterwards.
Plan one English test and one French test, on a phone and then a computer. If the agreed scope includes several paths or conditional branches, add a case for each. Testing only the shortest path is not enough.
If a booking or payment is part of the journey, use the agreed test mode. After launch, repeat a controlled check with the team without leaving a false order or appointment in the live system.
1. Check that switching language preserves the context
Open the English service page directly. Switch to French, then back to English. You should find the same service and be able to start the same process.
Check the information that affects the visitor’s decision: what the service includes, the area you serve, the conditions you state and the button leading to the form. The wording does not need to be a literal translation, but both versions should describe the same approved offer.
For search, Google recommends separate URLs for language versions and links that let people choose their language. Ask your provider to check that setup. This technical check accompanies the journey test; it does not promise a position in search results.[1]
2. Complete the form, then try a simple error
Start entering a request on your phone. Field labels should remain understandable as you type. Check that the questions, choices and instructions match the page’s language. W3C recommends identifying fields with labels correctly associated with the form controls.[2]
Next, try submitting with a required field left empty. Check what the message says, where it appears and how to return to the field. Repeat in the other language.
The message should explain what to correct. “Enter a valid email address” is more useful than an error code alone. W3C recommends clear feedback after submission, for both errors and success.[3]
On a computer, move through the form using the keyboard as well. Record any field you cannot reach or any step where the active field or button becomes hard to identify. These checks can reveal specific problems; they are not a complete accessibility assessment.
3. Read the confirmation as a customer
Now send the complete request. Read the message on the page and, if the journey includes one, the email you receive.
Does the confirmation describe the right next step? Is the language consistent? Are the contact details current? If it gives a response time, has the person responsible agreed to meet it?
Here is a fictional confirmation to adapt:
We have received your request. Our team will review the information before suggesting the next step. This submission does not confirm a service visit.
The exact wording depends on the service and how the business operates. Avoid adding an automatic promise of a quick response that nobody has agreed to provide.
4. Find the request on your team’s side
Ask the responsible person to open the destination tool and find “TEST EN 01”. Compare the stored information with what you entered: service, description, contact details and communication language where it forms part of the agreed journey.
If the scope includes an attachment, check that the right person can open it. If it includes a notification, check that it arrives. Confirm who takes ownership of the request and where that responsibility is visible.
In a fictional commercial renovation business, the form might pass a project type, municipality and description to the person handling enquiries. The test checks that these values arrive in the right place. It does not yet establish whether the project is feasible or profitable.
Agree on how to handle failures, too. Who is notified if the CRM connection fails? Where can the team find a request waiting to be transferred? What happens if someone submits the same project twice? Have your provider demonstrate the cases included in the project’s scope, in an environment where the test will not disrupt operations.
5. Keep an acceptance record
For each case, record what should happen, what you observed and what needs to be corrected and tested again. A simple shared record is enough.
| What to check | Evidence to keep |
|---|---|
| Same service in both languages | URLs tested and observations |
| Usable form | Device, browser, language and result |
| Understandable error | Field tested and message shown |
| Accurate confirmation | On-screen text and email, if included |
| Request received | Test reference found in the agreed tool |
| Clear responsibility | Responsible person or assignment rule |
| Failure handled | Case tested, result and agreed procedure |
| Correction verified | Date and result of the repeat test |
Keep screenshots with fictional data. A defect that prevents submission or receipt needs an explicit decision before launch. Assign an owner and a correction date to the remaining issues, then repeat the relevant test.
Measure the enquiry separately from a sale
If Google Analytics is included in the project, check what each event represents. Its enhanced measurement distinguishes the start of interaction with a form from its submission. Google also requires that personally identifiable information is not sent to Analytics.[4]
Keep separate checks for the analytics event, receipt in the destination tool and qualification by your team. We recommend verifying all three individually: a form counter does not replace reading an enquiry and does not demonstrate a sale.
Plan the right project
This check helps define what actually needs work. It may be a confirmation message, a form, a connection to your existing tool or a more complete enquiry journey.
Pixel & Practice designs bilingual websites and the systems behind them in Montréal. To discuss a project, tell us which service is involved, where your team receives enquiries and which step you want to improve. We agree on deliverables, responsibilities and acceptance criteria before work begins.
Sources
- Google Search Central, Managing multi-regional and multilingual sites, updated December 10, 2025, accessed September 12, 2026.
- W3C Web Accessibility Initiative, Labeling Controls, updated May 13, 2024, accessed September 12, 2026.
- W3C Web Accessibility Initiative, User Notification, updated June 3, 2022, accessed September 12, 2026.
- Google Analytics Help, Enhanced measurement events, undated page, accessed September 12, 2026.