https://www.example-insurance.co.uk/get-a-quote
Complete the motor insurance quote form through to the summary step
May 15, 2026, 10:30 AM
Zuko Agent Score
Promising but not reliable enough yet
This quote form is largely AI-ready: the agent identified the fields, navigated the page without getting stuck, and successfully triggered inline validation on the email field. The main limitations observed were inconsistent validation messaging, some restrictive email-format handling, and accessibility signals suggesting that error states may not be fully exposed to assistive technologies.
Where does this score sit on the scale?
7 key recommendations in your report
Jump to the list below to see what you can do to improve your form for AI agents.
AI Agent Readiness Summary
Key Findings
Email validation appears inconsistent between empty-state and format-state errors
When the Email field was left blank, the agent observed a message phrased as descriptive helper text turning red: "We need your email to send you the password link and set up your login details." When an invalid format was entered, the message changed to a more direct corrective error. This suggests the error pattern may not be fully consistent across validation states.
Email format handling showed some rejection behavior
The form rejected an invalid email string as expected, but the audit also flagged format-rejection behavior. That is appropriate for clearly invalid input, yet it is worth confirming the Email field accepts a wide range of valid real-world addresses and does not over-constrain users beyond standard type="email" behavior.
Accessibility signals suggest ARIA support around validation could be stronger
Although labels were identifiable and no label issue was detected, the audit flagged ARIA-related issues while inline validation was active. This commonly indicates that error text or invalid states may not be consistently announced to assistive technology, even when they are visually clear on screen.
Audit stopped at the legal-consent step by design
The form includes a required Terms and Conditions checkbox before account creation. The audit intentionally stopped before final submission at this legal-consent step, which is normal and was not treated as a usability defect.
Inline email validation was present and field-specific
The form surfaced email errors next to the relevant field during testing. The agent observed a specific inline format message for the Email field: "This email address is incomplete - it needs an @.", which is much clearer than a generic error and helps both users and automation recover.
Core fields were easy to identify with native inputs and useful autocomplete tokens
The interacted fields were all native form controls, which supports reliable automation and accessibility. The Name field has autocomplete="name", the Email field has autocomplete="email", and the Company field has autocomplete="organization", with descriptive names and ids such as name="email" / id="email" and name="company" / id="organisation".
Detailed Analysis
Field identification was strong overall thanks to native controls, clear field purposes, and appropriate autocomplete on the main text inputs. The main concern is not label clarity, but whether validation and state changes are fully exposed accessibly.
- The Name field (id="name", name="name") includes autocomplete="name", which improves identification and autofill support.
- The Email field (id="email", name="email") includes type="email" and autocomplete="email", making its purpose explicit to browsers and AI agents.
- The Company field (id="organisation", name="company") includes autocomplete="organization", which is the expected token for this kind of input.
- The terms-and-policy-checkbox field is a native required checkbox, but the audit flagged ARIA-related issues during the form interaction, suggesting that state or error messaging may not be fully announced to assistive technologies.
Navigation was straightforward: the form appeared to be a simple single-page flow with no modal interruptions, redirects, CAPTCHA, or timeout pressure. The agent moved through the fields and submit action without getting lost or blocked.
- The flow was shallow and single-page, with no multi-step navigation detected.
- No modal, redirect, CAPTCHA, bot-detection, or timeout friction was observed during interaction.
- The primary action was clearly identifiable as the "Get Quote" submit button, allowing the agent to test validation without confusion.
The form does provide inline, field-level feedback, which is a strong foundation. However, the observed error messaging for the Email field was somewhat inconsistent between the empty-state and invalid-format state, and accessibility exposure of those errors may need improvement.
- The Email field showed inline validation, which is positive, including the specific message "This email address is incomplete - it needs an @." for invalid format.
- When the Email field was empty, the observed message was "We need your email to send you the password link and set up your login details.", which appears closer to helper copy than a direct corrective error and may be less clear in an error state.
- The audit flagged ARIA issues while validation messages were present, suggesting the Email field's error state may not be reliably conveyed through attributes such as aria-invalid or linked error text.
Data entry was generally smooth because the form uses native inputs, sensible field types, and a simple layout. The main area to review is whether the Email field accepts the full range of valid addresses without unnecessary rejection.
- All interacted controls were native HTML inputs, which reduces ambiguity and supports reliable completion.
- The Email field uses type="email", which is appropriate for expected input and supports browser-level assistance.
- The Name field includes pattern="^(?!.*(www.|://)).*$", which may be intended to block URLs in a name input; this should be checked carefully to ensure it does not reject legitimate personal names containing uncommon but valid punctuation or text patterns.
- The audit detected format-rejection behavior on the Email field, so it would be prudent to confirm that valid edge-case email formats are still accepted.
The overall experience was good enough for the agent to complete the audit flow up to the final legal-consent boundary, but not polished enough to be considered highly optimized. Validation worked, yet the combination of ARIA concerns and somewhat uneven email error treatment creates avoidable friction.
- The agent was able to identify fields, enter data, and trigger validation in only a few steps, which indicates low structural friction.
- No blocking anti-automation measures such as CAPTCHA or bot detection were encountered.
- The audit detected both inline validation and ARIA-related issues, meaning the form is visually functional but may be less robust for assistive technology users.
- The process ended at the required terms checkbox and final submit action due to audit policy, not because the form was broken.
Recommendations
Link the Email error message to the Email field with accessible error attributes
For the Email field (id="email", name="email"), ensure the visible inline error text is programmatically associated using aria-describedby and set aria-invalid="true" when validation fails. If the error text is dynamically inserted, expose it through an aria-live region so screen readers announce the change when the user submits or leaves the field.
Make the empty Email error more explicitly corrective
Revise the empty-state validation for the Email field so the message directly tells the user what to do, not just why the address is needed. For example, replace descriptive copy like "We need your email to send you the password link and set up your login details." with a clearer action-oriented error such as "Enter your email address." while keeping any explanatory helper text separate from the error.
Keep Email validation permissive beyond basic type="email" checks
Review the Email field (type="email", id="email") to make sure validation accepts the broad range of valid real-world email addresses and does not layer stricter custom rules on top of native validation unless absolutely necessary. This reduces false rejections and improves completion for both users and agents.
Verify the Name field pattern does not reject legitimate names
The Name field (id="name", name="name") currently uses pattern="^(?!.*(www.|://)).*$" to block URL-like strings. Test this rule against legitimate names with punctuation, accents, apostrophes, hyphens, and other common variations to ensure the anti-URL pattern is not overly broad. If the pattern causes false negatives, replace it with server-side abuse checks instead of restrictive client-side blocking.
Add explicit error-state styling and semantics to the required terms checkbox
For the terms-and-policy-checkbox field (id="termsandpolicycheckbox"), make sure any validation failure is announced accessibly and tied to the checkbox with descriptive text. Required checkboxes are often visually clear but under-exposed to assistive technology unless the error text is linked and the invalid state is conveyed programmatically.
Keep helper copy separate from validation copy on the Email field
If the Email field currently reuses helper text as an error by simply changing its color, split these into two distinct elements: one persistent helper description and one conditional error message. This improves clarity, reduces ambiguity, and makes it easier to wire the correct text to aria-describedby depending on the field state.
Preserve the existing autocomplete tokens on Name, Email, and Company
Retain the current autocomplete values already present on the core fields: Name has autocomplete="name", Email has autocomplete="email", and Company has autocomplete="organization". These are good implementations and should be kept consistent if the form is refactored, because they materially help browser autofill, accessibility tooling, and AI agents.