# Autofocus on the First Form Field A/B Test Example

Page: https://alidemirbas.com.tr/en/lab/ab-test-library/tests/autofocus-on-the-first-form-field-ab-test-example

## Hypothesis

If the first field takes focus once the form is ready, visitors can start typing without clicking into it first. The form start rate, measured by intentional input, could rise as a result, while a mobile keyboard or scroll that appears unexpectedly could reverse the effect.

## When to run this test

Autofocus is worth trying on a page where the form is the main task and is visible right away, especially when session recordings show visitors clicking into the field before typing, many visitors leave without entering anything, or visitors take a long time to start on the first field. More visitors in the variant should then enter data in the first field on their own, without a rise in the page exit rate. A form in the middle or at the bottom of the page, or one that visitors need to read an explanation for first, is a poor fit for this test; review the form's position and copy instead.

## Primary metric

**Form start rate**: Count intentional user input; exclude programmatic focus and autofill events.

## Other metrics

- **Form completion rate**: Compare successful submissions among assigned visitors who see the form.
- **Page exit rate**: Compare exits after automatic focus among the same eligible visitors.
- **Form focus loss rate**: Check whether focus unexpectedly leaves the form or page, using the same event tracking in both arms.

## What to check before and during the test

- **Focus**: In the variant, focus the first field once the page is ready, only if the form is visible.
- **Keep constant**: Keep form position, field size, copy and validation unchanged.
- **Scrolling**: Record whether focus skips explanatory copy or causes unexpected scrolling.
- **Keyboard**: Check the mobile keyboard and the usable portion of the form.
- **Accessibility**: Verify that keyboard order and screen-reader focus follow the expected sequence.

## What to watch when reading the result

- Do not count focus events as form starts, because the variant creates them itself. When the form start rate based on intentional input rises but the form completion rate stays flat or the page exit rate goes up, there is no case for shipping the variant.
- Read the result separately by device and operating system; a desktop gain says nothing about what happens when a keyboard opens on mobile. Do not turn on mobile autofocus until you have tested it on real devices.
- For a form inside a modal, check that the close button stays in the focus order. Otherwise visitors may struggle to leave the modal, and the exit and focus loss data become misleading.
- If eligibility depends on the moment the form becomes visible, a trigger that behaves differently in one arm can skew the split, so check that visitor counts in the two arms match the planned ratio. If the split is balanced, see whether the form start gap clears chance with the [A/B test significance calculator](https://alidemirbas.com.tr/en/calculators/ab-test). A difference that stays small means this traffic was not enough to detect the effect of autofocus on form starts; record it that way.

## Frequently Asked Questions

### Do more focus events mean more form starts?

No. Programmatic focus is not intentional input. Count meaningful entry, including user-initiated autofill, consistently in both arms. Separate automatic page filling from user action.

### Can autofocus on a mid-page form cause problems?

Yes. It can move users past explanatory content. Restrict it to the intended visible form and monitor unexpected scrolling and abandonment.

### Can a desktop autofocus result be applied to mobile?

Test actual iOS and Android behavior separately. Page-load focus may not open the iOS keyboard. Check focus loss, keyboard behavior and navigation on real devices.