- From: Michael Aufreiter <notifications@github.com>
- Date: Thu, 10 Sep 2026 07:54:24 -0700
- To: w3c/editing <editing@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/editing/issues/545/5620678418@github.com>
michael left a comment (w3c/editing#545) W3C Editing Group Meetup August 13 2026: > Wenson explained that there is currently no way for web content to suppress the input accessory view. While native apps have more flexibility in this area, simply allowing web developers to hide the accessory view could result in situations where the keyboard becomes impossible to dismiss. > > Several possible approaches were discussed: > Allow developers to opt into suppressing the input accessory view while ensuring that the keyboard can still be dismissed, for example through an interactive swipe gesture. > > However, such gestures could potentially conflict with other page or application gestures. > > Explore a more declarative approach, where the page identifies a control that dismisses the keyboard. If such a control is present, and there is no need for previous/next navigation between form fields, the browser could potentially hide the input accessory view automatically. > > Consider whether the accessory controls could feel more closely integrated with the keyboard rather than appearing visually detached from it. > > Michael noted that the ideal solution would require minimal application-level customization and simply reclaim the space when the standard form navigation controls are unnecessary. > > Next steps > Wenson will discuss the ideas with the Safari team and explore possible approaches. > -- Reply to this email directly or view it on GitHub: https://github.com/w3c/editing/issues/545#issuecomment-5620678418 You are receiving this because you are subscribed to this thread. Message ID: <w3c/editing/issues/545/5620678418@github.com>
Received on Thursday, 10 September 2026 14:54:29 UTC