Stop chat bubbles and sticky bars from blocking a mobile quote request

Reproduce the smallest screen conflict

Open the published form on a phone with normal widgets enabled. Tap a lower field so the on-screen keyboard appears, then try to reach its helper text and the Submit button. Record the screen orientation and overlay state. A chat bubble that looks harmless above the fold can cover a field when the keyboard reduces the visible area.

Check coverage and target usability separately

W3C focus guidance addresses controls entirely hidden by author-created content, while target-size guidance concerns usable activation areas. Both matter here. Identify whether the visitor cannot see the focused control, cannot tap it or cannot dismiss the overlay. These are related but distinct problems that may require different supported component settings.

Source checks: W3C: Understanding Focus Not Obscured (Minimum) · W3C: Understanding Target Size (Minimum) · Wix Forms: Troubleshooting

Test typing, errors and submission with overlays present

Test the ordinary customer states rather than disabling all widgets before testing. Include a cookie notice that has not been dismissed, an open chat panel and a validation error near the bottom. Ask the maintainer to record the overlay's placement rules and make the smallest supported adjustment that keeps the contact task usable.

• Reproduce the issue on the published mobile page with the same widgets visible.
• Open the keyboard, enter sample text and inspect the currently focused field.
• Attempt error correction and submission while checking for covered controls.
• Adjust the responsible overlay's placement, dismissal or reserved layout space.
• Repeat the same test and check another narrow-screen state for new overlap.

Avoid replacing one blocked control with another

Do not simply shrink buttons until everything appears to fit. Small tightly packed targets can create a different usability problem. Hiding the chat launcher might help one page but break the intended contact option elsewhere. Avoid a repair that requires every customer to discover an undocumented gesture or rotate the phone just to submit.

Keep a device-specific repair record

Record the device, visible viewport state and control that was blocked. Keep before-and-after test outcomes, including whether the widget is open or closed. A repair passes when the relevant controls are visible and usable in the tested states. It does not certify the whole site or prove a numerical conversion gain.

Review overlays whenever the form changes

Include overlay behavior in the form's maintenance checklist. Retest after adding a sticky promotion, new consent component or chat tool. Give the owner a screenshot or short description of the repaired state and an accessible alternate contact route. Avoid assuming third-party widget updates will always preserve the existing spacing.

Worked example: an illustrative customer journey

For example, a mobile estimate form has a sticky call bar and chat bubble. When a visitor opens the keyboard for the last field, the bubble covers the error message and part of Submit. A maintainer changes the widget placement and reserves enough room for the form action.

The marked test can now correct the error and submit without closing the entire browser. The same phone is tested with the cookie notice present. This checks specific layout states, not all devices or the complete accessibility of each third-party widget.

Questions about this task