Form optimization means making it easier for the right person to send an enquiry that your team can use. That involves deciding what each field is for, explaining what happens next, and helping people recover when something goes wrong. Counting fields is only one part of the job. A shorter form can collect more submissions while leaving sales with fewer useful conversations.
Start with the next decision your team must make. Keep the information necessary for that decision, defer questions that belong in a conversation, and remove questions nobody acts on. Then test the complete journey: understanding the request, entering information, correcting mistakes, submitting successfully and receiving an accurate confirmation.
This guide is for marketing leads and website owners reviewing an enquiry form for a Canadian service business. It includes a field-purpose matrix, a fictional worked example and a keyboard/mobile error-recovery test script. The examples are invented teaching scenarios, not client results. No live form testing is claimed.
Define a useful enquiry before changing the form
A form is an agreement between the visitor and the receiving team. The visitor provides information because they expect a particular response. Sales needs enough context to provide that response. Problems begin when the form quietly serves additional purposes: feeding a reporting dashboard, completing every CRM property or collecting information that might become useful someday.
Write one sentence describing the transaction. For a fictional office maintenance company, it could be: “Request a conversation about recurring maintenance at a business premises.” That is different from requesting an exact quote, reporting an urgent repair or booking a confirmed appointment. Each promise requires different information and a different confirmation.
Next, separate three outcomes. A received request has reached the system designated to accept it. A usable request contains enough accurate information for the next action. A qualified enquiry meets your agreed business criteria after appropriate review. A visitor pressing a button proves none of those outcomes by itself.
For the maintenance example, usable might mean a reply address plus enough information to understand the requested service. Qualified might mean the premises is within the service area and the requested work is offered. The company need not know the exact floor area before starting that conversation. It may need the municipality before assigning the enquiry.
Agree these definitions with the person who receives the form, rather than only with the person editing the website. Ask for patterns: which missing answers prevent a response, which questions are asked again anyway, and which apparently complete answers turn out to be guesses? Use summaries without copying identifiable customer messages into the worksheet.
For the broader discipline of forming and evaluating hypotheses, see Canada Create’s introduction to conversion rate optimization. Here, the unit of work is a specific form and the decisions its answers support.
Give every field a decision and an owner
The field-purpose matrix is a working agreement, not an inventory of labels. Make one row for every proposed question, including hidden values that the form captures. Record the purpose, the decision changed by the answer, who uses it and when it is needed. “Sales asked for it” identifies a requester; it does not yet explain a purpose.
Try completing this sentence: “If the visitor answers differently, we will…” A service choice may change which team replies. A location may establish whether the business can help. A company-size question may change nothing until a later discovery meeting. When you cannot finish the sentence concretely, challenge the field before making it compulsory.
Use five decisions in the matrix: keep required, keep optional, show conditionally, defer or remove. Required means the stated request cannot reasonably proceed without the answer. Optional means the visitor can omit it without being penalized or silently rejected. Conditional means another answer creates a specific need. Deferred means it belongs at a later, named stage. Removed means it has no approved collection purpose in this form.
The following condensed matrix is fictional. It illustrates decisions for one maintenance enquiry, not a universal form specification.
| Question | Decision it supports | Treatment |
|---|---|---|
| Email address | Send the requested initial reply | Required for this email-first service |
| Municipality | Check coverage before assignment | Required; no full address yet |
| Service needed | Identify the relevant team | Required; include “Not sure” |
| Phone number | Arrange a call if the visitor prefers | Conditional on choosing a callback |
| Exact floor area | Prepare a later estimate | Defer to a scoping conversation |
| Additional context | Explain an unusual request | Optional with a narrow prompt |
We test pages, forms and offers to turn more visitors into enquiries.
Then add the cost of a wrong or missing answer. If an unknown municipality can be resolved easily, the team may choose to allow it and route to a review queue. If every unknown answer triggers a dead end, an apparently helpful “Not sure” option is misleading. The form and the receiving process must agree.
Assign an owner to each kept field. That person should be able to explain its use, maintain its options and review exceptions. A practical review date helps catch questions left behind after a service or workflow changes. It also makes removing a field a documented decision instead of a debate about personal preference.
Balance qualification against the work you ask visitors to do
Field count is a rough description of a form, not a complete measure of effort. Choosing one familiar service from a short list can be easier than writing a detailed explanation in a single text box. Finding an account number, estimating a project budget or locating an attachment can require work outside the form entirely.
Evaluate each question on four dimensions: can the person answer it now, do they understand why it is needed, how sensitive is the answer, and what happens if they cannot provide it? This reveals differences that a simple “six fields versus four” comparison hides.
Consider budget. A business may genuinely need to establish whether the scope is feasible. Requiring an exact amount before describing likely scope can encourage invented numbers. Possible alternatives include publishing a verified starting range, asking for a broad planning band with “Not established,” or discussing budget after the first response. The appropriate choice depends on the actual offer and sales process.
Do not treat free email addresses, unfamiliar job titles or incomplete company profiles as automatic evidence of poor quality. A legitimate small-business owner may use a personal inbox. A buyer gathering initial information may not know the final budget. Your qualification rules need a business rationale and a review path for uncertainty.
Equally, removing every qualifying question can create unnecessary work. If a company serves only a defined region, a clear service-area question may save both parties an unproductive exchange. State the boundary before the visitor invests effort. An honest explanation that the service is unavailable is different from allowing submission and discarding it later.
When changing a required field, describe the trade-off explicitly: “We will defer floor area because it does not change the first response; we will monitor requests that need an additional scoping exchange.” That creates an observable question. It avoids promising that fewer fields will necessarily improve sales.
Keep a distinction between missing information and a negative answer. “Unknown” is not the same as “outside service area,” and a blank budget is not the same as “insufficient budget.” Preserve those meanings in the receiving process so that form simplification does not accidentally become harsher qualification.
Make labels and instructions do useful work
A label identifies a question; help text explains how to answer it. Keep the label visible while the visitor types. Placeholder text can show an example, but it should not carry the only explanation of the field. The W3C WAI labelling tutorial describes associating controls with labels; for ordinary HTML controls, the label’s for value can match the control’s unique id.
Prefer “Municipality where service is needed” to “Location.” The latter could mean a home address, head office or work site. Prefer “What service are you considering?” to an unexplained internal department name. Test the wording with someone who does not know your CRM categories.
Explain required and optional status consistently. If a symbol marks required fields, explain it before the form. Provide format instructions before an error occurs, and keep important help available as people enter data. WAI’s form instructions guidance discusses both overall instructions and information associated with individual controls.
Visible wording and programmatic state should agree. For ordinary HTML controls, use the native required attribute where applicable; aria-required communicates a requirement but does not enforce validation. Optional fields must accept a blank answer in both the browser and the receiving system. For a group of radio buttons or related checkboxes, provide a group question as well as individual option labels. WAI’s grouping guidance shows the fieldset and legend pattern.
Write narrow prompts for free text. “Tell us which service you need and any timing constraints” gives a more useful starting point than “Tell us everything.” Where sensitive details are unnecessary, say so. A short instruction can discourage oversharing, but it does not replace appropriate handling if somebody includes sensitive information anyway.
Use answer options that reflect how visitors describe their need. Avoid making people choose between two overlapping categories just to continue. Where appropriate, include “Not sure” and make sure someone owns that route. Review the frequency of that selection as a possible wording problem, not simply a low-quality lead signal.
Submission wording should describe the actual commitment. “Request a call” differs from “Book a call.” The confirmation must preserve that distinction. Canada Create’s call-to-action guide covers broader CTA wording and placement; this review concerns whether the form’s promise matches what submission actually does.
Choose controls that accept reasonable answers
A form should not force people to reverse-engineer its database. If the receiving system stores separate name components, determine whether the first enquiry really requires that structure. If a website address is optional, a person without a website should not need to invent one. If you collect a telephone number, consider the countries and extensions your team actually supports.
Document accepted formats in the matrix before adding validation. Include realistic variations such as spaces around an email address, accented names, apostrophes and telephone punctuation. Agree what can be normalized harmlessly and what needs clarification. Silently rewriting a meaningful answer to fit a rule can conceal a problem rather than solve it.
Use appropriate input types and supported autocomplete purposes for fields about the person completing the form. WCAG 2.2 SC 1.3.5 applies to listed input purposes where the technology supports identifying them. The W3C explanation of input purpose distinguishes a general input type from a more specific purpose, such as the user’s own email address. Verify the resulting behaviour in the browsers you support.
For a person’s own email address, type="email" describes the input type while autocomplete="email" identifies its purpose. Match supported tokens to the actual question; a service-site municipality is not automatically the visitor’s home municipality. Correct programmatic purpose and successful browser autofill are separate checks: autofill alone does not establish SC 1.3.5, and a browser declining to autofill does not by itself establish failure.
In the planned test, try a fictional profile in an isolated browser profile, inspect which values appear and confirm that validation accepts them. Clear only that test profile afterwards. A phone keyboard may make entry easier, but it does not prove that international punctuation, extensions or correction work correctly.
For an ordinary enquiry, avoid file uploads unless the next decision needs them. Attachments introduce additional instructions, failure cases and handling responsibilities. When a file is essential, state accepted types and limits before selection, identify upload failures clearly and provide a workable alternative. Have the receiving team define the handling process before enabling the control.
Keep unknown answers honest. An estimated project date should remain an estimate. If the visitor chooses “Flexible,” do not convert it into a fixed date just because the receiving system expects one. The quality of the information depends on preserving what the person meant, not merely satisfying required properties.
Design the correction journey before writing the success message
Error recovery deserves its own specification. For each required field, document what happens when it is empty, malformed or rejected by the server. Then document how the visitor discovers the problem, reaches the affected control, corrects it and continues without losing unrelated work.
WCAG 2.2 SC 3.3.1 requires automatically detected input errors to identify the affected item and describe the error in text. A red border alone does not provide that description. The W3C error-identification guidance explains this requirement without prescribing one mandatory display pattern.
When a correction is known, provide a useful suggestion unless doing so would jeopardize security or the purpose of the content, as described in SC 3.3.3, Error Suggestion. “Email address: include an @ sign and a domain” gives the visitor a next step. “Invalid input” leaves them guessing.
For forms with several errors, an error summary can help visitors orient themselves. Link each summary item to the corresponding field, repeat the field’s label and provide local error text. WAI’s user-notification tutorial describes this pattern. Check the implemented focus and announcement behaviour rather than assuming that adding a summary makes recovery accessible.
Choose a predictable focus destination after an unsuccessful submission, such as a focusable summary or the first invalid control. Verify that following a summary link actually reaches the control and exposes its error. Associate help and error text with the input, for example through aria-describedby, and update invalid state when the error is resolved. Do not move focus repeatedly while someone types. These are implementation choices to test, not a requirement to combine every announcement mechanism.
Keep browser and server rules aligned. WAI’s validation guidance explains why client-side checks do not replace server validation. Test a controlled server rejection as well as a browser-detected error. Agree limits and accepted formats before release; a syntactically plausible email address does not prove that the inbox exists or belongs to the visitor.
Preserve valid, non-sensitive answers where appropriate within the active correction journey. If the email field is wrong, the visitor should not have to retype an unrelated service description. Persistence beyond the current session is a separate product and privacy decision; do not introduce indefinite browser storage as a quick usability fix.
Distinguish user-correctable input errors from technical failures. A server outage is not a malformed email address. An expired session is not a missing service selection. An uncertain network response may mean the request was accepted even though the browser did not receive confirmation. Each state needs honest wording and an appropriate recovery route.
Finally, test validation after correction. Old errors should not remain attached to corrected answers. New errors should not appear only after the visitor solves the first one. If the form validates while typing, check that it does not repeatedly interrupt someone who has simply not finished entering an answer.
Check keyboard access and mobile correction as separate tasks
A form can look clear on a desktop and still be difficult to complete without a mouse. WCAG 2.2 SC 2.1.1 addresses operation through a keyboard interface. For a lead form, test the route through fields, choices, help, submission and recovery. See the W3C keyboard explanation for the criterion and its scope.
Follow the sequence from the page entry point rather than clicking directly into the first field. Use Tab and Shift+Tab to move through controls and the conventional keys for each control type. Record unexpected jumps, unreachable controls and places where you cannot leave a component. Conditional fields and error summaries need to be included in this route.
Check that a keyboard user can see the current position. SC 2.4.7, Focus Visible addresses a visible focus indicator. Separately, SC 2.4.11, Focus Not Obscured (Minimum) requires that an author-created element does not entirely hide a component when it receives keyboard focus. Sticky headers, chat panels and consent banners deserve particular attention during correction. Apply the criterion’s notes about user-movable content and user-opened overlays before assigning a conformance failure, including whether the component can be revealed without advancing focus.
On a phone, repeat the error journey with the on-screen keyboard open. Can the person still find the error, reach the correction and see what happened afterwards? Rotate the device where supported, dismiss the keyboard and reopen it. Check that the page does not lose entered values or strand the person below an unseen error.
For vertically scrolling content, SC 1.4.10, Reflow addresses presentation at a width equivalent to 320 CSS pixels without loss of information or functionality and without two-dimensional scrolling, except for content that requires a two-dimensional layout. A form review should include narrow-width and zoomed layouts; one phone screenshot is insufficient evidence.
For pointer targets, SC 2.5.8, Target Size (Minimum) uses 24 by 24 CSS pixels with specified exceptions, including spacing, equivalent controls, inline targets, unmodified user-agent controls and essential presentation. Do not reduce this to “every checkbox must be 24 pixels.” Assess the actual target and relevant exception, and favour comfortable spacing for important actions.
These are selected checks, not a complete WCAG evaluation or a statement of legal compliance. Ask an accessibility specialist to review the applicable scope, assistive-technology behaviour and unresolved findings. A working keyboard route alone cannot establish that labels, errors, contrast and announcements meet every relevant requirement.
Make conditional questions and multiple steps earn their place
A conditional question is useful when one answer creates a real need for another. Choosing “Please call me,” for example, can reveal a phone field. State that requirement near the choice. If the visitor changes back to email, the hidden phone field must not remain an unexplained submission blocker.
Decide what happens to an answer when its question becomes irrelevant. The value might be retained temporarily if the person switches back, or cleared with an explanation where appropriate. The key is to avoid sending stale information that contradicts the final choice. Record that rule in the matrix and include a branch-switching test.
Do not use conditional logic merely to hide the apparent length of an unchanged questionnaire. Count the work across the whole route. A short first screen followed by unexpected compulsory questions may create a different kind of friction: the person has already invested time before learning the real information requirement.
Split a form into steps when the grouping helps people complete a genuinely necessary task. Identify the current step, make backward navigation predictable and explain what remains. If the request can be completed clearly on one screen, a multi-step design introduces navigation and state-management questions that may provide little benefit.
Within the same process, WCAG 2.2 SC 3.3.7, Redundant Entry addresses information already entered or provided that must be entered again: it should be automatically populated or available for selection, subject to exceptions for essential re-entry, security or information that is no longer valid. Browser autofill alone is not the website-provided reuse this criterion calls for. Review repeated contact details across steps instead of making visitors supply the same answers afresh.
Test the least convenient route: choose a branch, enter its answer, go back, change the branch and continue. Verify both the visible form and the accepted record in an authorized test environment. This is where a clean-looking interface can hide contradictory data or validation rules. A happy-path demonstration will not reveal those problems.
Collect information proportionate to the request
Data minimization belongs in the field decision, before styling begins. The Office of the Privacy Commissioner of Canada’s PIPEDA guidance on limiting collection says organizations should limit personal information to what is needed for identified purposes. Apply that question to visible fields and hidden collection alike.
In the fictional maintenance example, a municipality may support an initial coverage check while a full street address can wait until site planning. That is a design hypothesis to review against actual operational needs. It is not a universal determination that collecting addresses is unnecessary.
Before adding a field, ask where the answer will go. A single form can create a stored entry, an email notification, a CRM record and a support ticket. Identify necessary recipients and avoid casually reproducing the full message in every notification. Decide access and retention with the person responsible for privacy and records management.
The OPC’s meaningful-consent guidance emphasizes understandable information about collection, purposes, sharing and relevant risks. It also distinguishes necessary activities from other uses for which people need a choice. Explain the form’s actual handling near the decision and make fuller information available. A generic checkbox cannot establish that every intended use is appropriate.
Keep the requested response separate from optional promotional contact. Have a qualified reviewer determine the consent language and applicable privacy and electronic-messaging obligations for the organization. This guide does not determine which laws apply or provide a compliance sign-off.
For healthcare-related enquiries, do not turn a marketing contact form into a medical history form. Use a separately approved intake process when sensitive information is genuinely needed. The worksheets here require only fictional test data and contain no health information. Canada Create’s dental enquiry journey checklist addresses the wider practice-to-reception handoff; this guide keeps its focus on field decisions and recovery.
Review testing evidence too. Screenshots, recordings and error logs can reproduce what someone typed. Use made-up values in planned tests, record the minimum evidence needed to reproduce a defect, and follow the organization’s approved handling rules. Do not paste real enquiry messages into a public worksheet or analytics parameter.
For Google Analytics, check more than event parameters: page URLs and titles can expose submitted information too. Google’s guidance on avoiding personally identifiable information covers user-entered form data. Keep names, contact details and enquiry text out of this guide’s analytics examples; a generic event label is not a privacy review of the full page or destination.
Specify what success, waiting and failure mean
Write the form’s state messages together so they cannot contradict each other. Before sending, the button describes the action. During sending, the form indicates that work is in progress. After acceptance, the confirmation describes what was received and the next step. After rejection, it explains the problem and what the visitor can do.
A fictional confirmation might say: “Your maintenance enquiry has been received. Our enquiries team will review it and reply by email.” Add a response window only when the team has approved one it can support. Do not imply a quote is agreed, a service is scheduled or an appointment is confirmed unless that transaction actually occurred.
For status messages that appear without a change of context, WCAG 2.2 SC 4.1.3 addresses making them programmatically determinable so assistive technologies can present them without moving focus. Have a knowledgeable tester check that the implemented waiting and completion messages are announced appropriately. Moving focus and announcing a status are distinct design choices.
Agree the acceptance point with the technical owner. Does success mean a durable request was stored, an email was sent, or a CRM accepted the record? Those are different system events. A notification failure after durable storage may need an internal alert without telling the visitor that the request vanished. Conversely, showing success before any receiving system accepts the request can leave an enquiry stranded.
Plan for an ambiguous timeout. If the browser cannot confirm the outcome, do not automatically claim that nothing was sent. Provide an approved route to check or safely retry, and ask the technical owner how duplicate requests are handled. The appropriate solution depends on the implementation; the worksheet records the required behaviour without pretending to supply a universal integration fix.
Also test rapid repeat activation and a return to the confirmation page. The business should know whether these actions create another record or simply show the existing result. A disabled button may discourage repeated clicks, but it is not sufficient evidence of duplicate protection across the full process.
If validation or submission happens asynchronously, include delayed and out-of-order responses in the controlled test plan. A response to an older answer must not overwrite the result for a corrected answer, and a late callback error must not reactivate a hidden phone requirement. A rejected request needs a usable next action rather than an indefinitely disabled button. Announce meaningful state changes without repeatedly interrupting typing. Mark this check not applicable, with a reason, if the implementation has no asynchronous route.
Work through a fictional redesign without inventing a result
Imagine Cedar Example Maintenance, a fictional company receiving requests for recurring office maintenance. Its hypothetical existing form requires a full name, company name, email, phone, full address, exact floor area, budget and a detailed message. The sales coordinator says the first task is to check service type and municipality, then arrange a scoping conversation.
The team works through the matrix before drawing a replacement. It keeps an email reply address, a service question and municipality. It offers an optional contact name and company name. It makes phone conditional on a callback preference, defers the full street address, exact floor area and budget, and replaces the broad message prompt with optional timing or service context. Email remains required for the initial reply in this particular design; the callback preference changes follow-up, not that requirement.
That proposal is not approved merely because it contains fewer compulsory questions. The team asks what could go wrong. “Not sure” must reach a person who can clarify service type. A callback choice must not silently disappear when the request is stored. An unknown municipality needs a defined review route. Sales must be able to see that budget was deferred rather than infer that the visitor has none.
Next, the team writes a recovery specimen using fictional values. A visitor enters alex.example as an incomplete email address, selects a service and chooses a municipality. On submission, the form should identify the email problem in text, offer a correction route and preserve the unrelated answers. The person changes the address to alex@example.com and continues in a controlled test environment.
The addresses are placeholders for documentation, not delivery destinations. Use an approved test inbox for any authorized integration check. Never substitute a stranger’s address or telephone number simply because a form refuses an example value.
Now imagine two entirely synthetic cohorts with comparable definitions and outcome windows. Their numbers below exist only to show why form completion alone cannot decide the question.
For this example, each eligible visit contributes at most one received enquiry; repeat attempts are merged. Every received enquiry belongs to the same observed visit cohort, and qualified enquiries are a subset of those requests after the same completed review window. The counts are not unique people, button activations or all-time CRM totals. These assumptions make the numerator and denominator comparable.
| Measure | Scenario A | Scenario B |
|---|---|---|
| Eligible visits | 1,000 | 1,000 |
| Received requests | 100 | 130 |
| Qualified enquiries | 40 | 39 |
| Received requests / eligible visits | 10% | 13% |
| Qualified enquiries / received requests | 40% | 30% |
| Qualified enquiries / eligible visits | 4% | 3.9% |
Scenario B has more received requests but does not have more qualified enquiries. The difference does not establish a causal effect, statistical significance or a commercial loss. It simply demonstrates that a favourable submission metric can coexist with an unfavourable qualified-outcome metric. Actual evaluation needs appropriate comparison design, sufficient evidence and consistent follow-up.
Run a repeatable keyboard and mobile error-recovery script
The companion set contains two worksheets: a field-purpose matrix and an error-recovery test script. Each has a blank CSV and a clearly labelled fictional example. A shared dictionary explains the columns, and instructions describe how to use them. The test script contains ten manual procedures, not software that submits enquiries. The field matrix includes eleven proposed fields, including questions deferred until later. The download also includes a primary-source reference list.
Download the lead-form worksheets (ZIP)
Begin in an authorized staging environment with fictional data and controlled destinations. Record the form version, device, browser, input method and date. Agree which receiving system you can inspect. If you cannot safely generate a failure or verify a destination, mark that test blocked and explain the missing prerequisite.
- Walk the keyboard route. Reach the form from the start of the page, move forwards and backwards, operate each control and locate the send action. Repeat through conditional questions.
- Submit missing information. Leave required answers empty. Check that the response identifies what is wrong and provides a usable correction route.
- Correct one malformed value. Use the fictional incomplete email, correct it and verify that unrelated answers remain available and stale errors disappear.
- Change a branch. Request a callback, then switch away from it. Check that hidden requirements and stored values follow the agreed rule.
- Repeat on mobile and at narrow width. Include the on-screen keyboard, error navigation, target spacing and reflow. Record actual dimensions and zoom settings.
- Check announcements with assistive technology. Verify labels, required state, error association and relevant status updates with a knowledgeable tester.
- Exercise a controlled delivery failure. Use an approved staging failure mechanism. Check wording, retained answers and the supported recovery route.
- Verify accepted and repeated requests. Match the visible confirmation to a received test record, then inspect the agreed duplicate-handling behaviour.
- Check labels, autofill and optional answers. Confirm group questions and field labels remain visible; inspect supported input purposes, test a fictional profile and submit with optional fields blank. Check agreed format and length boundaries.
- Check delayed responses. Where asynchronous behaviour exists, use an approved fixture to delay and reorder replies. Confirm stale errors cannot override corrected values, hidden branches or the latest submission state.
Record expected and observed behaviour separately. “Pass” requires evidence from the actual environment under test. A proposed design, a screenshot of a mock-up or a rehearsal of the worksheet is not a live integration result. Keep “not run,” “blocked” and “not applicable” distinct; explain any exclusion.
For each failure, record one reproducible action sequence, its effect on the visitor and the owner of the correction. Retest the changed behaviour and the nearby route it could affect. A keyboard fix that moves an error summary may also change mobile scrolling, so include both in that retest.
Evaluate useful completions and the cost of uncertainty
Choose one primary outcome before comparing designs. For a lead form, qualified enquiries per eligible visit may be more useful than button clicks. Define what makes a visit eligible, how repeat requests are handled and how long the team has to classify an enquiry. Use the same definitions for both versions.
Keep supporting measures: received requests, incomplete requests, recoverable errors, duplicate requests, unclassified enquiries and the work required for clarification. A smaller form may shift work from the visitor to the team. That can be worthwhile, but the receiving team needs enough capacity to make the new process work.
Use counts alongside rates. If thirty requests are still awaiting review, report that uncertainty instead of labelling them unqualified. If tracking covers only some visits, describe the coverage gap and restrict the numerator to requests belonging to that same observed cohort. Do not quietly divide all received leads by a partially observed audience and call the result a complete conversion rate. A zero denominator makes the rate undefined; missing counts are unavailable, not zero.
For low-volume forms, start by resolving reproducible failures and observing whether people can complete the intended tasks. Those findings can justify a usability repair without proving a percentage uplift. A before-and-after comparison can be affected by traffic mix, seasonality, staffing and changes in the offer. Record those differences rather than crediting the form for every movement.
If traffic supports a controlled experiment, plan its allocation, outcome window, sample needs and decision rules with someone qualified to analyse it. Do not stop at the first encouraging fluctuation. Keep this evaluation focused on the field decision being tested; a simultaneous offer change and sales-process change makes the explanation harder.
The guide intentionally stops short of prescribing analytics events or auditing the entire landing page. Its practical question is narrower: did the revised form help people send usable requests, recover from mistakes and provide the information needed for the next decision?
Keep the matrix current after the redesign
Review the matrix when services, locations, receiving teams or form software change. Check that every required field still changes a real decision, every conditional route has an owner and every confirmation remains truthful. Revisit repeated “Other” answers and clarification requests before adding another compulsory field.
Keep the test script with the form specification. After a material change, repeat the relevant error and recovery cases as well as a successful submission in an authorized environment. Record what remains untested. Public documentation and the W3C/WAI references in this guide were checked on 8 October 2026; the example arithmetic and worksheet structure are synthetic checks, not certification of any website.
