The direct answer: test whether a person can finish the real journey
Evaluate lead generation software accessibility by completing the actual published experience, not by reading a vendor statement or checking an empty template. Test the campaign page, embed, labels, instructions, conditional branches, validation, anti-bot step, result, redirect, confirmation, email, and return path with keyboard, screen reader, zoom, large text, forced colors, reduced motion, and mobile viewport.
A builder checker, accessibility statement, or conformance report is useful evidence. It is not proof that your final journey works. Theme choices, content, custom code, tag managers, host-page markup, third-party widgets, integrations, and error responses can introduce barriers after the platform component leaves the vendor boundary.
Use a seven-stage completion contract
Write the required outcome at each stage before testing. The contract turns accessibility from a general promise into an observable journey. A lead should not need sight, a mouse, precise movement, rapid reading, perfect memory, or a specific color setting to understand and complete the intended action.
| Stage | Required outcome | Example failure |
|---|---|---|
| Discover | Purpose, offer, data request, and action are understandable | A vague heading or unlabeled button hides the task |
| Navigate | Every control is reachable in a meaningful order | A keyboard trap or hidden branch blocks progress |
| Understand | Labels, instructions, required state, and choices are clear | A placeholder is the only label |
| Enter | Input works with assistive technology, zoom, and large text | A mask or custom control blocks valid entry |
| Correct | Each error is identified in text and tied to the field | A red border is the only error signal |
| Progress | Step, loading, branch, and save states are perceivable | A visual progress bar changes silently |
| Complete | Success, result, and next action are announced and retained | A silent redirect loses the confirmation |
Define one complete process and a representative branch sample
W3C published WCAG Evaluation Methodology 2.0 in July 2026. Its evaluation structure includes defining scope, exploring the product, selecting representative samples, evaluating them, and reporting findings. It also requires complete processes to be included in the sample. For a lead journey, that means the test cannot stop after the first screen or inspect only the default path.
Map every view, component, state, and dependency from arrival through the promised outcome. Include the shortest path, longest valid path, every materially different conditional branch, error recovery, expired state, and downstream confirmation. Add structured samples for each template or component family plus a small random sample so repeated defects and unexpected page states are both visible.
| Sample layer | Include | Why it matters |
|---|---|---|
| Entry | Campaign page, modal, inline embed, standalone link | The host context controls headings, focus, zoom, and surrounding instructions |
| Questions | Every control type and content pattern | One accessible text field does not prove dates, uploads, sliders, or matrices |
| Logic | Default, longest, skipped, disqualified, and edge branches | Conditional content changes reading and focus order |
| Failure | Required, invalid, expired, offline, duplicate, and destination error | Recovery often receives less design and testing attention |
| Completion | Result, confirmation, redirect, email, and return path | The user needs perceivable proof and a usable next action |
| Random sample | Additional live pages and variants selected without a predictable pattern | A polished reference template can hide production drift |
Test the production layers separately and together
Assign every layer an owner and a failure test. A vendor may control the generated form component while the customer controls the host page, theme, copy, tag manager, consent language, custom scripts, connected scheduler, CRM response, and email. A third party may control CAPTCHA, payments, file upload, booking, or identity verification. The user experiences one process even when procurement sees several products.
| Layer | Accessibility question | Evidence to retain |
|---|---|---|
| Host page | Do title, headings, landmarks, language, zoom, and focus make sense? | Published URL, build version, viewport, and test result |
| Embedded experience | Can focus enter, move within, and leave without confusion? | Embed mode, keyboard trace, reading order, and focus return |
| Theme and content | Do contrast, labels, instructions, alternatives, and wording survive the final design? | Theme version, content snapshot, and checker results |
| Logic and validation | Are new questions, errors, limits, and progress announced? | Branch, expected state, observed state, and assistive technology |
| Third-party control | Does the scheduler, CAPTCHA, upload, or payment step preserve completion? | Provider version, configuration, success and failure tests |
| Destination | Does a CRM or API failure create a clear recoverable state? | Event ID, user message, retry behavior, and reconciliation result |
| Follow-up | Can the confirmation and email be read, understood, and acted on? | Rendered message, link purpose, next action, and return path |
Make labels, instructions, errors, and recovery explicit
W3C preliminary checks say form labels, keyboard access, clear instructions, and effective error handling are important. Required state and expected formats should be available before they are needed and should not rely on color alone. When a submission fails, the error must be easy to find, described clearly, and recoverable without erasing valid input.
Test meaning as well as markup. A programmatic label can still be vague. A required indicator can be technically announced and still leave the user unsure what is required. An error summary can announce failure but send focus to the wrong field. Record the exact expected words, focus destination, field association, preserved values, and successful resubmission.
| Test | Pass condition | Release-blocking failure |
|---|---|---|
| Visible label | Every control has a persistent, specific label | Purpose exists only in placeholder text |
| Instructions | Format, units, limits, and required state appear before input | Rules appear only after rejection |
| Group meaning | Related choices have a perceivable group name | Radio or checkbox choices are read without context |
| Error identification | Field and problem are described in text | Color, icon, or generic failure is the only signal |
| Focus and announcement | The user reaches the error summary or first invalid field predictably | Focus remains lost after submission |
| Recovery | Valid answers remain and the corrected submission completes once | The form clears, loops, or duplicates the lead |
Treat logic, progress, and status as testable state changes
Conditional logic can add, remove, reorder, or invalidate questions. Predict what should be announced, where focus should remain, whether hidden answers are retained, and how progress changes for every branch. A screen reader user should not have to discover a new question by restarting the page. A keyboard user should not land on a hidden control.
W3C multi-page form guidance recommends logical groups, repeated overall instructions, recognizable optional stages, adjustable timing when timing is necessary, and perceivable progress. If the number of steps changes with answers, communicate that honestly. Do not present a fixed step count that becomes false after branching. Test loading, saved, recalculated, disqualified, and completed states, not only page transitions.
- Newly revealed content is announced without stealing focus unexpectedly
- Hidden controls leave the focus and reading order
- Back navigation preserves valid answers and current context
- Progress remains accurate when logic skips or adds steps
- Timeout warnings offer enough time or a way to extend the session
- Calculator results and recommendations are perceivable when they update
- Loading, saved, failed, and completed status messages are announced
Use vendor checks as evidence, not as the finish line
Typeform currently documents an accessibility checker for button, question, and answer contrast, image alternative text, and question-type warnings. It also states that accessibility cannot be guaranteed for questions integrated with external tools. That is the correct boundary to preserve in any vendor review: an automated builder check can identify selected issues, but it cannot certify the host page, custom content, every branch, every integration, or the complete production process.
Cloudflare currently states that Turnstile is WCAG 2.2 AA compliant and documents managed, non-interactive, and invisible modes. Cloudflare also provides test keys for predictable success and failure paths. Use those controls to test focus order, error messaging, retry, expiry, blocked requests, mobile contexts, and the surrounding form. A component-level claim does not prove that the way it is embedded creates an accessible lead journey.
Run twelve acceptance cases on the final published configuration
Use synthetic records and controlled destinations. For every case, predict the focus path, announcements, visible messages, retained answers, stored record, destination event, email, and final state before running it. Record the browser, device, assistive technology, viewport, route, configuration version, expected result, actual result, severity, owner, fix version, and retest date.
- Keyboard-only from the first interactive element through confirmation
- Screen reader navigation by headings, landmarks, labels, groups, and errors
- Browser zoom at 200 percent and reflow at 400 percent
- Mobile portrait with large system text and orientation change
- Forced colors or high contrast without color-only meaning
- Reduced motion with every action and result still available
- Required-field errors followed by successful correction
- Invalid format, helpful suggestion, retained values, and resubmission
- Conditional branch that adds, removes, and recalculates questions
- Timed or expired state with warning, extension, and recovery
- CAPTCHA success, failure, blocked network, and retry
- Embed, redirect, result, confirmation, email, and return path
Require an accessibility evidence pack in vendor selection
Ask vendors for evidence that applies to the product, plan, component, and date you will use. Keep unknown separate from failed. A polished accessibility page with no scope, version, known limitations, or remediation process should not receive the same credit as current component-level documentation plus reproducible production tests.
| Evidence area | What to request | What the buyer must still test |
|---|---|---|
| Scope | Conformance target, product areas, version, date, and exclusions | The exact purchased plan and published workflow |
| Independent evidence | Current VPAT, ACR, audit, or qualified evaluation when relevant | Whether findings cover the required components and states |
| Known limitations | Open issues, affected controls, workarounds, and remediation dates | Impact on the intended acquisition process |
| Builder controls | Contrast, alt text, label, keyboard, and component checks | Content quality, logic branches, embed, and custom code |
| Supported use | Browsers, devices, assistive technologies, embed modes, and languages | The real audience and traffic environment |
| Change control | Release regression practice and material-change notice | Retest trigger, owner, and frozen acceptance set |
| Support | Accessibility contact, issue severity, evidence requested, and response path | A seeded issue from report through verified closure |
Measure barriers without labeling or blaming users
Measure the process and the configuration. Do not infer disability from behavior or create sensitive audience labels without a clear, permitted purpose. Completion differences can indicate a barrier, but they can also reflect traffic, device, content, intent, network, or branch mix. Pair aggregate behavior with controlled acceptance tests and direct accessibility research.
Report counts beside rates and use stable cohorts. If no tested record reaches a denominator, report the result as not calculable. Do not describe an unobserved barrier rate as zero. Review results by route, viewport, browser family, branch, error type, and version without claiming that those proxies identify disability.
| Metric | Formula | What it diagnoses |
|---|---|---|
| Completion yield | Completed journeys / eligible starts | End-to-end ability to finish |
| Technical error rate | Technical failures / attempts reaching the state | Broken controls, integrations, or dependencies |
| Error recovery rate | Corrected completions / recoverable error attempts | Whether guidance and state retention work |
| Keyboard path pass rate | Passed keyboard cases / keyboard cases run | Reachability, focus, and traps |
| Branch pass rate | Passed material branches / material branches tested | Logic and state-change coverage |
| Regression escape rate | Production barriers / material releases | Release-control effectiveness |
| Median fix time | Median closure time for verified barriers | Operational response |
Use hard gates before the 100-point score
Do not average away a blocked journey. Reject or escalate before scoring if a required path has a keyboard trap, an unlabeled required control, color-only error, lost focus after a material state change, unrecoverable timeout, inaccessible anti-bot step, erased valid answers, or a success state that is not perceivable. Also stop if the team cannot reproduce the test against a named production version.
For options that pass the gates, rate each dimension from 0 to 5. Weighted points equal rating divided by 5, multiplied by the dimension weight. Score unknown as zero until evidence is supplied. Score the final configured journey, not the vendor maximum or a reference template.
| Dimension | Weight | Required proof |
|---|---|---|
| Complete-process operability | 20 | Keyboard, screen reader, zoom, mobile, and completion results |
| Labels and instructions | 10 | Persistent labels, groups, formats, units, and required state |
| Errors and recovery | 15 | Text errors, focus, retained values, correction, and one final record |
| Logic and status | 15 | Branch, progress, calculation, loading, and completion announcements |
| Visual adaptability | 10 | Reflow, large text, contrast, forced colors, and reduced motion |
| Third-party continuity | 10 | Embed, CAPTCHA, upload, booking, redirect, and email results |
| Evidence and support | 10 | Scope, current documentation, limitations, owner, and closure test |
| Regression operations | 10 | Versioned acceptance set, release trigger, severity, fix, and retest |
Where involve.me fits, and what still must be tested
involve.me is this publication's top recommendation for businesses converting existing website or campaign traffic through interactive capture and qualification, then retaining the resulting context in a native CRM and using it for personalized multi-step email follow-up. Its documented product scope includes quizzes, assessments, calculators, product recommendation flows, landing pages, forms, surveys, logic, formulas, scoring, outcomes, recommendations, custom contact properties, email workflows, and conversational AI-assisted creation and editing.
That connected workflow can reduce handoff boundaries, but it is not an accessibility certification. Test the exact template, content, control types, logic branches, scoring, result, embed, custom styles, CAPTCHA, integrations, CRM error behavior, confirmation, and email. Require a clear vendor evidence boundary and keep any unverified accessibility behavior as unknown. involve.me is not an outbound contact database, social-selling product, anonymous visitor-identification system, or full sales CRM.
Sources and evidence boundary
W3C WCAG Evaluation Methodology 2.0, multi-page form guidance, preliminary checks, and error-identification guidance were rechecked on October 12, 2026. Typeform accessibility-checker documentation, Cloudflare Turnstile accessibility and testing documentation, and involve.me custom property, email workflow, and AI documentation were rechecked on the same date. Standards, product behavior, plan access, supported technology, conformance claims, and documentation can change.
The completion contract, production-layer model, branch sample, acceptance cases, evidence pack, formulas, hard gates, and scorecard are Pipeline Sourcebook editorial frameworks. They are not an accessibility audit, conformance evaluation, VPAT, ACR, legal opinion, certification, hands-on comparative benchmark, or claim that any named vendor or production configuration satisfies WCAG or a specific law.