External Sharepoint site's text inputs inaccessible on iPhone and iPad

SharePoint

iPhone

iPad

accessibility

mobile-issues

External Sharepoint site's text inputs inaccessible on iPhone and iPad

Master System Design with Codemia

Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.

Start Practicing Learn More

Introduction

When text inputs stop responding on an iPhone or iPad, the issue is rarely the HTML input element by itself. On external SharePoint sites, the real cause is usually a page-level interaction problem such as an overlay, a custom script that blocks touch events, or markup that behaves differently once Safari handles focus and the on-screen keyboard.

Why Inputs Become Untouchable on iOS

SharePoint pages often combine platform markup, custom branding, injected scripts, authentication components, and third-party widgets. That combination can work on desktop browsers and still fail on iOS because mobile Safari is stricter about focus, zoom, and touch handling.

The most common causes are:

an invisible overlay or spinner sitting above the form field
a touchstart or click handler that calls preventDefault() too aggressively
a fixed-position header or panel covering the input after viewport changes
an iframe or authentication prompt intercepting focus
custom CSS that makes the field look enabled while another element actually owns the tap target

The key debugging idea is simple: if the keyboard does not appear, the browser probably never delivered focus to the input.

A Minimal Reproduction and Fix

The HTML below shows a common failure pattern. A transparent overlay is placed above the form while a page is "loading". If that overlay remains active, taps never reach the input on iPhone or iPad.

html

1<!doctype html>
2<html lang="en">
3  <head>
4    <meta name="viewport" content="width=device-width, initial-scale=1">
5    <style>
6      .form-shell {
7        position: relative;
8        width: 320px;
9        margin: 2rem auto;
10      }
11
12      input {
13        width: 100%;
14        padding: 0.75rem;
15        font-size: 16px;
16      }
17
18      .overlay {
19        position: absolute;
20        inset: 0;
21        background: transparent;
22        pointer-events: auto;
23      }
24
25      .overlay.hidden {
26        pointer-events: none;
27      }
28    </style>
29  </head>
30  <body>
31    <div class="form-shell">
32      <input id="email" type="email" placeholder="[email protected]">
33      <div class="overlay hidden"></div>
34    </div>
35  </body>
36</html>

The fix is not SharePoint-specific: make sure any inactive overlay has pointer-events: none, or remove it from the document entirely. On complex SharePoint pages, the blocking element may come from a custom dialog, a branding layer, or a script that forgot to clean up after an async operation.

How to Debug It on a Real SharePoint Page

Start by reproducing the problem in Safari on iOS, because Chrome and Edge on iPhone still use the same browser engine underneath. Then inspect the page with Safari Web Inspector from a Mac if you can. Look for the element directly above the broken input and verify whether the field is actually receiving focus.

If the input is present but untouchable, check custom scripts first. Event handlers written for desktop often assume mouse behavior and accidentally suppress tap-to-focus on iOS. A simplified example looks like this:

javascript

1const formWrapper = document.querySelector(".form-wrapper");
2
3formWrapper.addEventListener("touchstart", event => {
4  if (event.target.matches("button")) {
5    return;
6  }
7
8  event.preventDefault();
9});

That pattern can block scrolling glitches, but it can also stop inputs from opening the keyboard. A safer fix is to narrow the handler to the exact element that needs it, or remove preventDefault() unless it is absolutely required.

In SharePoint specifically, also check whether a custom master page, injected web part, or external widget changed the mobile layout. Many "SharePoint input" bugs are really page customizations colliding with iOS behavior.

Common Pitfalls

Blaming SharePoint itself before checking overlays, third-party scripts, and custom branding layers.
Testing only in desktop emulation. The iOS keyboard and focus model need real-device verification.
Using broad preventDefault() handlers on containers that also hold form fields.
Forgetting that Chrome on iPhone uses the same WebKit engine as Safari, so switching browsers often does not change the result.
Ignoring fixed headers or panels that shift after the keyboard opens and end up covering the actual tap target.

Summary

Untouchable inputs on iPhone and iPad are usually caused by focus being intercepted, not by the input element itself.
On SharePoint pages, invisible overlays and broad touch handlers are common causes.
Debug on a real iOS device and inspect whether the field actually receives focus.
Remove inactive overlays or disable their pointer events so taps can reach the form control.
Review custom SharePoint branding and injected scripts before assuming the platform is at fault.